Il existe 2 manières de collecter les signaux clients envoyés au cours de l’usage d’un site web ou d’une application mobile. La première méthode consiste à faire travailler le navigateur qui en chargeant la page exécutera de petits morceaux de code (« tags »).

Ce sont ces tags qui collectent et envoient les données (origine, contenu, profil,..) vers les partenaires que le client a autorisés. Dans ce premier cas, tout repose sur le navigateur. La seconde méthode consiste à envoyer la donnée sur le serveur qui va se charger au travers de règles d’alimenter directement les différents partenaires sur leurs serveurs. Dans ce second cas, la collecte, la transformation et le partage s’affranchissent du navigateur pour s’effectuer de serveur à serveur.

Le server-side est devenu le sujet principal discuté à la machine à café au sein des équipes digitales. À raison ? Voyons les opportunités qu’il représente.

• Qualité de la donnée collectée : l’approche server-side collecte les données de manière centralisée sur un serveur plutôt que de manière distribuée par chaque navigateur. Au passage sur le serveur, une bonne plateforme server-side permet de contrôler la qualité de la donnée, d’identifier des erreurs et de les corriger sur place plutôt que d’attendre un patch correctif de l’équipe technique. Toutes les équipes Data apprécient ce point car le nettoyage de la donnée est un enjeu majeur. Faire la même chose dans une approche tag est possible mais alourdit le conteneur au point parfois de dégrader l’expérience client et ne permet pas de procéder si facilement aux correctifs. Qualité de la donnée collectée signifie qualité de la donnée transmise et garantit le bon fonctionnement des solutions alimentées. Au chapitre de la fiabilité, ajoutons que le traitement « server-side » est aussi un moyen de réduire les écarts parfois observés (du fait des contraintes des navigateurs) entre les données analytiques et transactionnelles.

• Agilité des équipes : Vous connaissez tous ce qu’on appelle les périodes de « code freeze », ces moments où rien ne peut être modifié sur le site afin de ne pas prendre de risque dans une période critique. Dans une approche server-side, c’est toujours le même flux de données qui alimente le premier serveur. Quand ce flux doit être modifié, corrigé, transformé, ce n’est plus au sein du code source mais de manière asynchrone, au moment du passage via le serveur. Désormais, les correctifs peuvent avoir lieu à tout moment, la transmission de données supplémentaires aussi, la modification des données également. C’est un gain particulièrement utile.

• Meilleur contrôle de la conformité du traitement des données : une seule requête envoyée sur le serveur qui va ensuite traiter, adapter et répartir les données aux différents partenaires. L’éditeur du site est donc en mesure de garantir à ses visiteurs une application réelle des règles affichées en matière de traitement des données. Les équipes en charge de la conformité y trouvent une sécurité complémentaire. Le piggy backing n’est plus possible.

• Qualité opérationnelle du site : Ce sujet est un des plus importants dans l’univers digital puisque tous ces objets que sont les sites, les applications mobiles obéissent à des contraintes industrielles de scalabilité et de qualité. Rien de plus complexe à maitriser pour une équipe technique qu’un grand volume de « tags », plus ou moins compatibles, plus ou moins hétérogènes, et déployés parfois par des tiers sans toutes les précautions nécessaires. L’exemple le plus courant tourne autour du ralentissement des temps de chargements des pages, provoqués par des lourdeurs javascript, des conflits javascript ou encore d’alertes de sécurité dans des tunnels de conversion à cause d’un tag non sécurisé.

• Meilleure performance du site web : Réduire le volume de scripts présents sur les sites web, limite le risque d’une dégradation de l’expérience client, accélère le temps de chargement des pages et permet à l’équipe technique de respecter ses standards internes et parfois ses objectifs. Or nous savons à quel point la performance est au cœur de l’expérience client. Une seconde de délai peut impacter vos conversions de 7% (Strangeloop).

• S’affranchir des contraintes techniques liées aux navigateurs : les Ad-blockers, dont les listes noires bloquent les appels à certains services depuis le navigateur, ou tout simplement les mécanismes de filtrage des cookies, à l’instar de l’Intelligent Tracking Prevention (ITP) d’Apple. Avec le server-side, les appels sont effectués depuis le serveur, ils sont donc hors du champ d’action des Ad-blockers. Et comme le service invoqué côté serveur peut être hébergé sur un sous-domaine du site (et non sur un domaine tiers), il n’est pas intercepté par les mécanismes de type ITP. Attention, cela ne dispense nullement de se conformer aux règles de collecte des consentements et le server-side sait porter un signal de consentement, contrairement à ce qu’on peut entendre ici ou là.

