Plan de marquage B2B : modèle d’événements et recette

Un plan de marquage décrit ce qui déclenche chaque mesure

Un plan de marquage transforme une question métier en consigne vérifiable : quelle action observer, à quel moment, avec quelles informations, dans quel outil et avec quelle preuve de bon fonctionnement. Il se prépare avant de configurer les balises.

Pour un site B2B, le point sensible est souvent le passage du contact au traitement commercial. Cliquer sur « Parler de mon projet », envoyer un formulaire, recevoir une demande et la qualifier sont quatre faits différents. Les enregistrer sous un même nom rend le diagnostic difficile.

Ce guide fournit un modèle rempli : quatre événements Web, deux états métier et six scénarios de recette. Le cas est entièrement fictif. Il ne décrit ni l’installation de Gemme Studio ni un résultat client. Adaptez les déclencheurs aux fonctions réellement présentes sur votre site.

Commencez par une question, puis relevez ce qui existe déjà

La question du cas pédagogique est la suivante : « Où s’interrompt le parcours entre la lecture d’une offre et une demande que l’équipe peut traiter ? » Le site fictif du projet Boréal comprend une page d’offre, un bouton vers Contact et un formulaire relié à un système de réception. L’équipe commerciale attribue ensuite un statut à chaque demande examinée.

Le choix des indicateurs se fait en amont. Le guide des KPI d’un site internet aide à définir les unités et les dénominateurs. Le plan de marquage précise ensuite comment produire les observations nécessaires, sans refaire cette sélection.

Avant d’ajouter une balise, relevez les dispositifs existants : outil analytics, éventuel gestionnaire de balises, collecte automatique des formulaires, connexion de réception et règles de confidentialité retenues. Identifiez la personne qui peut modifier chaque partie. Deux installations actives pour une même action peuvent produire deux événements sans produire deux demandes.

Dans GA4, les mesures améliorées peuvent notamment collecter form_start et form_submit. Leur présence ne dispense pas de vérifier le comportement de votre formulaire et sa réception. Une collecte personnalisée ne doit pas être ajoutée par-dessus une collecte existante sans examiner le risque de doublon.

Le modèle rempli : quatre événements Web et deux états métier

Les noms personnalisés ci-dessous sont des choix pédagogiques. Ils ne sont pas des fonctions natives garanties de Webflow. Les paramètres proposés sont des valeurs de classification définies par l’équipe ; ils ne contiennent ni nom, ni adresse e-mail, ni message de prospect. Leur disponibilité dans les rapports devra être vérifiée lors de l’implémentation.

M-01 — Le visiteur active le CTA de contact

Question : le bouton de la page d’offre conduit-il vers le contact ? Nom proposé : cta_contact_click, événement personnalisé. Déclencheur : activation du lien de contact convenu, au clic ou au clavier. La simple présence du bouton à l’écran ne suffit pas.

Paramètres : offer_type=diagnostic et cta_location=offer_footer pour le bouton du bas de la page fictive. Ces libellés stables décrivent le contexte ; ils ne reprennent pas un texte libre du visiteur. Destination : analytics, dans le périmètre de collecte autorisé.

Comptage : une occurrence par activation réelle. Une personne peut activer plusieurs fois le bouton : ce compteur n’est pas un nombre de prospects. Responsable : l’intégrateur vérifie le déclenchement ; le marketing valide le sens des deux classifications.

Recette : une activation autorisée produit une occurrence ; afficher la page sans utiliser le bouton n’en produit aucune. Contrôler aussi le lien réel : un événement enregistré ne prouve pas que la destination est correcte.

M-02 — Le visiteur commence le formulaire

Question : le formulaire est-il réellement commencé après l’arrivée sur Contact ? Nom : form_start si la collecte GA4 existante est utilisable et vérifiée. La documentation Google décrit la première interaction avec un formulaire au cours d’une session.

Contexte retenu : le formulaire fictif possède un identifiant HTML stable contact_project, à rapprocher du paramètre form_id effectivement reçu. Destination : analytics selon le dispositif retenu. Aucun contenu de champ n’est nécessaire à cette question.

Comptage : appliquer et documenter la règle réellement observée dans la collecte, sans ajouter un second événement de début sous un autre nom pour compter la même interaction. Responsable : la personne chargée de la mesure contrôle la collecte automatique ; l’intégrateur confirme l’identifiant du formulaire.

Recette : relever l’événement et son contexte lors d’une première interaction de test. Si le formulaire embarqué ou personnalisé n’est pas détecté comme attendu, conserver le contrôle en réserve et définir un déclenchement adapté avant de l’utiliser dans un taux.

