4 min.
Démystifier le tracking des données du côté serveur : le Google Tag Manager Server-Side et l’API des conversions de Facebook
1L’art de la gestion de projet2Un projet à succès commence par une bonne gouvernance3Cascade, agilité, demandes de changement?

Démystifier le tracking des données du côté serveur : le Google Tag Manager Server-Side et l’API des conversions de Facebook

  • Niveau Technique

Au cours des dernières semaines, j’ai reçu plusieurs questions de clients concernant le tracking de données du côté serveur. Dans cet article, j’essaierai de démystifier ce concept plutôt  technique. La vérité, c’est que l’effet combiné de la fin des données tierces, de la réduction de la durée de vie des données primaires (sur Safari) et de l’augmentation des besoins en termes de confidentialité fait en sorte que les dirigeants d’entreprises sont inquiets quant à l’exactitude de leurs données. Dans ce contexte, le lancement de Google Tag Manager Server-Side et de l’API des conversions de Facebook pique la curiosité des experts du marketing.

J’ai sélectionné quelques questions auxquelles je tenterai de répondre de manière concise :

  • En quoi consiste le tracking de données du côté serveur ?
  • Quels sont les avantages du tracking de données du côté serveur ?
  • Existe-t-il une différence entre la gestion de cookies du côté serveur et le tracking de données du côté serveur ?
  • Le tracking des données du côté serveur peut-il atténuer les effets d’ITP 2 ?
  • Devrais-je considérer de faire migrer mes efforts vers le tracking du côté serveur ?

Avant de plonger dans le vif du sujet, voici quelques définitions utiles :

  • Navigateur web : Un outil/logiciel (Chrome, Safari, Firefox) installé sur votre ordinateur qui vous permet de consulter des sites internet.
  • Cookies web : Une fonctionnalité des navigateurs web qui permet à un site internet d’emmagasiner des données durant une certaine période de temps (par exemple : un identifiant d’utilisateur anonyme, les préférences d’un utilisateur, etc.)
  • Serveur web : L’infrastructure qui héberge un site web (par exemple : adviso.ca) et présente les sites web au navigateur web.
  • Pixel espion ou pixel analytique : La portion d’un code installé sur un site web qui permet aux experts marketing de suivre les conversions et de construire des publics cibles.
  • Serveurs analytiques et publicitaires : Une infrastructure globale qui permet aux fournisseurs (Google, Facebook) de recueillir, d’emmagasiner et de transformer les données fournies par ses utilisateurs (marketeurs).

Voici une représentation simplifiée de l’architecture d’un site web :

Quelle est la différence entre le tracking du côté serveur et le tracking du côté client ?

Tracking du côté client

Habituellement, les opérations de tracking analytique et marketing se font grâce à un pixel (une portion de code). Le pixel est installé sur le site web. Lorsqu’un utilisateur arrive sur le site web, pour la première fois dans le cas présent, le pixel est téléchargé sur le navigateur web de l’utilisateur. Le pixel crée un cookie (le point 1 sur le graphique ci-dessous) dans le navigateur, dans lequel un identifiant anonyme est généré pour identifier l’utilisateur lors de ses interactions avec le site web (lorsqu’il navigue sur les pages ou clique sur les liens). Chaque fois que l’utilisateur interagit avec le site web, le pixel envoie un « événement » aux serveurs analytiques et publicitaires liés à l’identifiant anonyme se trouvant dans le cookie (le point 2 du graphique ci-dessous). Cet identifiant anonyme permet au fournisseur (Google, Facebook, etc.) de faire le lien entre l’événement et l’utilisateur. Le graphique ci-dessous illustre ce processus, que nous appellerons « tracking du côté client » (allant de votre navigateur au serveur analytique du fournisseur).

Tracking du côté serveur

Lorsque des fournisseurs (Google, Adobe, Facebook, etc.) parlent de tracking du côté serveur, ils font habituellement référence au processus qui permet d’envoyer des données de serveur à serveur – du serveur de votre site web au leur. Ce processus est invisible pour les navigateurs web et n’implique habituellement pas l’intervention de cookies. La création d’un identifiant (identifiant anonyme ou toute autre forme d’identification de l’utilisateur) est toujours nécessaire, mais cet identifiant peut être généré du côté serveur, ou encore transféré du navigateur au serveur. Le suivi du côté serveur n’a rien de nouveau – il est utilisé depuis de nombreuses années. Plusieurs fournisseurs offrent des fonctionnalités du côté serveur (des API pouvant être utilisées du côté serveur). Le graphique ci-dessous illustre ce concept. Le serveur web envoie les données directement aux serveurs du fournisseur (du serveur de votre site web au serveur analytique du fournisseur).

Quels sont les avantages du tracking du côté serveur ?

