Attribution des clics après Safari ITP : ce qui fonctionne encore en 2026

Apple a livré la première version d'Intelligent Tracking Prevention en septembre 2017. Elle était présentée comme une fonctionnalité de confidentialité, ce qui est exact. C'était aussi un démantèlement systématique de chaque contournement que l'industrie de l'ad tech avait assemblé depuis que l'écosystème de cookies tiers a commencé à craquer vers 2013. Chaque nouvelle version d'ITP a fermé l'issue de secours que les marketeurs avaient trouvée dans la précédente. Au moment où ITP 2.3 a été livré en 2019, la séquence de fermetures avait été suffisamment méthodique pour que les seuls chemins d'attribution qui fonctionnaient encore de manière fiable sur Safari soient ceux qui n'avaient jamais dépendu du tracking inter-sites tout court.

Cet article parcourt cette séquence dans l'ordre des dates : ce que chaque version a cassé, quel contournement elle visait spécifiquement à fermer, et où cela laisse l'attribution en 2026. L'article compagnon Attribution sans cookie expliquée couvre le paysage plus large à travers les navigateurs ; celui-ci est spécifiquement sur Safari et spécifiquement sur le pattern de chaîne de redirection qui survit à tout.

TL;DR#

• ITP 2.0 (2018) a bloqué tout accès au stockage tiers sur les domaines inter-sites, tuant le chemin standard d'attribution par pixel publicitaire sur Safari.
• ITP 2.1 (2019) a plafonné à 7 jours les cookies first-party posés par JavaScript, mettant fin aux fenêtres d'attribution d'un an posées via les gestionnaires de tags.
• ITP 2.2 et 2.3 ont supprimé les paramètres de décoration de lien et dégradé les en-têtes de referrer, fermant les derniers contournements par chaîne de requête.
• Un lien court sur votre propre domaine pose un cookie first-party côté serveur au moment de la redirection - c'est le seul pattern qui survit à ITP dans toutes ses versions et vous donne une fenêtre d'attribution fiable de 7 jours sur Safari.

La chronologie ITP : un décryptage version par version#

ITP n'est pas arrivé complètement formé. Il a été publié de manière incrémentale, chaque version ciblant une classe spécifique de contournement que l'industrie avait développée en réponse à la précédente. Comprendre la séquence importe parce que la forme technique de ce qui survit est définie par ce qui a été fermé et comment.

ITP 1.0 - septembre 2017. La première version classifiait les domaines comme « trackers inter-sites » d'après la fréquence de rebond et les signaux d'interaction utilisateur. Les domaines classifiés comme trackers voyaient leurs cookies partitionnés - ils pouvaient être posés, mais lus seulement dans un contexte inter-sites si l'utilisateur avait directement interagi avec le domaine du tracker dans les dernières 24 heures. Pour un domaine comme un pixel d'analytics standard que les utilisateurs ne visitent jamais directement, la fenêtre de 24 heures était un blocage de facto.

ITP 1.1 - mars 2018. Les annonceurs ont répondu à 1.0 en routant l'attribution à travers des chaînes de redirection qui touchaient le domaine du tracker comme atterrissage first-party avant de rebondir vers la destination. Cela donnait aux utilisateurs une « visite directe » au domaine du tracker, ce qui réinitialisait l'horloge d'interaction. ITP 1.1 a identifié ce pattern - connu sous le nom de bounce tracker - et a supprimé le crédit d'interaction que les chaînes de bounce-redirect généraient. Les domaines qui semblaient n'exister que pour le pattern bounce-and-redirect perdaient leur statut d'interaction.

Ce qu'ITP 2.0 a cassé#

ITP 2.0 a été livré en septembre 2018. C'était la rupture structurelle. Là où 1.x avait partitionné les cookies tiers, 2.0 est allé plus loin : il a supprimé entièrement l'accès au stockage tiers pour les domaines classifiés. Cookies, localStorage, IndexedDB, données en cache - tout était bloqué pour tout domaine qu'ITP classifiait comme tracker inter-sites.

L'effet pratique sur l'ad tech était significatif. Le Facebook Pixel, le tag de conversion Google Ads et la plupart des pixels de retargeting dépendent de la lecture d'un cookie inter-sites pour lier un clic à une conversion. Sur Safari après ITP 2.0, cette lecture échouait. Le propre reporting de Meta à l'époque indiquait un écart de 15-25 % dans la couverture d'événements sur le trafic Safari - des clics et conversions que le pixel voyait sur Chrome ou Firefox n'apparaissaient simplement pas pour les utilisateurs Safari.

