Suivi server-side HubSpot : guide de configuration complet

Si tu gères ton marketing ou tes ventes via HubSpot, la qualité de tes données sur les prospects dépend entièrement de la précision du suivi qui les alimente. Or, ce suivi a un problème : les navigateurs lui font des bâtons dans les roues.

Tout commence par un simple cookie. Le code de suivi standard de HubSpot installe un cookie appelé « hubspotutk » pour reconnaître les visiteurs qui reviennent sur le site et reconstituer le parcours d’un contact avant même qu’il ne remplisse un formulaire. La fonctionnalité « Intelligent Tracking Prevention » de Safari limite la durée de ce cookie à sept jours lorsqu’il est installé via JavaScript, ce qui correspond exactement à la configuration par défaut de HubSpot. Les bloqueurs de publicités et les paramètres de confidentialité stricts de Firefox, Edge et Safari vont encore plus loin. Ils bloquent carrément le script HubSpot et ses formulaires intégrés, ne laissant parfois qu’un espace vide à l’endroit où se trouvait ton formulaire de prospection.

Tout ça, ce n'est pas un risque futur. Ça se passe déjà sur ton site, et c'est en grande partie pour ça que les rapports « Original Source » et d'attribution multi-touch de HubSpot s'éloignent davantage de la réalité que la plupart des équipes ne le pensent.

Le suivi server-side de HubSpot résout le problème à la source. Au lieu que ce soit le navigateur qui contacte directement les points de terminaison js.hs-scripts.com et hsforms.net de HubSpot, c'est ton propre serveur qui s'en charge à la place du contact. Ce guide t'explique comment configurer le suivi server-side pour HubSpot à l'aide de Google Tag Manager et de TAGGRS.

Les avantages du suivi server-side de HubSpot

Avec le suivi côté client, le script HubSpot s'exécute dans le navigateur du visiteur. Il récupère les informations dont il a besoin sur la page, installe les cookies « hubspotutk » et « __hstc », puis contacte directement les serveurs de HubSpot pour enregistrer les pages consultées, identifier les visiteurs et envoyer les formulaires.

Le suivi server-side transfère cette connexion vers ton propre serveur. Le navigateur envoie une requête vers ton domaine (via un conteneur serveur Google Tag Manager), et ton serveur transmet les données pertinentes à l'API de HubSpot via une connexion privée et authentifiée. Le navigateur du visiteur n'entre jamais en contact avec les domaines de HubSpot.

Les équivalents server-side du script côté client de HubSpot sont son API « CRM Objects » pour les contacts et son API « Custom Behavioral Events » pour tout le reste : interactions avec les pages, consultations de produits, envois de formulaires personnalisés, tout ce que tu veux associer à une fiche de contact.

En gros, tout ce que le script HubSpot fait aujourd’hui dans le navigateur a son équivalent server-side ; tu ne perds donc aucune fonctionnalité en le déplaçant, tu changes simplement l’endroit où le travail s’effectue. Pour une équipe marketing, ça veut dire concrètement que les données qui alimentent tes listes, tes workflows et tes rapports sont plus complètes et ne dépendent plus de la coopération du navigateur de chaque visiteur.

Le suivi server-side vaut vraiment le coup d'être mis en place si c'est sur HubSpot que tu prends tes décisions : noter les prospects, déclencher des workflows, rendre compte de l'attribution à la direction ou optimiser tes dépenses publicitaires en fonction des données sur les contacts et les opportunités. Plus tu accordes d'importance à ces données, plus ces lacunes te coûtent cher.

Tu n'as pas encore l'habitude d'utiliser Google Tag Manager ? TAGGRS propose des guides qui abordent les bases avant de te lancer spécifiquement sur HubSpot :

Pourquoi le suivi côté client n'est pas fiable pour les utilisateurs de HubSpot en ce moment

Ce n'est pas juste une remarque générale du genre « les navigateurs sont de plus en plus stricts ces derniers temps ». Quelques changements spécifiques et récents affectent directement le suivi HubSpot, et chacun d'entre eux concerne un rapport ou un workflow que tu utilises déjà. Voici ce qui perturbe le suivi HubSpot côté client, et ce que chaque perturbation te coûte.

