Le bouton a été cliqué. La demande est-elle arrivée ?

Le rapport affiche 40 conversions, mais l’équipe dit n’avoir reçu que 25 demandes. Avant de décider qui a tort, établissez ce que chacun compte. Un clic sur un bouton, une tentative d’envoi et une demande enregistrée sont des événements différents.

Cette distinction influence les décisions budgétaires. Si le rapport compte une action qui n’aboutit jamais, la campagne peut être jugée sur des résultats que l’entreprise ne reçoit pas. Si la demande est enregistrée mais n’arrive jamais à son responsable, le problème se situe plus loin dans le processus.

Nous définissons la conversion comme l’action réelle que nous voulons, puis vérifions si la mise en œuvre mesure bien cette action.

Cet article suit deux questions liées : la demande est-elle arrivée jusqu’à l’entreprise, et dans quelles conditions peut-elle être mesurée ? C’est pourquoi la vérification du formulaire mène au suivi, aux navigateurs et au consentement.

Que signifie « formulaire envoyé » ?

Pour un simple formulaire de contact, définissez d’abord la réussite : les données passent la validation, le système accepte l’envoi et l’équipe peut retrouver l’enregistrement. La confirmation affichée au visiteur doit refléter ce qui s’est réellement passé.

Un projet peut relier un site, un service d’e-mail et un CRM, le système utilisé pour gérer les échanges avec les clients. L’acceptation par le site ne prouve pas que l’e-mail est arrivé ni que le transfert vers le CRM a réussi. Vérifiez chaque connexion pertinente.

Google Analytics documente l’événement generate_lead pour la génération d’une demande, par exemple au moyen d’un formulaire. Le nom ne vérifie pas le formulaire : l’équipe doit définir et mettre en place le bon déclencheur. Événements recommandés dans GA4 (en anglais)

Une page de remerciement confirme une action déjà réussie

Une page de confirmation peut expliquer l’étape suivante, le délai de réponse réel et ce que la personne peut faire entre-temps. Elle est aussi utile pour certaines mises en œuvre de la mesure.

Mais le simple affichage de cette page ne doit pas créer une nouvelle demande. Que se passe-t-il si l’utilisateur recharge la page, revient par l’historique ou ouvre directement le lien ? L’événement choisi pour une demande réussie doit être lié à la réussite réelle et protégé contre la duplication dans la mise en œuvre utilisée.

Redirigez uniquement une fois la réussite confirmée. Si le système signale une erreur, expliquez-la et permettez à l’utilisateur de corriger sans croire que le message a été reçu. Un minuteur qui ouvre toujours une page de remerciement peut masquer précisément l’échec que nous devons trouver.

Un exemple d’écart qui peut s’expliquer

Imaginez un test contrôlé dans lequel chaque tentative peut être suivie. Le bouton est cliqué 40 fois. Dix tentatives s’arrêtent à la validation, cinq rencontrent une erreur d’envoi et 25 créent des demandes acceptées et enregistrées. Dans cet exemple, les 25 parviennent aussi à l’équipe.

Si chaque clic est déclaré comme une demande réussie, le décompte est trop élevé de 15, soit 60 % de plus que les 25 demandes réellement reçues. C’est un problème de définition et de mise en œuvre de la mesure.

Les rapports réels peuvent différer pour d’autres raisons : périodes de reporting, fuseaux horaires, filtres, attribution ou conditions de collecte des données. N’appliquez pas l’explication de cet exemple à chaque écart. Suivez des cas identifiables tout au long du parcours.

Tester ce qui se passe quand quelque chose ne va pas

Un seul envoi réussi ne couvre pas toutes les situations pertinentes. Le test de recette doit inclure des comportements qui peuvent survenir en utilisation normale.

Répétez les cas pertinents sur mobile et sur ordinateur. Avec des formulaires externes, des systèmes de réservation ou des paiements, vérifiez le passage d’un système à l’autre. Une réservation peut exiger la confirmation d’un créneau disponible ; un paiement peut passer par plusieurs statuts. Définissez la conversion conformément au processus réel.

