Taggage “server-side” : J’y vais ou j’y vais pas ?

Avec la montée en puissance des enjeux liés à la Data, à la Privacy et au “First Party” dans le marketing digital, le sujet du taggage “server-side” revient souvent sur la table. La question sous-jacente, côté pilotage, est : “J’y vais ou j’y vais pas ?” ou encore, “J’y vais maintenant ou plus tard ?”. Dans cet article, on va tenter une approche synthétique afin d’aider à la décision.

Sommaire : 

Définitions utiles : 

  • Cookie 1st party : un cookie qui est associé au même nom de domaine que le site web visité. 
  • Cookie 3rd party (ou cookie tiers) : un cookie qui est associé à un domaine différent du site web visité (souvent un domaine d’une plateforme publicitaire).
  • ITP (Intelligent Tracking Prevention) : Fonctionnalité de confidentialité introduite par Apple sur Safari en 2017.
  • TMS (Tag Management System) : système de gestion des tags

3 problématiques principales

Dans un premier temps, posons sur la table trois principales problématiques souvent évoquées dans le contexte d’une stratégie “server-side”. Pour chacune de ces problématiques, nous allons aborder leurs impacts, et ce que peut apporter la technologie server-side.

Problématique 1 : La confiance en la Data (data quality)

Des décisions importantes sont prises sur la base des résultats observés dans les rapports Web Analytics. Des campagnes publicitaires sont également réglées et optimisées en fonction de données collectées. La fiabilité des données est donc un enjeu majeur.

Depuis ces dernières années, différents événements techniques ou réglementaires impactent la collecte de données :

  1. RGPD (réglementaire) : on perd une partie des données.
  2. Ad blockers (technique) : on perd une autre partie des données.
  3. Safari / iOS / Firefox(technique) : on perd encore des données (avec l’ITP, système de prévention du suivi qui bride considérablement l’usage des cookies)
  4. Cookies 3rd party de Chrome (technique) : en stand-by pour le moment, mais on s’attend à des évolutions prochaines qui amèneront certainement de nouvelles pertes de données 

Regardons ces différents points d’un peu plus près : 

1 – RGPD

Côté réglementaire, une partie des visiteurs ne donnent pas leur consentement. C’est normal, c’est acté. Et autant être clair dès le début, l’idée du server-side n’est pas de passer outre les consentements !

ℹ️  En France, on estime à environ 35 % la part des internautes qui ne donnent pas leur consentement
(source : Baromètre du Numérique Credoc – 2022)

⚠️ Impact : Une partie des données n’est pas collectée. Les KPIs de volumétrie des rapports Web Analytics perdent de leur sens (les proportions et les évolutions restent exploitables).Les fonctionnalités de ciblage publicitaire sont un peu moins précises.

2 – Ad blockers

Une proportion non négligeable d’utilisateurs équipent leurs navigateurs d’add-ons, appelés Ad blockers (bloqueurs de publicité). Le rôle de ces outils est principalement d’entraver le fonctionnement de processus à vocation marketing/publicitaire sur les sites visités. Parfois même, ces outils peuvent aller au-delà de cet objectif, en allant jusqu’à empêcher carrément le chargement de Tag Manager.

On l’a dit, sur le fond, il s’agit bien sûr de respecter les choix de l’utilisateur en termes de RGPD. Pour ça, votre site web est d’ailleurs vraisemblablement déjà équipé d’un gestionnaire de consentement (Axeptio, Cookiebot, Didomi…). 

Mais en chargeant un Tag Manager, en exécutant des tags et collectant des données dans le respect de la réglementation, vous faites simplement votre métier d’exploitant de site web, et vous pouvez légitimement viser l’objectif de ne pas laisser entraver vos outils conformes.

ℹ️  En France, environ 30 à 40 % des internautes (desktop) utilisent des ad blockers

⚠️ Impact : une partie supplémentaire des données n’est pas collectée. L’impact du point précédent (RGPD) est amplifié.

3 – ITP (Safari / Firefox…)

Le système ITP (Intelligent Tracking Prevention), lancé en 2017, est destiné à restreindre l’usage de cookies. Il est présent dans les navigateurs Safari et Firefox, entre-autres.

Il bloque notamment les cookies tiers, et purge les cookies 1st party après 7 jours.

ℹ️  En France, environ 32 % des internautes utilisent Safari (source Statista)

