Une balise de conversion n’observe pas toujours toute la réalité. Un bloqueur, une restriction du navigateur ou une valeur finalisée après l’achat peut laisser Google Ads avec un événement absent, incomplet ou déjà obsolète. La réponse de Google consiste désormais à réunir la mesure Web et la donnée backend dans une seule action de conversion.
Search Engine Land a signalé le 21 septembre l’ouverture des imports hors ligne pour compléter les conversions issues des balises. La documentation Google sur les conversions multisources confirme qu’il s’agit d’une bêta, reliée à Data Manager ou à son API.
1. Ce que change la conversion multisource
Le CRM, l’outil de commande ou le système de réservation peut devenir une source supplémentaire de la conversion déjà suivie sur le site. Si la balise a manqué l’événement, l’import peut créer la conversion et tenter de la rattacher à une interaction publicitaire. Si l’événement existe, l’import peut compléter des données utilisateur manquantes ou remplacer sa valeur.
Le périmètre est plus étroit que le nom pourrait le laisser croire. Google indique que la connexion concerne actuellement les actions de conversion Web configurées manuellement avec la balise Google ou Google Tag Manager. Les conversions importées depuis Google Analytics et les actions fondées sur une URL ne sont pas éligibles.
À retenir
Ce dispositif n’additionne pas deux conversions. Il rapproche deux observations du même résultat business dans une action unique, à condition de partager une clé fiable.
2. Le transaction ID devient votre garde-fou
Le champ transaction_id — ou identifiant de commande — sert à faire correspondre la ligne backend avec l’événement envoyé par la balise. Son format et sa valeur doivent être identiques dans les deux flux. Google exige aussi la date et l’heure de conversion, puis au moins un identifiant d’attribution : GCLID, GBRAID, WBRAID ou donnée client adaptée.
La déduplication ne traverse pas tout le compte. Elle fonctionne entre la balise et la source supplémentaire dans la même action de conversion. Créer une seconde action puis inclure les deux dans les objectifs de campagne peut donc compter deux fois la même vente.
Vérifiez la chaîne avant Google Ads
Testez l’identifiant dès le navigateur, puis dans le backend et dans l’export final. Les espaces ajoutés, préfixes, troncatures et changements de casse peuvent empêcher la correspondance. Pour un lead, définissez aussi un identifiant stable qui survit aux changements de statut dans le CRM.
3. La source backend peut réécrire votre valeur
Lorsqu’un identifiant correspond, la valeur et la devise importées remplacent durablement celles de la balise. C’est utile pour intégrer un remboursement total, une vente additionnelle ou un panier finalisé. C’est aussi le principal risque : envoyer des centimes là où la balise envoie des euros peut gonfler brutalement la valeur suivie.
Décidez quel système possède la valeur de référence. Pour l’e-commerce, ce sera souvent la commande nette après annulation ou remboursement. Pour la génération de leads, ce peut être une valeur par étape commerciale, mais elle doit rester stable, documentée et cohérente avec l’objectif d’enchères.
Erreurs à éviter
- Créer une deuxième action primaire au lieu de compléter l’action existante.
- Utiliser des identifiants différents entre la balise et le backend.
- Mélanger euros et centimes, ou envoyer une devise incohérente.
- Importer un export d’analytics plutôt que le registre officiel des commandes ou du CRM.
- Laisser les consentements par défaut sans vérifier leur adéquation.
4. Construisez un flux officiel, rapide et consenti
La source supplémentaire doit représenter le registre complet et officiel des transactions, pas une copie d’un autre outil de mesure exposé aux mêmes pertes que la balise. Envoyez les événements aussi vite que possible : Google recommande idéalement un import dans les 24 heures pour améliorer la correspondance et la fraîcheur du signal d’enchères.
Chaque ligne doit porter les champs de consentement pertinents. Seuls les événements consentis peuvent compléter la conversion. Documentez aussi la gestion des corrections : valeur nulle lorsque rien ne doit être modifié, zéro uniquement pour un résultat réellement annulé, et historique des rejets ou doublons.
5. Utilisez la période d’essai comme un vrai contrôle
Une nouvelle connexion entre dans une période initiale de 14 jours. Pendant cette phase, les nouvelles conversions apparaissent dans le reporting mais ne sont pas utilisées pour les enchères ; les remplacements de valeur sont également suspendus. Ce délai est une fenêtre de validation, pas une attente passive.
Comparez le nombre de transactions backend, les événements de balise, les correspondances et les créations nettes. Segmentez par jour, devise et type de résultat. Recherchez les valeurs extrêmes, les identifiants absents et les décalages horaires. Après la phase d’essai, le signal devient automatiquement éligible aux enchères : une anomalie non traitée peut alors modifier les décisions de Smart Bidding.
6. Plan d’action en 48 heures
Plan d’action 24/48 h
- Inventoriez les actions de conversion primaires, leur source et les objectifs qui les utilisent.
- Choisissez une action Web éligible et désignez le CRM ou la base de commandes comme registre officiel.
- Contrôlez sur un échantillon le
transaction_id, l’horodatage, les identifiants publicitaires, la valeur, la devise et le consentement. - Connectez la source à l’action existante, puis consignez les alertes et rejets pendant les 14 jours d’essai.
- N’autorisez l’usage dans Smart Bidding qu’après rapprochement avec les ventes nettes et validation des unités.
Les conversions multisources peuvent rendre la mesure plus résistante et plus proche de la réalité financière. Le gain ne vient toutefois pas du simple branchement d’un CRM. Il vient d’une identité transactionnelle cohérente, d’une source de vérité explicite et d’un contrôle avant que la donnée corrigée ne pilote les enchères.