Le guide du tracking Google Ads

La plupart des comptes que je récupère ont le même problème, et ce n'est jamais celui qu'on m'annonce. On me parle de structure, d'enchères, de mots clés. Puis j'ouvre le tracking, et je découvre que le compte prend ses décisions sur une donnée trouée. Ce guide corrige ça, dans l'ordre.

Chapitre 1Combien tu perds, et pourquoi

Entre 15 et 30% des conversions se perdent avant même d'arriver dans ton compte Google Ads. Ce n'est pas une estimation pessimiste, c'est la fourchette constatée sur les comptes ecommerce en Europe, et elle monte encore sur les comptes à fort trafic mobile.

Les quatre causes, dans l'ordre d'importance

• Les bloqueurs de publicité. Ils coupent les requêtes sortantes du navigateur vers les domaines des régies. Le tag se charge, la requête part, elle n'arrive jamais.
• L'ITP de Safari. Le mécanisme anti pistage d'Apple plafonne la durée de vie des cookies first-party posés en JavaScript, autour de 7 jours. Un visiteur qui revient au-delà est un inconnu.
• La navigation privée. Tout est effacé à la fermeture de l'onglet. Le parcours en deux visites devient deux visiteurs.
• Les bandeaux de consentement. Sans configuration correcte, un refus ne dégrade pas la mesure, il la supprime.

Ces quatre causes ont un point commun : elles agissent toutes dans le navigateur. C'est pour ça que la réponse technique se joue en dehors du navigateur, et c'est tout le sujet du chapitre 3.

Le vrai coût n'est pas ton dashboard

Quand on découvre ces pertes, le premier réflexe est de dire : mes chiffres sont sous-estimés, mon vrai ROAS est meilleur, tant mieux. C'est une erreur d'analyse. Le problème n'est pas ce que TU lis, c'est ce que l'ALGORITHME apprend.

Le Smart Bidding s'entraîne sur les conversions que tu lui remontes. Si 25% des ventes manquent, et surtout si elles manquent de façon non aléatoire (plutôt sur Safari, plutôt sur mobile, plutôt sur les parcours longs), alors l'algorithme apprend une version déformée de ta réalité. Il va sous-enchérir sur les segments qui convertissent mal EN APPARENCE, et sur-enchérir ailleurs. Tu ne pilotes pas avec un compteur imprécis, tu pilotes avec un compteur biaisé.

Sources : documentation ITP et first-party cookies, guides ssGTM (Stape, Kukie), cas d'audit publics.

Chapitre 2Les 7 briques du stack

Un tracking ecommerce complet tient en sept briques. Elles ne se valent pas toutes, et surtout elles ne se posent pas dans n'importe quel ordre.

L'ordre de pose

1. Fiabiliser d'abord l'événement d'achat lui-même. Sur Shopify, les évolutions du checkout cassent régulièrement les anciens scripts : c'est le premier endroit à vérifier.
2. Poser le CMP et les valeurs par défaut du Consent Mode avant le chargement des tags. Cet ordre n'est pas négociable, il conditionne tout le reste.
3. Construire un dataLayer d'achat propre : identifiant de transaction, devise, produits, et la valeur (voir chapitre 7).
4. Activer les Enhanced Conversions.
5. Passer au server-side.

Le sens de cet ordre : chaque brique suppose que la précédente est saine. Poser du server-side sur un événement d'achat qui se déclenche deux fois, c'est industrialiser une erreur.

Chapitre 3Le server-side GTM, expliqué de zéro

Ce que fait le GTM classique

Le Google Tag Manager que tout le monde connaît tourne dans le navigateur du visiteur. Chaque tag (GA4, Google Ads, pixel Meta) envoie ses propres requêtes, depuis le navigateur, vers les domaines des régies. C'est exactement la surface que les bloqueurs, l'ITP et la navigation privée attaquent.

Ce que fait le server-side

Le server-side ajoute un conteneur qui tourne sur un serveur que tu contrôles, joignable sur ton propre sous-domaine (par exemple data.tondomaine.com). Le navigateur envoie un flux unique vers ce sous-domaine. Ton conteneur reçoit l'événement, le filtre, l'enrichit si besoin, puis le transmet à GA4, Google Ads, Meta.

Deux gains, et il faut bien les distinguer. Le premier est la résilience : une requête vers ton propre domaine n'est pas traitée comme une requête tierce. Le second est le contrôle : tu décides ce qui sort, vers qui, avec quels champs. Tu passes d'un modèle où chaque régie se sert dans le navigateur à un modèle où tu possèdes le tuyau.

L'ordre exact des tags dans le conteneur serveur