⚠️ Impact : Ici, ce sont surtout les capacités de targeting ou les modèles d’attribution des systèmes publicitaires tiers qui sont impactés (cookies tiers bloqués). Côté Web Analytics, ils ne peuvent plus reconnaître un utilisateur récurrent efficacement (cookies 1st party purgés sous 1 à 7 jours).

4 – Blocage des cookies 3rd party sur Chrome

Même idée ici : Après avoir d’abord évoqué un report de la dépréciation des cookie-tiers à 2025, Google a récemment annoncéque les cookies tiers sur Chrome ne seraient  finalement pas dépréciés (22/07/24). Malgré tout, ce blocage des cookies tiers reste une problématique à adresser. Même si les évolutions à venir de Chrome ne consisteront pas en un blocage pur et simple, on peut s’attendre à ce qu’elles laissent plus de contrôle aux utilisateurs avec, pour conséquence, une altération du fonctionnement actuel.

C’est notamment le buzz autour de ce point qui génère une augmentation récente de l’intérêt pour les technologies server-side.

ℹ️  En France, environ 57 % des internautes utilisent Chrome (source Statista)

⚠️  Impact : Cela va amplifier l’impact du point précédent (ITP) sur les cookies tiers. Donc surtout pour ce qui va concerner le targeting des campagnes publicitaires et les modèles d’attribution (chute du rendement des investissements publicitaires ou ROAS).

En résumé, en réduisant la quantité de données collectées, la masse statistique est naturellement fragilisée. La confiance dans les données est ébranlée et les stratégies marketing perdent un peu de leur précision et de leur efficacité. 

Apports du Server-side sur la confiance dans la data : 

Sur cette première problématique, une implémentation en server-side va permettre de réduire l’impact des limites techniques :

  • Réduire l’impact des Ad blockers (selon solution technique utilisée).
  • Réduire l’impact des limitations sur Safari / Firefox (ITP).
  • Réduire l’impact du blocage 3rd party sur Chrome.

⚠️  Attention, il y a différentes manières d’implémenter le server-side, assurant plus ou moins d’efficacité. Nous aborderons à la fin de l’article nos préconisations en la matière.

👍  Avec le server-side, la collecte de données sera plus large et plus qualitative, ce qui sera favorable pour optimiser les stratégies de campagne marketing et améliorer la qualité d’analyse d’audience.

 

Problématique 2 : Maîtriser la donnée collectée (data governance)

En client-side, les scripts des tags peuvent collecter certaines données sans que ce soit complètement transparent et maîtrisé. En effet, il est assez difficile de vérifier ce qui est effectivement capté et envoyé par le tag.

En server-side, la mise en place du taggage implique un procédé dans lequel est définie chaque donnée captée client-side et envoyée vers les tags server-side.

Apports du Server-side sur la Data governance : 

Sur cette deuxième problématique, le server-side apporte : 

  • Une visibilité totale des données véhiculées par les tags
  • Un contrôle total de ces données véhiculées par les tags (anonymisation / modification de données personnelles)
  • Les “vendors” (Meta, Google…) n’accèdent qu’aux données paramétrées sur les tags dans le Tag Manager.

👍  Le server-side permet de reprendre la main sur le contrôle des data impliquées dans les process Web Analytics et Marketing Digital.

 

Problématique 3 : Préserver les performances des sites Web

Dans un système de taggage côté client, les tags sont chargés et exécutés par le navigateur de l’internaute.

Certains tags, pris individuellement, sont déjà assez lourds (ex : Facebook Pixel). Mais pris tous ensemble, on a parfois des cumuls de charge significatifs et impactants pour les visiteurs.

© Smile

Apports du Server-side sur la Performance des sites Web : 

Sur la problématique de performance, le server-side apporte : 

  • Une optimisation/limitation de la quantité d’éléments traités côté Client.
  • Favorable pour l’expérience utilisateur (UX).
  • Favorable pour le SEO.

👍  Le server-side favorise les performances du site Web et le SEO.

 

Le “server-side”, kézako ?

Mais Jamy, c’est quoi un tag “server-side” ?

Habituellement un tag de suivi (tracking) est exécuté sur le navigateur du client. L’échange de données est direct entre le navigateur du visiteur et la plateforme marketing ou analytics. On parle alors d’un tag “client-side”.