M-03 — Une tentative rencontre une erreur de saisie

Question : un défaut de saisie empêche-t-il de poursuivre ? Nom proposé : form_error, événement personnalisé. Déclencheur : une tentative d’envoi affiche effectivement une erreur de validation dans le formulaire du cas.

Paramètres : form_id=contact_project et error_type=required_field pour le scénario prévu. La catégorie d’erreur vient d’une liste fermée. Ne transmettez pas la valeur saisie ni le message libre du formulaire. Destination : analytics si la collecte est autorisée.

Comptage : une occurrence par tentative rejetée dans ce modèle, même si plusieurs champs sont signalés. La règle doit être traduite dans l’implémentation ; elle n’est pas obtenue en nommant simplement l’événement. Responsable : intégrateur pour la logique, responsable de mesure pour la nomenclature.

Recette : un scénario de saisie invalide produit l’erreur attendue et aucun événement de succès. Une correction suivie d’un envoi accepté doit être distinguée de cette première tentative.

M-04 — Le traitement confirme une nouvelle demande

Question : l’envoi a-t-il été accepté par le traitement retenu ? Nom GA4 envisageable : generate_lead, que Google classe parmi ses événements recommandés. Dans le modèle, le déclencheur choisi est la confirmation d’acceptation d’une nouvelle demande, identifiée par l’intégrateur.

Paramètres du modèle : form_id=contact_project et offer_type=diagnostic. Aucune valeur monétaire n’est inventée pour la demande. Destination : GA4 si cette destination et la collecte sont retenues. Le nom recommandé ne crée pas à lui seul un signal de succès fiable.

Comptage : une occurrence par nouvelle demande acceptée dans le parcours instrumenté. Un double clic, une nouvelle lecture de la confirmation ou le rafraîchissement d’une page de remerciement ne doivent pas créer une demande supplémentaire dans ce modèle. Responsable : intégrateur et responsable de mesure définissent ensemble le signal et sa protection contre les doublons.

Recette : rapprocher une demande synthétique acceptée et l’événement reçu. Si le seul déclencheur disponible est un clic sur « Envoyer » ou une page de remerciement accessible directement, le critère n’est pas satisfait. Ce succès technique ne prouve pas encore la présence dans le CRM ni la qualification.

M-05 — La destination de traitement possède la demande

Question : l’équipe dispose-t-elle réellement de la demande ? État métier proposé : request_received. Il est constaté dans le système de réception prévu, par exemple le CRM. Il n’est pas envoyé à GA4 par défaut.

Informations internes : référence de la demande, date de réception et canal de réception convenu. Elles restent dans le système métier du cas. La fiche distingue la réception de la demande de l’e-mail qui prévient l’équipe. Destination : registre interne de traitement.

Comptage : une demande distincte selon une règle de dédoublonnage documentée. Une mise à jour de sa fiche ne compte pas comme une nouvelle réception. Un même contact peut toutefois transmettre deux demandes différentes : dédoublonner seulement par adresse e-mail ferait perdre cette distinction. Responsable : la personne chargée de la réception.

Recette : retrouver la demande synthétique dans la destination prévue, avec ses informations attendues. Si la notification manque mais que la demande existe, documenter les deux faits séparément. Le guide des demandes Webflow non reçues aide à isoler une rupture de transmission.

M-06 — L’équipe a examiné et qualifié la demande

Question : les demandes reçues correspondent-elles au périmètre recherché ? État métier proposé : request_qualified, réservé à une décision de qualification effectivement validée. Le cas retient l’adéquation du besoin à l’offre et la possibilité de poursuivre l’échange ; les critères réels appartiennent à l’entreprise.

Informations internes : référence de la demande, décision, date d’examen et version des critères. Destination : CRM ou registre métier. Aucune connexion supplémentaire à un outil publicitaire ou analytics n’est nécessaire pour commencer cette lecture.

Comptage : une première qualification validée par demande selon la règle du cas. Les corrections de statut restent traçables et ne fabriquent pas de nouveaux prospects. Responsable : l’équipe commerciale définit les critères et tient les décisions à jour.

Recette : vérifier qu’une demande non examinée reste distincte d’une demande non qualifiée, et qu’une modification répétée ne multiplie pas les demandes. Une éventuelle remontée des états commerciaux vers un autre outil constitue un projet à définir séparément.

Préparer une recette qui peut aussi échouer