Le cookie de suivi est limité, et c'est celui dont HubSpot dépend le plus. « hubspotutk » est enregistré via « document.cookie », et les règles anti-suivi de WebKit suppriment tout cookie créé de cette manière au bout de sept jours sans visite.

Ce délai est ramené à 24 heures dès lors qu'un visiteur arrive sur ton site depuis un domaine que Safari a classé comme « traceur intersite », via un lien comportant des paramètres de requête — ce qui correspond exactement au schéma à l'origine de la plupart des clics sur des publicités payantes. Un prospect qui fait des recherches deux semaines avant de remplir un formulaire apparaît comme un nouveau visiteur qui vient pour la première fois lorsqu’il finit par se convertir, car le cookie qui reliait ses sessions précédentes a expiré quelques jours plus tôt.

Pour un achat mûrement réfléchi, avec un cycle de recherche de plusieurs semaines, c'est la norme. Le canal qui a initialement attiré ce prospect (souvent un canal coûteux comme le référencement payant ou un webinaire) n'est pas crédité, tandis que ce qu'il a tapé dans la barre d'adresse le jour de la conversion (généralement « direct ») s'attribue tout le mérite. Multiplie ça par un trimestre et ton rapport « Source d’origine » surévalue le trafic direct et organique, tout en négligeant les campagnes qui ont fait le boulot.

Les bloqueurs de pub et les systèmes de prévention du suivi dans les navigateurs bloquent le script, pas seulement le cookie. Le forum communautaire de HubSpot lui-même compte plusieurs fils de discussion ouverts à ce sujet : la « Protection renforcée contre le suivi » de Firefox et la « Prévention stricte du suivi » d'Edge bloquent les requêtes vers hsforms.net, ce qui signifie que hbspt.forms.create() ne s'exécute jamais et que les visiteurs voient une case vide à la place du formulaire. Pas de message d'erreur, pas de solution de secours. En général, le visiteur quitte simplement la page, et tu ne sais même pas qu'un prospect existait.

Le blocage au niveau du navigateur mis en place par Apple s'étend. Safari 27 ajoute le blocage par plage d'adresses IP au niveau de la couche réseau et ajoute des CDP comme Segment et Tealium à sa liste de scripts d'empreinte numérique. Si tu fais passer un suivi destiné à HubSpot par une CDP, ou par une balise de script que Safari classe comme un outil de fingerprinting, il peut perdre l'accès aux données de référent et aux paramètres de requête avant même d'atteindre HubSpot.

En d'autres termes, les données sur « d'où vient ce prospect » sont supprimées par le navigateur avant même que HubSpot ne les voie. Comme environ un visiteur sur quatre navigue sur Safari, ça représente une part importante, en pleine croissance et particulièrement motivée de ton audience qui devient « invisible », à savoir précisément les acheteurs d'appareils Apple que de nombreuses marques B2B et haut de gamme souhaitent le plus cibler.

L'utilisation des bloqueurs de pub n'est plus un problème marginal. Environ un tiers des internautes utilise un bloqueur de pub, et ce chiffre ne cesse d'augmenter. En bref, une part non négligeable de ton trafic ne laisse tout simplement jamais le script HubSpot se charger.

Comment le suivi côté client perturbe l'attribution et les données sur les prospects dans HubSpot

Les conséquences se ressentent dans les domaines que tu utilises concrètement pour mener tes campagnes.

Les sources de trafic « Original » et « Latest » sont déterminées à partir de l'historique de session du cookie de suivi. HubSpot essaie de faire correspondre une nouvelle fiche de contact à toute activité anonyme suivie via le cookie de ce visiteur. Quand le cookie est réinitialisé prématurément, cette activité antérieure disparaît ; HubSpot n'a donc plus rien à comparer et définit la « source d'origine » en fonction de la session qui se trouve être active au moment de la création de la fiche de contact, et non en fonction de la première visite réelle du visiteur.

Les rapports d'attribution qui attribuent à un canal la création d'un contact ou d'une opportunité s'appuient sur le même historique d'interactions. Moins il y a de pages vues et de points de contact suivis, plus l'attribution est simpliste et moins elle est utile. Ton marketing n'a pas cessé de fonctionner. C'est juste que HubSpot ne le voit plus.