Le blocage du stockage n'était pas limité aux cookies. Les scripts qui essayaient de persister des identifiants dans localStorage sous un domaine classifié comme tracker, ou d'utiliser les Service Workers pour la persistance, étaient également bloqués. L'intention de 2.0 était de rendre la couche de stockage tiers structurellement indisponible pour les besoins de tracking, pas seulement de casser une technique spécifique.

Ce qu'ITP 2.1 a cassé#

Si 2.0 a tué l'attribution tiers, ITP 2.1 (mars 2019) ciblait le contournement qui s'était développé en réponse : l'attribution par cookie first-party via l'injection de gestionnaire de tags.

La logique était saine. Si le pixel tiers était bloqué, vous pouviez encore persister l'attribution en écrivant un cookie first-party sur le propre domaine de l'annonceur via JavaScript - typiquement injecté par un gestionnaire de tags comme GTM. Le cookie était first-party et donc non soumis aux restrictions de stockage tiers d'ITP. Beaucoup d'équipes avaient migré vers des fenêtres d'attribution d'un an posées de cette manière, raisonnant qu'une écriture first-party document.cookie était sûre.

ITP 2.1 a plafonné tous les cookies posés via document.cookie - quel que soit le statut first-party ou third-party - à un maximum de 7 jours. Le plafond s'appliquait spécifiquement aux cookies posés par script ; les cookies posés via l'en-tête de réponse HTTP Set-Cookie n'étaient pas affectés par 2.1. La distinction est précise et conséquente : document.cookie = "..." en JavaScript est plafonné à 7 jours. Set-Cookie: ...; Max-Age=31536000 depuis une réponse serveur ne l'est pas.

La victime immédiate était la configuration d'attribution basée sur GTM. GTM écrit les cookies via JavaScript sur la page. Ces cookies, quelle que soit leur expiration déclarée, expirent maintenant en 7 jours sur Safari. Un utilisateur qui cliquait un lien de campagne un mardi et convertissait le mercredi suivant était hors de la fenêtre d'attribution. La fenêtre d'attribution par cookie first-party d'un an vers laquelle les équipes avaient migré après ITP 2.0 était partie.

Ce qu'ITP 2.2 a cassé#

ITP 2.2 a resserré deux domaines. D'abord, il a réduit le plafond des cookies JavaScript à 24 heures dans le cas spécifique où la page de destination était liée depuis un domaine qu'ITP avait classifié comme tracker inter-sites. Si un utilisateur cliquait un lien depuis la page d'un domaine classifié, les cookies first-party sur le site de destination posés via JavaScript étaient plafonnés à 24 heures - pas 7 jours. Le plafond de 7 jours restait pour les chemins de referrer non trackés, mais le plafond de 24 heures s'appliquait quand la chaîne de clic incluait un domaine classifié.

Deuxièmement, et plus largement remarqué, ITP 2.2 a introduit des limites sur la décoration de lien. Les plateformes publicitaires et outils d'analytics avaient développé un pattern d'ajout d'identifiants d'attribution comme paramètres de requête aux URL de destination - gclid pour Google Ads, fbclid pour Meta, msclkid pour Microsoft Advertising. Sous certaines conditions, si le domaine source était classifié comme tracker, ITP a commencé à dépouiller ces paramètres avant le chargement de la page ou à limiter les cookies pouvant être posés en réponse à leur présence.

C'était une attaque directe sur le chemin d'attribution basé sur gclid vers lequel les équipes avaient pivoté après 2.0 et 2.1. Le raisonnement était explicite : Apple considérait le tracking utilisateur basé sur les paramètres de requête comme équivalent en impact sur la vie privée au tracking par cookie, et les mêmes restrictions devraient s'appliquer.

Ce qu'ITP 2.3 a cassé#

ITP 2.3 (septembre 2019) a fermé deux derniers vides.

Le premier était la dégradation du referrer sur la navigation inter-sites. Là où les versions précédentes s'étaient concentrées sur le stockage et les paramètres de lien, 2.3 s'attaquait à l'en-tête referrer - la valeur Referer qu'une page reçoit quand un utilisateur y navigue depuis un autre site. Pour les navigations inter-sites depuis des domaines classifiés, ITP 2.3 dégradait le referrer à origin-only : https://classified-domain.com/ au lieu du complet https://classified-domain.com/path?campaign=spring&source=email. Le chemin et la chaîne de requête, qui contenaient souvent le contexte d'attribution, étaient dépouillés.

