Passer au contenu principal
L’Intelligent Tracking Prevention (ITP) d’Apple est une technologie visant à accroître la confidentialité des utilisateurs en empêchant le suivi indésirable par les sites web et les divers scripts qui y sont installés. Elle est utilisée dans tous les navigateurs Safari, y compris sur les ordinateurs de bureau (Macintosh) et tous les appareils iOS (iPhone et iPad). L’ITP apporte des restrictions majeures aux opérations que les logiciels basés sur JavaScript peuvent effectuer. Bien que l’ITP cible principalement les systèmes de publicité en ligne, les dernières versions sont beaucoup plus agressives et impactent significativement les logiciels d’analyse web, tels que Google Analytics. L’ITP affecte également de manière significative les outils d’A/B test. Kameleoon peut être pleinement fonctionnel même avec des appareils Apple où l’ITP est activé. Cependant, vous devez insérer une petite section de code de synchronisation sur vos serveurs back-end. Cet article explique les limitations techniques et les conséquences de l’ITP pour l’expérimentation et l’analyse.
  • Limitations techniques imposées par l’ITP.
  • Conséquences pour les opérations d’analyse web et d’optimisation des conversions.
  • Solution recommandée par Kameleoon pour éviter les problèmes liés à l’ITP.

​
Restrictions techniques de l’ITP​

L’Intelligent Tracking Prevention implémente des restrictions considérables autour de l’utilisation des cookies et autres stockages côté client (tels que le stockage local). Il est important de comprendre quelques caractéristiques importantes des cookies. Les cookies sont de (très) petits éléments de données qu’un site web stocke dans le navigateur d’un visiteur. Très souvent, ils représentent des identifiants uniques et aléatoirement générés. Chaque cookie est lié à un domaine (tel que www.example.com) et a une date d’expiration. Chaque fois qu’un appel serveur est effectué vers un domaine lié à un ou plusieurs cookies stockés sur votre ordinateur, les données contenues dans ces cookies sont envoyées au serveur web de ce domaine, automatiquement et de manière transparente. Par conséquent, des cookies sont constamment ajoutés à la plupart des requêtes web, avec deux conséquences immédiates :
  • La taille des requêtes web augmente, ralentissant votre vitesse de navigation.
  • Votre navigateur transfère des données vers des serveurs distants sans votre consentement explicite, vous permettant d’être identifié et suivi.
Comme les cookies sont généralement assez petits, le premier problème n’est généralement pas si significatif. Cependant, le second a une portée bien plus large et préoccupe grandement les défenseurs de la vie privée des utilisateurs. L’utilisation des cookies est un sujet complexe, car les cookies sont utilisés à de nombreuses fins différentes sur le web. Beaucoup d’entre eux, en raison de la nature sans état du protocole HTTP, sont nécessaires aux opérations de base d’un site web. Par exemple, les transactions e-commerce s’appuient généralement sur eux. Avec l’ITP, Apple vise à séparer les “bons” cookies (ceux nécessaires au fonctionnement normal d’un site web donné) des “mauvais” (ceux associés aux publicités, au suivi et aux atteintes à la vie privée). Les sites web peuvent définir des cookies en utilisant deux mécanismes différents :
  • Lorsqu’un appel est effectué vers un serveur web, le serveur définit le cookie en ajoutant un en-tête HTTP dans la réponse HTTP.
  • En utilisant du code JavaScript côté client.
Le domaine associé du cookie dépend de la méthode utilisée. Pour les cookies serveur, c’est le domaine où l’appel serveur a été envoyé. Pour les cookies JavaScript côté client, le domaine est l’une des pages depuis lesquelles le code JavaScript est exécuté (pas nécessairement le domaine hôte du fichier JavaScript). Les cookies tiers font référence aux cookies envoyés à un domaine autre que la page web que vous consultez actuellement. Par exemple, si vous parcourez www.randomshop.com, mais que ce site web effectue un appel vers tracking.ad-system.com, les cookies associés à www.ad-system.com peuvent être envoyés avec la requête HTTP. Ils seront considérés comme des cookies tiers dans le contexte de votre session de navigation actuelle sur www.randomshop.com. Lorsqu’un cookie expire, le navigateur le supprime complètement. Cependant, comme l’entité qui crée le cookie choisit la date d’expiration, elle peut être définie loin dans le futur (par exemple, 10 ans ou plus). Cette durée garantit qu’il dure bien au-delà de ce qui est nécessaire au fonctionnement normal du site web d’origine. Cette pratique est en train de changer avec l’ITP. Voici les deux principales restrictions imposées par l’ITP 2.3 :
  • Dans toutes les versions d’ITP, les cookies tiers sont fortement restreints. Les cookies tiers sont bloqués par Safari 24 heures après leur définition dans le navigateur. Techniquement, ils ne sont pas supprimés mais ne sont plus automatiquement envoyés au serveur tiers via les requêtes HTTP. Dans l’exemple précédent, un visiteur venant sur www.randomshop.com obtient un cookie de www.ad-system.com via un appel HTTP vers ce serveur lors de sa première visite. Si le visiteur revient plus de 24 heures plus tard, la prochaine requête HTTP vers www.ad-system.com ne reçoit pas les données du cookie d’origine.
  • À partir de la version 2.3, tous les stockages côté client (cookies basés sur JavaScript et LocalStorage) expirent après 7 jours !
Étant donné que les logiciels d’analyse web et d’A/B test ne reposent généralement pas sur des cookies tiers, la première restriction concerne principalement les systèmes de publicité. Le reste de cet article se concentre sur la seconde restriction.

​
Conséquences des limitations des stockages côté client​

