Safari ITP et suivi publicitaire : ce qui fonctionne encore

L’Intelligent Tracking Prevention (ITP) de Safari limite la durée pendant laquelle un site peut reconnaître un visiteur qui revient. Il bloque tous les cookies tiers et plafonne à 7 jours les cookies posés par JavaScript, ou à 24 heures après certains clics publicitaires. Les achats envoyés côté serveur à partir de vos données de commande, les identifiants de clic enregistrés quand l’acheteur arrive et les données client hachées fonctionnent toujours.

Ce guide explique chaque règle ITP telle que WebKit la documente, ce que ces règles font aux fenêtres d’attribution et au remarketing, et quelles méthodes de suivi fonctionnent encore pour une boutique en ligne. Il se termine par une façon de vérifier dans quelle mesure Safari touche votre propre boutique.

Qu’est-ce que Safari ITP ?

L’Intelligent Tracking Prevention est un ensemble de protections de la vie privée dans WebKit, le moteur de navigateur derrière Safari sur Mac, iPhone et iPad. WebKit l’a étendu à de nombreuses reprises et documente les règles actuelles sur sa page Tracking Prevention.

Certaines règles ITP s’appliquent à tous les sites. D’autres ne s’appliquent qu’aux domaines qu’ITP a classés comme capables de suivi intersite, d’après le comportement de ces domaines sur les sites que visite une personne. ITP est activé par défaut : il touche donc chaque visiteur Safari de votre boutique, pas seulement ceux qui sont soucieux de leur vie privée.

Quelles sont les limites des cookies dans Safari ITP ?

Le plafond de 7 jours pour les cookies de script

La plupart des pixels et outils d’analyse écrivent leurs propres cookies first-party avec JavaScript. Le pixel Meta, par exemple, garde un identifiant navigateur dans un cookie appelé _fbp. Dans Safari, ITP supprime les cookies et autres données de stockage créés par JavaScript après 7 jours sans interaction de l’utilisateur sur votre site. WebKit définit l’interaction de l’utilisateur comme un clic, un tap ou une pression de touche. Le défilement ne compte pas.

En pratique, un acheteur qui revient et utilise votre site dans les 7 jours conserve généralement le cookie. Un acheteur qui reste absent plus de 7 jours revient sans lui, et ressemble à un nouveau visiteur.

Le plafond de 24 heures après un lien décoré

Les plateformes publicitaires ajoutent des identifiants de clic aux liens de leurs publicités. WebKit appelle cela la décoration de lien. Quand un domaine qu’ITP a classé comme traceur envoie le visiteur vers votre page, et que l’URL finale comporte une chaîne de requête ou un fragment, les cookies que JavaScript écrit sur cette page d’arrivée sont plafonnés à 24 heures. Le plafond s’applique à la page atteinte par cette navigation, pas au site entier.

Cookies tiers

Safari bloque par défaut tous les cookies tiers, et WebKit indique qu’il n’y a aucune exception à ce blocage. Un tiers ne peut demander l’accès que par des mécanismes comme la Storage Access API. Une plateforme publicitaire ne peut donc pas lire son propre cookie depuis vos pages. Elle dépend des cookies first-party que son pixel écrit, qui relèvent des règles de 7 jours et de 24 heures.

Masquage par CNAME et par adresse IP

Un contournement courant est un sous-domaine de suivi, comme t.yourstore.com, qui pointe vers un serveur de suivi. Les cookies de ce sous-domaine sont posés dans la réponse HTTP : ce ne sont donc pas des cookies de script. WebKit considère le sous-domaine comme masqué quand il pointe par un CNAME vers un domaine différent. Depuis Safari 17, il le considère aussi comme masqué quand son adresse IP ressemble à celle d’une partie différente de votre site, par exemple quand les deux adresses sont dans des plages réseau nettement différentes. Dans les deux cas, ITP plafonne à 7 jours les cookies posés dans la réponse. Le propriétaire du serveur n’a pas d’importance pour ces règles.

Comment Safari traite-t-il les identifiants de clic dans les liens ?

