L'impact de l'Intelligent Tracking Prevention (ITP) sur les tests A/B, et comment contourner ses restrictions
Retrouvez notre dernier article sur la mise à jour 2.3 de l'ITP d'Apple.
Les marketeurs peuvent-ils toujours faire confiance à leur outil d'A/B testing ?
La sortie de la dernière version de l'Intelligent Tracking Prevention d'Apple pose de nombreuses questions sur la fiabilité des pratiques d'optimisation du taux de conversion.
Chez Kameleoon, nous sommes surpris que l'ITP ne fasse pas encore les gros titres du marketing digital. Bien que le sujet soit assez technique, il peut potentiellement avoir un impact énorme pour les professionnels du marketing qui mènent des expériences d'A/B testing.
Pour en savoir plus, nous avons interrogé notre CTO, Jean-Noël Rivasseau, sur l'ITP, et tout particulièrement la dernière version (2.1) qui introduit des restrictions majeures sur le fonctionnement des navigateurs et applications utilisant JavaScript, notamment concernant les cookies.
L'ITP est présent nativement sur le navigateur Safari, et bien que celui-ci soit relativement peu présent sur le marché du desktop, il en va tout autrement pour les appareils mobiles, où Apple possède une part de marché bien plus importante (avoisinant les 40 à 50 %). Cela signifie que près de la moitié de votre trafic web pourrait être affectée par l'ITP !
Voici les points clés qui sont ressortis de nos échanges avec Jean-Noël :
- Les caractéristiques de l'ITP 2.1
- Son impact sur les outils d'A/B testing
- Les solutions que nous avons trouvées chez Kameleoon
1 Qu'est-ce que l'Intelligent Tracking Prevention ?
L'ITP d'Apple vise à améliorer le respect de la vie privée de l'utilisateur en empêchant les sites web et les divers scripts installés sur ceux-ci de suivre les utilisateurs de manière non sollicitée. Il est présent sur tous les navigateurs Safari.
La dernière version, ITP 2.1, introduit de nouvelles restrictions majeures pour les logiciels de Web Analytics en JavaScript. Pour faire simple, cela signifie que les cookies créés en JavaScript (qui n'étaient déjà pas fiables à 100 % même avant l'ITP car les utilisateurs pouvaient les effacer manuellement) perdent toute valeur avec l'ITP.
Là où les versions précédentes de l'ITP ciblaient essentiellement les systèmes de publicité en ligne, la 2.1 est bien plus agressive et affecte très fortement les logiciels de web Analytics (tels que Google Analytics) et les outils d'A/B testing.
Pourquoi ? Simplement parce que l'ITP limite la durée de vie des cookies créés en JavaScript à 7 jours. Ou pour reprendre la formule du blog WebKit d'Apple pour les développeurs : « Avec l'ITP 2.1, tous les cookies persistants côté client, autrement dit les cookies créés via document.cookie, ont une date limite d'expiration de sept jours. »
Limiter les cookies créés en JavaScript à 7 jours est une manœuvre très agressive. Presque toutes les plateformes de web Analytics (y compris Google Analytics) reposent actuellement sur le duo JavaScript/Front-end et elles utilisent toutes un cookie pour stocker l'identifiant unique du visiteur.
Cet identifiant est généré de manière aléatoire sur la première page vue lors de la première visite d'un utilisateur sur votre site web. Il est ensuite réutilisé pour toutes les pages vues et lors des visites suivantes afin de suivre cet utilisateur spécifique. Cela permet notamment à Google Analytics de savoir si un visiteur est nouveau (car un nouvel identifiant/cookie aura été généré) ou déjà venu (car le système retrouvera le cookie qui a été créé précédemment).
Étant donné que les cookies ont à présent une durée de vie de sept jours dans Safari, cette nouvelle valeur remplace le délai d'expiration bien plus long habituellement défini par Google Analytics.
Autrement dit, un visiteur qui consulte un site une première fois un lundi, puis revient sur ce site le mardi de la semaine suivante, sera considéré comme un visiteur totalement nouveau. Sa nouvelle visite ne sera pas reliée à la première.
Cela signifie donc que votre indicateur « nouveaux visiteurs », sur Google Analytics, sera totalement fantaisiste en ce qui concerne le trafic provenant de Safari. Et de nombreux autres indicateurs (comme le nombre de visiteurs uniques, le délai avant l'achat, etc.) seront également complètement faussés. Il devient donc très difficile de faire confiance aux chiffres affichés par les solutions de web Analytics basées sur les cookies !
2 Comment l'ITP 2.1 affecte-t-il les outils d'A/B testing ?
La majorité des plateformes de test et d'optimisation de la conversion intègrent également des fonctions de web Analytics au sein de l'outil. Cela signifie qu'elles souffriront des mêmes problèmes que décrits plus haut, ce qui est déjà en soi problématique. Mais pour les tests A/B, un obstacle encore plus important vient s'ajouter.
Il est dû au fait qu'à chaque fois qu'un visiteur est inclus dans un test, une variante est sélectionnée pour lui. Cette variante doit être mémorisée, pour qu'en cas de retour, le visiteur voie la même chose que la fois précédente. Pour ce faire, toutes les solutions de testing front-end stockent cette information (le lien entre le test et la variante) dans un cookie.
Avec l'ITP, un visiteur qui réapparaît plus de sept jours après le déclenchement initial du test risque de voir une variante différente. Dans ces conditions l'A/B testing n'a plus aucune valeur et ne produit plus de résultats pertinents.
Pour résoudre ce problème, les fournisseurs de solutions d'A/B testing peuvent être tentés de ne plus créer de cookies via leur code JavaScript, mais plutôt de les stocker sur le serveur via un en-tête HTTP. Il faut cependant pour cela accéder au code au niveau du back-end, ce qui est une opération complexe. Le succès de la plupart des solutions de testing existantes est lié à la promesse d’une configuration particulièrement simple, via un simple fichier JavaScript statique à inclure dans le code source HTML, ou à déployer encore plus rapidement via un système de gestion des tags.
Si un client doit fournir des efforts importants pour installer et maintenir ces solutions, il est probable qu’il choisisse de s’en passer complètement. Autrement dit, contourner l'obstacle en faisant appel aux en-têtes HTTP n'est pas réellement une option pour les fournisseurs de web Analytics.
3 Pourquoi Kameleoon est-elle la seule plateforme d'optimisation de la conversion qui gère de manière automatique et transparente l'ITP d'Apple ?
En deux mots, parce que notre équipe d'ingénieurs a mis en place un stockage local cross-domain pour Kameleoon.
Le Local storage, une technologie web prise en charge par quasiment tous les navigateurs en 2019, est tout simplement un espace de stockage des données au niveau du navigateur, qui permet de gérer les données de la même manière que les cookies.
Compte tenu de toutes ses caractéristiques, le stockage local semble le candidat idéal pour remplacer les cookies. Et l'ITP 2.1 n'impose aucune restriction à ce niveau. D'ailleurs, plusieurs plateformes de test ont déjà opté pour un stockage web local au lieu du stockage basé sur les cookies. En revanche, le local storage présente un problème de taille : il est limité à un seul sous-domaine précis.
Ceci est dû au système de partitionnement des sous-domaines / protocoles utilisés. Contrairement aux cookies, où le code JavaScript exécuté sur http://www.example.com peut créer un cookie associé au domaine *.example.com (ce qui signifie que vous pouvez accéder à ce cookie depuis buy.example.com ou même buy.now.really.example.com), le stockage local est partitionné en fonction d'un sous-domaine ET d'un protocole spécifiques.
Si vous enregistrez des données sur le stockage local du sous-domaine http://www.example.com, vous ne pourrez pas y accéder plus tard à partir d'une page sur http://buy.example.com, ni même sur https://www.example.com. Le protocole et le domaine doivent tous les deux afficher une correspondance exacte.
Pour cette raison, à moins d'avoir la chance d'avoir un seul site, et un seul sous-domaine pour la totalité de votre site, vous allez rencontrer de sérieuses difficultés si vous utilisez une solution qui repose sur une simple implémentation du stockage local.
Vos problèmes paraîtront similaires à ceux causés par l'ITP, mais pour une raison tout à fait différente. À titre d'exemple, imaginons que l'essentiel de votre site de e-commerce soit hébergé sur https://www.randomshop.com, mais que le tunnel de conversion soit sur https://transaction.randomshop.com. Si votre ID visiteur est persistant sur le stockage local, votre solution d'analytics va comptabiliser deux visiteurs différents lorsqu'un achat se produit, l'un vu sur www.randomshop.com et l'autre sur transaction.randomshop.com. Les données ne transitent pas de manière transparente d'un domaine à l'autre, et une telle solution identifierait ici deux sessions distinctes, et non une seule session du même visiteur.
Pour l'A/B testing, c'est (là encore) la double peine. Si vous réalisez un test qui modifie le menu de navigation, avec deux variantes, un utilisateur pourra tout à fait être exposé à la première variante sur le site principal, mais à la deuxième plus loin dans le tunnel ! Ceci est non seulement désastreux en termes d'expérience utilisateur, mais cela rend également les résultats du test totalement caducs.
Nous sommes donc allés plus loin et avons mis en place un stockage local entièrement cross-domaine, étant donné que même un faible pourcentage des pages sur un sous-domaine différent de votre site web peut décrédibiliser voire fausser les résultats de vos tests A/B.
Pour tout vous dire, nous avions mis en place ce projet de stockage local dès 2014 ! À l'époque, nous avions juste besoin d'un espace de stockage important sur le navigateur, car nous souhaitions enregistrer toutes les données collectées par Kameleoon au niveau du front-end.
Ceci nous permet d'appliquer nos algorithmes prédictifs de machine learning à ces informations – car oui, nous exécutons des algorithmes de réseaux neuronaux directement sur le navigateur, en JavaScript ! Ce système fonctionne très bien, mais il mériterait un article à part entière.
Lorsque les premières versions d'ITP sont sorties, nous avons dû adapter quelque peu notre système. Étrangement, les domaines externes de stockage local sont traités comme des tierces parties par toutes les versions d'ITP, comme s'il s'agissait de cookies. Nous avions initialement installé le fichier iFrame commun sur notre propre domaine (Kameleoon) et non sur le domaine client, essentiellement pour simplifier la configuration. Les données communes sur le stockage local étaient alors considérées comme tierces et bloquées par Safari. Pour corriger ceci, nous avons modifié l'emplacement de l'iFrame pour qu'il soit hébergé sur le domaine du client.
Ainsi, pour pouvoir profiter de tests A/B et d'Analytics sans ITP avec Kameleoon, vérifiez que vous utilisez notre double méthode d'intégration de fichiers JavaScript & iFrame – et voilà ! C'est aussi simple que ça. Deux remarques pour conclure :
- Bien que nous puissions garantir que notre propre système d'Analytics n'est pas affecté par l'ITP et que toutes les données de trafic sont correctes, nous ne pouvons évidemment pas garantir la même chose pour les plateformes tierces de web Analytics. Les passerelles d'intégration que nous avons créées avec des outils partenaires continuent de fonctionner de la même manière qu'avant. Nous recommandons aux clients d’échanger directement avec leurs fournisseurs à ce sujet.
- Nos SDK côté serveur (et nos SDK mobiles) ne sont absolument pas affectés par l'ITP, car les appels de suivi pour l'Analytics sont effectués de serveur à serveur et jamais en front. Si vous utilisez la passerelle back-end/front-end, un cookie sera utilisé pour synchroniser le kameleoonVisitorCode, mais il sera créé via le serveur (en-tête HTTP) et non du côté front, et sera considéré comme un cookie first-party, autrement dit non affecté par l'ITP.
L'équipe Kameleoon est très fière de pouvoir proposer à ses clients cette solution simple pour résoudre les problèmes liés à l'ITP 2.1. Grâce à cette solution, nos clients peuvent continuer à réaliser des tests A/B stables et pertinents sur leur trafic mobile, sans devoir consacrer un temps précieux à mettre en place des ajustements au cas par cas pour contourner l'ITP.
En tant qu'éditeur de logiciels, nous sommes convaincus que notre rôle est de faire le maximum pour simplifier la vie de nos clients – une philosophie qu'illustre parfaitement cet exemple.
Nous continuerons de suivre l'évolution de la technologie ITP d'Apple, ainsi que les initiatives des autres navigateurs (Firefox possède une technologie assez similaire à l'ITP, mais qui n'est pas encore aussi extrême). Toute nouvelle version sera analysée rapidement et nous proposons des solutions aussi vite que possible.
Pour tout savoir sur les aspects techniques de l'ITP 2.1 et la solution trouvée par Kameleoon, consultez notre documentation.
