UTM, cookies, pixel : comment fonctionne vraiment le tracking web

Si tu pilotes des budgets d'acquisition, tu utilises des UTM, tu poses des pixels et tu entends parler de cookies à longueur de journée. Mais est-ce que tu sais vraiment ce qui se passe techniquement quand un internaute clique sur une de tes pubs ? Comprendre cette mécanique, c'est la base pour diagnostiquer un problème de tracking, challenger une agence ou arbitrer tes budgets en connaissance de cause.

L'objectif du tracking : relier une session à une source

L'enjeu du tracking au sens large, c'est de collecter le plus de données possible sur les gens qui passent sur ton site. Appliqué à l'acquisition, l'objectif devient plus précis : être capable de rattacher des sessions à des leviers, des campagnes et des annonces, pour ensuite lier ces sessions à de la performance et arbitrer tes budgets.

Il y a deux problèmes distincts, et il ne faut pas les confondre.

Le premier est facile : lier une session à une source de trafic. C'est le rôle des UTM. Le second est difficile : savoir quelle session, parmi toutes celles d'un même utilisateur, a réellement déclenché la vente. C'est le problème de l'attribution, et il mérite un article à lui tout seul.

Les UTM : une simple convention dans l'URL

Les UTM sont des paramètres que tu ajoutes dans tes URL de destination : utm_source, utm_medium, utm_campaign, etc. C'est une convention popularisée par Google, mais rien de magique : tu pourrais mettre n'importe quel paramètre, y compris tes propres ID internes.

Quand un internaute arrive sur ton site, un bout de code JavaScript présent dans ta page (le fameux "tracker") lit l'URL, décode ces paramètres, et envoie l'information à tes outils : ton analytics d'un côté, les régies publicitaires de l'autre. C'est comme ça que tu sais que telle session vient de telle campagne, de tel adset, de telle annonce.

L'UTM flague donc la source à l'arrivée. Mais pour suivre ce que fait la personne ensuite, page après page, il faut autre chose : un cookie.

Le cookie : un simple fichier texte avec un ID

Un cookie, concrètement, c'est un petit fichier texte déposé sur ton navigateur, qui contient essentiellement un identifiant. Rien de plus.

Pourquoi c'est indispensable ? Parce que le web est par nature "sans mémoire". Chaque fois que tu charges une page, ton navigateur appelle un serveur et lui demande du contenu. Sans identifiant, le serveur ne sait pas qui tu es : il te servirait une page générique à chaque fois. Impossible de rester loggé, impossible de conserver un panier d'une page à l'autre. Le cookie, c'est ce qui permet de dire au serveur : "charge-moi cette page pour cette personne".

Deux propriétés importantes à retenir :

Le cookie est lié au device et au navigateur. Tu as un ID sur ton ordinateur, un autre sur ton téléphone. Et sur mobile, les applications et le navigateur ne partagent pas leurs cookies : ce sont deux mondes séparés.

Chaque acteur pose son propre cookie. Sur un même site, tu peux avoir un cookie du site lui-même, un cookie Meta, un cookie Google. Ces cookies ne se parlent pas entre eux. Meta n'a pas besoin de savoir ce que Google sait : chacun gère son propre référentiel d'identifiants.

First party vs third party

La distinction clé, c'est qui pose le cookie.

Un cookie first party est posé par le site que tu visites, sur son propre domaine. C'est le cookie "technique" par excellence : session, login, panier. Sans lui, internet ne fonctionne pas. C'est d'ailleurs pour ça que ces cookies sont exemptés de consentement : même quand un utilisateur refuse les cookies dans la bannière, les cookies strictement techniques sont déposés, et c'est légal.

Un cookie third party est posé par un tiers (Meta, Google, un outil de chat) sur un site qui n'est pas le sien. C'est historiquement le carburant de la publicité personnalisée : c'est comme ça que Criteo a bâti son business, en reconnaissant le même internaute de site en site pour lui afficher du retargeting personnalisé.

Attention à ne pas confondre les deux axes : first/third party décrit qui pose le cookie, technique/publicitaire décrit à quoi il sert. Un cookie third party peut être technique (un widget de chat), et un cookie first party peut servir la publicité. Cette nuance est exactement ce qui a permis l'émergence du tracking server-side, on y reviendra.

Le pixel : un abus de langage

Quand on dit "le pixel Meta", on mélange en réalité plusieurs choses.

Côté plateforme, le "pixel" est en fait un dataset : un réceptacle d'événements dans le Business Manager. Côté site, le pixel est un script JavaScript qui a deux rôles distincts.

Premier rôle : poser et lire le cookie. C'est le pixel qui dépose l'identifiant Meta sur le navigateur du visiteur, puis qui le relit à chaque page pour confirmer que c'est toujours la même personne. Meta ne peut pas déposer un cookie tout seul sur un site : il faut que le site ait intégré le script.

Deuxième rôle : envoyer les événements. PageView, AddToCart, Purchase, avec leurs paramètres (valeur, devise, contenu). À chaque événement, le pixel joint l'ID du cookie pour que la plateforme sache à qui rattacher l'action.

Comment Meta te reconnaît sur plusieurs devices

Tu as un ID cookie différent sur ton téléphone et sur ton ordinateur. Pourtant Meta sait que c'est toi dans les deux cas. Comment ?

Tout simplement parce que tu es loggé. Dès que tu te connectes à ton compte Facebook ou Instagram sur un device, Meta associe l'identifiant technique de ce device à son identifiant interne, celui de ton profil. Deux cookies différents, un seul utilisateur. C'est l'immense avantage des plateformes "logged-in" : leur graphe d'identité est bien plus solide que n'importe quel cookie.

Ce qu'il faut retenir

Le tracking client-side classique, c'est donc : des UTM dans l'URL pour flaguer la source, un script JavaScript qui lit tout ça, des cookies pour maintenir l'identité de session en session, et des événements envoyés aux plateformes avec l'ID du cookie.

Ce modèle a très bien fonctionné pendant quinze ans. Puis Apple, le RGPD et les navigateurs sont passés par là, et tout s'est compliqué. C'est l'objet du prochain article : ITP, iOS 14, tracking server-side et Conversions API.