Bienvenue sur la documentation Addingwell

Notre documentation a été créée pour vous accompagner dans une implémententation server-side réussie. Vous y trouverez des tutoriels d'implémentation détaillés : que ce soit pour vos premiers pas chez Addingwell, le set-up des cas d'usage (Meta CAPI, Google Ads, ...), mais aussi pour l'optimisation de votre setup : (by-pass des ad blockers, by-pass de l'ITP Safari, envoi des données utilisateurs,...). Cette documentation est régulièrement mise à jour, n'hésitez pas à y revenir régulièrement pour découvrir de nouveaux articles !

Avant de passer dans le vif du sujet, nous vous proposons ci-dessous un tour d'horizon sur le tracking server-side pour bien comprendre ses enjeux, ses bénéfices clés et son fonctionnement. Bonne lecture !

Comprendre le tracking server-side : contexte, solution & avantages

Contexte : de nouveaux freins au tracking

Le contexte lié à la collecte des données des sites web est en constante évolution. Depuis quelques années, les freins au tracking se multiplient : la réglementation a été modifiée, de nouveaux outils bloquant le suivi sont apparus, et des restrictions ont été mises en place par certains navigateurs.

1. Tout d’abord, les réglementations concernant la collecte de données se sont durcies. En Europe, par exemple, des normes de protection de la vie privée ont été instaurées via le RGPD. Le consentement est obligatoire (via un bandeau de cookies) pour que l’utilisateur indique s’il accepte le tracking de sa navigation par un outil analytique et/ou le suivi de ses données à des fins publicitaires. D’autres régulations existent dans d’autres pays (LAW 25 au Québec, CCPA en Californie…).
2. Les adblockers peuvent, quant à eux, détecter les traceurs tiers (comme GTM ou même Google Analytics) et les bloquer. On estime que 25 % des Français possèdent aujourd’hui un adblocker sur leur navigateur. Et ces extensions anti-tracking seront de plus en plus utilisées dans les années à venir.
3. Le tracking est également menacé par les évolutions techniques des navigateurs. Firefox et Safari bloquent déjà les cookies tiers, qui sont utilisés pour tous les tags publicitaires.
4. De la même manière, après de nombreux changements de cap sur le sujet, Chrome a finalement décidé de laisser le choix aux utilisateurs avec la possibilité d’accepter ou de refuser les cookies tiers à partir de 2025. Comme observé avec le bandeau de cookies pour le RGPD, il est fort probable que beaucoup d’utilisateurs refuseront les cookies tiers sur Chrome.

Tous ces freins au tracking conduisent aujourd’hui à une forte dégradation de la fiabilité des données et à une déperdition très importante du volume de données collectées. Il est donc de plus en plus difficile de se baser sur des données réalistes, et pour un annonceur, d’obtenir de bonnes performances publicitaires sur le digital car :

• la fiabilité des données est dégradée dans les outils analytics
• il est de plus en plus difficile de correctement attribuer son ROI
• le reach du retargeting est plus faible

La solution : le passage au tracking server-side

Pour pallier ces nouveaux freins dans votre collecte de données, la meilleure option reste le passage au tracking server-side. Voici les 3 avantages principaux qu’offre une implémentation réussie :

1. Une collecte de données améliorée. En passant au tracking server-side, vous franchissez une première étape pour contourner les adblockers, ainsi que les protocoles ITP/ETP (blocage des cookies tiers sur Safari, Firefox). Mais il faudra pousser l'implémentation plus loin (comme proposé dans la solution Addingwell) pour que cela soit bien fonctionnel. Enfin la transmission de données de serveur à serveur va vous aider à compenser la perte de données liées à la limitation des cookies tiers. Cet envoi de data via le serveur est aujourd'hui fortement recommandé par les plateformes publicitaires : Meta CAPI, Pinterest CAPI, Tiktok... pour venir compléter l'envoi de données traditionnel (via un pixel) et vous assurer un suivi optimal de vos conversions.
2. Amélioration du temps de chargement de votre site. Les exécutions de tags depuis le serveur permettent d’éviter de charger chacun des scripts médias ou analytiques depuis le navigateur, améliorant ainsi mécaniquement les performances de votre site.
3. Une meilleure gouvernance des données. En passant par un serveur intermédiaire, vous avez la main sur ce que vous souhaitez faire des données collectées en les envoyant depuis votre serveur. C’est à vous de choisir quelles informations envoyer ou non à vos différents partenaires (Analytics, Media), ce qui vous garantit un contrôle total dans cette chaîne de collecte et de transmission. Ce n’est pas le cas avec un tracking traditionnel côté web, où il est difficile de savoir quelles données sont récupérées par un SDK publicitaire depuis un navigateur et de maîtriser totalement ces données.

