Quels sont les impacts de l'ITP sur le tracking ?

Qu'est-ce que l'ITP ?

L'Intelligent Tracking Prevention (ITP) est une fonctionnalité de confidentialité intégrée au navigateur Safari d'Apple. Elle utilise le machine learning embarqué sur l'appareil pour classifier les domaines ayant des capacités de tracking cross-site et restreint progressivement leur accès aux cookies et au stockage. L'ITP a évolué à travers plusieurs versions, chacune renforçant davantage les restrictions.

Quels navigateurs et appareils sont concernés ?

L'ITP s'applique à Safari sur macOS (Mojave 10.14 et versions ultérieures) et Safari sur iOS/iPadOS (iOS 12 et versions ultérieures). Puisque Safari est le moteur de navigateur par défaut sur tous les appareils iOS (y compris les navigateurs in-app), l'impact s'étend à une part significative du trafic mobile.

Impact sur l'identification des visiteurs (limitation de la durée de vie des cookies)

À partir de l'ITP 2.1, tous les cookies persistants créés via document.cookie (JavaScript) sont limités à une expiration de 7 jours. Comme le SDK JS Piano Analytics définit son cookie d'identification visiteur via JavaScript par défaut, cela signifie :

Si un visiteur revient après plus de 7 jours sans visiter votre site, un nouvel identifiant visiteur peut lui être attribué.
Cela peut gonfler le nombre de visiteurs uniques et fausser les métriques centrées sur le visiteur (par exemple, visites par visiteur, nouveaux vs. visiteurs de retour).

Mesurer l'impact : si vous avez implémenté l'identification utilisateur (tracking des utilisateurs connectés), vous pouvez analyser le nombre d'identifiants visiteurs distincts par utilisateur identifié sur les appareils iOS/Safari pour estimer l'effet de l'expiration des cookies.

Solution recommandée : implémenter un endpoint cookie côté serveur qui définit les cookies Piano via les headers de réponse HTTP. Les cookies définis de cette manière par un serveur first-party ne sont pas soumis à la même limitation de 7 jours.

Alternativement, l'utilisation du Custom Domain Data Collection (CDDC) permet de définir les cookies dans un contexte first-party côté serveur, contournant ainsi cette limitation.

Impact sur les données de referrer et d'URL de page

Pour les requêtes tierces vers des domaines classifiés comme potentiels trackers, Safari réduit le referrer à l'origine de la page uniquement (par exemple https://www.example.com/ au lieu de l'URL complète). Si votre implémentation repose sur l'URL de la page plutôt que sur des noms de pages explicitement tagués, vous risquez de perdre le détail au niveau de la page dans vos rapports.

Solution recommandée : toujours taguer les noms de pages explicitement plutôt que de se reposer sur l'URL.

Activez addEventURL: true pour capturer les URL complètes incluant les paramètres marketing.
Définissez votre Referrer-Policy sur no-referrer-when-downgrade pour préserver les données de referrer dans la mesure du possible.

Impact sur les cookies tiers

Les cookies tiers pour les domaines classifiés comme ayant des capacités de tracking sont entièrement bloqués. Les cookies partitionnés ne sont plus supportés. Cela signifie que tout tracking reposant sur des cookies tiers ne fonctionnera pas dans Safari.

Solution recommandée : utilisez des cookies first-party (le SDK JS Piano Analytics utilise des cookies first-party par défaut, donc cette restriction particulière ne devrait pas affecter directement les implémentations standard).

Comment atténuer les effets de l'ITP avec le CDDC ?

Le Custom Domain Data Collection (CDDC) est la solution d'atténuation la plus efficace disponible. Il fonctionne en collectant les données sur un sous-domaine contrôlé par le client via un enregistrement CNAME, ce qui permet de définir les cookies côté serveur (via les headers de réponse HTTP) plutôt que via JavaScript. Les cookies définis côté serveur ne sont pas soumis à la limitation de 7 jours.

Le CDDC réduit également l'impact de certains adblockers, puisque les requêtes apparaissent comme first-party d'un point de vue réseau.

Important : le CDDC atténue mais ne contourne pas entièrement toutes les restrictions de stockage de Safari dans les versions les plus récentes. Il n'existe pas de solution unique qui restaure complètement le comportement pré-ITP.

Pour les organisations s'appuyant sur l'exemption ePrivacy, les cookies côté client sont nécessaires. Cela est dû aux besoins de synchronisation (notamment la capacité pour JavaScript de déterminer le statut de privacy et de gérer correctement l'état d'opt-out/consentement).

Comme les cookies côté serveur ne sont pas directement accessibles à JavaScript de la même manière, utiliser uniquement des identifiants définis côté serveur peut empêcher la synchronisation en temps réel requise et entraîner des problèmes de conformité privacy selon l'implémentation.

D'autres options sont disponibles, telles que :

Auto-héberger le SDK : téléchargez le SDK depuis le Piano Analytics JS GitHub repository et hébergez-le sur votre propre infrastructure. Vous pouvez éventuellement renommer le fichier (par exemple, votresite.com/nom-personnalise.js) pour éviter également la détection par les adblockers.
Intégration NPM : intégrez le package piano-analytics-js directement dans votre application JavaScript via NPM/ESM. Cela fait du SDK un composant entièrement first-party de votre bundle applicatif.
Implémentation server-side : construisez les hits côté serveur en utilisant l'API de collecte, contournant entièrement les restrictions côté client. Assurez-vous que la propriété previous_url est renseignée pour chaque page vue afin d'éviter une mauvaise classification en trafic Direct.