4 solutions pour muscler vos cookies avec le server-side
Pour des cookies qui durent plus longtemps, tout simplement.
Ce que j’aborde dans cette édition :
Les bons et les mauvais cookies.
Les 4 façons d’allonger la durée de vie de vos cookies contre les restrictions des navigateurs.
Temps de lecture : 7 minutes.
Je suis Baptiste Moisan, expert Tracking et Analytics.
Et c’était (encore) un pont vendredi dernier : je vous livre donc cette édition avec une semaine de décalage. Je reprends le rythme normal en juin—au moins jusqu’aux vacances d’été.
N’hésitez pas à répondre à ce mail pour me faire vos retours : ils m’aident à écrire sur les sujets importants pour vous.
Bonne lecture !
Les cookies n’ont pas la cote.
Supprimés prématurément par les navigateurs ou carrément bloqués, ce n’est pas une chasse aux oeufs mais aux cookies qui se joue (il est un peu tard en juin pour ce mauvais jeu de mot).
Et malgré les promesses d’un monde cookieless qu’on n’a pas fini d’attendre, tous les experts en tracking vous le diront : l’annonceur en a encore besoin dans sa stratégie de mesure.
Que ce soit pour tracker ses résultats dans les plateformes publicitaires ou identifier un utilisateur dans un outil de web-analytics, le cookie reste un indispensable.
Même les solutions de mesure alternatives (le suivi avancé au premier chef) sont encore complémentaires.
Le choix de Google de conserver les cookies tiers dans Chrome le montre1 : tout un pan de l’industrie publicitaire en ligne repose encore sur ce petit fichier texte enregistré par le navigateur.
Et soigner ses cookies est indispensable pour l’annonceur : c’est ce qui va lui permettre de mesurer ses résultats plus précisément et de donner de meilleurs signaux aux plateformes publicitaires.
Le tracking server-side est là pour s’en occuper et les fortifier.
Dans cette édition, je vous présente 4 façons de faire durer vos cookies plus longtemps avec une infra de tracking server-side, de la plus simple à la plus complexe.
Le bon et le mauvais cookie
Avant de rentrer dans le vif du sujet, il faut faire la différence entre le bon et le mauvais cookie.
Je vous donne la distinction faite par Safari. Même si le navigateur n’est pas seul sur le marché, il a tendance à donner le tempo en terme de protection contre le tracking avec l’ITP2.
Pour Safari, le bon cookie est déposé par votre serveur en HTTP : c’est un cookie first-party, bien sous tous rapports. Ce cookie a souvent un rôle technique et peut être indispensable au bon fonctionnement du site.
Il n’est donc soumis à aucune restriction en terme de durée de vie.
Une boutique Shopify va par exemple déposer un cookie _shopify_y. C’est le bon cookie qui va vivre longtemps : 13 mois.
Le cookie moins sympa est déposé en JavaScript par un tag. Même s’il reste en first-party, Safari les aime moins : il leur impose une date d’expiration de 7 jours. C’est par exemple le cas du cookie _fbp, déposé par le tag Facebook.
Et les cookies vraiment méchants pour Safari sont ceux qui stockent des IDs de clics. Ils ne vivront que 24 heures dans le navigateur.
Quand on est annonceur, on a besoin que les cookies contenant l’ID de clic vivent longtemps. C’est grâce à eux qu’on attribuent des conversions et qu’on donne des signaux à la plateforme.
Et le tracking server-side vient à leur rescousse.
Posez vos cookies avec un serveur de tracking
On l’a vu : Safari n’aime pas les cookies déposés en JavaScript.
Des cookies jugés meilleurs, et qui auront le droit à une plus longue vie, sont ceux déposés par son propre serveur—en HTTP.
Et c’est exactement ce que peut faire un serveur de tracking.
Quand vous installez Google Ads en server-side, vous envoyez de la donnée vers votre serveur (ss.monserveur.com/g/collect/…) et ce dernier répond en demandant de déposer un nouveau cookie dans le navigateur de l’utilisateur : le cookie FPGCLAW.
Ce cookie (qui contient un ID de clic) est déposé en HTTP par votre propre domaine. C’est une première façon de passer sous les radars de l’ITP de Safari et de faire vivre un cookie plus longtemps.
Mais… c’était sans compter sur le CNAME cloacking defense3, mécanique intégrée depuis Safari 16.4.
Le navigateur compare l’adresse IP de votre serveur avec celle de votre serveur de tracking. Et si ces adresses sont trop différentes, Safari sévit. Une durée de vie de 7 jours est imposée au cookie, même déposé en HTTP par votre serveur de tracking.
7 jours, c’est mieux que 24 heures. Mais c’est toujours moins bien que 90 jours—la durée de vie “normale” d’un ID de clic. On peut s’en approcher en utilisant d’autres méthodes.
Restaurez vos cookies
Les fournisseurs de serveur de tracking, comme Stape et Addingwell, proposent une fonctionnalité qui permet de réécrire les cookies prématurément disparus.
La mécanique est simple : on associe un “master cookie” déposé par votre serveur, qui contient un identifiant unique (comme _shopify_y), à tous les cookies boudés par Safari. Cette combinaison est enregistrée bien au chaud, dans une base de données.
Quand l’utilisateur revient sur votre site, le master cookie est toujours là, grâce à sa longévité de 13 mois. Mais les cookies publicitaires ont pu être effacés. Votre serveur de tracking va les rétablir en retrouvant le master cookie dans sa base de données et tous les cookies publicitaires associés.
Dans les plateformes, c’est une option qui peut s’activer en un clic.
Mais ça nécessite d’avoir un master cookie sur lequel s’appuyer, lequel doit respecter deux conditions :
Il doit être déposé par votre serveur principal.
Il doit contenir un identifiant par utilisateur unique.
Cachez l’adresse de votre serveur de tracking
Et si on maquillait l’adresse du serveur de tracking pour empêcher Safari de repérer une trop grande différence avec le serveur principal ?
C’est ce que fait le reverse proxy : il permet à votre serveur de tracking d’adopter la même adresse que votre serveur principal. Résultat : vous passez sous les radars du CNAME cloacking.
Le reverse proxy peut être mis en place relativement facilement. Mais à deux conditions près :
Votre serveur de tracking est hébergé sur la Google Cloud Platform ou Addingwell.
Vous utilisez le réseau Cloudflare.
Si vous cochez ces cases, l’activation peut se faire en quelques clics pour la GCP et Addingwell.
Montez une “mini-CDP”
Cette dernière solution est la plus avancée.
Monter une mini-CDP juste pour restaurer les cookies s’avèrera trop complexe : mieux vaut s’appuyer sur les fonctionnalités de cookie restore ou de reverse proxy.
La mini-CDP va plus loin en unifiant toute la donnée associée à un utilisateur : ID, cookie first-party, cookies publicitaires, adresse email, commandes, LTV, etc.
Et toutes ces données peuvent être activées dans les plateformes publicitaires pour améliorer la mesure et enrichir les signaux.
Techniquement, cette mini-CDP peut être hébergée dans Firestore : la base de données noSQL de la Google Cloud Platform.
Elle s’interface nativement avec sGTM qui propose des variables built-in pour retrouver de la donnée dans une base de données Firestore :
Et une fois cette donnée retrouvée, elle peut être envoyée aux plateformes.
L’alternative à Firestore : Stape Store, qui fonctionne exactement de la même manière, avec ses propres variables sGTM.
Loin de pouvoir se séparer des cookies immédiatement, le tracking server-side offre plusieurs solutions pour allonger leur durée de vie face aux restrictions des navigateurs.
La plus simple consistera à “juste” poser le cookie avec votre serveur et la plus avancée à monter une mini-CDP pour unifier toute la donnée de vos utilisateurs—y compris leurs cookies publicitaires.
On partage ?
Si cette newsletter peut intéresser un partenaire, un collègue ou un ami passionné de tracking (oui, ces personnes existent), n’hésitez pas à lui transférer ce mail !
Si vous avez des questions, des remarques, des retours, vous pouvez directement me répondre ou commenter sur Substack : je me ferais un plaisir de vous lire.
Bon week-end ✌️
Baptiste
Next steps for Privacy Sandbox and tracking protections in Chrome. The Privacy Sandbox. https://privacysandbox.com/news/privacy-sandbox-next-steps/
Tracking Prevention in WebKit. WebKit. https://webkit.org/tracking-prevention/#intelligent-tracking-prevention-itp
CNAME Cloaking and Bounce Tracking Defense. WebKit. https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/