Groupe Mutuel : tracking e-commerce avancé et intégration CRM

Le défi : un clic n'est pas un lead

L'assurance est un secteur à fort enjeu. Les données sont sensibles. Le parcours client est long et passe par plusieurs canaux. Un visiteur clique sur une annonce, compare les offres, repart, revient, et finit parfois par échanger avec un conseiller du réseau de vente.

L'équipe marketing pilotait des campagnes SEA et Meta. Les statistiques web montraient des clics et des vues de formulaire. Le CRM détenait le vrai résultat : les leads qualifiés, et les ventes. Ces deux mondes ne se parlaient pas. La question business était simple : quelles campagnes apportent des leads qualifiés, et pas seulement du trafic ?

Y répondre demandait de résoudre trois choses à la fois : l'attribution entre le web et le CRM, le tracking e-commerce des offres en ligne, et un dispositif de consentement assez strict pour le secteur de l'assurance santé.

L'architecture de mesure d'entreprise

Tout est orchestré avec Google Tag Manager. Un seul conteneur, une seule couche de données documentée, et une nomenclature commune au marketing, à l'IT et au réseau de vente. Le code applicatif pousse les événements dans le dataLayer. GTM se contente de les lire et de les router vers GA4 et les plateformes publicitaires. Aucune balise ne dépend d'un sélecteur CSS.

Le consentement d'abord : OneTrust câblé dans GTM

En assurance santé, une balise qui se déclenche avant le consentement n'est pas un petit bug. C'est un incident de conformité. OneTrust a donc été câblé dans le conteneur comme source unique de vérité pour le consentement.

• L'état par défaut est « refusé » : les valeurs par défaut de Consent Mode sont définies avant toute autre balise, lors de la phase d'initialisation du consentement.
• Les catégories correspondent aux signaux de consentement : chaque catégorie OneTrust met à jour le signal associé : analytics_storage, ad_storage,ad_user_data et ad_personalization.
• Chaque balise a une exigence de consentement : les balises d'analyse et de publicité ne peuvent pas se déclencher sans opt-in explicite. Rien n'est laissé au comportement par défaut.
• Testable : le dispositif a été vérifié dans l'aperçu GTM et dans l'onglet réseau du navigateur. « Aucune balise avant le consentement » est donc vérifié, pas supposé.

Un événement de lead sans donnée personnelle

Lorsqu'un formulaire est soumis, le site attend la réponse de l'intégration Dynamics 365. Seul un lead confirmé déclenche un événement. Le payload contient ce dont le marketing a besoin pour optimiser : le formulaire, le produit, une tranche de scoring et la source de la campagne. Il ne contient jamais de nom, d'adresse e-mail ni de donnée de santé.

window.dataLayer = window.dataLayer || [];

// Déclenché uniquement après la confirmation de création du lead par Dynamics 365
window.dataLayer.push({
  event: 'generate_lead',
  form_id: 'quote_request_health',
  lead_product: 'health_insurance',
  lead_score: 'hot',            // tranche de scoring, jamais la donnée personnelle brute
  lead_channel: 'sales_network',
  crm_status: 'created',
  campaign_source: 'google',    // issu des paramètres UTM conservés
  campaign_medium: 'cpc',
  campaign_name: 'health_brand_fr'
});

Extrait simplifié, à titre d'illustration. Les noms de champs et les valeurs sont des exemples.

Intégration du CRM Microsoft Dynamics 365

Les formulaires du site ont été connectés à Microsoft Dynamics 365. Chaque soumission devient un lead dans l'outil du réseau de vente. Le contexte de tracking l'accompagne.

• Les UTM sont capturés à l'arrivée et conservés pendant toute la session, même si le visiteur parcourt plusieurs pages avant de remplir un formulaire.
• Les données de campagne sont transmises avec le formulaire, dans des champs dédiés, à côté du lead lui-même.
• Le réseau de vente voit l'origine : chaque lead du CRM porte la campagne qui l'a généré, et son statut de qualification peut être relu par campagne.

Résultat : une clé commune entre le web et le CRM. Le marketing ne reporte plus des « soumissions de formulaire ». Il reporte les leads acceptés par le réseau de vente, regroupés par campagne.

Tracking e-commerce des offres en ligne

Certaines offres peuvent être souscrites en ligne. Pour celles-ci, le tracking e-commerce GA4 a été conçu autour du parcours d'assurance, pas d'une boutique classique. Les offres sont traitées comme des articles, avec leur produit, leur catégorie et leur prix. Les événements e-commerce standard de GA4 décrivent chaque étape.

• Page d'atterrissage : view_item lorsqu'une offre est affichée.
• Devis démarré : begin_checkout lorsque le visiteur entre dans le parcours de devis.
• Étapes du devis : les événements add_shipping_info etadd_payment_info sont associés aux vraies étapes du parcours. Les abandons sont ainsi visibles étape par étape.
• Devis final ou souscription : purchase, avec un identifiant de transaction unique pour éviter les doublons.

Avec le tunnel complet dans GA4, l'équipe voit où partent les visiteurs et de quelle campagne ils viennent.

Impact business et résultats

Le principal résultat est la clarté. L'équipe marketing dispose désormais d'une vue sur l'ensemble du tunnel, du premier clic sur une annonce jusqu'au lead dans le CRM, puis jusqu'à la conversion de l'offre en ligne.

• Optimisation sur la qualité des leads : les campagnes Google Ads (SEA) et Meta sont jugées sur la qualité des leads dans le CRM, pas sur des indicateurs web superficiels comme les clics ou les vues de formulaire.
• Le budget suit le revenu : la dépense peut quitter les campagnes qui apportent du volume sans lead qualifié, pour aller vers celles qui alimentent le réseau de vente.
• Un pipeline fiable et conforme : aucune balise ne se déclenche avant un consentement explicite, et aucune donnée personnelle n'est envoyée aux outils d'analyse.
• Un langage commun : le marketing, l'IT et le réseau de vente lisent les mêmes événements, avec les mêmes noms. Les données sont directement liées au revenu du réseau de vente.