L'attribution sans cookie expliquée : ce qui fonctionne encore en 2026

Le stack d'attribution marketing que la plupart des équipes ont construit entre 2012 et 2019 reposait sur deux choses : un cookie tiers déposé par la plateforme publicitaire sur la landing page, et un pixel navigateur qui se déclenchait sur la page de conversion et retrouvait ce cookie. Les deux moitiés de cette paire sont maintenant dégradées. Aucune ne se rétablira.

Cet article n'est pas une lamentation pour le cookie. C'est une carte de ce qui fonctionne réellement en 2026 - quels chemins d'attribution ont survécu, lesquels ont été commercialisés comme solutions sans en être réellement, et à quoi ressemble un stack fonctionnel en pratique pour les équipes qui font de l'acquisition payante sur du trafic UE.

TL;DR#

• Apple ITP 2.3, Firefox Enhanced Tracking Protection et la suppression progressive des cookies tiers en cours dans Chrome signifient ensemble que 60 à 70 % du trafic web UE bloque ou limite sévèrement les cookies tiers par défaut.
• Deux chemins d'attribution fonctionnent encore : les identifiants côté serveur passés via un ID de clic, et le dépôt de cookie first-party via une chaîne de redirection que votre domaine contrôle.
• Sans cookie ne signifie pas sans consentement. La Directive ePrivacy 2002/58/CE et le RGPD exigent toujours le consentement pour les analytics non essentiels, quel que soit le mécanisme de stockage.
• Le stitching de fingerprint probabiliste n'est pas un repli conforme en UE ; le matching déterministe par hash d'email combiné à un ID de clic côté serveur est la seule approche qui tient à la fois sous le scrutin de la précision et de la réglementation.

Ce qui a changé : une brève chronologie#

Safari a commencé à restreindre les cookies tiers en 2017 avec ITP 1.0. Les restrictions ont escaladé rapidement. ITP 2.3, publié en septembre 2019, a plafonné la durée de vie des cookies first-party posés par script à sept jours, et à vingt-quatre heures quand la chaîne de référence incluait un tracker inter-sites connu. Ce changement à lui seul a cassé la passation standard click-ID-vers-cookie sur laquelle reposaient la plupart des fournisseurs d'attribution.

Enhanced Tracking Protection de Firefox a déployé Total Cookie Protection à tous les utilisateurs en 2022, partitionnant chaque cookie tiers par site de premier niveau. Un cookie posé par pixel.example.com sur votre page de checkout et la page de checkout de votre concurrent sont maintenant deux cookies entièrement séparés - la corrélation inter-sites est partie par construction.

Le calendrier de Chrome a été décalé plusieurs fois depuis que Google l'a annoncé en 2019. La position actuelle, documentée sur le site Privacy Sandbox (consulté le 2026-05-12), montre la dépréciation se déroulant pour un sous-ensemble d'utilisateurs avec un déploiement complet toujours en cours. Quelle que soit la date finale de Chrome, l'image UE est déjà fixée : Safari et Firefox représentent ensemble la majorité du trafic mobile et desktop soucieux de confidentialité sur les marchés UE. Les stratégies d'attribution qui exigent des cookies tiers sont déjà cassées pour une grande part de votre audience européenne.

L'effet combiné mesuré à travers des comptes de performance marketing UE typiques : l'attribution par pixel côté navigateur sous-compte les conversions de 25 à 45 % selon le mix de trafic, avec les secteurs verticaux à forte composante iOS (mode, beauté, applications, services par abonnement) à l'extrémité haute de cette plage.

Les deux chemins d'attribution survivants#

Chemin 1 : identifiants côté serveur#

La mécanique de base est simple. Quand un utilisateur clique votre pub, la plateforme publicitaire ajoute un identifiant de clic à l'URL de landing - fbclid pour Meta, gclid pour Google, et ainsi de suite. Cet identifiant existe dans l'URL, pas dans un cookie, donc ITP et le partitionnement de cookies ne le touchent pas.

Votre landing page lit l'ID de clic depuis l'URL et l'écrit dans un cookie first-party sur votre propre domaine, ou le transmet à votre panier et éventuellement à l'enregistrement de commande. Quand l'utilisateur convertit, votre back-end lit l'ID de clic de la commande et envoie la conversion serveur-à-serveur à l'API de conversion de la plateforme publicitaire - l'API Conversions de Meta, GA4 Measurement Protocol, l'endpoint d'événements côté serveur de Mixpanel.