Les événements comportementaux personnalisés et les événements e-commerce déclenchés via du JavaScript côté client héritent de tous ces problèmes. Si le script est bloqué, l'événement ne se déclenche jamais. Tout workflow ou système de notation des prospects basé sur cet événement reste bloqué, sans rien faire, sans qu'aucune erreur ne t'explique pourquoi.

Il y a quand même une chose qui fonctionne même si les cookies sont bloqués : les formulaires HubSpot peuvent récupérer les paramètres UTM directement depuis l'URL de la page actuelle au moment de l'envoi, donc l'attribution au niveau de la campagne pour cet envoi précis est généralement conservée. Ce qui n'est pas conservé, c'est tout ce qui dépend du lien entre cet envoi et les sessions précédentes du visiteur, suivies par les cookies.

Ce que les utilisateurs de HubSpot gagnent grâce au suivi server-side

Le suivi server-side change ce à quoi tu peux te fier dans HubSpot. Voici ce qui s'améliore une fois que la connexion passe par ton propre serveur :

- Des formulaires qui s'affichent vraiment, ce qui a l'impact le plus direct sur tes revenus parmi tous ceux de cette liste. Un formulaire bloqué, c'est un prospect que tu ne verras jamais et pour lequel tu n'auras pas à payer deux fois. Une requête de formulaire servie depuis ton propre domaine, via ton serveur, ne figure pas sur les mêmes listes de blocage que hsforms.net; ainsi, les visiteurs ayant des paramètres de confidentialité stricts ou utilisant des bloqueurs de pub peuvent toujours le voir et le remplir.

- Un cookie de suivi qui reste actif plus d'une semaine. Les cookies définis via un en-tête de réponse HTTP ne sont pas soumis à la limite de sept jours imposée par Safari aux cookies JavaScript pour « hubspotutk », mais seulement si ton serveur parvient à contourner le mécanisme de protection distinct de WebKit, qui masque les adresses CNAME et IP et qui, lorsqu'il se déclenche, limite également à sept jours la durée de vie des cookies définis via HTTP.

Pour en profiter pleinement, il faut que ton serveur soit hébergé sur un véritable sous-domaine de première partie avec une plage d'adresses IP correspondant à celle de ton site principal, comme expliqué dans la section « Configuration » ci-dessous. Le moyen le plus fiable de garantir cette correspondance est de faire passer ton conteneur de serveur par un Cloudflare Worker de la même origine que ton site principal, via un chemin du type votredomaine.com/metrics plutôt que par un sous-domaine distinct, car la vérification de correspondance d'adresse IP de Safari ne s'applique pas du tout dès lors que tout provient véritablement de la même origine.

- Une attribution qui reflète la réalité. Il y a moins de sessions perdues en cours de route, ce qui fait que les rapports « Source d'origine », « Dernière source » et « Multi-touch » se rapprochent davantage de la réalité. C'est super important quand tu décides de ton budget : une attribution qui sous-estime les leads payants ou organiques te pousse à supprimer les canaux qui fonctionnent bien.

- Des événements comportementaux personnalisés fiables. L'envoi d'événements server-side via l'API de HubSpot garantit qu'un bloqueur de pub du côté du visiteur n'a aucune incidence sur la transmission de l'événement à HubSpot.

- Un meilleur contrôle sur ce que tu envoies. C'est toi qui décides exactement quels champs sont transmis à HubSpot et à quel moment, ce qui fait de la minimisation des données et du respect du consentement une question de configuration plutôt qu'une simple question de chance.

- Une page plus légère. Moins il y a de scripts côté client qui se disputent le thread principal, moins ça affecte le temps de chargement, ce qui est important tant pour le taux de conversion que pour les Core Web Vitals.

Au final, tout ça te permet d'avoir encore plus de prospects parmi ceux que tu génères déjà, qui sont bien enregistrés dans HubSpot, correctement attribués et prêts à être exploités par tes workflows et tes rapports.

Ce dont tu as besoin avant de commencer

La mise en place du suivi server-side pour HubSpot ne nécessite pas de refonte. La plupart des étapes ne s'effectuent qu'une seule fois, et tu disposes peut-être déjà de certains éléments si tu utilises GA4 server-side.