Le second changement étendait la logique de plafonnement du stockage. En plus du plafond de 7 jours sur les cookies JavaScript, ITP 2.3 appliquait un plafond de stockage après un seul clic inter-sites depuis un domaine classifié : tout le stockage côté client sur le site de destination - cookies, localStorage, IndexedDB - était soumis au plafonnement. L'intention était de fermer une classe de patterns d'attribution avec état où le simple fait d'être lié depuis un domaine classifié démarrait un compte à rebours sur la capacité de la destination à persister des données.

Ensemble, 2.2 et 2.3 ont fermé les trois principales routes que les équipes avaient utilisées après 2.0 et 2.1 : paramètres de décoration de lien, attribution basée sur le referrer, et accumulation de stockage à travers les chaînes de clic inter-sites.

Ce qui survit#

La séquence ITP était méthodique, mais elle était ciblée sur le tracking inter-sites. Les patterns qui survivent sont ceux qui sont vraiment first-party - où les données d'attribution sont capturées sur votre propre domaine, posées via votre propre serveur, et ne passent jamais par le stockage d'un domaine tiers.

Cookies first-party posés par serveur. Le plafond de cookies d'ITP 2.1 s'applique aux écritures document.cookie via JavaScript. Les cookies posés par un serveur via l'en-tête de réponse HTTP Set-Cookie conservent leur expiration déclarée. La contrainte clé est que le cookie doit être posé sur le domaine que le serveur contrôle.

Transfert d'événement côté serveur. Si l'identifiant de clic est capturé au moment de la redirection et stocké côté serveur, la recherche d'attribution au moment de la conversion est une opération serveur-à-serveur. Aucun cookie navigateur n'a besoin de survivre 7 jours ; l'ID de clic est dans votre base de données. C'est l'architecture derrière le suivi de conversion côté serveur et l'approche que Meta CAPI, GA4 Measurement Protocol et l'API TikTok Events sont tous conçus pour supporter.

Matching déterministe via email ou téléphone hashé. Quand un utilisateur est authentifié ou a soumis une adresse email, la conversion peut être rattachée au clic d'origine par hash d'email plutôt que par identité de cookie. Ce chemin est indépendant d'ITP entièrement - il n'a jamais reposé sur le stockage navigateur. La limitation est la couverture : ça ne fonctionne que pour les utilisateurs qui se sont identifiés dans la fenêtre d'attribution.

Le contexte technique complet pour ces patterns est dans Attribution sans cookie expliquée.

Le pattern de redirection par lien court#

Les liens courts sur votre propre domaine - pas sur un domaine de raccourcisseur partagé - vous donnent le chemin de cookie posé par serveur sous une forme qui fonctionne naturellement avec le trafic de campagne.

La mécanique est simple. Quand un utilisateur clique sur un lien de campagne pointant vers go.acme.example/spring26, la requête atteint un gestionnaire d'edge sur go.acme.example. Le gestionnaire d'edge capture l'événement de clic, génère un ID de clic, et pose un en-tête Set-Cookie sur la réponse de redirection - un cookie first-party posé par serveur sur acme.example. Il émet ensuite la 302 vers l'URL de destination avec l'ID de clic ajouté comme paramètre de requête.

Parce que le cookie est posé via Set-Cookie par le serveur au moment de la redirection, le plafond JavaScript de 7 jours d'ITP 2.1 ne s'applique pas. Le cookie conserve quelle que soit l'expiration que le serveur a posée. Sur Safari, avec ITP 2.3 pleinement actif, un cookie posé par serveur sur go.acme.example survit pour la fenêtre complète configurée. Nous posons une expiration de 7 jours par défaut chez Elido parce que cela correspond de toute façon à la contrainte la plus restrictive d'ITP pour les cookies posés par JS, et le cookie posé par serveur tient pour les 7 jours complets.

La page de destination lit alors l'ID de clic depuis le cookie ou depuis le paramètre de requête (selon ce qui est disponible), l'écrit dans les attributs de panier ou de commande, et l'événement de conversion le porte côté serveur au moment de l'achat. Aucun domaine inter-sites n'est impliqué. Le cookie est sur votre domaine. La recherche d'attribution est une opération côté serveur. ITP n'a rien à bloquer.

