Le piège des impressions ClickType Google Ads

Les tables stats de Google Ads DTS gonflent silencieusement les comptages d’impressions — parfois d’un facteur six — sauf si un filtre sur le type de clic est appliqué. Le problème n’apparaît pas comme une erreur ; les requêtes s’exécutent normalement et les tableaux de bord affichent des chiffres erronés.

Ce qui se passe

Les tables stats dans Google Ads DTS contiennent une colonne segments_click_type. Cette colonne segmente chaque ligne par le type d’interaction survenue : clic sur le titre, clic sur le lien site, appel téléphonique, clic pour directions vers un magasin, clic URL, et ainsi de suite.

Le piège est que les impressions sont répétées pour chaque type de clic. Quand une annonce est affichée et génère des données pour trois types de clics différents, cette impression apparaît trois fois dans la table — une fois par ligne de type de clic. Si vous additionnez les impressions sans tenir compte de cela, vous comptez la même impression plusieurs fois.

En pratique, les comptages d’impressions dans DTS peuvent être 3 à 6 fois supérieurs à la réalité. Interroger la table stats brute sans ce filtre produit des comptages d’impressions qui ne correspondent pas à l’interface Google Ads.

Ce n’est pas un cas particulier. Chaque campagne avec plusieurs types d’interactions — ce qui représente la plupart des campagnes — aura cette duplication. Cela affecte chaque table de la famille *Stats* : CampaignBasicStats, AdGroupStats, KeywordStats, et plus encore.

Le correctif pour les impressions

Filtrez sur le type de clic URL_CLICKS lors de l’addition des impressions :

WHERE segments_click_type = 'URL_CLICKS'

La ligne URL_CLICKS représente le comptage d’impressions canonique pour chaque date et entité. Elle capture l’impression associée à l’interaction de clic URL primaire, ce qui correspond à ce que l’interface Google Ads affiche.

Le piège : les clics nécessitent un traitement différent

N’appliquez pas le même filtre aux clics. Filtrer les clics par un seul type de clic vous donnerait uniquement le sous-ensemble de clics de ce type d’interaction, déflant votre comptage de clics exactement comme le comptage d’impressions non filtré était gonflé.

L’approche correcte est asymétrique : filtrez les impressions sur URL_CLICKS, mais additionnez les clics sur toutes les lignes (ou utilisez une somme conditionnelle) :

SELECT
  campaign_id,
  -- Impressions : filtrer sur URL_CLICKS pour éviter la duplication
  SUM(CASE WHEN segments_click_type = 'URL_CLICKS'
      THEN metrics_impressions ELSE 0 END) AS impressions,
  -- Clics : additionner sur tous les types de clics
  SUM(metrics_clicks) AS clicks,
  -- Coût : aussi additionner sur tous les types de clics
  SUM(metrics_cost_micros) / 1000000 AS cost
FROM `project.dataset.p_CampaignBasicStats_CUSTOMERID`
WHERE _DATA_DATE BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
GROUP BY campaign_id

Cette asymétrie est suffisamment déroutante pour piéger des ingénieurs expérimentés. L’instinct est d’appliquer un filtre cohérent à toutes les métriques, mais les impressions et les clics ont des sémantiques différentes dans le modèle de données DTS. Les impressions sont répliquées sur les types de clics ; les clics sont segmentés par type de clic. Le correctif pour l’un casserait l’autre.

Pourquoi URL_CLICKS spécifiquement

Le type de clic URL_CLICKS représente les clics sur l’URL finale de l’annonce — la destination principale que vous avez configurée. Les autres types de clics (clics sur liens de site, clics sur bouton d’appel, clics pour directions, etc.) représentent des interactions supplémentaires.

L’interface Google Ads rapporte les impressions au niveau campagne/groupe d’annonces/mot-clé sans segmentation par type de clic — elle affiche un seul comptage d’impressions quel que soit le nombre de types de clics déclenchés. Le filtre URL_CLICKS reproduit ce comportement en sélectionnant la ligne qui représente l’affichage de l’annonce, pas les lignes d’interactions supplémentaires.

Vous pouvez vérifier que cela fonctionne en comparant vos résultats de requête avec l’interface Google Ads sur une période récente de 7 jours. Avec le filtre appliqué, les chiffres devraient s’aligner dans la plage de variance attendue (voir Ad Platform Metric Divergence pour expliquer pourquoi un certain écart est normal).

Dans un modèle dbt

Ce filtre appartient à votre modèle de base ou intermédiaire pour les stats de campagne — pas dispersé dans des requêtes ad hoc. Placez-le une fois dans la couche de transformation pour que chaque modèle en aval hérite du comportement correct :

-- models/base/google_ads/base__google_ads__campaign_stats.sql
SELECT
  _DATA_DATE AS date_day,
  campaign_id,
  SUM(CASE WHEN segments_click_type = 'URL_CLICKS'
      THEN metrics_impressions ELSE 0 END) AS impressions,
  SUM(metrics_clicks) AS clicks,
  SUM(metrics_interactions) AS interactions,
  SUM(metrics_cost_micros) / 1000000 AS cost,
  SUM(metrics_conversions) AS conversions,
  SUM(metrics_conversions_value) AS conversions_value
FROM `{{ source('google_ads', 'p_CampaignBasicStats_CUSTOMERID') }}`
WHERE _DATA_DATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY 1, 2

Ce modèle gère à la fois le piège ClickType (via la somme conditionnelle des impressions) et la conversion des micros (division du coût par 1 000 000) en un seul endroit. Chaque modèle mart référençant les stats de campagne peut joindre ce modèle de base sans se préoccuper de l’un ou l’autre problème.

Le pattern plus large

Le piège ClickType est une instance spécifique d’un pattern plus large dans les données Google Ads : l’API (et DTS) retourne des données segmentées par défaut, et agréger des données segmentées sans comprendre la logique de segmentation produit des résultats erronés. La même prudence s’applique chaque fois que vous voyez une colonne segments_* dans une table stats — comprenez ce qu’elle segmente avant d’additionner.

C’est documenté dans la propre documentation de schéma de Google, mais d’une manière facile à manquer si vous interrogez les données de manière empirique plutôt que de lire d’abord la spécification du schéma. La plupart des équipes le découvrent à la dure, généralement quand un chiffre sur un tableau de bord ne correspond pas à une vérification manuelle dans l’interface Google Ads.

Tout reporting Google Ads basé sur DTS qui n’applique pas ce filtre produira des comptages d’impressions gonflés.