• Productivité des équipes : Parfois, les équipes qui découvrent le server-side ont l’impression d’être démunies car elles n’envisagent pas qu’une plateforme puisse les aider à prendre le contôle de ces flux de données. Au final une plateforme server-side facilitent un certain nombre d’opérations sur les données qui sont, sans le server-side, soit impossibles, soit très complexes à réaliser et nécessitent la coordination entre plusieurs équipes. Parmi ces fonctions très utiles qui font de vous l’aiguilleur du paysage digital : le contrôle qualité en temps réel combiné à de l’alerting, l’enrichissement des données en temps réel avec des scores (crm, prédictif,…), la maîtrise des sources comme des destinations

• Dissociation Collecte/Partage : C’est sans doute la dimension la plus révolutionnaire. Désormais, si la collecte se fait toujours au niveau du device car c’est là que l’utilisateur interagit avec le site web, l’application mobile ou le device connecté, la transmission et la stratégie de partage et de circulation de la donnée se construit côté serveur. Le javascript présent au sein de la page web peut se limiter à l’essentiel, gagner en légèreté et moins mobiliser l’énergie du navigateur, lui permettant de délivrer le contenu plus rapidement. Dans beaucoup de cas, la période de « code freeze » n’a plus lieu d’être et les équipes peuvent continuer à optimiser leurs campagnes sans interagir avec le code source du site.

• Sécurité et respect de la vie privée : la philosophie du server-side offre un niveau de sécurité et de confidentialité supérieur à vos utilisateurs en supprimant les risques d’interception des données. Le RGPD a introduit l’idée que les marques ne sont que « locataires » des données, et non propriétaires. Par ailleurs les risques encourus sont importants. Dans ce contexte, construire la confiance des utilisateurs est encore plus essentiel et toute technologie qui protège l’accès à cette donnée va dans le bon sens. Moins de Piggy backing, moins de fichiers javascript qui se reconfigurent à la volée, des éléments que le régulateur devrait apprécier.

Dans le sillage du cookieless, le « server-side », autrement dit la collecte des données côté serveur, s’impose peu à peu dans la feuille des routes des équipes en charge du marketing digital. Une nouveauté qui suscite des questions, des doutes, voire des craintes. Et contribue à construire quelques mythes…

Mythe #1 : « Avec le server-side, les tags sont morts, le tag management aussi »

Il est vrai que le server-side est aussi désigné comme un procédé « tagless », sans tag. Facile d’en déduire donc que le tag management est mort. Sauf que la réalité technique est plus complexe. Toutes les solutions ne sont pas éligibles au server-side. Si le server-side est déjà possible pour l’analytics ou la gestion des consentements, il s’avère plus complexe à mettre en œuvre pour les ad servers ou les solutions de personnalisation. La transition va demander du temps et les deux modalités, traitements côté navigateur et côté serveur, vont cohabiter d’ici là. Nous n’en avons donc pas fini avec le tag management. Ce qui nous laisse le temps, aussi, de gérer l’inévitable évolution du métier – on y revient.

Mythe #2 : « Le server-side, c’est une affaire de développeurs »

Avec l’émergence du server-side se développe aussi le sentiment que le sujet du tracking change de camp, qu’il passe des mains des équipes marketing à celles des développeurs. Soyons clairs : c’est un (gros) raccourci. Oui, la mise en œuvre d’intégrations dites « tagless » est technique. Voilà pourquoi tout ne va pas se faire en un jour, mais plus probablement s’échelonner sur quelques années. Mais nous parlons ici de la mise en œuvre à travers les solutions du marché. Car une fois les solutions à jour – les gestionnaires de tags (qu’il faudra sans doute renommer) comme les solutions des partenaires –, le server-side reste à sa place : dans les coulisses. Et c’est bien aux responsables marketing qu’il revient encore et toujours de travailler sur les données collectées.

Mythe #3 : « Avec le server-side, une partie de mon job se volatilise »

Fini les tags, donc fini le tag management et… les jobs associés ? Les trafic managers et spécialistes du tagging doivent-ils s’inquiéter ? Pas vraiment. Tout est une question de définition du « tag management ». Si l’on considère que le tag management consiste avant tout à optimiser le placement des tags dans des containers exécutés dans un navigateur, alors, oui, ce tag management-là est appelé à disparaitre peu à peu.

En revanche, si le « tag management » est aussi vu comme l’art de traiter la donnée avant de la transmettre à ces partenaires, alors le tag management est loin d’être mort. Au contraire, il entre même dans une nouvelle ère. Le server-side élargit sensiblement le champ des possibles, qu’il s’agisse de contrôler la qualité de la donnée, de l’enrichir ou encore de la distribuer avec précision aux partenaires. En résumé, le server-side représente un véritable appel d’air pour la créativité sur le front de la data.