Ce chemin fonctionne parce qu'il ne touche jamais de cookies tiers. L'ID de clic est dans la chaîne de requête URL au moment de l'atterrissage. Votre cookie first-party sur votre propre domaine n'est pas restreint par ITP de la même manière que les cookies tiers (bien qu'il soit soumis au plafond de 7 jours sur les cookies posés par script si la chaîne de référence est suspecte - plus de détails ci-dessous). L'événement de conversion circule serveur-à-serveur, entièrement en dehors du navigateur.

Les points faibles sont réels. Si l'utilisateur efface ses cookies entre l'atterrissage et la conversion, l'ID de clic est parti. Si la conversion se produit sur un appareil différent, il n'y a pas de lien cross-device à moins que vous n'ayez un utilisateur connecté avec une adresse email connue. Et iOS 17 a introduit Link Tracking Protection en navigation privée et Mail, qui dépouille les paramètres d'ID de clic connus des URL - fbclid, gclid, msclkid sont sur la liste de dépouillement. Un utilisateur qui arrive via l'app Mail avec link tracking protection activé ne portera pas du tout l'ID de clic dans votre site.

Chemin 2 : chaîne de redirection first-party#

Le deuxième chemin survivant utilise une redirection que vous contrôlez comme surface d'attribution. Au lieu de l'ID de clic de la plateforme publicitaire, vous générez votre propre identifiant persistant au moment de la redirection sur votre propre domaine.

Quand un utilisateur clique un lien sur votre domaine - qu'il s'agisse d'un lien court, d'une redirection de landing de campagne ou d'un deep link brandé - le gestionnaire de redirection sur votre edge s'exécute avant que les restrictions de confidentialité du navigateur ne s'appliquent. Il peut :

1. Poser un cookie first-party avec un ID de clic généré par serveur sur votre domaine.
2. Ajouter l'ID de clic comme paramètre URL à l'URL de destination.
3. Logger l'événement de clic côté serveur avec le contexte technique complet (IP, user-agent, referrer, timestamp) au moment du clic plutôt qu'au moment du chargement de la page.

Parce que c'est votre domaine et votre cookie côté serveur, il se situe en dehors des restrictions de cookies tiers que cible ITP. Le cookie est posé par votre serveur via un en-tête de réponse Set-Cookie sur la réponse de redirection - les cookies posés par serveur ne sont pas soumis au plafond ITP de 7 jours qui s'applique aux écritures document.cookie depuis JavaScript.

C'est la surface d'attribution qu'un raccourcisseur d'URL fournit et qu'un pixel navigateur ne peut pas. La redirection se résout sur le domaine du raccourcisseur. Si ce domaine est votre propre domaine brandé, votre ID de clic est first-party, posé par serveur et architecturalement positionné avant toute restriction de confidentialité côté navigateur.

Comment un lien court devient la surface d'attribution#

Le flux de redirection fonctionne ainsi. L'URL de destination de votre pub est un lien court brandé - par exemple, go.acme.example/summer-sale. L'utilisateur clique. La requête de redirection atteint le gestionnaire d'edge d'Elido, qui :

• Cherche l'URL de destination.
• Génère un identifiant elido_click et logge l'événement de clic côté serveur.
• Pose un Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 first-party sur la réponse de redirection.
• Ajoute ?elido_click=<id> à l'URL de destination avant de transférer.

La page de destination reçoit l'ID de clic dans la chaîne de requête. Votre gestionnaire de tags ou code de thème le lit et le stocke sur l'enregistrement de panier ou de commande. Quand la conversion se produit, vous faites un POST sur POST /v1/conversions avec l'ID de clic et les détails de commande - Elido gère le hashing SHA-256 des identifiants client et le fan-out côté serveur vers Meta CAPI, GA4 Measurement Protocol et Mixpanel.

L'ID de clic n'a jamais vécu dans un cookie tiers. Il a été posé par serveur, first-party, loggé avant que la couche de confidentialité du navigateur n'ait eu une chance d'interférer. Pour la mécanique complète de l'étape de transfert côté serveur, le suivi de conversion côté serveur via les liens courts couvre la déduplication, les exigences de hashing et la sémantique de retry en détail.

Pour la question plus large de comment ITP dégrade spécifiquement l'attribution des clics et ce que la chaîne de redirection par lien court fait à ce sujet, Attribution des clics après Safari ITP est le compagnon opérationnel de cet article.

Stitching d'identité : ce qui fonctionne et ce qui ne fonctionne pas#

Les ID de clic côté serveur résolvent le problème d'attribution pour les utilisateurs qui cliquent un lien et convertissent dans la même session navigateur sur le même appareil, sans effacer les cookies, sans link tracking protection dépouillant le paramètre. Cela couvre encore la majorité des conversions e-commerce. Mais ça ne couvre pas tout, et les approches que les équipes utilisent pour combler l'écart restant varient significativement à la fois en précision et en exposition légale.

Le matching déterministe fonctionne. Si l'utilisateur est connecté, ou fournit son adresse email à un moment quelconque dans le funnel (capture d'email, inscription newsletter, checkout), vous pouvez hasher cette adresse email avec SHA-256 et l'inclure dans l'événement de conversion. Meta CAPI, GA4 et Mixpanel acceptent tous l'email hashé comme signal de matching aux côtés ou en lieu et place d'un ID de clic. Le taux de match pour le trafic à email connu est élevé - Meta rapporte en interne des taux de match au-dessus de 90 % quand un email normalisé et hashé est présent. C'est le mécanisme de stitching principal qui survit intact à la dépréciation des cookies.