C'est pourquoi le support de domaine personnalisé sur un lien court compte pour l'attribution : pas seulement pour le branding mais pour la classification first-party du cookie. Un domaine de raccourcisseur partagé comme bit.ly ou short.io est une origine différente de votre site. Un cookie posé sur bit.ly est un cookie tiers sur acme.example ; ITP 2.0 le bloque. Un cookie posé sur go.acme.example est first-party ; rien dans ITP n'y touche. La page solutions/marketers couvre le flux d'attribution de campagne de bout en bout.

Pour le contexte RGPD plus profond sur quelles données de clic un raccourcisseur peut traiter légalement et comment configurer la minimisation des données sur le schéma d'événement de clic, voir RGPD pour les raccourcisseurs d'URL.

Ce qui ne fonctionne toujours pas#

L'honnêteté est moins coûteuse que de survendre une solution partielle.

Attribution view-through inter-domaines. Si un utilisateur voit une pub sur publisher.example sans cliquer et convertit plus tard sur advertiser.example, il n'y a pas de chemin sûr ITP pour cette attribution. La view-through exige intrinsèquement un signal inter-sites de l'impression à la conversion. Safari le bloque, et les approches de transfert côté serveur ci-dessus sont initiées par le clic - elles exigent que le clic pose le cookie first-party ou écrive l'ID de clic.

Stitching temps réel pour utilisateurs non authentifiés. Si un utilisateur convertit sans jamais se connecter ou soumettre une adresse email, le seul identifiant disponible est l'ID de clic du cookie ou du paramètre de requête. Si le cookie a expiré (au-delà de 7 jours après le premier clic, ou 24 heures si le plafond plus serré de 2.2 s'applique), le stitch est perdu. Le stockage côté serveur de l'ID de clic résout cela pour les conversions dans la fenêtre. Il ne résout pas pour les conversions qui arrivent après la fermeture de la fenêtre.

Fenêtres d'attribution plus longues que 7 jours sur Safari pour le premier touch. Si votre business a un cycle d'achat mesuré en semaines ou mois - courant en SaaS B2B, e-commerce de forte valeur, services financiers - la fenêtre de 7 jours sur les cookies first-party Safari signifie qu'une fraction substantielle des conversions ne sera pas attribuable à leur clic d'origine. Pour ces modèles d'affaires, le chemin déterministe par hash d'email est la seule option ; l'attribution probabiliste sur Safari n'est pas assez fiable pour agir dessus.

Fingerprinting comme substitut. Canvas fingerprinting, fingerprinting audio et énumération de polices sont des contournements qui tentent de ré-identifier les utilisateurs à travers les sessions sans cookies. Apple s'est explicitement engagé à réduire la surface de fingerprinting dans Safari. Les notes de version d'ITP 2.3 font référence à « protection additionnelle contre d'autres formes de tracking inter-sites », et la direction a continué dans chaque version Safari suivante. Le fingerprinting porte aussi un risque légal matériel sous l'Article 6 du RGPD, comme exploré dans RGPD pour les raccourcisseurs d'URL. Ce n'est pas un remplacement viable pour les patterns décrits ci-dessus.

Point de départ pratique#

Le pattern de redirection fonctionne. Configurez un domaine personnalisé sur votre workspace de lien court (go.yourdomain.example), routez le trafic de campagne à travers lui, et configurez votre page de destination pour lire le paramètre de requête elido_click ou le cookie first-party et l'écrire dans vos attributs de commande ou panier avant que l'utilisateur ne convertisse. Puis routez les conversions côté serveur vers les plateformes publicitaires via l'API de conversions. La fenêtre de 7 jours couvre la majorité des chemins clic-à-conversion pour la plupart des types de campagne.

Pour la configuration du transfert de conversion - Meta CAPI, GA4 Measurement Protocol, la sémantique de retry et la forme de déduplication - le suivi de conversion côté serveur est le compagnon technique de cet article. Pour la surface produit, les fonctionnalités de suivi de conversion est le point de départ.

ITP n'a pas tué l'attribution. Il a tué une architecture spécifique d'attribution - celle construite sur le stockage persistant inter-sites et l'accumulation indifférenciée de données à travers des domaines que vous ne contrôlez pas. L'architecture qui l'a remplacée est plus défendable, pas moins.