Mythe #4 : « Le server-side, c’est une black box – on perd tout contrôle »

Ce sentiment est compréhensible. Le tag management côté navigateur donne le sentiment d’accéder à la collecte des données comme on lit dans un livre ouvert. Avec une mécanique gérée côté serveur, cette lisibilité semble révolue. En apparence seulement. Dans la pratique, tout reste bien sous contrôle et accessible : le gestionnaire de tags demeure le « hub » au sein duquel la collecte des données, leur traitement et leur envoi aux partenaires sont mis en œuvre. Au lieu de gérer des tags, la solution pilote des intégrations « tagless », de serveur à serveur, mais les rend toujours lisibles et manipulables.

Mythe #5 : « Le server-side, ça se gère en interne, avec des développements spécifiques »

C’est souvent ainsi que sont inaugurées les nouveautés techniques, surtout – et c’est encore le cas pour le server-side – quand tout le marché n’est pas encore au diapason de cette nouvelle donne. De fait, il peut être tentant de s’appuyer sur des développements maison pour maîtriser ces échanges de serveur à serveur. Une tentation qui perd de vue l’essentiel : l’objectif n’est pas seulement de mettre en œuvre le server-side mais de masquer sa complexité technique durablement afin que les équipes marketing puissent travailler de manière agile au quotidien. Un enjeu pour lequel un produit logiciel sera toujours plus éprouvé qu’un développement spécifique.

Mythe #6 : « Le server-side, ça va coûter cher… »

Le server-side appelant une refonte technique commune à toutes les parties prenantes, oui, des budgets dédiés sont requis. Mais ils doivent être considérés au regard des bénéfices obtenus. Le nombre de tags traités pour un site au sein du navigateur va se réduire sensiblement au profit de la web performance, donc de l’expérience utilisateur. Surtout, la bascule côte serveur permet un contrôle qualité et un enrichissement de la donnée hors de portée d’un traitement côté navigateur. La transition vers le server-side étant à peine amorcée, son potentiel est encore très sous-estimé. Probable qu’il conduise à transmettre moins de données aux partenaires mais… beaucoup plus pertinentes.

Mythe #7 : « Le server-side c’est un vrai SPOF »

Dans le lexique informatique, le SPOF, pour « Single Point of Failure » ou point de défaillance unique, laisse entendre que la disponibilité d’un système repose sur celle d’un seul de ses composants. Vu qu’avec le server-side toutes les interactions s’effectuent de serveur à serveur (et non de navigateur à serveur), la capacité du serveur-gestionnaire de ce dialogue à tenir la charge est questionnée. De fait, les infrastructures vont devoir être dimensionnées pour relever deux défis : d’une part collecter tous les hits, d’autre part traiter et partager la donnée. Bonne nouvelle : une solide expérience a été cumulée sur ce sujet. On sait par exemple, en cas de pic imprévu, « bufferiser » les traitements (les mettre de côté momentanément) pour les traiter par lots ensuite.

Mythe #8 : « Avec le server-side, je peux me passer du consentement »

C’est un raccourci à oublier au plus vite… Le « server side » est une modalité technique de collecte et de traitement des données. Il ne change rien aux précautions à prendre pour se conformer au RGPD (Règlement Général sur la Protection des Données) et aux directives de la CNIL sur la collecte du consentement. Que les informations soient transmises depuis un navigateur ou un serveur, le consentement de l’utilisateur doit être obtenu.

Mythe #9 : « Mettre en œuvre le consentement avec le server-side, c’est compliqué »

Si la gestion des consentements s’appuie sur un développement maison, qui n’a pas été conçu dans la perspective du server-side, oui, la transition peut s’avérer douloureuse. Ce n’est pas le cas pour des solutions comme TrustCommander, notre Content Management Platform, dont l’architecture a d’emblée été pensée pour s’inscrire dans un mode server-side. Ainsi, la propagation des consentements auprès des partenaires pilotés en server-side s’effectue de manière indolore.

Mythe #10 : « Avec le server-side, la confidentialité des données est forcément renforcée »

En matière de sécurité, rien ne va de soi. Ce n’est pas parce que les interactions sont gérées de serveur à serveur qu’elles sont naturellement plus sécurisées. Ce sera le cas si ces infrastructures sont auditées et sécurisées dans les règles de l’art, et si le trafic entre serveurs fait l’objet d’un chiffrement digne de ce nom. Précisons aussi que, selon les modalités techniques retenues, même avec le server-side, un datalayer peut subsister dans le navigateur et donc exposer des données. Si ces données sont sensibles, la mise en œuvre du server-side peut se faire sans requérir un datalayer. La sécurité du server-side relève donc d’un ensemble de mesures. Et de choix.