Sécuriser les KPI stratégiques avec la collecte server-to-server

Les Tag Management Systems Server sont assez récents, mais les concepts de collecte server-side ne sont pas neufs pour autant. Sur Universal Analytics, l’utilisation du Measurement Protocol permettait déjà, en quelque sorte, d’envoyer des données depuis un serveur avant l’apparition des TMS server. A travers l’API du Measurement Protocol, Google Analytics permet l’envoi de données en direct sans implémenter de tags sur le site (par exemple depuis un back-office). Ce procédé utilisé par quelques acteurs a démontré son efficacité en termes de qualité de données, mais il était réservé à Google Analytics. Maintenant que le tracking server-side devient un standard et que chacun dispose d’un TMS Server, il devient intéressant de se pencher à nouveau sur cette méthode de collecte aux nombreux avantages, pour l’étendre à sa collecte média.

A retenir

• Le “Full” server-side (ou server-to-server) est une méthode de collecte qui ne remplace pas les tracking server-side “Hybrides”, mais qui vient seulement en complément pour augmenter et enrichir la collecte.
• Le server-to-server est généralement plutôt adapté aux évènements de conversion.
• Pour justifier sa mise en place, il est recommandé d’inscrire un projet “Full” server-side dans une approche de collecte globale dans laquelle s’intègrent un ensemble de use cases (pilotage à la valeur, tracking des conversions offline, etc.)

Hybride et Full server-side : Deux approches parfaitement complémentaires

Cela fait maintenant longtemps que l’on parle de tracking server-side, bien avant même l’explosion des migrations server autour des sujets de la privacy et de la fin des cookies tiers. Pour autant, il n’existe pas qu’une seule manière de concevoir un tracking server-side, et il y a souvent un peu de confusion autour du sujet. 

Migrer en server-side, cela signifie se munir d’un outil supplémentaire (un Tag Management System Server) qui sera intercalé entre une source de donnée (ex : le site web) et la plateforme de destination de cette donnée (ex : Google Analytics, Meta, Google Ads, etc.). Une fois cette nouvelle brique installée, s’offre alors plusieurs approches pour collecter sa donnée :

1. Le server-side “Hybride”, ou client-to-server :

Dans le TMS Client installé sur le site, un tag collecteur unique est installé en remplacement des tags analytics et média actuels. Ce tag collecteur a pour rôle d’envoyer les données vers le TMS Server. C’est ce TMS Server qui sera à son tour configuré avec des règles de déclenchement, des variables et enfin les tags migrés depuis le TMS Client. Le TMS Server génère alors lui-même les appels pour envoyer les données aux différentes solutions. C’est aujourd’hui la méthode privilégiée dans le cadre d’une migration server-side pour les raisons suivantes : 

• Basée sur les mêmes principes de collecte qu’une collecte client-side, la migration est rapide, scalable et permet de transitionner vers le server-side en toute agilité.
• C’est aujourd’hui la méthode recommandée par l’ensemble des éditeurs car elle permet de répondre rapidement à de nombreux enjeux actuels (cookies, first-party data, privacy, etc.) moyennant des efforts contenus.
• C’est le seul mode de collecte capable de garantir l’exhaustivité des événements et des données (consenties bien entendu) nécessaires au pilotage media et analytics.

     2. Le “Full” server-side, ou server-to-server :

Dans le cadre d’une collecte « full server-side », les données transitent d’un serveur à un autre serveur sans passer par un client (comme le navigateur d’un utilisateur par exemple). Cette approche n’est pas nouvelle, certaines technologies permettent déjà de faire cela depuis des années, comme le Measurement Protocol de Google Analytics. L’arrivée des TMS server-side permet désormais d’étendre ce mécanisme de transit de la donnée de serveur à serveur à un plus grand nombre de solutions (notamment les outils média). Les conversions peuvent donc désormais être envoyées aux plateformes média directement depuis le back-office. De plus, la collecte “full server-side” est aussi une méthode de collecte qui offre un bien meilleur niveau de qualité et ouvre enfin la porte à une collecte plus large et diversifiée (back-office, CRM, ERP, etc.)

Dans le cadre d’une migration server-side, la méthode privilégiée est donc, évidemment,  l’implémentation “Hybride” car plus exhaustive, plus proche d’un tracking web classique, tout en offrant beaucoup d’avantages (first-party data, privacy, etc.). L’implémentation “Full” server-side présente néanmoins des avantages propres et peut être un excellent complément à cette collecte hybride. Le “Full” server-side (même si le terme “Full” est trompeur) ne vient donc pas remplacer un tracking “Hybride”, et on préfèrera donc le terme de  “server-to-server” ou “S2S”.

Les avantages du tracking server-to-server

Une donnée plus propre et de meilleure qualité

Dans un tracking server-side “Hybride”, le principal point de fragilité se situe justement lors de la collecte côté client qui est sujette à des dérives multiples. Qu’il s’agisse des AdBlockers, les défauts dans le DataLayer, les erreurs et conflits Javascript dans les tags, les navigateurs et extensions toujours différents chez les visiteurs, les trackings client-side sont exposés à de nombreux risques qui empêchent la collecte exhaustive. Même s’il existe des solutions pour réduire l’impact des AdBlockers dans une collecte hybride (avec Addingwell par exemple), en confiant l’envoi des données au back-office, il n’est plus nécessaire de passer par le navigateur du visiteur et la donnée est transmise sous sa forme la plus propre directement au TMS Server. Ce dernier recevra donc la donnée en direct et ne pourra être interceptée par un AdBlocker. Enfin, la donnée sera même potentiellement plus riche.

Protéger les conversions et optimiser son ROI média

