Pourquoi votre trafic GA4 apparaît en Unassigned après l'ajout d'une bannière de cookies

Tous les articles

Unassigned n'est pas du trafic manquant. C'est du trafic que GA4 a bien reçu et qu'il n'a pas pu rattacher à un canal. Après la mise en ligne d'une bannière, vous l'obtenez en général pour l'une de ces trois raisons : le consentement arrive en cours de visite et la source d'origine a déjà disparu, la session n'a jamais enregistré de session_start, ou une configuration côté serveur remet une identité sur des pings censés rester anonymes.

Unassigned veut dire collecté, pas perdu

Un visiteur qui ne consent jamais, sur un site qui conditionne correctement ses balises, ne produit aucun événement. Cela se voit à un total de sessions plus bas, pas à une ligne dans la catégorie Unassigned. Unassigned apparaît quand GA4 détient bien des événements pour une session et ne peut les faire correspondre à aucune définition de canal : pas de paramètres de campagne, pas de référent exploitable, ou pas de session start sur lequel accrocher une source.

Le discours rassurant des pages d'aide de la plupart des fournisseurs de consentement, selon lequel Unassigned prouve que la bannière fait son travail, vaut pour le premier cas de figure ci-dessous et pas pour les deux autres. Dans ceux-là, quelque chose est collecté sous une forme que GA4 ne peut pas exploiter, et cela mérite d'être corrigé plutôt qu'accepté.

Cas de figure un : le consentement arrive en cours de visite

Quelqu'un arrive depuis une annonce ou un résultat de recherche, la bannière s'affiche, et analytics_storage reste refusé pendant qu'il lit. Rien de ce qui pourrait porter la source n'est stocké nulle part. À la troisième page, il accepte. GA4 se met alors à collecter correctement, mais la page sur laquelle il démarre est une page interne : le référent est votre propre domaine et les paramètres de campagne sont deux navigations plus tôt. Les règles de canaux n'ont rien à lire, la session atterrit donc dans Unassigned.

Ce cas de figure est réel et en partie inévitable. C'est aussi celui que vous pouvez réduire. Avec URL passthrough activé, les identifiants de clic publicitaire de Google voyagent dans la query string d'une page à l'autre pendant que les cookies sont refusés, de sorte qu'un visiteur qui accepte tardivement arrive quand même avec quelque chose d'attribuable. Savoir si cette option vous est seulement accessible dépend de quel Consent Mode votre site utilise réellement.

Cas de figure deux : la session n'a jamais enregistré son début

L'attribution de canal dépend du premier événement d'une session. Si la balise de configuration et les balises d'événement sont conditionnées différemment, ou si l'état de consentement par défaut est défini après le déclenchement de la balise Google, vous vous retrouvez avec des sessions dont le premier événement collecté est tout autre chose : un envoi de formulaire, un défilement, un achat.

Le signe qui ne trompe pas, ce sont des sessions Unassigned qui contiennent des conversions. De l'activité réelle, sans origine. C'est un défaut de câblage plutôt qu'un effet de la confidentialité, et cela appartient à la même famille que les chutes soudaines dont nous avons parlé dans pourquoi vos conversions GA4 ont chuté du jour au lendemain.

Cas de figure trois : les pings refusés reçoivent une identité

C'est celui dont personne n'écrit, et c'est le plus rapide à inonder une propriété. Dans une configuration Google Tag Manager côté serveur, le client GA4 peut gérer ses propres cookies. Laissé sur le réglage géré par le serveur (Server Managed), le conteneur écrit un identifiant propriétaire et l'appose sur les requêtes entrantes, y compris les pings sans cookie envoyés précisément parce que le consentement avait été refusé.

Ces pings arrivent désormais avec un identifiant stable. Au lieu d'alimenter la modélisation que le trafic refusé est censé nourrir, ils sont comptés comme des sessions. Ils ne portent aucune donnée de campagne, puisque rien n'avait le droit d'en stocker, et ils atterrissent donc tous dans Unassigned. Leur part suit votre taux de refus, et elle apparaît quelques jours après la mise en ligne de la bannière — c'est exactement pour cela que la bannière prend le blâme.