Où nous vérifions le signal, et où nous vérifions la demande

Les outils de débogage montrent quels événements sont envoyés et ce qu’ils contiennent. DebugView dans GA4, par exemple, permet d’examiner les événements d’un appareil sur lequel le mode débogage est activé. Documentation de DebugView (en anglais)

En parallèle, vérifiez la demande là où elle est enregistrée et là où l’équipe la traite. Un événement d’analyse ne confirme pas la remise d’un e-mail. Un e-mail reçu ne confirme pas qu’un événement d’analyse n’a été envoyé qu’une seule fois.

Les tests doivent respecter les conditions de collecte, y compris les choix de consentement configurés. Ne vous attendez pas à ce que chaque demande apparaisse de façon identique dans chaque outil. Gardez les coordonnées hors des noms d’événements et des URL de pages.

Le suivi relie l’action au rapport

Le suivi enregistre les événements pertinents et les envoie aux outils d’analyse ou de publicité : visites, débuts de formulaire, demandes confirmées et commandes. Ce que signifie un événement, l’endroit d’où il est envoyé et les conditions dans lesquelles il peut être utilisé influencent tous le reporting.

Une balise est un composant de code qui participe à cette mesure. Son installation n’est qu’une partie de la mise en œuvre. Nous devons savoir quelle action la déclenche, quelles informations elle envoie, à qui et avec quelles autorisations.

Le suivi dans le navigateur et le suivi sur le serveur

Avec le suivi côté client, du code s’exécute dans le navigateur du visiteur et envoie des événements. Avec le taggage côté serveur, un serveur contrôlé par l’organisation reçoit et traite les données avant de les transmettre aux destinations configurées. Le navigateur peut rester la source d’origine. Google : introduction au taggage côté serveur (en anglais)

Si la seule source est un script qui ne s’est jamais exécuté, déplacer sa destination vers votre propre sous-domaine ne recrée pas l’événement manquant. Une intégration déclenchée par une demande enregistrée peut en revanche s’appuyer sur la confirmation de l’application sans attendre le chargement d’une page de remerciement. Ce sont des architectures différentes, même si toutes deux sont décrites comme du « suivi serveur ».

Le Measurement Protocol de GA4 (en anglais) permet à des systèmes d’envoyer directement des événements. Google le présente comme un complément à la collecte existante ; l’utiliser seul peut produire un reporting partiel. Envoyer un événement par une API ne fournit pas automatiquement des informations complètes sur la session, la source et le parcours.

Pourquoi nous recommandons d’évaluer un composant côté serveur

Pour un projet dont les décisions de promotion dépendent des demandes et des ventes, il vaut la peine de se demander si les résultats confirmés dans le CRM peuvent alimenter la mesure. Notre recommandation part du problème concret : ce qui manque, où l’information se perd et quelle décision serait mieux éclairée.

Une mise en œuvre bien conçue peut valider les données avant de les envoyer, contrôler ce qui part vers chaque destination et relier des événements commerciaux qui se produisent après une visite. Par exemple, elle peut distinguer une nouvelle demande d’une demande qualifiée ensuite par l’équipe.

Mettez ces avantages en regard de la configuration, de l’hébergement, de la sécurité, du suivi, de la maintenance et de la responsabilité en cas d’incident. Pour un formulaire simple, corriger l’événement et tester le consentement peut résoudre le problème initial. Une boutique ou un processus de vente impliquant plusieurs systèmes peut gagner davantage à un composant serveur.

Chez NOT MORE., nous justifions ce choix par un plan de mesure et des critères de vérification. Nous ne promettons pas que l’installation d’un service récupérera chaque conversion ou augmentera automatiquement le ROAS.

Pourquoi les navigateurs peuvent montrer des parties différentes du même parcours

