Conversions hors ligne : renvoyer à Google Ads ce que le CRM sait

Sommaire

Sur un compte orienté génération de contacts, la conversion déclarée à Google Ads est presque toujours l’envoi du formulaire. C’est la seule chose que la balise voit. Et c’est exactement ce que les stratégies d’enchères automatiques vont apprendre à produire : des envois de formulaire, au meilleur coût, quelle que soit la personne qui le remplit.

Le CRM, lui, sait trois semaines plus tard que tel contact était un étudiant, tel autre un concurrent, et que le troisième a signé. Cette information existe ; elle ne revient simplement jamais à la régie. L’import de conversions hors ligne est le canal qui la fait revenir.

Ce que l’enchère apprend quand elle ne voit que le formulaire

Une stratégie d’enchères optimise sur le signal qu’on lui donne, pas sur l’intention qu’on lui prête. Si toutes les demandes valent une conversion, la demande d’un étudiant qui prépare un mémoire vaut autant que celle d’un directeur commercial qui veut un devis cette semaine. Et la première est généralement moins chère à obtenir.

Le résultat est mécanique : le coût par contact baisse, le volume monte, et la vente constate que les contacts ne valent rien (la tension décrite dans l’article sur la qualification d’un lead). Le compte n’est pas mal réglé. Il fait précisément ce qu’on lui a demandé.

Le principe : un identifiant qui fait l’aller-retour

Le mécanisme tient en quatre temps. Un clic sur une annonce ajoute un identifiant à l’URL de la page d’arrivée. Le site le capte et le transmet avec le formulaire. Le CRM le stocke sur la fiche du contact. Quand le contact franchit une étape, on renvoie à Google Ads l’identifiant, le nom de l’étape, sa date et sa valeur.

Google Ads retrouve alors le clic d’origine et rattache la conversion à la campagne, au groupe d’annonces et au mot clé qui l’ont produite. Rien de tout cela ne passe par le navigateur au moment de la conversion : c’est ce qui distingue l’import de la balise, et ce qui le rend complémentaire d’une collecte côté serveur plutôt que concurrent.

Les trois identifiants de clic

Le plus connu est le GCLID, ajouté par le marquage automatique, qui doit donc être activé dans le compte. La documentation de Google en décrit deux autres, liés aux parcours iOS :

• GBRAID, présent quand un clic sur une annonce, sur le Web, mène vers une application iOS ;
• WBRAID, présent quand un clic sur une annonce, dans une application iOS, mène vers une page Web.

Pour un site de génération de contacts, la conséquence pratique est simple : le formulaire doit capter les trois, pas seulement le GCLID. Un contact arrivé avec un seul WBRAID et sans GCLID est invisible pour un dispositif qui n’attend que le second.

Capter et conserver

La procédure de Google décrit les trois pièces à poser, dans cet ordre :

1. Une lecture à l’arrivée : un script lit le paramètre dans l’URL et le conserve côté navigateur, parce que le visiteur ne remplit presque jamais le formulaire sur la page d’arrivée.
2. Un champ caché par identifiant dans chaque formulaire, rempli avec la valeur conservée au moment de l’envoi.
3. Un champ personnalisé dans le CRM, sur l’objet contact ou lead, qui reçoit la valeur et ne l’écrase jamais.

Un détail qui coûte cher quand on l’ignore : le GCLID est sensible à la casse. Une intégration qui le passe en minuscules, ou un tableur qui le reformate, produit des identifiants que Google ne reconnaîtra pas.

Ce point de capture est le même que celui de la source d’origine du contact, et il se perd pour les mêmes raisons : redirections, navigation sur plusieurs sessions, appels. Le sujet est traité pour lui-même dans l’article sur la source d’origine d’un contact.

Les conversions améliorées pour les leads

Google présente aujourd’hui les conversions améliorées pour les leads comme une version améliorée de l’import classique, et recommande de migrer vers elles. La différence porte sur la clé de rapprochement.