Un identifiant de clic comme fbclid ou gclid fait partie de l’URL d’arrivée. En navigation normale, Safari charge l’URL avec ses paramètres : un script de la page d’arrivée peut donc lire l’identifiant de clic. Le plafond de 24 heures ci-dessus limite la durée de vie d’un cookie écrit sur cette page. Il ne retire pas l’identifiant de clic de l’URL.

La navigation privée va plus loin. Depuis Safari 17, la Link Tracking Protection s’applique quand le visiteur passe d’un site à un autre, par exemple d’une publicité à votre boutique. Safari supprime un ensemble de paramètres de requête que WebKit a identifiés comme servant au suivi intersite des utilisateurs ou des clics. L’annonce de WebKit ne liste pas ces paramètres. Son exemple supprime un paramètre de suivi et conserve un paramètre de campagne. Sur la page d’arrivée, les scripts tiers qui lisent l’URL la reçoivent aussi sans la chaîne de requête. Les mêmes protections sont disponibles en navigation normale pour les personnes qui activent la protection avancée contre le suivi et le fingerprinting pour toute la navigation.

Et Private Relay et les adresses IP ?

Selon WebKit, Safari masque par défaut les adresses IP aux traceurs connus depuis Safari 15. Les personnes qui paient iCloud+ peuvent aussi activer iCloud Private Relay. Il fait passer le trafic de Safari par deux relais distincts, gérés par des opérateurs différents : les sites voient alors l’adresse IP d’un relais et non celle du visiteur. Apple indique que l’adresse du relais conserve la localisation approximative du visiteur, au niveau de la ville, et que plusieurs utilisateurs d’une même zone peuvent partager une adresse.

Cela affaiblit le suivi qui repose sur l’adresse IP, comme l’association d’un visiteur par adresse IP et navigateur. Cela n’affecte ni les identifiants de clic, ni les adresses e-mail hachées, ni les données de commande. ROASaurus n’utilise une correspondance par IP qu’en dernier recours, et seulement quand exactement un visiteur récent avec cette adresse IP et ce navigateur correspond. Une adresse de relais partagée aboutit alors généralement à aucune correspondance.

Que signifie ITP pour les fenêtres d’attribution ?

Une fenêtre d’attribution est le nombre de jours après un clic pendant lesquels un achat peut encore être crédité à ce clic. Dans ROASaurus, vous choisissez une fenêtre de 1 à 90 jours, avec 7 jours par défaut. Les plateformes publicitaires ont leurs propres réglages. Dans Safari, une configuration qui repose uniquement sur les cookies du navigateur ne peut relier un achat à un clic que tant que le cookie existe.

L’effet grandit avec la fenêtre. Une fenêtre de 1 jour ou de 7 jours n’est pas plus longue que la durée de vie de 7 jours d’un cookie de script, sauf si le plafond de 24 heures s’applique. Avec une fenêtre de 28 jours, les achats du jour 8 ou plus faits par des acheteurs qui ne sont pas revenus entre-temps dépendent d’autres données.

Voici comment estimer cela pour une boutique. Les chiffres sont un exemple ; utilisez les vôtres.

Que signifie ITP pour le remarketing ?

Les audiences de remarketing sont construites à partir d’événements du navigateur, comme les personnes qui ont consulté un produit ou l’ont ajouté au panier. Dans Safari, la plateforme ne peut pas utiliser ses cookies tiers, et le cookie first-party du pixel est supprimé après 7 jours sans visite. Un visiteur Safari qui revient après 8 jours paraît nouveau pour le pixel. Ses consultations de produits précédentes ne sont plus rattachées à lui dans le navigateur.

Deux effets en découlent. Les audiences à longue durée, comme 30 ou 180 jours, conservent moins de visiteurs Safari que la durée ne le suggère. Votre outil d’analyse affiche aussi plus de nouveaux visiteurs et moins de visiteurs récurrents que vous n’en avez réellement. Les audiences de liste de clients construites à partir d’adresses e-mail hachées dans votre boutique ou votre outil d’e-mailing ne dépendent pas des cookies : elles ne sont donc pas touchées de la même façon.

Qu’est-ce qui fonctionne encore dans Safari ?

Événements côté serveur issus des commandes

