Le problème : de nombreuses propriétés GA4 ont une part importante du trafic qui est associé à une source (channel grouping) “Unassigned”
Avec l’arrivée de GA4, nous avons remarqué chez plusieurs clients, un nouveau channel grouping : “Unassigned”. Ce traffic, dont on arrive à récupérer que très peu d’informations, deviens très vite gênant lorsqu’il représente la première ou seconde source d’acquisition.
Je vous détaille ici comment nous avons réussi à résoudre le problème pour nos cas clients. Mais, il peut y avoir aussi d’autres origines à ce traffic Unassigned que je listerai à la fin de l’article.
“Unassigned” ou “(Other)*” ?
*Correspond aux canaux ”(non disponible)” ou “(autre)” dans la version française
“(Other)” était un peu le canal fourre-tout d’UA. Toutes les campagnes dont les paramètres UTMs ne correspondaient pas aux règles par défaut ou préalablement définies étaient catégorisées dans “autre”.
Vous avez dû remarquer déjà que le groupe “(Other)” a disparu dans GA4; il a été remplacé par ce fameux groupe “Unassigned”.
Mais en réalité, ce “channel” regroupe 2 notions :
1- Les sources / médium qui ne sont pas associés à un “channel”, qui se résout assez simplement.
2- La source “(not set)”, qui est beaucoup plus problématique
Concernant le premier point, pour éviter d’avoir du traffic qui se retrouve dans unassigned, il n’y a pas de secret… Vous pouvez :
- Améliorer la gouvernance de vos campagnes médias et en particulier de vos paramètres UTMs pour avoir un alignement sur la nomenclature définie par défaut dans GA4
- Ajuster les règles de channel grouping personnalisés pour ranger les UTMs égarés
Pour identifier l’origine de ce trafic mal assigné, il suffit d’aller dans le report “Traffic Acquisition” puis, dans le tableau indiquant les données par canal d’acquisition, d’ajouter en dimension secondaire les sources / medium.
Mais passons alors au second sujet : le trafic de source “(not set)”
Désertion des sources d’acquisition
En cherchant à identifier l’origine du trafic Unassigned, vous avez peut-être remarqué la ligne suivante:
Le channel grouping est “Unassigned”, et la valeur de “source/medium” est (not set)
Il s’agit de la valeur par défaut lorsque la valeur de cette dimension est vide, un équivalent du null, en soit. Ce n’est pas du trafic direct, mais du trafic dont on a “perdu” l’origine.
Il s’avère que nos clients où ce phénomène est visible ont pour beaucoup le même point commun :
- consent mode pour gérer le consentement des utilisateurs
- la méthode du reporting identity choisie est “Blended”
Coïncidence vous dîtes ? Pour vous répondre, j’ai repris le cheminement des hits, depuis la console pour vous présenter consent mode, dans BigQuery pour voir la donnée brute (la source de vérité GA4 et si cet article vous suffit pas, lisez celui d’Aristide Riou), et enfin dans l’interface GA4 pour voir une belle conséquence de reporting identity en blended.
La première chose à savoir est que, peu importe si vous avez accepté ou refusé les cookies, un tag GA4 qui utilise consent mode se déclenchera. Pour différencier les hits consentis et non consentis, un paramètre est ajouté: Google Consent Storage (GCS). Il contient 4 caractères: G pour Google, puis 3 chiffres. Dans l’ordre: les cookies essentiels, les cookies analytics et les cookies de retargeting. Chacun a la valeur 1 lorsque consentis et 0 lorsque refusés.
- G100: Seuls les cookie essentiels sont déposés
- G110: Seuls les cookies essentiels et analytics sont déposés
- G101: Seuls les cookies essentiels et marketing sont déposés
- G111: Tous les cookies sont déposés
Vous pouvez voir cela directement au niveau du hit de collecte envoyé dans le network.
Cette information est stockée dans la dimension “analytics_storage” que vous pouvez retrouver dans BigQuery avec la fonction suivante:
- “No” ou “Denied”, le consentement n’a pas été donné pour ce hit
- “Yes” ou “Granted” le consentement a été accordé
Néanmoins, ce n’est pas parce que le hit est collecté que toutes les informations remontent. Si un utilisateur a refusé le consentement alors, il ne sera pas possible de collecter tous les paramètres du hit… ni l’origine du trafic !
Pour voir cela dans BigQuery, il suffit de chercher les dimensions de source ou de medium pour le trafic non consenti d’un côté (
”analytics_storage” LIKE ‘No’) et le trafic consenti de l’autre (”analytics_storage” LIKE ‘Yes’). On voit bien ci-dessous que les sources de trafic sont vides ou “null”.
Mais pourquoi cela serait un problème ? Si la personne n’a pas donné son consentement, ses données ne devraient pas apparaître dans Google Analytics n’est-ce pas ?
Oui, sauf.. dans un cas précis. Lorsque vous avez paramétré votre compte Google Analytics 4, vous avez dû choisir votre méthode d’identification des utilisateurs: Reporting Identity.
L’une des options, “Blended”, vous propose de modéliser des données pour reconstituer les sessions des utilisateurs ayant refusé les cookies. Dans sa doc, Google précise que ce modeling est fait à partir de sessions similaires. Il semblerait tout de même qu’un certain nombre de sessions soient crées artificiellement à partir des hits non consentis, lesquels n’ont pas de source d’acquisition..
Vous commencez peut-être à voir où je vous emmène; comparons BigQuery et l’interface GA4. Sur une même journée, si l’on regarde au niveau de l’évènement de page vue, le total affiché dans l’interface de GA4 correspond dans BigQuery à la somme des hits de page vues consenties et non consenties:
Ces pages vues ne peuvent être associées à des sessions réelles (collectées grâce au consentement de l’utilisateur). GA va donc générer des sessions artificielles mais pour lesquelles il n’aura pas certaines informations comme la source. Ainsi, ces sessions tombent dans le groupe de trafic Unassigned.
On sait donc d’où ce trafic vient, maintenant, que faire avec ?
La solution ici est assez simple: passer en reporting identity de type Device based. Ainsi, vous avez les véritables données brutes, d’utilisateurs ayant consenti à leur collecte. Lâchez prise, acceptez qu’une partie des utilisateurs naviguant sur votre site ne veut pas partager avec vous leurs données, et ne faites pas aveuglément confiance à un algorithme qui est une véritable boite noire. Notez que :
- ce changement est rétroactif, vous ne verrez donc pas la courbe se crasher d’un seul coup mais tout votre historique de données sera modifié.
- vous pouvez changer de reporting identity autant de fois que vous le souhaitez (à priori)
D’autres origines à votre trafic Unassigned / (not set)
Nous avons ici traité le cas que nous avons rencontré le plus souvent. Il existe malgré tout d’autres situations qui peuvent générer du traffic “Unassigned / (not set)”.
Parmi celles-ci, notons les cas suivants :
- Utilisation du “measurement protocol”
Le “measurement protocol” est en réalité l’API de collecte de GA4 à laquelle on envoie directement de la donnée depuis des hits serveur. Afin que ces hits puissent être associés à des sources de trafic, ils doivent d’abord être associés à un ID de session qui a été créé côté client dans GA4… et c’est souvent là que l’implémentation est mal exécutée.
On retrouve pas exemple souvent ce cas dans l’implémentation de GA4 avec Segment.
Voici également un article qui creuse ce sujet :
[Solved] How to remove not set in Google Analytics 4?
Learn what not set in Google Analytics 4 is, what causes it and how to fix it (if the situation allows us to do that).
https://www.analyticsmania.com/post/not-set-in-google-analytics-4/#measurement-protocol
![[Solved] How to remove not set in Google Analytics 4?](https://www.analyticsmania.com/wp-content/uploads/2023/05/cover-picture-12.jpg)
- Evénements de session_start manquant
Il peut également se produire que des implémentations mal maîtrisées créent des sessions pour lesquelles il n’existe pas d’event de “session_start”. Cette situation est décrite succinctement dans cet article :
[GA4] What the value (not set) means in your reports - Analytics Help
Learn the most common reasons why (not set) values appear in GA4 reports and how to prevent those issues(not set) is a placeholder name that Analytics uses when it hasn't received any information for
https://support.google.com/analytics/answer/13504892?hl=en#zippy=,in-this-article
et dans mon article de la même série Focus GA4 :
Tout savoir sur l’attribution dans GA4N’hésitez pas à me contacter si vous avez un cas d’étude différent de celui que je vous ai détaillé. Je me ferai un plaisir de relever le défi !
Les requêtes de cet article
L’auteur : Lucie Lafarge
Consultante tracking & analytics chez UnNest, je travaille sur les sujets liés à la collecte et l’analyse de vos données de navigation.
Après 3 années au sein d’une agence dédiée à l'équipe data & analytics de Royal Canin, j’ai pu aiguiser mon sens de l'analyse pour transformer la donnée en actions concrètes.
✉️ Me contacter : lucie.lafarge@unnest.co