Voici la liste de contrôle complète à consulter avant de créer des balises HubSpot :

• Un compte Google Tag Manager avec un conteneur Web et un conteneur serveur. Si tu débutes avec GTM, commence par consulter le guide du débutant.
  
• Une couche de données opérationnelle sur ton site, ou au minimum une balise de configuration GA4 qui transmet les données de base sur les pages et les événements vers ton conteneur serveur. Le guide de configuration server-side de TAGGRS t'explique comment mettre en place cette connexion, car la plupart des balises HubSpot dans le conteneur serveur s'appuient sur des données qui lui parviennent déjà par ce biais.
  
• Un conteneur de serveur TAGGRS, déployé avec un sous-domaine propriétaire sur ton propre domaine. Crée un compte gratuit pour commencer ; l'offre gratuite couvre jusqu'à 10 000 requêtes par mois, ce qui est suffisant pour la plupart des configurations initiales.
  
• Un jeton d'accès à une application privée HubSpot. HubSpot a désactivé ses anciennes clés API le 30 novembre 2022. Crée une application privée dans Paramètres > Intégrations > Applications privées, et attribue-lui uniquement les périmètres dont tu as réellement besoin : crm.objects.contacts.write et crm.objects.contacts.read pour les fiches de contact, ainsi que analytics.behavioral_events.send si tu envoies des occurrences d’événements comportementaux personnalisés. Si tu souhaites également créer ou modifier des définitions d’événements via l’API plutôt que via l’interface utilisateur, il s’agit d’un champ d’application distinct : behavioral_events.event_definitions.read_write. Le guide des applications privées de HubSpot explique les étapes à suivre. Copie le jeton dès qu’il est généré. HubSpot ne t’affichera plus jamais la valeur complète.
  
• Si tu envoies des événements comportementaux personnalisés, tu dois d'abord créer les définitions d'événements dans HubSpot. HubSpot a besoin que l'événement et ses propriétés soient définis avant d'accepter une occurrence envoyée via l'API. Tu peux le faire via « Gestion des données » > « Gestion des événements » dans l'interface utilisateur, ou via l'API de définition d'événements si tu préfères utiliser un script.
  
• Une configuration de consentement qui couvre ton conteneur serveur, et pas seulement la bannière propre à HubSpot. La bannière de consentement intégrée à HubSpot ne bloque que les cookies HubSpot et les intégrations natives à HubSpot. Elle n'a pas accès à un conteneur serveur GTM personnalisé ; tu devras donc faire en sorte que ta plateforme de gestion du consentement transmette directement son signal à GTM. La configuration du Consent Mode de TAGGRS et le guide d'intégration de CookieConfirm montrent tous deux comment cette connexion fonctionne concrètement.

Étape par étape : configurer le suivi server-side HubSpot avec Google Tag Manager

Voici la procédure complète, du début à la fin :

1. Déploie le conteneur de ton serveur TAGGRS et connecte-le à un sous-domaine de ton propre domaine (par exemple measure.tondomaine.com). C'est ce qui permet aux cookies créés par ton serveur d'être considérés comme des cookies « de première partie » plutôt que « de tierce partie ».

2. Vérifie que ta couche de données transmet bien les données au conteneur serveur. La plupart des configurations procèdent ainsi en envoyant un événement de configuration GA4 depuis le conteneur web ; le conteneur serveur a alors accès aux mêmes données d'événement pour chaque balise que tu crées par-dessus, y compris HubSpot.

3. Crée ton application privée HubSpot et copie le jeton d'accès. Enregistre-la sous forme de variable GTM server-side, et non pas comme une valeur codée en dur dans une balise, pour pouvoir la modifier plus tard sans avoir à modifier toutes les balises qui l'utilisent.

4. Ajoute une balise à ton conteneur serveur qui appelle l'API de HubSpot. Commence par chercher une balise serveur HubSpot existante dans la Template Gallery de Google Tag Manager.

5. Configure le tag « Créer ou mettre à jour un contact ». C'est cette étape qui transforme l'envoi d'un formulaire en fiche de contact. Au minimum, associe une variable d'e-mail de contact issue de ta couche de données à la requête, car c'est l'e-mail que HubSpot utilise pour déterminer s'il faut créer un nouveau contact ou mettre à jour un contact existant.