L'appariement de déduplication compte ici. Chaque événement de conversion a besoin d'un event_id (pour Meta) ou transaction_id (pour GA4) qui est identique entre le pixel côté navigateur et l'envoi côté serveur. Sans ça, les deux événements s'ingèrent et la conversion est comptée double. L'ID de commande est la clé de déduplication standard pour les événements d'achat.

Le fingerprinting probabiliste ne fonctionne pas - et n'est pas légal en UE. Le fingerprinting de navigateur assemble un identifiant unique à partir de la combinaison de la résolution d'écran, des polices installées, du fuseau horaire, du user-agent, du fingerprint de rendu canvas et signaux similaires. L'identifiant est probabiliste - il assigne un match à haute confiance entre deux événements sans cookie partagé ni connexion. Certains fournisseurs d'attribution offrent ceci comme solution de « mesure sans cookie ».

En UE, cette approche a un problème légal spécifique. La Directive ePrivacy 2002/58/CE, Article 5(3), exige le consentement pour accéder ou stocker des informations sur l'équipement terminal d'un utilisateur. La position de l'EDPB, répétée dans plusieurs décisions d'autorités de contrôle depuis 2022, est que le fingerprinting tombe sous le périmètre de l'Article 5(3) que l'identifiant soit techniquement un « cookie » ou non. La DSB autrichienne, la CNIL française et le Garante italien ont chacun émis des actions d'application sur le fingerprinting sans consentement. La revendication « nous n'utilisons pas de cookies, nous utilisons le fingerprinting » n'est pas un argument de conformité ; c'est l'argument qui invite à un examen plus rapproché.

Même en dehors de l'exposition légale, le fingerprinting probabiliste se dégrade en précision à mesure que l'entropie du navigateur décroît. Les navigateurs modernes orientés confidentialité abaissent activement l'entropie en normalisant la sortie canvas et limitant la résolution des API de timing. La qualité du signal chute précisément dans la population - soucieuse de confidentialité, à forte composante iOS - où vous avez le plus besoin d'une mesure précise.

Le stitching cross-device via CRM est l'écart restant. Pour les utilisateurs qui convertissent sur un appareil différent de celui sur lequel ils ont cliqué, le matching déterministe par email est la seule approche qui fonctionne. Si l'utilisateur est connecté sur les deux appareils, l'ID utilisateur est le lien. S'ils ne sont pas connectés, l'ID de clic sur l'appareil A et la conversion sur l'appareil B ne peuvent pas être connectés sans que l'utilisateur fournisse volontairement un identifiant (email, téléphone) que vous pouvez hasher et matcher. Cet écart ne peut pas être fermé côté serveur. C'est une vraie limite d'attribution dans le monde sans cookie.