1. Conversion Linker (dans le conteneur serveur, pas seulement le web). C'est lui qui capte et conserve l'identifiant de clic. Sans lui, le rattachement de la vente au clic publicitaire est perdu.
2. Tag de remarketing Google Ads, avec ton identifiant de conversion.
3. Tag de conversion d'achat : identifiant de conversion + libellé, créés côté Google Ads en choisissant la méthode manuelle avec code.
4. Données fournies par l'utilisateur attachées au tag de conversion : c'est la version serveur des Enhanced Conversions (chapitre 4).

La conversion d'achat reste la conversion primaire et unique, avec des valeurs différentes par commande. Les micro-conversions (ajout au panier, début de paiement, contact) restent secondaires.

Les six pièges documentés

• Laisser en production la valeur de démonstration codée en dur (le fameux 1$ des tutoriels).
• Poser les tags Ads avant que les événements GA4 arrivent côté serveur.
• Oublier le Conversion Linker : l'identifiant de clic n'est jamais réclamé.
• Avoir un Conversion Linker uniquement côté navigateur tout en affirmant faire du server-side.
• Rester sur l'hébergement par défaut sans domaine personnalisé : tu perds le bénéfice cookie, qui est la moitié de l'intérêt.
• Ne pas vérifier en mode Preview que le Linker a bien réclamé la requête.

Sources : documentation Stape, MeasureSchool, MeasureU, Analytics Mania (Shopify), Google Developers.

Chapitre 4Les Enhanced Conversions

Quand le cookie du clic a disparu, Google ne peut plus relier la vente à la publicité. Les Enhanced Conversions envoient, avec la conversion, une donnée client first-party hashée (email, téléphone, adresse). Google la compare à ses utilisateurs connectés et retrouve le lien.

Formulé simplement : tu dis à Google que cet achat appartient au hash de telle adresse email. Le Smart Bidding récupère un exemple d'entraînement qu'il aurait perdu.

Le déclencheur d'activation est simple : dès que tes taux de correspondance sont faibles, ou dès que tu constates un écart entre les commandes de ton back office et les conversions du compte, tu actives.

Chapitre 5Le Consent Mode v2

Il faut séparer deux choses que tout le monde confond. Le bandeau cookies (le CMP) est l'interface qui pose la question à l'utilisateur. Le Consent Mode est le langage de signal que les tags Google lisent pour savoir ce qu'ils ont le droit de faire. Le premier est visible, le second est la machine à états derrière.

Les deux derniers sont l'apport de la version 2, et ce sont eux qui conditionnent l'usage du remarketing et des listes clients sur le trafic européen.

Les deux points qui décident de tout

• Les valeurs par défaut se posent avant les tags. Si les tags se chargent avant de connaître l'état du consentement, tu casses à la fois la conformité et la modélisation.
• Mode Basic ou Advanced. En Basic, un refus signifie qu'aucun signal ne part. En Advanced, des signaux anonymisés partent et Google modélise les conversions manquantes. La différence de volume mesuré est significative, et c'est légal quand c'est correctement implémenté.

Chapitre 6L'import offline : apprendre à Google ce qu'est un bon client

Les tags voient ce qui se passe sur le site. Beaucoup d'entreprises encaissent ailleurs, ou plus tard : le commercial signe la semaine suivante, la commande est remboursée, le CRM qualifie un lead en opportunité puis en client. L'import de conversions offline renvoie ces résultats tardifs à Google Ads, rattachés à l'identifiant du clic d'origine.

Ce que ça change, chiffré

• Ecommerce, distributeur américain à gros budget. Le compte affichait un ROAS confortable, mais seulement 11% des ventes venaient de nouveaux clients : l'algorithme, laissé en maximisation de valeur, avait trouvé le chemin facile, revendre aux clients existants. Après branchement de la vérité CRM (vrais nouveaux clients, valeur enrichie de la durée de vie à 90 jours) et activation du mode acquisition, le coût par nouveau client est passé de 287$ à 94$.
• SaaS B2B français. Compte à l'abandon, coût par lead intenable. Le tracking a d'abord été repris pour séparer les leads qualifiés des curieux, puis les enchères ont visé la valeur du lead qualifié, pas le formulaire rempli. Résultat : équilibre atteint en 3 mois, rentabilité confirmée à 6 mois, coût par acquisition en baisse de plus de 30% et volume de leads qualifiés en hausse de 52%, à budget constant.
• Paiement B2B allemand, marché en déclin. Les signaux de qualité issus du CRM (étapes de qualification jusqu'à la signature) ont été importés dans les enchères, pour que l'algorithme optimise sur la qualité et non sur le volume de formulaires.