Aller plus loin avec Addingwell : des bénéfices supplémentaires

Pour aller encore plus loin et bénéficier du plein potentiel du server-side, la solution Addingwell vous offre 3 avantages supplémentaires :

4. Le by-pass des adblockers. Le server-side ne permet pas nativement de contourner les adblockers installés sur les navigateurs de vos utilisateurs. Notre solution permet de charger les librairies JS de Google Tag Manager et de Google Analytics 4 depuis des urls non détectables via un CDN. Les adblockers ne peuvent donc plus détecter les requêtes vers ces librairies, ni les bloquer.
5. Contournement de l'ITP de prévention Safari. Via Addingwell, vous pouvez contourner les nouvelles limitations sur la durée des cookies imposées par Safari, ét récupérer ainsi des données sur les visiteurs de plus de 8 jours sur l'environnement Apple
6. Une implémentation facilitée. La solution Addingwell a été pensée pour vous faciliter au maximum la transition vers le tracking server-side :

• Installation sans effort : Commencez à utiliser notre service en quelques minutes seulement !
• Infrastructure de premier ordre : Nous utilisons les meilleures technologies du marché pour garantir que nos serveurs fonctionnent toujours à pleine capacité, offrant rapidité et robustesse.
• Support réactif et compétent : Notre équipe comprend le tagging et est là pour vous aider dès que vous avez besoin d'assistance.
• Un monitoring de vos données en production via votre espace de travail, pour comprendre facilement les évènements reçus et envoyés par votre serveur à vos différents prestataires, et corriger les éventuels problèmes liés à votre implémentation.

Tracking Client-Side et Tracking Server-Side : Fonctionnements

Maintenant que vous connaissez les avantages liés à l'implémentation d'un tracking en server-side, il est temps de rentrer dans le détail et de comprendre concrètement ce qui distingue le fonctionnement entre le client-side et le server-side.

Contrairement à la collecte de données depuis le navigateur d’un utilisateur (communément appelée tracking web ou tracking client-side), la collecte server-side implique un serveur en tant qu’instance intermédiaire.

Fonctionnement du Tracking Web (appelé aussi Tracking Client-Side)

Voici un schéma d’une implémentation de tracking côté web :

En simplifiant, votre Google Tag Manager web est un conteneur qui se charge depuis le navigateur de l’internaute. Comme son nom l'indique, il "contient" tous les tags analytiques et médias que vous avez paramétrés. Chaque tag se déclenche sur certains événements de navigation en appelant les scripts d’un ou plusieurs prestataires.

Dans notre exemple ci-dessus, sur un événement de navigation sur le site (une page vue par exemple), notre tag GA4 se déclenche en faisant appel à la librairie GA4 : une requête part donc du navigateur vers google-analytics.com/collect.

Comme expliqué précédemment, ce fonctionnement a un triple impact négatif :

• sur le temps de chargement de vos pages (tous les scripts sont chargés depuis le navigateur, ce qui ralentit la navigation),
• sur la maîtrise des données envoyées via ces scripts tiers (que vous ne contrôlez pas),
• sur la quantité de données collectées. Les cookies tiers deviennent obsolètes sur certains navigateurs, et les adblockers peuvent détecter certaines requêtes spécifiques (vers GTM ou Google Analytics par exemple) et bloquer l’envoi de ces données au partenaire final.

Fonctionnement du Tracking Server-Side

Voici le schéma d’une implémentation de tracking server-side :

Votre tracking server-side s'affranchit des problématiques de collecte de données tierces (3rd party) et améliore les performances de votre site web. En effet, vos données sont collectées depuis un seul type de tag dans votre conteneur web (dans notre exemple, un tag GA4). Ce tag envoie ensuite les données à votre serveur, configuré comme un sous-domaine de votre site pour garantir une collecte en first-party.