Au lieu de reposer uniquement sur l’identifiant de clic, le dispositif utilise une donnée fournie par l’utilisateur (l’adresse e-mail, le plus souvent), hachée. Au moment de l’envoi du formulaire, la balise Google transmet cette donnée hachée. Plus tard, quand le contact progresse, on importe la même donnée hachée avec l’étape franchie, et Google rapproche les deux.

Deux précisions issues de la documentation. Le GCLID reste recommandé dans les envois, « chaque fois que possible », pour la précision du rattachement. Et il redevient obligatoire si aucune balise ne collecte la donnée fournie par l’utilisateur sur le site.

Trois façons de faire remonter les données

Deux points de calendrier. Google qualifie désormais l’import de fichiers à l’ancien format de fonctionnalité legacy et oriente vers le Gestionnaire de données. Et l’aide Google Ads annonce qu’à partir du 15 juin 2026, les envois de conversions hors ligne et de conversions améliorées pour les leads migrent vers l’API Data Manager et sont bloqués dans l’API Google Ads pour les intégrations qui ne l’utilisaient pas déjà. Une intégration maison écrite avant cette date mérite donc d’être vérifiée.

Quel que soit le canal, la fréquence compte plus que la méthode. Google recommande, pour les stratégies d’enchères automatiques, un envoi au moins quotidien, ou à défaut à rythme régulier. Une remontée faite « quand quelqu’un y pense » produit un signal en dents de scie que l’algorithme interprète comme une variation de performance.

Quelles étapes remonter, et avec quelle valeur

La tentation est de ne renvoyer que la signature. C’est souvent une erreur, pour deux raisons : elle arrive tard, parfois au-delà des délais acceptés, et elle est trop rare pour qu’un algorithme en tire quelque chose.

La pratique qui fonctionne consiste à créer une action de conversion par étape, de source « Importation à partir de clics », et à n’en déclarer qu’une seule comme principale, celle qui sert aux enchères. Les autres restent secondaires : visibles dans les rapports, sans effet sur l’optimisation.

Le choix de l’étape principale obéit à deux contraintes contraires : plus elle est tardive, plus elle ressemble au chiffre d’affaires ; plus elle est précoce, plus elle est nombreuse et rapide. L’étape « accepté par la vente » est souvent le bon compromis, à condition que le critère d’acceptation soit écrit, sans quoi la conversion mesure l’humeur de la personne qui trie.

La valeur

Une valeur fixe par étape suffit pour commencer, et elle se calcule à partir de l’historique du CRM. Exemple de calcul hypothétique : si un client signé rapporte en moyenne 12 000 € de marge sur la première année, et qu’un lead qualifié sur quatre finit par signer, un lead qualifié vaut environ 3 000 € au moment où il est qualifié. C’est cette valeur espérée qu’on envoie, pas le montant d’un devis qui n’existe pas encore.

Les délais : fenêtre, ancienneté, traitement

Trois limites documentées se cumulent, et c’est leur combinaison qui décide de ce qui peut remonter.

• L’ancienneté du clic. La FAQ des imports hors ligne indique que Google ne conserve le GCLID que 90 jours : une conversion rattachée à un clic plus ancien est rejetée. Pour les envois fondés sur des données utilisateur, la même page indique 63 jours.
• La fenêtre de conversion de l’action. Elle se règle action par action, de 1 jour jusqu’à 30, 60 ou 90 jours selon la source de conversion, avec 30 jours par défaut. Une conversion hors de cette fenêtre est rejetée elle aussi.
• Le délai de traitement. Un clic de moins de six heures n’est pas encore exploitable ; Google indique un traitement habituellement inférieur à 12 heures, jusqu’à 72 heures pour les conversions rattachées à un GBRAID ou un WBRAID. Une action de conversion qui vient d’être créée demande 4 à 6 heures avant le premier envoi.

La règle pratique qui en découle : mesurez dans le CRM le délai entre la demande et chaque étape. Une étape dont le délai habituel dépasse la fenêtre ne peut pas être l’étape principale, et une partie de ses occurrences ne remontera jamais. C’est l’autre argument en faveur d’une étape intermédiaire.