En client-side : 

  • Chaque tag est chargé/exécuté par le navigateur.
  • Chaque tag collecte ses données (souvent les mêmes que d’autres tags).

Dans le cas d’un tag server-side, des informations sont transmises depuis le client-side vers un autre container hébergé sur un serveur dans le cloud, par l’intermédiaire d’un seul tag qui agit comme “transporteur”. Les tags sont alors exécutés avec ces données depuis le serveur vers les plateformes marketing ou analytics.

En server-side : 

  • Un seul tag de collecte est chargé par le navigateur.
  • Un seul tag de collecte prend les données pour les rendre disponibles aux tags server-side.

© Smile

Ok, mais à quoi ça sert ?

Grâce au fait que les tags soient exécutés depuis un serveur au lieu du navigateur/client, on obtient les caractéristiques suivantes : 

  • Un tag server-side ne dépose pas de cookie tiers sur le navigateur des visiteurs. Cependant, les cookies déposés par le serveur deviennent de la first party. 
  • Un tag server-side ne peut envoyer que des données reçues par le point d’entrée unique en provenance du client.
  • Un tag server-side ne s’exécute pas sur le navigateur des visiteurs. 

Cela confère alors ces principaux avantages : 

  • Amélioration de la qualité de données
    En limitant l’impact des Ad blockers ou des limitations liées aux cookies tiers, on collecte plus de données.
  • Maîtrise des données collectées
    En manageant le pipe de données vers les tags server-side, vous reprenez le contrôle de ce qui est envoyé et donc collecté.
  • Optimisation des temps de chargement
    En exécutant les tags en server-side, on allège le travail du navigateur. Cela va dans le sens de l’amélioration de l’expérience utilisateur, et l’optimisation SEO.
  • Méthode plus durable
    L’évolution des réglementations et des technologies tendent à augmenter l’intérêt du  server-side. En prenant le train assez tôt, on peut espérer une bonne pérennité, par opposition à tout ce qui tourne autour des cookies et du client-side

 

Quelques idées reçues

  • Le server-side permet de contourner les Ad blockers

À mon sens, c’est un peu vrai et un peu faux : ce n’est pas la vocation première du server-side. Cependant, il est vrai que

Ce n’est pas la vocation première du server-side. Cependant, en effet, logiquement en envoyant des tags server-side, ceux-ci ne seront plus entravés.

Mais pour faire fonctionner un taggage server-side, votre site doit quand même continuer d’utiliser un container de Tag Manager client-cide avec des tags qui font le lien vers le server-side. Ces tags “bridge” peuvent restés bloqués par un Ad blocker. Dans ce cas, on ne peut pas dire que le server-side contourne l’Ad blocker. Même chose si l’Ad blocker bloque carrément le Tag Manager.

En résumé, le server-side en soi, n’est pas suffisant pour contourner les Ad blockers.

On évoquera un peu plus loin dans cet article que des techniques d’implémentation avancée permettent de limiter l’impact des Ad blockers.

  • Le server-side permet de ne rien charger côté client

Là aussi, c’est à nuancer et pour la même raison : En fait, la plupart du temps quand on parle de taggage server-side, on parle en fait de “Client to Server to Server”. À noter qu’il existe un type d’implémentation avancée permettant de de faire du Server to Server (avec le Measurement Protocol, réservé aux connaisseurs).

Pour faire fonctionner un taggage server-side “classique”, votre site doit donc quand même continuer d’utiliser un container de Tag Manager client-side avec des tags qui font le “bridge” vers le server-side. Du coup, dans tous les cas, il reste des processes côté navigateur/client.

Mais en effet, certains tags, eux, seront déportés côté serveur. 

En résumé, le server-side (classique) peut réduire les chargements côté client, mais pas les éliminer complètement.

  • Le server-side c’est bien, mais c’est cher

Alors, sur le sujet du coût, tout est relatif (encore !?) : Si on se contente de regarder les coûts directs des solutions et du temps d’expert nécessaire à la mise en place, ça peut refroidir (sinon on ne fait rien et on ne dépense rien de plus).

Mais bien évidemment, je vais proposer ici d’élargir un peu la réflexion : je me suis livré à un rapide calcul sur un coin de nappe (bon ok … j’ai utilisé un tableur) que je voudrais vous partager : 