La recette se prépare avec des données synthétiques, une destination de test connue et l’accord des responsables sur les effets des envois. Chaque fiche conserve la version, le scénario, le résultat attendu, la preuve observée et une réserve éventuelle. Les six contrôles suivants sont des attentes du modèle, pas des tests réalisés sur votre site.

R-01 — Activer le CTA : vérifier une activation à la souris puis au clavier. Attendu : la bonne destination et une occurrence par activation dans la collecte autorisée. Une vue du bouton seule ne déclenche pas M-01.

R-02 — Corriger une saisie invalide : préparer un cas rejeté puis corriger les données. Attendu : une erreur classée pour la tentative rejetée ; aucun succès à ce stade ; l’envoi valide est contrôlé séparément.

R-03 — Vérifier le succès et les répétitions : rapprocher l’envoi synthétique accepté, M-04 et la réception métier. Examiner le double clic et le rafraîchissement. Attendu : pas de nouvelle demande ni d’événement de succès supplémentaire pour une simple répétition de la confirmation. Si le traitement permet plusieurs demandes, distinguer ce cas d’un doublon.

R-04 — Refuser puis accepter la mesure : contrôler les comportements prévus par le dispositif de confidentialité validé. Attendu : la collecte respecte ces choix, sans contournement pour « retrouver » un événement absent. Dans le cas fictif, le formulaire doit rester utilisable indépendamment de l’autorisation de mesure ; ce fonctionnement est lui aussi à vérifier.

R-05 — Séparer réception et notification : sur un environnement de test autorisé, vérifier les deux traces. Attendu : la demande conservée et l’alerte reçue font l’objet de deux constats, même si l’un manque. Ne provoquez pas une panne sur le site public pour remplir la fiche.

R-06 — Reprendre une demande connue : vérifier la réception d’une nouvelle demande d’un contact déjà présent, puis sa qualification. Attendu : le contact et la demande ne sont pas confondus ; une correction de statut reste une correction. Le responsable commercial peut retrouver la règle de comptage utilisée.

Pour organiser la remise de ces preuves avec les autres contrôles du projet, utilisez un cahier de recette de site web. Une réserve de collecte ne doit pas être masquée par un statut global « tracking installé ».

Vérifier les paramètres reçus, pas seulement le compteur

Une occurrence sous le bon nom peut porter un mauvais identifiant de formulaire ou une mauvaise classification d’offre. Vérifiez le déclencheur, la destination, les paramètres et la cardinalité attendue pour chaque scénario.

Dans GA4, DebugView permet d’inspecter les événements reçus sur un appareil en mode débogage. Cet outil aide à contrôler la collecte ; il ne prouve ni la réception commerciale ni la disponibilité de chaque paramètre dans vos rapports habituels. Des réglages de confidentialité peuvent aussi empêcher l’apparition d’événements dans cette vue.

Un écart entre événements analytics et demandes internes demande donc une enquête, pas une correction arithmétique automatique. La couverture de mesure, les règles de comptage, les répétitions et les canaux peuvent différer. Si vous ne savez pas rapprocher les populations, conservez les volumes séparés et nommez la limite.

Limiter les données et garder une version du plan

Google demande de ne pas transmettre à Analytics des informations permettant d’identifier personnellement l’utilisateur. Cela concerne aussi les informations qui pourraient se trouver dans les URL, les titres ou les paramètres. Le message d’un prospect n’est pas une catégorie de mesure.

Dans le modèle proposé, les paramètres Web utilisent des classifications fermées. Les références individuelles de demandes et les informations commerciales restent dans le système métier. Ce choix de minimisation ne vaut pas validation juridique de votre installation : les destinations, accès, durées et règles de collecte restent à définir pour le projet réel.

Le plan porte une version, une date de contrôle et un responsable. Une évolution du formulaire, du libellé d’offre, de la destination de réception ou de la collecte automatique déclenche une revue des fiches concernées. Conservez ce qui a changé et les scénarios à rejouer ; ne redéfinissez pas silencieusement un indicateur au milieu d’une comparaison.

Le livrable à demander avant de considérer la mesure terminée

Demandez les fiches d’événements et d’états métier, les règles de répétition, les destinations, les scénarios exécutés et leurs preuves, ainsi que les réserves encore ouvertes. Une capture de tableau de bord ne remplace pas ces éléments.

Pour une création ou refonte de site B2B, précisez dès le cadrage quels parcours doivent être mesurés et qui possède la réception commerciale. Vous préparez un projet Webflow ? Présentez votre parcours de demande, vos outils existants et les décisions que vous souhaitez éclairer. Le périmètre de conception, d’intégration et de mesure pourra être défini explicitement, sans supposer une instrumentation complète par défaut.