Qu'est-ce que le tracking first-party ?

En résumé — Le tracking first-party collecte des données via votre propre domaine plutôt que via des scripts tiers. Toutes les grandes plateformes publicitaires l'utilisent déjà — Google, Meta et TikTok ont adopté les cookies first-party entre 2017 et 2019. Mais les cookies first-party seuls ne règlent pas le problème de perte de données. Les bloqueurs de publicités bloquent les requêtes quel que soit le type de cookie, et Safari ITP limite même la durée de vie des cookies first-party à 7 jours. La vraie solution combine le tracking côté serveur avec une infrastructure first-party pour contourner entièrement les restrictions des navigateurs.

Qu'est-ce que le tracking first-party ?

Le tracking first-party est une méthode de collecte des données des visiteurs de votre site en utilisant votre propre domaine et infrastructure serveur, plutôt que de s'appuyer sur des scripts tiers externes comme le gtag.js de Google ou le pixel de Meta.

La distinction clé ne porte pas sur les données collectées — mais sur qui pose le cookie et où va la requête. Quand un visiteur arrive sur votre site, le tracking traditionnel charge un fichier JavaScript depuis un domaine tiers (comme google-analytics.com ou connect.facebook.net). Le tracking first-party fait transiter la collecte de données via votre propre domaine — par exemple tracking.votresite.com — de sorte que le navigateur traite les cookies comme first-party.

Cela compte parce que les navigateurs font davantage confiance aux cookies first-party qu'aux cookies tiers. Mais comme nous allons le voir, les cookies first-party seuls ne résolvent pas le problème complet de perte de données.

Le tracking first-party n'est pas nouveau — chronologie

De nombreux articles présentent le tracking first-party comme une innovation récente. C'est trompeur. Toutes les grandes plateformes publicitaires ont adopté les cookies first-party il y a des années, contraintes par le lancement en 2017 par Apple de l'Intelligent Tracking Prevention.

L'idée que le tracking first-party est "nouveau" masque la vraie histoire : les plateformes l'ont adopté il y a 7–8 ans, et il ne règle toujours pas complètement le problème de perte de données.

Pourquoi les cookies first-party seuls ne suffisent pas

C'est là que la plupart des articles se trompent. Passer aux cookies first-party était la première étape évidente — et toutes les grandes plateformes l'ont franchie il y a des années. Mais trois forces rendent même les cookies first-party peu fiables.

1. Les bloqueurs bloquent les requêtes, pas seulement les cookies

C'est le détail critique que la plupart des contenus marketing omettent. Les bloqueurs comme uBlock Origin, AdBlock Plus et le bloqueur intégré de Brave maintiennent des listes de filtres (EasyList, EasyPrivacy) qui bloquent les requêtes HTTP vers les endpoints de tracking connus. Peu importe si le cookie est first-party ou third-party — c'est la requête elle-même qui est bloquée. Si votre script envoie des données vers un schéma de tracking reconnu, il est bloqué.

Environ 40% des utilisateurs dans les marchés avertis en technologie utilisent des bloqueurs, représentant 15 à 25% de tout le trafic web perdu à cause du blocage de requêtes — indépendamment du type de cookie.

2. ITP réduit la durée de vie des cookies first-party

L'Intelligent Tracking Prevention de Safari plafonne les cookies définis via JavaScript (document.cookie) à 7 jours. Un visiteur récurrent qui n'est pas venu sur votre site depuis plus d'une semaine apparaît comme un nouvel utilisateur, créant d'énormes lacunes dans les données des visiteurs récurrents. Safari détient ~20% du trafic web mondial et plus de 30% sur mobile dans les marchés occidentaux. Pour les activités B2C, c'est une perte de données significative.

3. ITP cible aussi le CNAME cloaking

Depuis Safari 16.4 (avril 2023), Apple est allé plus loin. Si Safari détecte qu'un enregistrement CNAME pointe vers un domaine tiers, même les cookies définis côté serveur sur ce sous-domaine sont limités à 7 jours. Cela vise directement le contournement le plus courant — le CNAME cloaking — et signale qu'Apple ferme activement les failles, pas seulement les durées de cookies.

Les cookies first-party règlent un problème (la confiance du navigateur) mais en laissent trois autres ouverts : le blocage des requêtes, les restrictions temporelles, et les refus de consentement. C'est pourquoi l'industrie a évolué au-delà des cookies.

Le tracking côté serveur : la vraie évolution

