Patterns de tests pour les modèles publicitaires cross-platform

Tester les modèles publicitaires cross-platform requiert une attention particulière parce que les modes d’échec sont distincts : les connecteurs de plateformes peuvent devenir obsolètes indépendamment, la normalisation intermédiaire peut se casser pour une plateforme tandis que les autres semblent correctes, et les différences de fuseaux horaires créent des variances que vous devez distinguer des véritables bugs.

Fraîcheur des sources

Les tests de fraîcheur des sources sont votre première ligne de défense. Chaque connecteur de plateforme a des caractéristiques de latence différentes, et vous voulez savoir quand les données cessent d’arriver avant que les parties prenantes ne remarquent des tableaux de bord vides.

sources:
  - name: google_ads
    freshness:
      warn_after: {count: 24, period: hour}
      error_after: {count: 48, period: hour}
    loaded_at_field: _fivetran_synced
  - name: facebook_ads
    freshness:
      warn_after: {count: 24, period: hour}
      error_after: {count: 48, period: hour}
    loaded_at_field: _fivetran_synced
  - name: linkedin_ads
    freshness:
      warn_after: {count: 24, period: hour}
      error_after: {count: 48, period: hour}
    loaded_at_field: _fivetran_synced

Le seuil d’avertissement à 24 heures / d’erreur à 48 heures fonctionne bien comme point de départ. Certaines plateformes se mettent à jour plus fréquemment que d’autres — les données Google Ads arrivent typiquement en quelques heures, tandis que LinkedIn peut accuser un retard d’une journée entière. Resserrez les seuils par plateforme à mesure que vous apprenez le comportement réel de vos connecteurs.

Exécutez dbt source freshness comme étape séparée avant votre dbt run principal. Si une source est obsolète, vous voulez le savoir avant de reconstruire des modèles sur des données incomplètes. Certaines équipes configurent ceci comme un circuit breaker : si une source publicitaire échoue à la vérification de fraîcheur, ignorez entièrement les modèles de reporting publicitaire plutôt que de produire des résultats partiels.

Réconciliation des dépenses

La réconciliation des dépenses est le test de plus haute priorité pour les modèles publicitaires cross-platform. Le total des dépenses unifiées doit correspondre à la somme des dépenses des plateformes individuelles, et toute variance significative signale un bug de transformation.

models:
  - name: mrt__marketing__campaign_report
    tests:
      - dbt_utils.unique_combination_of_columns:
          combination_of_columns:
            - date_day
            - platform
            - campaign__id
    columns:
      - name: campaign__spend
        tests:
          - not_null
          - dbt_expectations.expect_column_values_to_be_between:
              min_value: 0
              max_value: 1000000

Le test unique_combination_of_columns capture un mode d’échec spécifique : des lignes dupliquées après une mauvaise JOIN ou une déduplication incomplète dans la couche intermédiaire. Si la même campagne le même jour apparaît deux fois, les dépenses sont comptées en double. Ce test le détecte immédiatement.

Pour la validation spécifique aux dépenses, un test singulier qui compare le total unifié à la somme des totaux par plateforme est inestimable :

-- tests/assert_unified_spend_reconciles.sql
WITH unified AS (
    SELECT SUM(campaign__spend) AS total_spend
    FROM {{ ref('mrt__marketing__campaign_report') }}
    WHERE date_day >= CURRENT_DATE() - 7
),
platform_sum AS (
    SELECT SUM(campaign__spend) AS total_spend
    FROM (
        SELECT campaign__spend FROM {{ ref('int__google_ads__campaign_report') }}
        WHERE date_day >= CURRENT_DATE() - 7
        UNION ALL
        SELECT campaign__spend FROM {{ ref('int__facebook_ads__campaign_report') }}
        WHERE date_day >= CURRENT_DATE() - 7
        UNION ALL
        SELECT campaign__spend FROM {{ ref('int__linkedin_ads__campaign_report') }}
        WHERE date_day >= CURRENT_DATE() - 7
    )
)
SELECT
    unified.total_spend AS unified_total,
    platform_sum.total_spend AS platform_total,
    ABS(unified.total_spend - platform_sum.total_spend) AS difference
