Le cookie _ga de GA4 : tout comprendre (et le changement de mai 2025)

Le changement silencieux de mai 2025

En mai 2025, Google a modifie le format du cookie _ga sans annonce officielle. L’ancien format GA1.x, utilise depuis les debuts de GA4, a ete remplace par un nouveau format GS2.x. Ce changement a casse 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 etait simple et previsible : GA1.2.1234567890.1678901234. Deux chiffres de version, suivis de deux composants numeriques separes par des points. Le client_id correspondait aux deux derniers segments.

Le nouveau format GS2 utilise une structure radicalement differente : des parametres cle-valeur etiquetes avec des separateurs $. Le cookie contient desormais des metadonnees supplementaires sur le consentement, l’horodatage et le stream ID, le tout encode dans une chaine compacte.

Anatomie du nouveau cookie GS2

Le format GS2 encode plusieurs informations dans un seul cookie. On y trouve le client_id (toujours present, mais dans un segment etiquete), le timestamp de premiere visite, le timestamp de la session courante, le nombre de sessions, et des flags lies au consentement.

La logique de parsing change completement. Au lieu de faire un simple split sur le point et prendre les deux derniers segments, il faut maintenant identifier les segments par leur etiquette, puis extraire la valeur associee. Le template GTM de Julius Selnekovič est actuellement la reference 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 reconciliation 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-meme et de laisser la bibliotheque GA4 gerer l’extraction du client_id via l’API gtag get.

Safari ITP et la duree de vie des cookies

Le cookie _ga est un cookie first-party, ce qui signifie qu’il est defini sur votre propre domaine. Mais les navigateurs ne traitent pas tous les cookies first-party de la meme maniere.

Sur Chrome, le cookie _ga a une duree de vie maximale de 400 jours, renouvelee a chaque visite. Un utilisateur Chrome qui visite votre site une fois par mois conserve le meme client_id indefiniment.

Sur Safari, la situation est radicalement differente. Intelligent Tracking Prevention (ITP) limite les cookies first-party definis via JavaScript a 7 jours de duree de vie. Si un utilisateur Safari ne revient pas dans les 7 jours, son cookie _ga expire et il recoit un nouveau client_id a sa prochaine visite. C’est comme si c’etait un nouvel utilisateur. Pire : les cookies definis via document.cookie dans un contexte identifie comme tracking sont limites a 24 heures.

L’impact sur vos metriques est direct : le nombre d’utilisateurs uniques est surevalue, le taux de retour est sous-evalue, et l’attribution multi-session est tronquee pour tous les utilisateurs Safari. Etant donne que Safari represente entre 25 et 35% du trafic web en France (plus sur mobile), c’est un biais massif.

La parade technique consiste a definir le cookie via un header HTTP Set-Cookie cote serveur plutot que via JavaScript. Les cookies serveur ne sont pas soumis a la limitation ITP de 7 jours. C’est exactement ce que permet le server-side tracking avec la fonctionnalite 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 configure le Consent Mode v2 en mode Advanced, GA4 ne depose aucun cookie. Pas de _ga, pas de _gid, rien. Mais GA4 envoie quand meme des pings anonymises aux serveurs de Google.

Ces cookieless pings contiennent des informations limitees : le timestamp, la page visitee, et des signaux agrenes (taille d’ecran, langue). Google utilise ces pings pour alimenter ses modeles de machine learning et estimer les conversions manquantes. C’est ce qu’on appelle la modelisation comportementale.

Le point cle a retenir : en Consent Mode Advanced, vous n’avez aucun cookie, mais vous avez quand meme des donnees modelisees dans GA4. La qualite de cette modelisation depend directement du volume de trafic consenti que vous collectez. Plus votre taux de consentement est eleve, plus le modele est fiable.

Le cookie _ga dans l’ecosysteme cross-domaine

Le cookie _ga est le seul cookie de GA4 qui participe au cross-domain tracking. Les autres cookies (_gid, _ga_STREAM) sont specifiques a un data stream et ne sont pas transferes entre domaines. Quand un utilisateur passe d’un domaine a un autre avec le cross-domain configure, c’est le client_id extrait du cookie _ga qui est transmis via le parametre _gl dans l’URL.

Avec le changement de format GS2, cette mecanique reste identique dans son principe, mais le parsing du cookie _ga cote recepteur doit etre compatible avec le nouveau format. Pour les implementations standard via gtag.js ou GTM, Google gere cette compatibilite automatiquement. Pour les implementations custom, la mise a jour est a votre charge. En cas de doute, consultez le glossaire first-party cookie pour les fondamentaux.