La couche de conformité#

Le cadrage de « l'attribution sans cookie » peut induire les gens à penser que parce qu'aucun cookie n'est posé, aucun consentement n'est requis. Ce n'est pas ce que dit la loi.

La Directive ePrivacy 2002/58/CE, Article 5(3), s'applique à tout stockage ou accès d'information sur l'équipement terminal d'un utilisateur - pas seulement les cookies. Un cookie first-party posé à des fins d'analytics exige le même consentement qu'un cookie tiers posé à des fins de tracking, si ce cookie est non essentiel. Le cookie d'ID de clic posé par serveur décrit ci-dessus est adjacent aux analytics ; il peut ou non exiger le consentement selon l'évaluation de votre responsable de traitement quant à la finalité et l'implémentation nationale applicable de la Directive.

Ce que fait l'approche côté serveur - et c'est son réel avantage de conformité - c'est de décaler le traitement hors de l'appareil de l'utilisateur et sur le serveur. Le log d'événement de clic, le transfert d'événement de conversion, le stitching d'identité : tous se produisent dans votre back-end et le back-end d'Elido, pas dans un script navigateur. Cela signifie que les ad blockers ne les interceptent pas, les fonctionnalités de confidentialité de navigateur ne les partitionnent pas, et la posture de minimisation de données est contrôlable par vous plutôt que dépendante de ce qu'un tag tiers décide d'envoyer.

La question de la base légale RGPD est séparée de la question ePrivacy. Même avec l'attribution côté serveur, vous avez besoin d'une base légale sous l'Article 6 du RGPD pour traiter les données de clic sur des sujets UE identifiables. Pour les analytics au niveau campagne, la plupart des responsables de traitement fondent ceci sur l'intérêt légitime sous l'Article 6(1)(f) après une Évaluation d'Intérêt Légitime. Pour le profilage au niveau individuel ou le retargeting, la base est plus difficile. Le cornerstone RGPD pour les raccourcisseurs d'URL couvre l'analyse des Articles 6, 28 et 30 en détail ; le résumé ici est que sans cookie ≠ sans consentement, et la couche de conformité ne disparaît pas parce que le mécanisme de stockage a changé.

Les défauts d'événement de clic d'Elido reflètent une posture de minimisation de données : les IP sont tronquées à /24 (IPv4) avant persistance, les chaînes user-agent complètes sont parsées et abandonnées. Les données en pleine résolution sont disponibles par workspace si votre cas d'usage l'exige, mais le défaut est le réglage conservateur. Cela compte pour la conversation d'avenant DPA avec vos acheteurs. Pour plus sur cette conversation, solutions/marketers couvre les points de contact côté achat pour les équipes marketing.

Ce que vous abandonnez#

La comptabilité honnête compte. L'attribution côté serveur sans cookie récupère la plupart du signal perdu à la dégradation côté navigateur, mais elle ne récupère pas tout.

Identité cross-device en temps réel. Comme noté ci-dessus : si un utilisateur clique sur mobile et convertit sur desktop sans événement de connexion liant les deux, l'attribution est perdue. Il n'y a pas de remède côté serveur conforme pour cela. L'écart est structurel.

Attribution view-through précise. L'attribution view-through - créditer une campagne pour une conversion qui a suivi une impression publicitaire, pas un clic - exige que la plateforme publicitaire ait matché l'utilisateur à travers les deux événements. Les API de conversion côté serveur gèrent bien l'attribution basée sur le clic ; la view-through dépend du propre graphe cross-device de la plateforme, qui lui-même se dégrade en proportion de la perte de signal. Attendez-vous à ce que le reporting view-through soit plus bruyant et moins fiable que les chiffres basés sur le clic.

Longues fenêtres de lookback. La plupart des endpoints d'API de conversion côté serveur imposent un plafond de lookback sur la distance dans le temps qu'un clic peut être attribué à une conversion. Le lookback standard de Meta CAPI est de 7 jours pour le click-through. Le Measurement Protocol de GA4 a une fenêtre d'attribution qui varie par canal. Ces plafonds sont plus courts que les fenêtres de 28 ou 90 jours que certaines équipes utilisaient dans le monde basé sur les cookies. Les produits par abonnement et les achats considérés avec de longs cycles de recherche verront plus de conversions tomber en dehors de la fenêtre attribuable.

