Migration server-side : pourquoi procéder pas à pas

Migrer vers le server-side doit se faire de manière progressive, partenaire par partenaire. Objectif : se donner le temps du « test and learn » et de travailler la qualité des données.

Non, opter pour le server-side n’impose pas de migrer tous les partenaires à marche forcée. Bien au contraire, tout converge aujourd’hui pour encourager les entreprises à suivre une démarche progressive. Citons au moins deux raisons. Primo, les partenaires sont loin d’être tous prêts pour une mise en œuvre des tags côté serveurs. Secundo, il est hautement recommandé de se donner le temps d’apprendre.

Résultat, pour au moins plusieurs mois encore, la gestion des tags ne sera ni totalement client-side, ni totalement server-side mais… hybride. Comment procéder ? Tout d’abord, en préparant votre organisation pour le server-side. Ensuite, en suivant ces étapes pour la mise en œuvre.

Étape #1 : choisir son architecture

Deux méthodes sont possibles aujourd’hui pour implémenter une collecte server-side : les API et le « master tag » –  notez que ces deux méthodes peuvent être combinées. La première consiste donc à utiliser les APIs server-side mise à disposition par une plateforme comme celle de Commanders Act pour transmettre l’ensemble des événements attendus dans le cadre de vos cas d’usage. Pour y parvenir, prenez le temps de cataloguer vos événements pour chacun de ces cas.

Quant à la méthode « master tag », elle est ainsi nommée car, même en server-side, elle passe par le dépôt d’un tag – mais d’un unique tag. C’est lui qui collecte l’ensemble des événements requis par vos scénarios au sein du navigateur afin de les communiquer à la solution server-side pour traitement.

Ici, une précaution doit être prise : il s’agit de déposer ce tag en first-party. À défaut, les navigateurs comme Safari ou Firefox (et Chrome l’année prochaine) inhibent ce tag, ce qui conduit à perdre des données. Heureusement, via le procédé de délégation de sous-domaine, il est tout à fait possible de positionner le master tag de Commanders Act comme un tag first party.

Étape #2 : travailler la qualité des données

Cette étape doit être l’objet de toutes les attentions. Les données collectées via le server-side représentent votre « data hub » : le socle de données sur lequel vont s’appuyer les activations de vos partenaires. C’est d’ailleurs le bon moment pour revoir le datalayer et le catalogue d’événements à intégrer. Objectif : améliorer la collecte bien sûr, mais aussi anticiper le déploiement de nouveaux cas d’usage.

Ce travail doit être l’occasion de « recetter la donnée ». Avec deux objectifs : tout d’abord, vous assurer que le consentement est bien propagé afin que l’information diffusée aux différents partenaires soit conforme aux préférences de l’utilisateur. Ensuite, veiller à ce que la donnée soit normalisée, donc formatée pour être réellement exploitable.

Voilà pourquoi Commanders Act met à disposition plusieurs outils (source data quality ou encore live events inspector) pour recetter les données versées au data hub et contrôler leur qualité. Un travail qui peut s’effectuer en temps réel et que la plateforme outille jusqu’au bout, notamment avec une fonction de « data cleansing » qui permet de corriger les données erronées de manière automatique avant envoi aux partenaires.

Prendre le temps de travailler la qualité des données représente à la fois un prérequis et un bénéfice. Un prérequis car, sans une donnée de qualité, la mécanique server-side s’enraye rapidement. Un bénéfice, car cette qualité accrue génère aussi des activations plus précises, donc un retour sur effort tangible et des campagnes plus performantes.

Étape #3 : migrer un premier partenaire

La méthode de collecte est actée ? La donnée travaillée ? Il est temps de migrer un premier partenaire, si possible un « bon candidat », donc un partenaire qui a bien documenté la démarche de migration. C’est le cas par exemple de Facebook qui, comme d’autres, recommande de conserver pendant une période d’observation les deux flux de données, client-side (depuis le pixel classique) et server-side (depuis la « Conversion API »).

Cette période sera mise à profit pour contrôler la qualité des données distribuées. Commanders Act propose à cette fin dans sa plateforme plusieurs outils de suivi et d’alerte, de quoi mener ce travail de « test and learn » de manière sereine.

Une fois le connecteur server-side déployé, une période d’observation s’impose – disons deux semaines – pour vérifier qu’aucune interruption de service n’a lieu. Cette période passée, le tag client-side peut être désactivé pour conserver uniquement l’activation server-side.

Bonne nouvelle, ce travail profite mécaniquement aux autres partenaires et contribue donc à accélérer les migrations suivantes. Puisez dans le catalogue de destinations de Commanders Act et planifiez ces migrations.

Pour mener à bien la migration server-side, ne vous enfermez pas dans une gestion de projet pressurisée par les échéances. Priorisez la migration des partenaires en fonction de vos impératifs business et associez les équipes médias aux différentes étapes du projet. Surtout, donnez-vous le temps de travailler la qualité de vos données et de tester les implémentations, un partenaire l’un après l’autre. Vos données méritent bien ce temps et cette attention.

Découvrez pourquoi le server-side va devenir votre meilleur allié !