Le cookie _ga de GA4 : format GS2.x et impacts (2025)

Le changement silencieux de mai 2025

En mai 2025, Google a modifié le format du cookie _ga sans annonce officielle. L’ancien format GA1.x, utilise depuis les debuts de GA4, a été remplacé par un nouveau format GS2.x. Ce changement a cassé silencieusement des dizaines d’outils tiers, de scripts custom et de templates GTM qui parsaient le cookie _ga pour en extraire le client_id.

L’ancien format était simple et prévisible : GA1.2.1234567890.1678901234. Deux chiffres de version, suivis de deux composants numériques séparés par des points. Le client_id correspondait aux deux derniers segments.

Le nouveau format GS2 utilise une structure radicalement différente : des paramètres clé-valeur étiquetés avec des séparateurs $. Le cookie contient désormais des métadonnées supplémentaires sur le consentement, l’horodatage et le stream ID, le tout encodé dans une chaîne compacte.

Anatomie du nouveau cookie GS2

Le format GS2 encode plusieurs informations dans un seul cookie. On y trouve le client_id (toujours présent, mais dans un segment étiqueté), le timestamp de première visite, le timestamp de la session courante, le nombre de sessions, et des flags lies au consentement.

La logique de parsing change complètement. Au lieu de faire un simple split sur le point et prendre les deux derniers segments, il faut maintenant identifier les segments par leur étiquette, puis extraire la valeur associée. Le template GTM de Julius Selnekovič est actuellement la référence pour parser ce nouveau format dans un conteneur server-side.

L’impact pratique est significatif. Si vous avez des scripts custom qui lisent le cookie _ga pour faire du cross-domain maison, du Cookie Restore server-side, ou de la réconciliation CRM, ces scripts sont probablement casses depuis mai 2025. La solution est de migrer vers le nouveau parsing ou, mieux, de ne plus parser le cookie vous-même et de laisser la bibliothèque GA4 gérer l’extraction du client_id via l’API gtag get.

Safari ITP et la durée de vie des cookies

Le cookie _ga est un cookie first-party, ce qui signifie qu’il est défini sur votre propre domaine. Mais les navigateurs ne traitent pas tous les cookies first-party de la même manière.

Sur Chrome, le cookie _ga à une durée de vie maximale de 400 jours, renouvelée à chaque visite. Un utilisateur Chrome qui visite votre site une fois par mois conserve le même client_id indéfiniment.

Sur Safari, la situation est radicalement différente. Intelligent Tracking Prevention (ITP) limite les cookies first-party définis via JavaScript à 7 jours de durée de vie. Si un utilisateur Safari ne revient pas dans les 7 jours, son cookie _ga expire et il reçoit un nouveau client_id à sa prochaine visite. C’est comme si c’était un nouvel utilisateur. Pire : les cookies définis via document.cookie dans un contexte identifié comme tracking sont limités à 24 heures.

L’impact sur vos métriques est direct : le nombre d’utilisateurs uniques est surévalué, le taux de retour est sous-évalué, et l’attribution multi-session est tronquée pour tous les utilisateurs Safari. Étant donné que Safari représente entre 25 et 35% du trafic web en France (plus sur mobile), c’est un biais massif.

La parade technique consiste à définir le cookie via un header HTTP Set-Cookie côté serveur plutôt que via JavaScript. Les cookies serveur ne sont pas soumis à la limitation ITP de 7 jours. C’est exactement ce que permet le server-side tracking avec la fonctionnalité Cookie Restore, configurable lors d’un setup GA4 et GTM avance.

Consent Mode et les cookieless pings

Quand un utilisateur refuse le consentement cookies et que vous avez configuré le Consent Mode v2 en mode Advanced, GA4 ne depose aucun cookie. Pas de _ga, pas de _gid, rien. Mais GA4 envoie quand même des pings anonymisés aux serveurs de Google.

Ces cookieless pings contiennent des informations limitées : le timestamp, la page visitée, et des signaux agrégés (taille d’écran, langue). Google utilise ces pings pour alimenter ses modèles de machine learning et estimer les conversions manquantes. C’est ce qu’on appelle la modélisation comportementale.

Le point clé à retenir : en Consent Mode Advanced, vous n’avez aucun cookie, mais vous avez quand même des données modélisées dans GA4. La qualité de cette modélisation dépend directement du volume de trafic consenti que vous collectez. Plus votre taux de consentement est élevé, plus le modèle est fiable.

Le cookie _ga dans l’écosystème cross-domaine

Le cookie _ga est le seul cookie de GA4 qui participe au cross-domain tracking. Les autres cookies (_gid, _ga_STREAM) sont spécifiques à un data stream et ne sont pas transférés entre domaines. Quand un utilisateur passe d’un domaine à un autre avec le cross-domain configuré, c’est le client_id extrait du cookie _ga qui est transmis via le paramètre _gl dans l’URL.

Avec le changement de format GS2, cette mécanique reste identique dans son principe, mais le parsing du cookie _ga côté récepteur doit être compatible avec le nouveau format. Pour les implémentations standard via gtag.js ou GTM, Google gère cette compatibilité automatiquement. Pour les implémentations custom, la mise à jour est à votre charge. En cas de doute, consultez le glossaire first-party cookie pour les fondamentaux.