L'attributionattribution pub cassée d'un loueur IT, recâblée dans HubSpot

Le problème : payer pour de la pub, aveugle sur le retour

La société loue et gère du parc IT pour des entreprises, et une vraie part de sa demande vient du search payant. De l'argent partait sur Google Ads chaque mois, et en surface HubSpot paraissait en bonne santé : clics et impressions continuaient d'affluer, les contacts continuaient d'apparaître. Le problème était en dessous. Vers novembre 2023, ces contacts issus de la pub ont cessé de porter leur attribution, au niveau contact comme au niveau deal. Les clics arrivaient ; le lien vers leur provenance, non.

La conséquence est celle que redoute toute équipe d'acquisition payante : vous ne pouvez pas dire quelles campagnes génèrent du pipeline. Le budget continue de couler vers des mots-clés et des campagnes sur la foi, parce que la donnée qui vous dirait ce qui marche s'est éteinte en silence. Le reporting dessinait toujours des graphiques, mais la colonne la plus importante, la source d'origine, mentait, donc chaque décision bâtie dessus était une supposition déguisée en chiffre.

Le mandat n'était pas « reconstruisez notre CRM ». HubSpot était le bon outil et l'équipe y vivait. Le mandat était : trouver pourquoi l'attribution a cassé, la réparer, et rendre le reporting de nouveau fiable, pour qu'un euro dépensé en pub puisse être tracé jusqu'au pipeline qu'il crée.

La cause racine : un cookie tombé par terre

Avant de changer quoi que ce soit, l'audit a remonté exactement où l'attribution fuyait. Un contact dans ce business est créé ou mis à jour de trois façons différentes, et chacune devait être vérifiée à part, parce qu'un seul chemin cassé suffit à empoisonner tout le rapport.

Trois chemins, un cassé

Les trois portes d'entrée étaient une soumission de formulaire, une création via l'API, et un événement ajout au panier. Parcourir chacune a révélé deux défaillances distinctes. Les paramètres UTM étaient perdus aux changements de page, donc le signal de campagne ne survivait jamais au trajet jusqu'au formulaire. Et les contacts créés via l'API ne portaient jamais le cookie hutk, le jeton de tracking que HubSpot utilise pour relier une personne à sa session, donc HubSpot n'avait d'autre choix que de marquer leur source d'origine comme offline.

Le build : réparer le tracking, puis réaligner tout le modèle

Trouver la fuite n'était que la moitié du travail. L'autre moitié était de la réparer à la source et de s'assurer que le reste du modèle puisse de nouveau être cru, sur chaque objet, pas seulement le contact.

Le correctif d'attribution

La réparation a déplacé le tracking hors de l'API Contacts vers les appels JavaScript trackPageView et trackEvent, qui portent la session et le cookie dont HubSpot a besoin, et remappé les formulaires pour que le signal UTM survive au trajet. Tout le correctif a été documenté pour que la source d'origine lise Paid Search correctement au lieu de retomber sur offline. Le tracking formulaire et ajout au panier a été rétabli dans HubSpot.

Trois pipelines, réalignés

L'attribution repose sur le modèle de données, donc le modèle devait être cohérent. Nous avons mis le lifecycle en accord entre Contact, Société et Deal, sur trois pipelines parallèles, Company Lifecycle, Orders et MDM, avec les étapes entièrement cartographiées. Faire cela a fait remonter le genre de contradiction qui se cache à la vue de tous : 880 sociétés affichaient une commande gagnée mais zéro client dans le lifecycle, un écart que personne n'avait quantifié avant que les pipelines soient forcés de s'accorder.

Workflows audités, reporting reconstruit

Chaque workflow HubSpot a été passé en revue et a reçu un verdict, garder, changer ou couper, retirant ceux qui effaçaient le lifecycle sans délai, bloquaient des retours en arrière légitimes ou créaient des doublons. Sur cette fondation propre, nous avons construit un reporting des deals, sociétés et contacts par source et par campagne à travers le tunnel. Toute l'architecture des pipelines a été documentée et transmise à l'équipe RevOps interne.

Ce qui a changé pour l'équipe

Oubliez les tableaux de bord qui avaient l'air corrects. Ce qui a changé, c'est que les chiffres sont devenus vrais, et que la dépense est devenue traçable.

Le titre est la traçabilité, pas un graphique de vanité. Le tracking formulaire et ajout au panier a été rétabli, la source d'origine relit Paid Search, et le reporting relie maintenant deals, sociétés et contacts à la source et à la campagne qui les ont produits. L'équipe est passée de dépenser à l'aveugle à pouvoir demander quelle campagne a généré quel pipeline et obtenir une réponse droite.

En dessous, le modèle est cohérent. Trois pipelines s'accordent, les workflows ne corrompent plus le lifecycle, et les contradictions silencieuses, comme les 880 sociétés gagnées mais non clientes, sont visibles au lieu d'être enfouies. L'architecture a été documentée et remise à l'équipe RevOps interne, pour que le correctif survive à la mission.

Sur quoi ça tourne

Un build ciblé sur les outils que l'équipe utilisait déjà, chaque brique faisant un seul job et la société détenant les clés.

• HubSpot · le système de référence : lifecycle entre Contact, Société et Deal, trois pipelines, et le reporting par source et campagne reconstruit.
• Google Ads · le canal d'acquisition payante dont l'attribution a été remontée dans HubSpot de bout en bout.
• Google Tag Manager · là où le correctif trackPageView et trackEvent porte la session et le cookie dont HubSpot a besoin.
• Clay et Amplemarket · l'enrichissement derrière le maintien à jour des fiches société et contact.

Aucun changement d'outil, aucune boîte noire. L'architecture des pipelines et le correctif d'attribution ont été documentés et transmis, exactement de la même façon que chaque build que nous livrons.