Avec les réglementations sur la protection des données, les équipes média souffrent déjà d’une collecte appauvrie alors même qu’elles dépensent continuellement du budget dans leurs campagnes. Sur cette donnée diminuée, certains acteurs voient encore leur donnée amputée un peu plus par des initiatives qui vont au-delà des restrictions légalement encadrées (Apple ITP, Firefox ETP, AdBlockers, etc.). Même si le tracking server-side ne permet pas de se soustraire au respect de la RGPD, il n’est pas interdit de protéger sa donnée de ces initiatives privées qui n’ont pas de cadre légal. Pour les équipes média, les enjeux sont alors très forts à maximiser la collecte, tout en respectant la RGPD et le consentement de la collecte.

Un dispositif technique aux multiples use cases

Lorsqu’on fait le choix du server-to-server, on peut le faire au départ pour ses conversions web et la qualité des données inhérente à ce type de tracking. Néanmoins, la mise en place d’un tel dispositif ouvre la porte à de nouveaux use cases à forte valeur. Il est d’ailleurs recommandé de recenser l’ensemble des use cases envisagés dès les phases d’initialisation de projet afin de construire une architecture de collecte globale et ambitieuse.

Exemples de use cases : 

1. Un setup “Offline Conversion Ready” : Configurer un TMS Server pour réceptionner la donnée issue d’un back-office, c’est déjà faire la moitié du travail nécessaire pour mesurer des conversions offline. Dans le secteur du luxe par exemple, l’essentiel des transactions se fait en boutique. Pour les compagnies d’assurance, le site web collecte principalement des leads, mais les conversions se font offline.

2. Pilotage média à la marge : Puisque c’est le back-office qui transmet désormais la donnée sans passer par le client, il devient possible de transmettre des données sensibles difficiles à faire transiter côté client. Ajouter la marge à une transaction ecommerce offrira alors pilotage plus ROIste de son média.

Les points d’attention importants avant de se lancer

Le respect de la privacy et de la RGPD

La collecte server-to-server reste une collecte avec des finalités de traitement marketing, analytics, etc. Elle est donc (comme la collecte client-side ou la collecte hybride) soumise aux mêmes règles, et on veillera donc à ce que des conversions “non-consenties” ne soient pas collectées. Le back-office devra donc relayer l’état du consentement de l’utilisateur au TMS Server pour que ces règles soient respectées.

Une approche plutôt orientée conversion

Techniquement parlant, le back-office ne peut transmettre que les données dont il a connaissance et pour lesquelles il reçoit un signal : une transaction, une création de compte, une soumission de formulaire, une inscription à une newsletter, etc. Sont donc exclus les évènements et les interactions qui ont lieu sur une page sans communication avec un serveur.

Certains sites SPA (Single Page Application) qui sont bâtis sur des technologies telles que React, Vue, Angular, etc. ont tendance à communiquer plus régulièrement avec leur serveur pour mettre à jour le contenu rendu à l’écran. Il pourrait donc être envisageable de tracker en server-to-server certains events ou micro-conversions supplémentaires.

Les solutions compatibles

Toutes les solutions ne sont malheureusement pas compatibles avec la transmission de données server-to-server. Par exemple (et à l’heure où nous rédigeons cet article), les tags de conversion Google Ads et les Floodlights disponibles nativement dans GTM Server n’envoient pas de requête directement vers Google Ads ou Double Click, mais font exécuter l’appel depuis le navigateur client de l’utilisateur. Pour faire fonctionner ces solutions, le navigateur client est donc indispensable. Dans ce contexte, il est donc difficile de confier au seul back-office la remontée des conversions web. A ce jour, les solutions Google permettent uniquement l’upload de conversions offline via API.

En revanche, les solutions telles que Meta Facebook, Snapchat, TikTok, Pinterest, etc. ne fonctionnent pas de la même manière. Le déclenchement de leur tag respectif dans GTM Server génère un appel API direct vers les plateformes, sans passer par le navigateur client. Une collecte des conversions en server-to-server se prêtera donc assez bien aux acteurs qui sont fortement investis dans le social media.

En conclusion : le tracking server-to-server est-il fait pour tout le monde ?

Chez certains acteurs, la mise en place d’un projet de collecte server-to-server pour quelques tags média seulement peut être difficile à justifier. Pour d’autres acteurs en revanche, le social média représente une part très importante dans les stratégies marketing. Les budgets dépensés sur ces plateformes sont conséquents et les enjeux à maximiser la collecte sont aussi très forts. Aujourd’hui et pour ces acteurs-ci, l’approche server-to-server est une opportunité.

Par ailleurs, la collecte server-to-server ouvre également la voie à de nouveaux cas d’usage à forte valeur ajoutée, tels que le pilotage à la valeur et la collecte omnicanale de ses conversions offline. L’implémentation d’un tracking server-to-server devient alors très avantageux. D’ailleurs, certains clients de Converteo ont déjà opté pour ce procédé et commencent à remonter les commandes réalisées en boutique vers leurs outils media. Le TMS Server se distingue alors un peu plus de son homologue client-side en se positionnant comme un réel outil central de la collecte, capable de répondre à des cas d’usage jusqu’alors compliqués et longs à mettre en place.

Démarrer un projet Serveur 2 Server va forcément représenter un coût et impliquer de nombreuses équipes (notamment l’IT avec l’intégration d’un plan de marquage S2S). Le ROI d’une telle implémentation doit donc être mesuré et positif à terme. Dans cette optique, il est essentiel de se poser les bonnes questions et d’adopter une vision globale et à long terme. Réussir un projet server-to-server, c’est penser une collecte multi-sources de qualité, une collecte qui peut être enrichie, pour alimenter un ensemble d’outils et finalement servir des use cases à grande valeur.