Domination du last-click. Sans graphe d'identité multi-touch, l'attribution côté serveur par défaut va au last-click - l'ID de clic le plus récent dans la chaîne reçoit le crédit. Pour les campagnes de notoriété de marque qui pilotent des conversions assistées sur une longue période, l'attribution last-click côté serveur sous-évaluera systématiquement la dépense haut de funnel. La mitigation est le stitching CRM via email hashé : si l'email de chaque utilisateur connecté est sur chaque événement de conversion, vous pouvez reconstruire une séquence multi-touch pour la portion connectée de votre audience. Pour les utilisateurs anonymes, le last-click est le plafond.

Un stack pratique#

Étant données les contraintes ci-dessus, voici le stack d'attribution qui fonctionne pour une équipe de performance marketing faisant tourner du trafic UE en 2026.

ID de clic par lien court comme point d'entrée. Toutes les destinations publicitaires sont des liens courts brandés sur votre domaine. La redirection pose un cookie first-party côté serveur et ajoute l'ID de clic à l'URL de destination. Cela vous donne un identifiant persistant, posé par serveur qui survit à ITP et au partitionnement de cookies pour la session.

Plomberie panier et commande. L'ID de clic est écrit dans un attribut de panier au chargement de la page (depuis le paramètre URL ou le cookie first-party). À la création de commande, l'ID de clic est sur les attributs personnalisés de la commande. C'est la passation durable - une fois que l'ID de clic est sur la commande, il n'expire pas.

CAPI côté serveur vers Meta. Sur commande payée, votre back-end (ou la fonctionnalité de transfert de conversion) fait un POST vers Meta CAPI avec l'ID de clic, l'email hashé SHA-256, et les identifiants fbc/fbp des cookies first-party. L'event_id est l'ID de commande, matchant le pixel côté navigateur. Meta déduplique dans la fenêtre de matching de 48 heures.

Measurement Protocol côté serveur vers GA4. Simultanément, un événement côté serveur GA4 est envoyé avec transaction_id égal à l'ID de commande. Le client_id est la valeur du cookie GA4 _ga si disponible, l'ID de clic en repli. GA4 déduplique sur transaction_id dans la fenêtre de session.

Stitch CRM par hash email. Pour toute conversion où l'ID de clic est manquant (organique, direct, recherche de marque), l'adresse email hashée est le signal d'attribution. Cela peuple le segment « utilisateur connu » de votre attribution et supporte une reconstruction multi-touch basique pour les clients connectés.

Import de conversions offline pour le long lookback. Pour les produits par abonnement ou pipelines B2B où la conversion se produit des semaines après le clic, l'import de conversions offline via l'API batch de la plateforme (événements offline de l'API Conversions Meta, conversions offline Google Ads) vous permet d'envoyer des événements d'attribution au-delà de la fenêtre de lookback temps réel. La clé de match est toujours l'email ou le téléphone hashé ; la fenêtre temporelle est étendue. Cela ne résout pas l'attribution anonyme à long cycle, mais ferme la boucle pour la portion de votre audience qui a fourni une adresse email.

Le stack ci-dessus n'exige pas de CDP. Il exige un raccourcisseur d'URL qui génère et persiste des ID de clic côté serveur, un back-end qui plombe l'ID de clic jusqu'à la commande, et une couche de transfert de conversion qui gère le hashing et le fan-out d'API. Pour l'implémentation technique de la couche de fan-out, le suivi de conversion côté serveur via les liens courts a les formes de payload, la mécanique de déduplication et la sémantique de retry. Pour où cela s'inscrit dans un workflow UTM de campagne complet, voir solutions/marketers.

La version de ce stack qui ne fonctionne pas : une qui repose sur le propre graphe cross-device de la plateforme publicitaire pour la résolution d'identité, espère que les utilisateurs iOS ont App Tracking Transparency activé d'une manière qui bénéficie à votre mesure, ou utilise le fingerprinting probabiliste pour combler les vides. La première est hors de votre contrôle. La seconde est un vœu pieux. La troisième est une responsabilité de conformité en UE.

Travaillez avec ce qui tient.