Deux autres paramètres de l’envoi méritent attention. L’heure de conversion est celle du changement d’étape dans le CRM, avec son fuseau horaire explicite : une erreur de fuseau produit une conversion antérieure au clic, rejetée. Et Google dédoublonne sur le triplet identifiant, nom de la conversion et heure : renvoyer le même historique chaque jour est sans risque, à condition que l’heure ne change pas d’un envoi à l’autre.

Le consentement

L’import ne contourne pas le choix du visiteur. Le modèle de fichier comporte des colonnes de consentement, et la documentation de l’API recommande fortement de renseigner ce champ sur chaque conversion, faute de quoi elle risque de ne pas être attribuable. Ces valeurs reprennent les signaux ad_user_data et ad_personalization décrits dans l’article sur le mode Consentement de Google.

La conséquence est en amont : pour pouvoir les renvoyer, il faut avoir stocké l’état du consentement au moment de la demande, sur la fiche du contact, à côté de l’identifiant de clic. Un CRM qui ne le stocke pas oblige à envoyer un champ vide ou une valeur inventée, et aucune des deux n’est défendable.

Contrôler la qualité

Un import qui tombe en panne ne lève aucune erreur visible dans les campagnes : les conversions cessent simplement d’arriver, et les enchères s’ajustent à un signal qui a disparu. Trois contrôles, à inscrire dans la routine hebdomadaire.

1. Les diagnostics de données hors ligne. Depuis le récapitulatif des conversions, l’état de l’action mène à une page de diagnostic qui note la qualité des données importées, liste les alertes par type d’erreur et retrace les sept derniers jours ou les sept derniers envois.
2. Les erreurs par ligne. Pour un import de fichier, la page des importations permet de télécharger les lignes rejetées avec leur motif : identifiant trop ancien, heure antérieure au clic, donnée non hachée, action de conversion introuvable.
3. Le rapprochement avec le CRM. Le nombre de leads qualifiés du mois portant un identifiant de clic, comparé au nombre de conversions lead_qualifie reçues, colonne « par heure de conversion ». L’écart ne sera jamais nul ; c’est sa stabilité qui compte, comme pour les autres écarts entre outils.

Le troisième contrôle est le seul qui détecte une panne en amont : un formulaire refait qui a perdu son champ caché ne produit aucune erreur d’import, il produit des contacts sans identifiant.

Corriger après coup

Un lead qualifié par erreur, un client qui se rétracte : les ajustements de conversion permettent de retirer une conversion ou d’en modifier la valeur, jusqu’à 55 jours après son enregistrement selon la FAQ. Une conversion retirée ne peut plus être ajustée ensuite.

L’ordre des opérations

1. Activer le marquage automatique et vérifier que le GCLID arrive bien dans l’URL, puis dans le CRM, sur un vrai clic.
2. Écrire la définition de chaque étape remontée, avec la vente.
3. Créer les actions de conversion, toutes secondaires.
4. Importer quelques semaines d’historique et lire les diagnostics.
5. Automatiser l’envoi quotidien.
6. Passer l’étape choisie en principale, en notant la date, et laisser passer au moins un cycle de conversion avant de juger.

Les quatre premières étapes sont du travail de données ; seule la dernière touche aux campagnes. C’est souvent là que le dispositif rencontre sa vraie limite : une stratégie d’enchères qui change de signal change de comportement, et le pilotage de cette transition fait partie de la gestion du référencement payant, pas de la configuration.

Les erreurs fréquentes

Passer la signature en principale d’emblée. Trop rare, trop tardive : l’algorithme n’a rien à apprendre.

Envoyer l’heure de l’import au lieu de l’heure de l’étape. Les conversions se décalent, et les doublons ne sont plus reconnus.

Laisser la balise du formulaire en principale à côté de l’import. L’algorithme optimise alors sur deux signaux dont l’un contredit l’autre.