Un cookie stocke des informations dans le navigateur, par exemple pour maintenir une session ou reconnaître une visite. « Propriétaire » et « tiers » décrivent son contexte par rapport au site. Être propriétaire ne rend pas automatiquement un cookie nécessaire ni exempté de consentement ; sa finalité compte.

Ce sont des exemples tirés de la documentation des éditeurs de navigateurs, pas une liste complète de toutes les versions et de tous les appareils. WebKit (en anglais), Firefox (en anglais), Chrome (en anglais)

Évitez les affirmations générales selon lesquelles tous les cookies auraient disparu, ou selon lesquelles la même personne serait reconnue de façon identique partout. Les extensions de blocage, les données effacées, les changements d’appareil, les pertes de connexion ou un départ avant l’envoi d’un événement peuvent tous jouer. Examinez-les comme des possibilités plutôt que de les utiliser pour expliquer chaque écart.

Le consentement sur un site n’oblige pas un navigateur à autoriser un mécanisme qu’il bloque. De même, le fait qu’un navigateur permette une transmission n’établit pas l’autorisation d’utiliser les données à n’importe quelle fin.

Règles européennes, politiques de Google et bandeau de consentement ont des rôles différents

En Europe, évaluez à la fois les règles sur le stockage d’informations ou l’accès à celles-ci sur un appareil et, le cas échéant, la protection des données personnelles. Obtenez le consentement avant d’utiliser les cookies qui l’exigent ; les fonctions strictement nécessaires bénéficient d’exceptions. Expliquez clairement les finalités et rendez le retrait facile. L’Europe est à vous : recommandations officielles sur les cookies (en anglais)

Les règles des navigateurs sont des décisions techniques de leurs éditeurs. Les politiques de Google sont des conditions d’utilisation de ses produits. Les exigences européennes forment le cadre juridique. Dans la mise en œuvre, nous les traitons séparément et vérifions leur application avec le délégué à la protection des données ou le spécialiste juridique du projet.

Pour les usages de mesure et de publicité concernés impliquant des personnes dans l’Espace économique européen, Google exige le consentement applicable et les signaux correspondants. La Roumanie fait partie de l’EEE. Cette exigence concerne les produits Google et peut s’appliquer même lorsque le visiteur utilise un autre navigateur que Chrome. Exigences de Google pour le trafic de l’EEE (en anglais)

La CMP recueille le choix. Le mode Consentement le transmet.

Une CMP (plateforme de gestion du consentement) gère l’interface et les préférences du visiteur. Le mode Consentement transmet le choix aux balises Google et adapte leur comportement. Installer un bandeau ne démontre pas que le lien entre les deux fonctionne.

Dans une configuration de taggage côté serveur Google, les signaux de consentement doivent aussi parvenir au composant serveur. Déplacer le traitement ne passe pas outre les préférences de la personne. Vérifiez séparément comment les intégrations d’autres fournisseurs respectent ces préférences. Le mode Consentement dans Tag Manager côté serveur (en anglais)

Le mode Consentement v2 comprend des signaux distincts, que nous ne réduisons pas à un seul « cookies acceptés » :

Définissez l’état initial avant les opérations contrôlées par ces signaux, puis mettez-le à jour après le choix du visiteur. Testez aussi ce qui se passe lorsqu’il change d’avis. Les noms des signaux sont techniques ; l’explication présentée au visiteur doit être compréhensible. Configurer le mode Consentement (en anglais)

Les modes de base et avancé produisent des comportements différents

Ce tableau résume le mécanisme de Google ; les données exactes dépendent de la balise et de la configuration. « Sans cookies » ne signifie pas « rien n’est transmis ». Évaluez le mode avancé au regard des données, des finalités et des exigences du projet. Sa disponibilité dans une plateforme n’établit pas qu’une mise en œuvre est juridiquement appropriée. Mode de base et mode avancé (en anglais)

Événements observés, données modélisées et résultats dans le CRM