Nous l'avons trouvé sur une refonte du consentement en production, après des semaines de croissance inexpliquée de la catégorie Unassigned du client. Le correctif tenait en un réglage : basculer la gestion des cookies du client GA4 sur JavaScript Managed, pour qu'un ping refusé reste anonyme de bout en bout. C'est aussi la raison pour laquelle passer au serveur ne vous permet pas de retirer la bannière, ce que nous détaillons dans faut-il encore une bannière de cookies avec le marquage côté serveur.

Comment savoir lequel vous avez

1. Comparez la forme, pas le total

   Regardez si Unassigned a augmenté, ou si vos totaux ont simplement baissé pendant que le mix de canaux restait stable. Un nombre plus petit avec le même mix, c'est le consentement qui fonctionne comme prévu. Une catégorie nouvelle, qui n'était pas là le mois dernier, est une question de câblage.

2. Cherchez des conversions dans Unassigned

   Construisez une exploration sur la source et le support de session et placez vos événements clés à côté. Une acceptation tardive produit des sessions silencieuses ; des conversions entières sans origine pointent plutôt vers les cas de figure deux et trois.

3. Lisez l'état de consentement sur un hit réel

   Refusez tout, ouvrez le panneau réseau et trouvez la requête vers le point de collecte. Le paramètre gcs nomme l'état, et G100 signifie que les deux types de stockage sont refusés. Vérifiez ensuite si cette même requête porte un identifiant client. Un ping refusé avec un id attaché, c'est le cas de figure trois.

4. Ouvrez le client GA4 de votre conteneur serveur

   Si vous faites du marquage côté serveur, regardez le réglage de gestion des cookies du client. Server Managed signifie que le conteneur fabrique ses propres identifiants, quel que soit l'état de consentement à l'entrée.

5. Vérifiez quand se déclenche l'état par défaut

   L'état par défaut doit être défini avant l'exécution de la balise Google, sur chaque page, y compris la première de la visite. Plus tard que cela, et le premier hit de la session part dans un état que personne n'a choisi.

Ce que vous pouvez réellement récupérer

Une partie de tout cela est le prix honnête du consentement et ne disparaîtra pas. Sur les implémentations clients d'Amplio Data, nous observons généralement environ 34% des sessions derrière la bannière, et 20 à 40% des conversions perdues récupérables une fois Consent Mode v2 et le marquage côté serveur correctement câblés. Ces chiffres sont des fourchettes mesurées sur les implémentations clients d'Amplio Data, pas une garantie. La récupération dépend de votre mix de trafic, de vos régions et de la configuration de vos balises.

Une chose mérite d'être dite clairement, parce que les pages des fournisseurs laissent entendre le contraire : la modélisation ne vide pas la catégorie Unassigned. Elle comble des trous dans les rapports standards pour du trafic que vous n'avez jamais collecté. Elle ne remet pas une source sur une session arrivée sans source. Si vous voulez la vue d'ensemble de ce qui survit à un refus, nous l'avons traitée dans ce que devient votre donnée GA4 quand les utilisateurs refusent les cookies.

La version courte

Unassigned après une bannière, ce sont trois problèmes différents sous une même étiquette. Le premier est le coût réel d'une acceptation tardive et se réduit avec URL passthrough. Le deuxième est un défaut d'ordre des balises et se repère aux conversions sans origine. Le troisième est un réglage côté serveur qui défait discrètement le refus qu'il était censé respecter. Vérifiez le câblage avant d'accepter le discours rassurant.

Velo envoie le signal de consentement dans la forme que Google attend et vous montre ce que chaque état transmet réellement, de sorte qu'un défaut comme le troisième est visible dès le premier jour plutôt qu'après un mois d'Unassigned. Le mécanisme est détaillé sur la page produit.

Si votre problème d'Unassigned n'a pas la forme du consentement, l'équipe derrière Velo maintient la liste complète des causes, marquage des liens et règles de canaux compris, dans pourquoi le trafic GA4 apparaît en Unassigned sur le blog d'Amplio Data.