C'est depuis votre conteneur serveur que la requête (envoyée par le tag GA4 du conteneur web via une URL de transport) est réceptionnée, puis transformée par le client GA4 en objet de données. Les tags de vos prestataires sont ensuite déclenchés depuis votre serveur en utilisant les informations contenues dans cet objet de données.

Comme illustré dans le schéma :

• Tous vos tags analytiques et médias sont chargés depuis le serveur et non depuis le navigateur de l'internaute (à l'exception du tag GA4 initial qui reste déclenché depuis votre conteneur web), ce qui contribue à améliorer le temps de chargement de votre site.
• Vous gardez le contrôle sur les données envoyées à vos tags prestataires : vous avez la possibilité de bloquer ou d'ajouter les données souhaitées depuis votre conteneur serveur avant de les envoyer.
• Votre collecte de données se fait en first-party : les données sont transmises depuis votre domaine de navigation (example.com) à votre serveur de tracking (metrics.example.com, un sous-domaine de votre site).
• De plus, grâce à une optimisation du paramétrage de votre tracking server-side via la solution Addingwell, vous pouvez contourner les adblockers et les limitations de suivi imposées par Safari

Pour aller plus loin : fonctionnement du client GA4 dans votre conteneur server

Lors de votre première configuration server-side, vous allez découvrir un nouvel élément essentiel qui n'existait pas dans votre conteneur Google Tag Manager web : le client. (À ne pas confondre avec le « tracking côté client », qui se réfère au tracking opéré depuis le navigateur de l'internaute - cf. schéma « Client-side tagging »).

Un client est un élément de votre conteneur Google Tag Manager server qui sert de point d'entrée pour vos flux de données. Ce client analyse les requêtes HTTP entrantes et peut choisir de s'approprier l'une d'elles. Une fois qu'un client s'approprie une requête, aucun autre client dans le conteneur ne pourra traiter cette même requête.

Après avoir analysé et pris en charge une requête HTTP entrante, le client transforme les informations de la requête en un objet de données d'événement (Event Data Object). Cet objet de données peut ensuite être utilisé par les différentes balises dans le conteneur.

Le client le plus couramment utilisé est le client GA4. Il est conçu pour s'approprier les requêtes HTTP entrantes ayant une empreinte Google Analytics 4. Cela signifie que le client GA4 va analyser et s'approprier les requêtes envoyées par vos tags GA4 déclenchés depuis votre conteneur WEB. Une fois la requête prise en charge, le client GA4 transforme les informations contenues dans cette requête en un objet de données d'événement, sur lequel les tags et déclencheurs de votre GTM Server pourront s'appuyer !

Pour aller plus loin : fonctionnement des Tags côté server

Le fonctionnement des Tags dans votre conteneur Server est à peu près semblable à celui de vos tags côté Web . Ils peuvent être déclenchés sur un événement particulier et être enrichis par des données contenues dans l'objet de données d'événements (par exemple une valeur de conversion, un mail utilisateur...) via des variables.

Contrairement aux Tags côté Web qui se déclenchent via des évènements poussés via un datalayer, les Tags côté Server se déclenchent sur des Event Name contenus dans des objet de données d'événement.

A noter donc qu'un même objet de données d'événement peut bien servir de déclencheur pour plusieurs tags différents.

Prenons l'exemple d'un événement Purchase, que nous souhaitons envoyer depuis notre conteneur SERVER, à Google Analytics 4, Google Ads et Meta, enrichi de données utilisateurs (email par exemple), et de données e-commerce (valeur de conversion par exemple) :

Enfin, sur certains tags Server, comme le tag META CAPI d'Addingwell, le mapping des évènements natifs GA4 vers Meta se fait automatiquement. Ainsi, vous n'avez pas à vous préoccupper de renommer vos évènements (page_view en PageView par exemple) pour que META les comprennent. Sur ce même tag, vous n'avez pas non plus à vous préoccupper de renvoyer des user_data, ni de les hasher pour META : à partir du moment ou vos données utilisateurs sont bien envoyées à votre server, le tag gère cela pour vous !

Prêt à passer au server-side ?

Bravo, vous avez terminé notre introduction sur le tracking server-side, et surtout vous en avez compris les bénéfices principaux ! Vous êtes dorénavant prêt à créer votre espace de travail Addingwell, et à commencer votre implémentation en suivant notre documentation ! Si vous avez des questions durant votre set-up, n'hésitez pas à contacter notre équipe support