Certains rapports Google utilisent la modélisation pour estimer des résultats lorsque l’observation directe est incomplète. La disponibilité dépend du produit, de la configuration, du volume de données et de l’éligibilité. Google Ads documente la modélisation des conversions, tandis que GA4 documente séparément la modélisation comportementale. Activer le mode Consentement ne garantit pas les mêmes estimations pour chaque compte. La modélisation des conversions dans Google Ads (en anglais) La modélisation comportementale dans GA4 (en anglais)

Gardez les rôles distincts : le CRM confirme les demandes qu’il contient ; l’outil d’analyse décrit les événements et les parcours disponibles ; les plateformes publicitaires attribuent les résultats selon leurs propres règles et peuvent inclure de la modélisation. Une estimation n’est pas une demande identifiable supplémentaire que l’équipe devrait s’attendre à trouver dans sa boîte de réception.

Le but de la vérification est donc d’expliquer les écarts et de vérifier que chaque système est correct pour son rôle. Forcer tous les totaux à concorder peut masquer précisément ces différences de définition.

Plusieurs sources d’événements demandent une déduplication

Si la même commande ou la même demande est envoyée par plusieurs chemins, concevez la déduplication pour que la destination reconnaisse une seule action. Convenez des identifiants et des règles propres à chaque destination, y compris pour les nouvelles tentatives. Google Ads documente les identifiants de transaction uniques pour les achats ; réutiliser un identifiant pour des commandes différentes peut entraîner un sous-comptage. L’identifiant de transaction dans Google Ads (en anglais)

Nous ne supposons pas que deux intégrations installées en parallèle sont automatiquement coordonnées. Nous vérifions l’extension de la plateforme, les balises du navigateur, le serveur et les imports du CRM. Une demande qualifiée plus tard est une étape distincte : définissez-la comme telle, plutôt que de la mélanger avec la demande initiale.

Les conversions améliorées sont un mécanisme distinct. Elles peuvent compléter la mesure Google avec des données fournies par le client, hachées pour le rapprochement. Le hachage transforme une valeur, comme une adresse e-mail, en une représentation calculée ; il ne supprime pas tout lien avec la personne. Ce n’est pas la même chose qu’héberger un serveur de taggage. À propos des conversions améliorées (en anglais)

Ce mécanisme n’autorise pas l’envoi de tous les champs du formulaire. Vérifiez l’éligibilité, les mentions d’information, le consentement requis et les champs autorisés par l’intégration. Google restreint les catégories sensibles. Les coordonnées n’ont leur place que dans les fonctions et les champs prévus pour elles, jamais dans des noms d’événements ou des URL arbitraires. Règles de Google relatives aux données client (en anglais)

Un autre exemple : la demande existe, mais le rapport en voit moins

Prenons un second test fictif, distinct de l’exemple des 40 clics. Il y a 100 demandes uniques correctement enregistrées sur la même période, avec une mise en œuvre en mode de base. Trente n’ont pas le consentement requis pour l’envoi vers la destination évaluée. Sur les 70 restantes, dix événements échouent à cause d’un problème technique identifié.

Les nombres ne s’additionnent pas : ce sont des niveaux imbriqués du même ensemble. Dans cet exemple, nous n’incluons ni modélisation, ni attribution aux annonces, ni décalage temporel. Les pourcentages sont inventés pour la démonstration, ce ne sont pas des estimations des taux de consentement du marché.

Une intégration serveur ne pourrait aider à récupérer les dix événements manquants pour raison technique que si elle reçoit la confirmation, dispose de l’autorisation applicable et traite réellement la cause. Déplacer du code sur un serveur ne rend pas éligibles les 30 demandes sans consentement. Et l’arrivée d’un événement ne prouve pas quelle annonce a provoqué la demande.

Ce que nous vérifions aussi pour une mise en œuvre complète

Le test du formulaire est suivi du test des conditions de mesure. Nous choisissons les cas pertinents pour l’architecture et vérifions le résultat à destination :