Limiter les cookies basés sur JavaScript à une expiration de 7 jours est très agressif. Presque toutes les plateformes d’analyse web (y compris Google Analytics) sont basées sur JavaScript ou le front-end, et toutes utilisent un cookie pour stocker l’identifiant unique du visiteur. Cet identifiant est aléatoirement généré lors de la première page vue de la première visite du visiteur sur votre site web. Lors des pages vues et visites suivantes, l’identifiant est réutilisé depuis le cookie pour identifier le visiteur. Cela permet au logiciel d’analyse de différencier un nouveau visiteur (un nouveau cookie est généré) d’un visiteur récurrent (un cookie précédemment défini a été trouvé). Comme Safari réduit la durée de vie du cookie à 7 jours, un visiteur effectuant une première visite le lundi, puis revenant le mardi de la semaine suivante est considéré comme un visiteur totalement nouveau. Autrement dit, les données de la nouvelle visite ne seront pas liées à la précédente. En conséquence, vos métriques de nouveau visiteur dans le logiciel d’analyse ne sont plus fiables pour votre trafic Safari. Beaucoup, beaucoup d’autres métriques peuvent également être faussées (nombre de visiteurs uniques, temps avant achat, etc.). Il est difficile de faire confiance à un nombre produit par des solutions d’analyse basées sur les cookies. Pour les sites web sur ordinateur, cela pourrait être considéré comme une gêne mineure, puisque la part de marché de Safari sur ordinateur d’Apple est relativement faible (généralement entre 5 % et 10 %). Cependant, pour les sites web fortement mobiles, la part de marché des appareils iOS est souvent plus proche de la fourchette de 40-50 %. Cette part de marché signifie que presque la moitié de votre trafic peut être affectée ! La majorité des plateformes de test et d’optimisation des conversions intègrent leurs capacités d’analyse web. Celles-ci souffrent de problèmes identiques, ce qui est problématique en soi. Cependant, pour les expériences A/B, un obstacle encore plus sérieux apparaît. Chaque fois qu’un visiteur est placé dans une expérience, le logiciel de test sélectionne une variation pour le visiteur. Cette variation doit être mémorisée avec précision, car si le visiteur revient, il doit voir la même variation qu’il avait vue précédemment. Toutes les solutions de test front-end stockent cette information (l’association entre l’expérience et la variation) dans un cookie. Avec l’ITP, un visiteur qui revient plus de 7 jours après le déclenchement initial d’une expérience risque de voir une variation différente. Dans ces conditions, l’A/B test ne produit pas de résultats fiables. Pour plus de détails techniques, consultez ce billet de blog sur l’ITP et ses implications pour l’analyse web. L’article fournit également une liste de contournements au défi de l’ITP, qui est couvert dans la section suivante.

​
Solutions pour Kameleoon​

Le premier contournement que Kameleoon a implémenté a été de sauvegarder des informations importantes, telles que les allocations de variation, dans LocalStorage plutôt que dans des cookies. En fait, l’utilisation de LocalStorage au lieu de cookies dans Kameleoon précède l’ITP, car LocalStorage présente plusieurs avantages par rapport aux cookies. L’un des avantages est que les cookies définis par JavaScript n’étaient pas entièrement fiables, même avant l’ITP, car les utilisateurs pouvaient les effacer manuellement. Utiliser LocalStorage à la place a initialement fonctionné ; cependant, la dernière version d’ITP traite LocalStorage comme un cookie, et les entrées expirent après 7 jours. En conséquence, cette méthode ne garantit plus des A/B tests et personnalisations fiables sur Safari. La solution recommandée par Kameleoon consiste à définir le cookie kameleoonVisitorCode, qui contient l’identifiant important visitorCode, sur le serveur en utilisant un en-tête HTTP plutôt qu’uniquement sur le navigateur avec JavaScript. L’ITP n’impose pas de restrictions sur les cookies définis par les serveurs, donc ce cookie peut avoir une date d’expiration suffisamment longue. En utilisant cette méthode, le système synchronise ce cookie entre le front-end et le back-end, et la durée de vie du cookie n’est plus limitée par l’ITP. Sur Safari, une fois que Kameleoon obtient le visitorCode en lisant le cookie kameleoonVisitorCode défini par le serveur, il vérifie si le LocalStorage actuel est vide. S’il est vide, la dernière visite du visiteur a probablement eu lieu il y a plus de 7 jours. Kameleoon effectue un Server Synchronization Call (SSC) pour récupérer toutes les données présentes dans LocalStorage depuis les serveurs backend. Une fois cet appel terminé, les données sont restaurées à leur état précédent. Les opérations normales peuvent alors reprendre. Bien que le cœur de l’analyse ne soit pas affecté par l’ITP et que les données de trafic rapportées soient fiables, Kameleoon ne peut pas garantir la même chose pour les plateformes d’analyse web tierces. Les ponts d’intégration avec les outils partenaires continuent de fonctionner de la même manière. Discutez de la situation avec le fournisseur de la solution d’analyse choisie.

​
Conclusion​

En utilisant la solution détaillée dans cet article, vous pouvez continuer à exécuter des expériences AB fiables avec la base d’utilisateurs Safari. Kameleoon fournit un contournement recommandé et encourage sa mise en œuvre plutôt que l’exclusion de Safari de la base de test. D’autres changements de l’ITP sont attendus à mesure qu’Apple travaille à protéger la vie privée des utilisateurs. Kameleoon continue de surveiller l’évolution de la technologie ITP d’Apple et des initiatives similaires d’autres éditeurs de navigateurs. Par exemple, Firefox dispose d’une solution similaire à l’ITP, mais elle n’est pas encore aussi stricte. Toute modification majeure sera analysée et des solutions seront communiquées.