Un achat envoyé à partir des données de commande de votre boutique ne dépend d’aucun cookie dans Safari. La boutique enregistre la commande, un serveur l’envoie à l’API de la plateforme, et la plateforme la reçoit. L’événement inclut l’e-mail et le numéro de téléphone hachés de la commande. La plateforme peut les associer à l’un de ses utilisateurs et consulter ses propres enregistrements de clics et de vues publicitaires, dans sa propre fenêtre d’attribution. Lisez ce qu’est le suivi côté serveur pour le chemin complet des données.

Identifiants de clic capturés à l’arrivée

L’identifiant de clic figure dans l’URL de la première page. Un script peut l’y lire et l’envoyer à votre serveur, où il est stocké avec l’identifiant visiteur. La copie sur le serveur n’expire pas après 7 jours. Ce qui expire, c’est le cookie du navigateur qui relie une visite de retour à cet identifiant visiteur stocké. D’autres données peuvent encore relier une commande à un clic stocké, comme une adresse e-mail que l’acheteur a donnée plus tôt dans un formulaire d’inscription, ou l’identifiant de clic dans l’URL d’arrivée de la session qui a passé la commande.

Collecte first-party, avec la limite de 7 jours

Servir le script de suivi et ses requêtes depuis votre propre domaine garde la collecte first-party, ce qui aide aussi contre les bloqueurs de publicité. Cela ne fait pas durer les cookies plus longtemps à lui seul. Un sous-domaine de suivi qui pointe par un CNAME vers un autre domaine, ou que WebKit voit comme une adresse IP tierce, tombe sous le plafond de 7 jours. Un sous-domaine de suivi ROASaurus réémet l’identifiant visiteur sous forme de cookie HTTP, mais Safari peut quand même plafonner ce cookie à 7 jours. Le proxy d’application Shopify garde les requêtes sur le domaine de votre boutique, mais Shopify retire les cookies des requêtes et des réponses du proxy d’application : l’identifiant visiteur y est donc écrit par JavaScript, et la règle de 7 jours s’applique.

Ce que vous dit l’acheteur

Les acheteurs peuvent vous dire comment ils vous ont trouvé, et cette réponse ne dépend pas des cookies. Un sondage post-achat pose la question après le checkout. Dans ROASaurus, le modèle Total Impact combine la réponse avec les données de clics, et donne 50% du crédit au sondage quand il y a aussi des clics.

Comment vérifier dans quelle mesure Safari touche votre boutique

1. Trouvez la part de Safari dans vos commandes

   Dans votre outil d’analyse, regroupez les achats par navigateur. Comptez Safari sur Mac, iPhone et iPad.

2. Mesurez le délai entre le clic et l’achat

   Trouvez combien de commandes arrivent plus de 7 jours après le clic publicitaire. Dans le rapport d’attribution de ROASaurus, comparez les fenêtres de 7, 14 et 28 jours et regardez combien de crédit se déplace.

3. Comparez les achats du pixel avec les commandes

   Comptez les événements Purchase envoyés par votre pixel, par navigateur si votre plateforme le permet, et comparez-les avec vos commandes sur la même période.

4. Vérifiez vos événements serveur

   Assurez-vous que chaque commande payée est envoyée côté serveur avec l’e-mail et le téléphone hachés, et que les copies navigateur et serveur partagent un même identifiant d’événement.

Si une grande part de vos commandes vient de Safari, et que beaucoup d’entre elles arrivent plus de 7 jours après le clic, les cookies du navigateur seuls sous-estimeront vos publicités. Les achats envoyés à partir des données de commande, avec des données client hachées, donnent aux plateformes publicitaires un autre moyen d’associer ces commandes. Vous pouvez voir comment ROASaurus procède sur la page suivi côté serveur, et comment il crédite les clics dans l’attribution.

Sources

1. WebKit: Tracking Prevention in WebKit
2. WebKit: Intelligent Tracking Prevention 2.2
3. WebKit: CNAME Cloaking and Bounce Tracking Defense
4. WebKit: Private Browsing 2.0
5. Apple Developer: Prepare your network or web server for iCloud Private Relay

Dans ROASaurus

• Le suivi côté serveur dans ROASaurus
• L’attribution dans ROASaurus
• Tunnels de vente et domaines liés

À lire aussi