FROM unified
CROSS JOIN platform_sum
WHERE ABS(unified.total_spend - platform_sum.total_spend) / NULLIF(platform_sum.total_spend, 0) > 0.03

Le seuil de 3 % tient compte des différences de fuseaux horaires. Le DECISIONLOG de dbt_ad_reporting de Fivetran documente cela comme une variance attendue. Tout ce qui dépasse 3 % signale un bug de pipeline qui mérite investigation.

Tests de granularité

Les violations de granularité sont le bug de transformation le plus courant dans les modèles cross-platform. Une mauvaise JOIN dans la couche intermédiaire peut silencieusement faire exploser les lignes, doublant ou triplant les dépenses pour une plateforme tandis que les autres semblent correctes.

Appliquez dbt_utils.unique_combination_of_columns à chaque modèle unifié sur les colonnes date, plateforme et ID d’entité :

models:
  - name: mrt__marketing__campaign_report
    tests:
      - dbt_utils.unique_combination_of_columns:
          combination_of_columns:
            - date_day
            - platform
            - campaign__id

  - name: mrt__marketing__ad_group_report
    tests:
      - dbt_utils.unique_combination_of_columns:
          combination_of_columns:
            - date_day
            - platform
            - ad_group__id

  - name: mrt__marketing__ad_report
    tests:
      - dbt_utils.unique_combination_of_columns:
          combination_of_columns:
            - date_day
            - platform
            - ad__id

Ces tests doivent s’exécuter en CI et à chaque run dbt de production.

Détection d’anomalies statistiques

Le package dbt-expectations ajoute une détection d’anomalies statistiques qui détecte les problèmes que les tests structurels automatisés manquent. Des pics de dépenses, des chutes d’impressions ou des patterns de conversion qui sortent des normes historiques peuvent signaler :

• Un connecteur qui a commencé à extraire des données dupliquées
• Un changement d’API de plateforme qui a modifié la façon dont une métrique est reportée
• Une campagne qui a été mise en pause ou lancée sans que l’équipe data en soit consciente

columns:
  - name: campaign__spend
    tests:
      - dbt_expectations.expect_column_values_to_be_between:
          min_value: 0
          max_value: 1000000
      - dbt_expectations.expect_column_mean_to_be_between:
          min_value: 10
          max_value: 50000
          group_by: [platform]

Ces tests créent des garde-fous autour du comportement “normal”. Ils ne détecteront pas tous les problèmes, mais ils détecteront les problèmes dramatiques — une colonne de dépenses soudainement 6 ordres de grandeur trop élevée parce que quelqu’un a oublié la division de Google des micro-unités en devise, par exemple.

Réconciliation manuelle

Les tests automatisés détectent les problèmes structurels. La réconciliation manuelle hebdomadaire des totaux de dépenses du warehouse avec les interfaces des plateformes détecte les problèmes subtils.

Choisissez une fenêtre de 7 jours récente, tirez le total des dépenses du tableau de bord natif de chaque plateforme, et comparez-le avec votre warehouse. Documentez la variance pour chaque plateforme et investiguez tout ce qui dépasse la plage attendue de 1-3 %.

Un cas reporté d’une fintech de 500 personnes : leur calcul de CLTV s’est cassé à cause d’un problème de source de données tiers, les faisant perdre une partie des 100 000 GBP qu’ils avaient dépensés sur Google ce jour-là, plus plusieurs jours de recalibrage. Les tests automatisés ne l’ont pas détecté parce que l’intégrité structurelle des données était correcte — les chiffres étaient valides mais incorrects.

Résumé d’une stratégie de tests

Pour le reporting publicitaire, les dépenses sont la métrique principale à protéger, suivies de l’exactitude des conversions, puis des comptages d’impressions et de clics.