ITP, iOS 14, server-side, CAPI : pourquoi ton tracking s'est effondré (et comment il s'est reconstruit)

Dans l'article précédent, on a vu comment fonctionne le tracking client-side classique : UTM, cookies, pixel. Ce modèle reposait massivement sur les cookies third party et sur des appels JavaScript directs entre le navigateur du visiteur et les serveurs de Meta ou Google. Puis les régulateurs et les navigateurs ont changé les règles du jeu.

Acte 1 : le consentement (RGPD)

Premier coup de frein : le RGPD et la CNIL. Le constat était simple : tout le monde posait des cookies dans tous les sens sans que les utilisateurs le sachent. La réponse : obligation de recueillir le consentement pour les cookies non essentiels. D'où les bannières que tu connais. Les cookies strictement techniques restent exemptés, mais les cookies publicitaires nécessitent un opt-in.

Acte 2 : les navigateurs bloquent les cookies third party (ITP)

Deuxième coup, plus violent : Apple. À partir de 2017, Safari déploie l'Intelligent Tracking Prevention (ITP), durci d'année en année. Le principe : c'est l'éditeur du navigateur qui décide ce que le navigateur laisse passer. Et Apple a décidé que les cookies third party ne passeraient plus, et que même certains cookies first party posés par JavaScript seraient purgés au bout de quelques jours.

Concrètement : tu vois une pub sur Facebook, tu cliques, tu arrives sur le site via Safari. Le pixel essaye d'appeler les serveurs de Meta pour poser son cookie et remonter l'événement. Safari bloque. Résultat : la conversion existe, mais Meta ne la voit pas.

C'est ce qui explique les "drops de performance" observés sur ces années-là. Ce n'étaient pas de vraies baisses de performance : c'étaient des baisses de tracking. Les ventes avaient lieu, on ne savait juste plus les rattacher aux campagnes.

Acte 3 : iOS 14 et le monde applicatif

Sur mobile, le problème est différent : dans l'app Facebook, il n'y a pas de cookies. Le navigateur et les applications sont deux univers séparés qui ne se parlent pas. Ce qui permettait de faire le lien, c'était un identifiant publicitaire partagé entre les apps, l'IDFA chez Apple.

Avec iOS 14.5 (avril 2021) et le framework App Tracking Transparency, Apple a rendu cet identifiant opt-in : chaque app doit demander explicitement la permission de te suivre. La grande majorité des utilisateurs refuse. Résultat : le lien entre "j'ai vu ou cliqué une pub dans l'app" et "j'ai converti sur le site" s'est massivement dégradé, exactement comme sur Safari mais avec des barrières placées à d'autres endroits.

La riposte : le tracking server-side

Face à ça, l'écosystème a trouvé une parade élégante. Puisque le navigateur bloque les appels vers les domaines tiers, on ne va plus appeler les tiers depuis le navigateur.

Le montage est le suivant. Au lieu de poser un pixel Meta qui appelle directement facebook.com, tu poses ton propre tracker qui envoie les données vers un sous-domaine à toi, par exemple t.tonsite.com. Pour Safari, c'est un site qui s'envoie de l'information à lui-même : c'est du first party, il y a mille raisons techniques légitimes de le faire, impossible de le bloquer sans casser internet.

Derrière ce sous-domaine, il y a un serveur qui t'appartient. Et c'est ce serveur qui, dans un second temps, transmet les données aux serveurs de Meta, Google, TikTok. De serveur à serveur, il n'y a plus de navigateur dans la boucle, donc plus rien à bloquer.

Comment les plateformes réconcilient ensuite les deux flux (le pixel classique quand il passe, et le flux server-side) ? Grâce à des identifiants partagés : l'ID de clic présent dans l'URL (fbclid côté Meta, gclid côté Google), l'ID d'événement, et les données utilisateur hashées. Si le même événement arrive par les deux canaux avec le même ID, Meta le dédoublonne. Si un seul canal l'a vu, Meta le récupère quand même. Et comme ton cookie first party est plus persistant que ce que les plateformes peuvent poser elles-mêmes, c'est toi qui fais le lien dans le temps : "cet utilisateur que tu vois comme nouveau, moi je sais que c'est le même qu'il y a trois semaines".

CAPI : ce n'est pas juste du server-side

On confond souvent Conversions API et tracking server-side. C'est très proche, mais la vraie valeur de CAPI est ailleurs.

Le server-side "imite" le fonctionnement d'avant pour que ça marche techniquement malgré les blocages. CAPI, c'est la capacité d'envoyer aux plateformes des événements qui viennent directement de ton back-office, avec des informations que le navigateur n'a jamais eues.

Au moment où le pixel envoie un Purchase, tu ne sais pas encore si la commande sera annulée, remboursée, ou retournée. Ton back-office, lui, le saura. Avec CAPI, tu peux renvoyer l'information retraitée : des achats nets des rétractations, des marges plutôt que du chiffre d'affaires. La plateforme optimise alors sur ta vraie valeur, pas sur un signal brut.

Le cas d'usage roi, ce n'est d'ailleurs pas l'e-commerce : c'est la lead gen. Un lead est envoyé instantanément, mais sa qualification se fait offline, des jours plus tard. Sans CAPI (ou son équivalent Google, les conversions améliorées et l'import de conversions offline), la plateforme optimise sur du volume de leads, pas sur des leads qui signent.

Un mot sur les données personnelles : les emails et numéros de téléphone envoyés aux plateformes sont hashés (SHA-256) avant l'envoi. Ce n'est pas le navigateur qui l'impose, c'est une exigence de conformité et de design des plateformes : deux emails identiques hashés avec le même algorithme donnent le même hash, ce qui permet le matching sans transmettre la donnée en clair.

Comment vérifier que tout ça tourne

Tu ne peux pas tester le flux server-side avec une extension de navigateur, puisque justement il ne passe pas par le navigateur. Le bon réflexe : le Gestionnaire d'événements de Meta (ton dataset).

Trois choses à regarder.

D'abord, la répartition browser vs serveur par événement. En temps normal, tu dois voir plus d'événements côté serveur que côté navigateur, puisque le serveur capte aussi tout ce que Safari et les bloqueurs filtrent. Un écart de 10 à 60 % au-dessus est sain. En dessous de 10 %, soit tout ton trafic accepte les cookies, soit ton flux serveur est incomplet. Au-delà de 60 à 70 %, il y a probablement un problème côté pixel (ou alors ton audience est massivement sur iPhone, typique des marques premium).

Ensuite, la qualité de matching (Event Match Quality). Si Meta te signale des champs manquants (email, téléphone, fbclid), c'est autant de conversions qu'il n'arrivera pas à rattacher à des utilisateurs.

Enfin, l'onglet Diagnostics, qui remonte les alertes de configuration. Si le flux CAPI s'arrête, Meta te préviendra.

Ce qu'il faut retenir

Le tracking moderne, c'est un système à deux jambes : un flux client-side qui passe quand il peut, et un flux server-side qui garantit l'exhaustivité, réconciliés par des identifiants partagés. La couche CAPI par-dessus permet d'enrichir le signal avec ta donnée back-office. Une fois que tout ça remonte proprement, il reste la vraie question : à quel levier attribuer chaque vente, et comment mesurer l'incrément réel. C'est l'objet du troisième article.