Voici les principaux avantages à migrer vos opérations de tracking du côté client au côté serveur :

  • Moins de pertes d’événements et de conversions attribuables au temps de chargement de la page et aux bloqueurs de publicités, ce qui améliore la précision de vos opérations de suivi.
  • Une plus grande confidentialité des données, puisqu’elles ne sont pas partagées avec le navigateur web.
  • Une meilleure performance de la page grâce à la réduction du nombre de balises et de pixels associés à votre page.

L’un des désavantages du tracking du côté serveur est qu’il requiert plus de travail en amont. Vous devenez responsable de la collecte de certaines données du côté client (données du navigateur, adresse IP, etc.).

Quelle est la différence entre les cookies web gérés du côté serveur et le tracking du côté serveur?

Cette question est sans doute la plus grande source de confusion en ce qui concerne le tracking du côté serveur. Faire migrer vos opérations de tracking du côté serveur ne signifie pas nécessairement que vous gérez (créez ou supprimez) les cookies de votre site web du côté serveur. De la même manière, vous pouvez gérer vos cookies du côté serveur sans faire migrer toutes vos opérations de suivi du côté serveur également. Prenons quelques minutes pour rappeler certains faits important au sujet des cookies.

Les cookies web sont créés :

  • Du côté client (navigateur web) — par exemple, le chargement d’un pixel analytique ou publicitaire sur votre navigateur web crée un cookie ;
  • Du côté serveur (serveur web) — par exemple, lorsqu’une page web est demandée, le serveur crée un cookie et l’envoie au navigateur au moment d’afficher la page. Ces cookies sont souvent utilisés pour emmagasiner des données sensibles quant à votre statut de connexion, vos préférences, etc. La plupart du temps, les pixels analytiques ou publicitaires (par exemple : JavaScript) ne peuvent accéder au contenu de ce type de cookies. Par conséquent, ces cookies sont considérés comme étant plus sécuritaires. L’équipe de Safari (Apple) encourage l’utilisation de ce type de cookies. Lorsqu’on parle de cookies gérés du côté serveur, il est question de ce type de cookies. Il s’agit bien sûr d’une explication simplifiée pour les besoins de cet article.

Lisez cet article pour en savoir plus sur la gestion des cookies web du côté serveur.

Tel que je l’ai expliqué plus haut, le tracking du côté serveur est simplement le procédé par lequel on envoie des données de serveur à serveur, plutôt que du navigateur au serveur. Mais attention : ne tenez pas pour acquis que le tracking du côté serveur implique nécessairement des cookies web gérés du côté serveur. Lisez la prochaine section pour comprendre pourquoi cette distinction est importante.

Le tracking du côté serveur peut-il atténuer les effets d’ITP 2 ?

Si vous n’êtes pas familier avec les répercussions d’ITP 2 sur la mesure des performances web, je vous invite à consulter l’article de ma collègue portant sur les effets d’ITP 2 sur vos indicateurs de performance web.

ITP 2 cible spécifiquement les cookies web. Par conséquent, si vos opérations de tracking du côté serveur ne gèrent pas de données du côté serveur, alors elles n’atténueront pas les effets d’ITP 2. Au moment d’écrire ces lignes, la durée de vie des cookies primaires, créés du côté serveur, n’a pas été écourtée par Safari. Traditionnellement, une entreprise entreprend le tracking du côté serveur afin d’améliorer la performance de sa page et la précision de ses données. L’intérêt grandissant pour les cookies gérés du côté serveur est né avec l’apparition d’ITP 2.

Devrais-je considérer de faire migrer mes efforts vers le tracking du côté serveur ?

Pour déterminer si le tracking du côté serveur convient à votre entreprise, il faut commencer par se poser les questions suivantes :

  1. Voulez-vous améliorer la performance de votre page web ?
  2. Voulez-vous protéger des données confidentielles ?
  3. Voulez-vous améliorer la précision de vos données ?
  4. Avez-vous accès à une équipe de développeurs web ?
  5. Comment prévoyez-vous gérer le consentement des utilisateurs du côté serveur (en empêchant l’utilisation de balises avant d’avoir obtenu le consentement de l’utilisateur) ?

Le désir de gérer les cookies du côté serveur ne devrait pas être la seule raison qui motive la migration de vos initiatives de collecte de données du côté serveur. L’explication est simple : si ITP 2 a des répercussions sur ces cookies, vous aurez investi temps et argent dans cette migration pour rien.

Le tracking du côté serveur demande un certain degré d’expertise. Il est plus difficile à maîtriser que le tracking traditionnel. Vous aurez besoin d’experts en ingénierie (des développeurs web). Google Tag Manager, Adobe Launch, Facebook Conversion API et Segment offrent tous leurs propres versions du tracking du côté serveur. Chacun d’entre eux a une manière différente d’effectuer ce suivi. Par exemple, Google Tag Manager Server-Side et Adobe Launch Server-Side proposent des versions hybrides de tracking du côté serveur, puisqu’ils dépendent encore des technologies du côté client.

J’espère que cet article vous a aidé à mieux comprendre la notion complexe de tracking du côté serveur. Pour toute question, n’hésitez pas à nous contacter.