Ensuite, ajoute les propriétés personnalisées que tu veux suivre (détails de la source du prospect, chemin d'accès à la page, nom du formulaire) en tant que champs supplémentaires dans le corps de la même requête. Ce que tu définis ici, c'est ce que ton équipe commerciale et tes rapports verront ; ça vaut donc le coup d'en définir un peu plus que le strict minimum tant que tu y es.

6. Configure le suivi des événements comportementaux personnalisés, si tu en as besoin. Associe le nom de l'événement et ses propriétés de manière à ce qu'ils correspondent exactement à ce que tu as défini dans HubSpot lors de l'étape de configuration ci-dessus. Les noms doivent correspondre au nom interne généré par HubSpot, et non au libellé d'affichage, sinon l'événement sera rejeté.

7. Ajoute des déclencheurs pour chaque balise. Une balise « contact-create » se déclenche généralement lors des événements de soumission de formulaire déjà présents dans ta couche de données. Une balise d'événement comportemental se déclenche lors de n'importe quel événement personnalisé que tu suis (une consultation de la page des tarifs, une vidéo visionnée jusqu'au bout, un ajout au panier sur une intégration e-commerce connectée à HubSpot).

8. Teste tout en mode « Aperçu » de GTM, en activant l'aperçu à la fois sur le conteneur Web et sur le conteneur serveur. Le guide de test de TAGGRS explique comment analyser le flux de requêtes entre les deux. Envoie un vrai formulaire de test et vérifie que le contact apparaît (ou est mis à jour) dans HubSpot, puis déclenche un événement comportemental de test et vérifie qu’il s’affiche bien dans l’historique du contact.

9. Fais fonctionner la nouvelle configuration en parallèle de ton code de suivi HubSpot actuel pendant une courte période, au lieu de le supprimer tout de suite. Ça te permettra de comparer le nombre de contacts créés et le volume d'événements avant de basculer complètement, et ça te protégera au cas où quelque chose serait mal configuré dans la nouvelle installation.

10. Publie ton serveur et tes conteneurs web une fois que les tests semblent ok.

Une fois publiée, la modification est immédiatement effective pour tous les visiteurs, et les données commencent à transiter par ton propre domaine dès le prochain envoi de formulaire. À partir de là, le travail consiste simplement à gérer les balises et les règles de consentement. Tu n'as plus besoin de dépanner un script côté client à chaque fois qu'un navigateur modifie ses règles de confidentialité.

Les erreurs courantes à éviter

Quand une configuration HubSpot server-side ne fonctionne pas correctement, ça ne génère généralement pas d'erreur. Les balises semblent fonctionner, mais soit les données n'arrivent pas jusqu'à HubSpot, soit elles sont mal transmises ; du coup, le problème passe souvent inaperçu jusqu'à ce qu'un rapport te semble bizarre. Voici les erreurs qui en sont le plus souvent à l'origine :

• Envoyer des événements comportementaux personnalisés avant de les définir dans HubSpot. HubSpot rejette tout événement qu'il ne reconnaît pas déjà ; du coup, la balise se déclenche, mais rien ne s'enregistre, et il n'y a pas d'erreur évidente qui te permette d'identifier la cause. Définis d'abord l'événement et ses propriétés dans HubSpot, à chaque fois.
• Des champs manquants ou erronés dans le jeton de l'application privée. Un jeton dont la portée n'est pas correcte ne génère pas d'erreur visible. Le tag s'affiche comme « déclenché » alors que HubSpot rejette la requête en silence ; les contacts ou les événements n'apparaissent donc jamais. Vérifie le code de réponse réel en mode aperçu du conteneur serveur plutôt que de te fier au statut « déclenché ».
• Aucune adresse e-mail de visiteur n'est disponible au moment où la balise se déclenche. C'est grâce à l'adresse e-mail que HubSpot décide s'il faut mettre à jour un contact existant ou en créer un nouveau. Sans elle, l'opération échoue carrément ou génère un contact en double sans aucune information permettant de le faire correspondre, ce qui, au fil du temps, pollue discrètement ta base de données. Assure-toi que la variable d'e-mail soit renseignée avant que le tag ne s'exécute.
• On fait tourner les systèmes de suivi anciens et nouveaux en parallèle, sans plan de nettoyage. C'est une bonne idée de faire tourner les deux pendant quelques semaines pour pouvoir les comparer, mais si les deux continuent à créer des contacts et des événements indéfiniment, tu vas compter deux fois les mêmes éléments et gonfler tous les rapports basés sur ces données. Décide dès le départ laquelle des deux configurations est ta « source de vérité », et désactive l'autre dès que tu fais confiance aux chiffres.
• En partant du principe que le cookie server-side dépasse automatiquement la limite de sept jours. Ça ne marche que si ton sous-domaine ne pointe pas (via un enregistrement DNS CNAME) vers un domaine tiers et si la plage d’adresses IP de ton serveur correspond à celle de ton site principal. Si l’une de ces conditions n’est pas remplie, Safari réapplique la même limite de sept jours que tu avais contournée server-side, donc tu as tout le travail de configuration sans profiter des avantages en termes d’attribution. Le routage via une configuration Cloudflare Workers de même origine est le moyen le plus fiable de garantir cette correspondance.
• Transmission de données à caractère personnel avant d'avoir vérifié le consentement. Le server-side te donne plus de contrôle sur ce que tu envoies, mais seulement si tu intègres réellement la vérification du consentement dans les conditions de déclenchement de chaque balise. L'architecture n'impose pas le consentement à ta place, et c'est en partant du principe qu'elle le fait qu'une configuration respectueuse de la vie privée peut discrètement devenir non conforme.
• Pas de couche de données, ou alors elle est incohérente. Ici, chaque balise dépend du fait que les données parviennent au conteneur serveur sous une forme prévisible. Quand les noms d'événements ou les clés de paramètres varient d'une page à l'autre, les balises cessent de se déclencher sans raison apparente, et tu te retrouves à déboguer la balise alors que le vrai problème se situe en amont. Définis une nomenclature cohérente avant de construire quoi que ce soit dessus.

D'autres outils qui valent le coup d'être associés à ta configuration HubSpot

Si tes prospects proviennent de Google Ads, cette fonctionnalité protège directement tes rapports publicitaires. Le GCLID est le marqueur utilisé par Google pour associer un clic à une conversion. Lorsque Safari le supprime de l'URL, Google Ads ne peut plus déterminer quels clics ont généré des clients. Du coup, ton ROAS semble moins bon qu'il ne l'est en réalité et l'algorithme s'optimise sur la base de données erronées. La fonctionnalité « Click ID Recovery » rétablit les valeurs GCLID que Safari supprime des URL avant même qu’elles n’atteignent ton formulaire.

HubSpot ne récupère pas automatiquement le GCLID. Tu dois créer une propriété de contact personnalisée dont le nom correspond au paramètre de l'URL, puis l'ajouter à ton formulaire en tant que champ masqué. Le système de correspondance des champs masqués de HubSpot la remplira automatiquement lorsqu'un visiteur arrivera avec ce paramètre dans l'URL. Une fois cette étape franchie, notre guide sur la correction des imprécisions du ROAS dans GA4 explique comment le GCLID enregistré est transformé en conversion hors ligne une fois la transaction conclue, et notre guide sur les conversions améliorées aborde plus en détail la procédure de téléchargement.

Le script de suivi amélioré masque et crypte la requête entre le navigateur et le serveur, ce qui permet à davantage d'événements d'échapper à la détection des bloqueurs de pub avant même d'atteindre ton conteneur serveur.

Si tu gères du trafic en provenance de l'UE, associe cette configuration au Consent Mode V2 pour que les signaux de consentement soient transmis avec les données jusqu'à HubSpot, et pas seulement aux balises de Google. Notre présentation du RGPD pour le suivi server-side t'en dit plus sur ce que ça implique concrètement.

Conclusion

Le suivi côté client de HubSpot a été conçu pour un univers des navigateurs qui n'existe plus vraiment. Entre la limite de sept jours imposée par Safari pour les cookies, les bloqueurs de pub qui suppriment complètement le script et les navigateurs qui classent de plus en plus d'outils marketing comme présentant un risque de « fingerprinting », se fier uniquement au navigateur, c'est perdre des contacts, attribuer à tort ceux que tu conserves et passer à côté d'événements qui devraient alimenter tes scores de prospects.

En transférant cette connexion server-side, via Google Tag Manager et TAGGRS, la requête passe par ton propre domaine plutôt que par celui de HubSpot, où les bloqueurs de publicités et les paramètres de prévention du suivi n'ont rien à détecter. Ça te permet aussi de contrôler ce qui est envoyé à HubSpot et à quel moment, ce qui facilite la gestion de la confidentialité, au lieu de la compliquer.

Prêt à te lancer ? Crée un compte TAGGRS gratuit ou réserve une démo pour qu'on discute ensemble de la configuration de ton HubSpot.

FAQ

C'est quoi, le suivi server-side pour HubSpot ?

Le suivi server-side pour HubSpot consiste à faire passer par ton propre serveur les données qui, normalement, seraient envoyées directement du navigateur d'un visiteur vers les serveurs de HubSpot. Au lieu que le script HubSpot appelle directement js.hs-scripts.com ou hsforms.net, ton serveur reçoit l'événement et le transmet aux API CRM et Events de HubSpot via une connexion authentifiée. Du coup, les données parviennent à HubSpot même quand les bloqueurs de pub ou les paramètres de confidentialité du navigateur auraient bloqué le script standard server-side.

Est-ce que HubSpot prend en charge le suivi server-side de manière native ?

Pas dans le sens où la plupart des gens l'entendent. Le code de suivi, les formulaires et la bannière de consentement propres à HubSpot sont tous conçus pour fonctionner côté client, et ses intégrations natives se synchronisent via l'API CRM plutôt que par le biais d'un gestionnaire de balises server-side. Pour obtenir un véritable suivi server-side, la plupart des équipes associent un conteneur serveur Google Tag Manager aux jetons d'accès de l'application privée de HubSpot ainsi qu'à ses API « CRM Objects » et « Custom Behavioral Events », en utilisant un hébergeur comme TAGGRS pour faire tourner le conteneur serveur.

Quel impact ça a sur l'attribution des prospects et des contacts dans HubSpot ?

En général, ça améliore les choses. Les rapports « Source d’origine », « Dernière source » et d’attribution de HubSpot reposent sur la persistance d’un cookie de suivi d’une session à l’autre pour un visiteur. Quand ce cookie est limité à sept jours par l’ITP de Safari, ou bloqué complètement par un bloqueur de pub, HubSpot perd le fil entre les premières recherches d’un visiteur et son envoi final du formulaire. Le suivi server-side, combiné à un sous-domaine propriétaire correctement configuré, prolonge la durée de vie de cette identité, ce qui signifie que davantage de contacts sont attribués au canal qui les a réellement amenés sur le site.

Le suivi server-side de HubSpot est-il conforme au RGPD ?

Oui, à condition que la configuration soit pensée en tenant compte du consentement. Comme les données transitent par ton propre serveur avant d’atteindre HubSpot, tu contrôles exactement ce qui est transmis, ce qui facilite l’application du principe de minimisation des données et permet de vérifier le statut de consentement d’un visiteur avant que toute donnée personnelle ne quitte ton serveur. La bannière de consentement propre à HubSpot ne s'étend pas à un conteneur de serveur personnalisé ; tu as donc toujours besoin de ta plateforme de gestion du consentement pour transmettre directement son signal à ta configuration Google Tag Manager, comme expliqué dans la section de configuration ci-dessus.

Tu as besoin de supprimer le code de suivi standard de HubSpot ?

Pas tout de suite. Le mieux, c’est de faire tourner les deux en parallèle pendant quelques semaines. Ça te permettra de comparer la création de contacts, le volume d’événements et l’attribution entre les deux configurations avant de te décider. Une fois que tu auras confiance dans les chiffres server-side, tu pourras décider soit de supprimer complètement le code côté client, soit d’en conserver une version allégée pour des éléments comme le widget de chat HubSpot, qui dépend toujours du jeton d’identification du visiteur exécuté dans le navigateur.