Partons sur une hypothèse d’un e-commerçant qui fait des campagnes SEA utilisant du retargeting. Nous avons quelques KPIs à disposition :

  • Il dépense 5 000 € / mois en SEA.
  • Son CPC moyen est de 1,5 € / clic.
  • Son panier moyen est de 140 € avec une marge brute de 40%.
  • Il observe un taux de conversion moyen issu du SEA à 3%.

Tout va bien dans le meilleur des mondes et tout ronronne avec environ 100 conversions par mois et une marge brute totale générée de 7 000 € / mois.  Les retombées directes du SEA sont positives à + 2 000 € / mois (marge brute – CPC-spending). Et puis un “beau jour”, on lui réduit ses capacités de targeting à cause d’une update de Chrome qui bloque les cookie tiers… À partir de là, ses campagnes étant un peu moins efficaces, il voit son taux de conversion descendre à 2%. Il perd alors 2 333 € de marge par mois, juste pour -1 % de taux de conversion… 

Je vous laisse vous projeter sur la suite, et imaginer d’autres scénarios. Mais en résumé, en mettant en perspective les coûts du server-side, c’est généralement plutôt rassurant. Ce qui risque d’être cher, c’est de ne rien faire.

Comment on fait ?

Alors, la question est assez large. Comme j’ai déjà utilisé beaucoup de votre précieux temps (et que des experts bien plus capés que moi sur le sujet proposent déjà d’excellentes ressources), je vais tenter de résumer ma façon de voir les choses de manière concise et simplifiée :

  • Méthode 1 : “old school”

Le client nous ouvre une instance serveur dans le cloud (souvent sur Google Cloud Platform car directement proposé par Google Tag Manager), on met tout en place pour véhiculer les data du client-side vers le server-side… On fait les tests, on voit les tags server-side partir… tout va bien. On fait du server-side !

Mais… sans s’en apercevoir immédiatement, on a des tags client-side ‘bridge’ bloqués par des adblocker… on a des container tag manager client-side bloqués par des Ad blockers… on peut avoir un souci sur l’instance Google Cloud pour une question de facturation que le client n’a pas géré… on peut avoir des problème sur des data mal collectées… etc.

On se retrouve rapidement avec un risque fort lié au manque de monitoring et un effet ‘boîte noire’. Bref, on y arrive, mais bon, c’est plein de petits tracas, souvent assez sournois et  impactant pour les perfs de votre opération “server-side”.

  • Méthode 2 : S’appuyer sur une solution/partenaire expert

Et puis, un beau jour, on découvre sur un forum de data/marketing, ou dans un article de blog, qu’une entreprise française propose une plateforme et des services répondant à ces problématiques.

On n’est plus seul, de véritables experts vous accompagnent. Des outils simplifient largement la mise en œuvre. La plateforme évolue régulièrement.

Bref, l’ensemble surclasse largement la méthode “old school”.

Ce partenaire technologique, c’est Addingwell. Et non, je n’ai aucune action chez eux (dommage d’ailleurs).  Il y a vraiment un gap (ce qui n’est pas illogique d’ailleurs). On voit rapidement qu’ils connaissent très bien leur sujet et que tout ce qu’ils mettent en place répond directement à des problématiques concrètes. On gagne énormément en temps de mise en place, en possibilités et en fiabilité.

Conclusion

J’y vais ou j’y pas ?

  • Vas-y !  Vu les problématiques de data et de performance déjà existantes, et celles à venir, il faut se positionner sur cette technologie (à part si tu ne fais pas d’acquisition de trafic / advertising du tout).

J’y vais maintenant ou plus tard ?

  • Tu le vois, mais ne tarde pas trop quand même : Au moment où les prochaines évolutions de Chrome liées aux cookies tiers vont arriver (2025 ?), il risque d’y avoir embouteillage de demandes d’implémentation de server-side.

Et je fais comment ?

  • Tu appelles UX-Republic (au hasard).
    • Nous étudierons le besoin et proposerons éventuellement à notre partenaire Addingwell de se joindre à nous pour vous mitonner un projet adapté.

    En tout cas, on déconseille d’y aller sans être accompagné. La complexité de mise en place d’un taggage server-side est un cran au-dessus d’une implémentation client-side (qui peut déjà s’avérer assez délicate).

 

 


Laurent Neuville, Consultant Web Analytics Senior chez Smile