• La première visite, avant tout choix explicite : ce qui est chargé, ce qui est stocké et ce qui est transmis selon la variante validée.
• Le refus, l’acceptation partielle et l’acceptation : si chaque finalité modifie réellement le comportement des balises concernées.
• Le retrait du consentement : si les opérations suivantes respectent le changement, y compris sur le serveur.
• Des navigateurs et des appareils représentatifs : si les différences peuvent s’expliquer et si le formulaire fonctionne toujours.
• La confirmation par l’application, le rechargement de la page et les nouvelles tentatives techniques : si une seule action métier est comptée comme prévu.
• Les formulaires externes, les paiements ou les systèmes de réservation : si le contexte nécessaire et autorisé est préservé.
• Les événements de qualification, de vente ou d’annulation : si l’étape, la valeur, la devise et la date reflètent le processus réel.

Documentez aussi ce qui ne peut pas être observé. Une bonne mise en œuvre distingue l’absence d’autorisation, les limites techniques, les erreurs de configuration et les règles de reporting. Chacune appelle une réponse différente.

Ce que nous remettons après la vérification

L’équipe doit pouvoir voir ce que représente chaque événement, quand il se déclenche, où arrive la demande et comment reconnaître une erreur. Nous documentons les cas testés et les limites qui demeurent.

Puis nous convenons du résultat utilisé pour évaluer et optimiser la campagne. Une action intermédiaire peut être utile, mais elle doit être identifiée et interprétée comme telle. Le lien avec les demandes qualifiées et les ventes est établi séparément, selon les données et la mise en œuvre disponibles.

Chez NOT MORE., la mesure fait partie de la préparation de la campagne. Nous revérifions le parcours après les changements pertinents de formulaires, de pages ou d’intégrations, pour que le rapport continue de décrire le processus réel.

Ce que vous pouvez demander lors de la prochaine vérification

• Quelle est exactement l’action que nous appelons conversion ?
• Pouvons-nous suivre un envoi de test jusqu’à son enregistrement et sa prise en charge par l’équipe ?
• Que se passe-t-il dans le rapport lorsque le formulaire échoue ou que la page est rechargée ?

Le rapport et les demandes reçues ne concordent pas ?

Partez des définitions et de quelques envois de test. Nous pouvons établir où naît l’écart et ce qui doit être corrigé avant que ces chiffres n’orientent la prochaine décision budgétaire.

Qui met en place la mesure, et qui la suit après le lancement

NOT MORE. peut définir le plan de mesure, configurer les outils, développer les intégrations et tester le parcours convenu, y compris des composants côté serveur lorsque c’est pertinent. L’architecture découle du besoin, des données disponibles, des ressources et des conditions d’utilisation. Les limites des navigateurs et du consentement restent pertinentes, quel que soit l’endroit où s’exécute une partie de la mise en œuvre.

Votre équipe confirme la signification commerciale de chaque événement, la source des données et les responsabilités en matière d’accès et d’exploitation. Les décisions juridiques et de protection des données sont validées avec les spécialistes compétents ; la mise en œuvre technique suit ces décisions. Lorsque d’autres prestataires interviennent, nous établissons qui répare chaque partie de la chaîne.

À la livraison, nous testons les parcours normaux, le refus du consentement, les erreurs et les duplications pertinentes pour la configuration. Si nous assurons aussi le suivi, nous précisons les alertes et les vérifications, leur fréquence et qui intervient. Le reporting explique ce qui est observé, ce qui manque et quelles conclusions les données permettent. Une mise en œuvre correcte soutient l’analyse ; elle ne promet pas une visibilité complète sur chaque utilisateur.

Partir du problème que vous voyez, sans diagnostic technique

Vous n’avez pas besoin d’identifier la balise, l’intégration ou le navigateur à l’origine d’un écart. Partez de ce que vous observez : des demandes manquantes, des totaux différents ou une confirmation peu claire. Nous définissons les vérifications et les accès nécessaires, puis expliquons les constats au regard de la question métier. Si une analyse ou une mise en œuvre distincte est nécessaire, nous convenons d’abord de son périmètre et de son coût. La complexité technique doit devenir des décisions que vous pouvez évaluer.