Le vrai changement de donne n'est pas les cookies first-party — c'est de déplacer la collecte de données hors du navigateur entièrement. Le tracking côté serveur gère les événements sur votre serveur, puis les envoie directement aux plateformes publicitaires. Le navigateur n'est jamais impliqué, ce qui rend les bloqueurs et ITP sans objet.

Comment ça fonctionne en pratique : un événement survient sur votre site (achat, inscription, ajout au panier). Votre serveur le capture — pas un JavaScript dans le navigateur. Votre serveur envoie ensuite des données first-party hachées (email, téléphone) directement à Meta, Google ou TikTok. La plateforme associe les données hachées à des profils utilisateurs et attribue la conversion.

Les principales implémentations :

Meta Conversions API (CAPI). Votre serveur envoie des événements de conversion à Meta avec des identifiants hachés. Meta déduplique par rapport aux données du pixel et associe aux profils utilisateurs. Cela contourne complètement les bloqueurs et ITP.

Google Enhanced Conversions. Données client first-party hachées (email, téléphone, adresse) envoyées de serveur à serveur à Google Ads. Google les associe aux comptes connectés pour une meilleure attribution.

Google Tag Manager Server-Side (sGTM). Un conteneur serveur fonctionnant sur votre sous-domaine proxifie toutes les requêtes de tracking via votre infrastructure — vous donnant un contrôle total sur le flux de données.

Résultat : 20 à 30% de conversions supplémentaires tracées par rapport aux configurations pixel seul.

Mise en garde importante : le tracking côté serveur nécessite toujours le consentement. Déplacer le tracking hors du navigateur n'élimine pas le besoin de consentement sous le RGPD et la directive ePrivacy. Vous partagez toujours des données personnelles avec des plateformes publicitaires tierces. Le tracking côté serveur change l'origine des données (votre serveur plutôt que le navigateur), mais cela ne change pas la réalité juridique. Quiconque présente le tracking côté serveur comme un contournement du RGPD vous induit en erreur.

Le CNAME cloaking : un correctif temporaire

Certains fournisseurs de tracking utilisent le CNAME cloaking pour déguiser un tracking tiers en first-party. Le principe : vous créez un enregistrement DNS CNAME faisant pointer track.votresite.com vers tracker.vendor.com. Pour le navigateur et la plupart des bloqueurs basiques, la requête semble first-party.

Cela a fonctionné pendant quelques années. Mais l'écosystème a rattrapé son retard :

Safari 16.4+ (avril 2023). Détecte les chaînes CNAME qui pointent vers des domaines tiers et plafonne les cookies à 7 jours — même ceux définis côté serveur.

Firefox + uBlock Origin. Utilise l'API browser.dns pour résoudre les chaînes CNAME en temps réel et bloque les requêtes aboutissant à des domaines de trackers connus.

Brave (depuis v1.17, 2021). CNAME uncloaking intégré qui résout les enregistrements et bloque les destinations de trackers.

Bloqueurs au niveau DNS (NextDNS, Pi-hole, AdGuard Home). Résolvent les enregistrements CNAME au niveau réseau et bloquent si la destination finale est un tracker connu.

Le CNAME cloaking est un correctif temporaire aux rendements décroissants. Il fonctionne encore contre les bloqueurs basiques, mais échoue face à tous les navigateurs axés sur la confidentialité et les protections au niveau DNS. Ce n'est pas une solution stratégique — c'est du sparadrap.

Comment TrustData implémente le tracking first-party

TrustData adopte une approche différente : une vraie infrastructure first-party, côté serveur par conception, sans aucune dépendance aux astuces de CNAME cloaking que les navigateurs combattent activement.

Installation en 5 minutes. Ajoutez un seul snippet à votre site. Pas de conteneur sGTM, pas de projet Google Cloud, pas de configuration DNS complexe.

+30–40% de données supplémentaires. En combinant la collecte first-party avec le transfert côté serveur, TrustData récupère le trafic rendu invisible par les bloqueurs et ITP aux implémentations standard.

Pas de CNAME cloaking. Pas d'astuces DNS, pas de contournements temporaires que les navigateurs casseront prochain trimestre.

Conforme au RGPD par conception. Respecte les signaux de consentement de votre CMP. Ne prétend pas que côté serveur = sans consentement.

Fonctionne avec GA4. TrustData ne remplace pas vos analytics — il les complète. Vous gardez GA4 pour l'analyse comportementale tout en obtenant le tableau complet.