Avec l'avènement de Google Analytics 4 (GA4), les marketeurs doivent retourner sur les bancs de l’école 🎒.
GA4 est plein de surprises, certaines agréables d’autres un peu moins. L'un de ces défis majeurs est la catégorisation du trafic sous le terme "Unassigned".
Vous ouvrez les rapports d'acquisition de trafic dans Google Analytics 4 et là, vous vous trouvez abasourdi : vous voyez un mystérieux “Unassigned” venant s’attribuer 25% de votre trafic.
Qu'est-ce que c'est et comment s'en débarrasser ? Cet article a pour but de vous expliquer les différentes raisons de sa présence dans les rapports GA4. Certaines peuvent être corrigées, d'autres doivent être acceptées (à moins que Google corrige sooooon les problèmes associés).
Sommaire :
Nous avons été les premiers surpris, on était habitués au trafic “Other” dans Universal Analytics mais avec l’arrivée de GA4, nous avons identifié chez certains de nos clients, un nouveau canal d'acquisition : “Unassigned”.
Ce trafic, surtout quand il s’agit de plus de 30% de son trafic, devient très vite génant dans l’analyse de ses performances d’acquisition site centric. C’est là que le rôle de Sherlock Holmes prend tout son sens, il faut jouer l’enquêteur pour essayer de comprendre d’où provient ce trafic "Unassigned". 🔍
Les dimensions de la source de trafic fournissent des informations sur l'origine du trafic du site web ou de l'application. GA4 propose différentes dimensions pour l'analyser. Parmi les plus utilisées, nous pouvons parler de :
Pour plus de détails je vous invite à lire notre article sur l’attribution dans Google Analytics 4.
Beaucoup d’utilisateurs de GA4, au début de l’implémentation nous ont signalé une part significative de leur trafic regroupée sous le terme "Unassigned".
Pourquoi "Unassigned" et non "Other" ? Avec Universal Analytics (UA), le terme "Other" était utilisé comme la poubelle des sources d’acquisition ne correspondant pas aux règles de la solution ou pré-établies dans vos custom channel groupings.
GA4 a remplacé cela par le canal "Unassigned", pour autant au sein du trafic "Unassigned" dans GA4, on retrouve la défintion du "Other" dans UA mais également un point plus problématique sur un trafic remontant en “not set”.
Analysons ensemble ces différents points.
D’où provient ce trafic "Unassigned" dans Google Analytics 4 ?
Il faut avoir en tête la liste et les règles des différents canaux dans GA4. Je vous conseille de garder sous la main cette liste. Dans la mesure du possible, essayez d'utiliser des valeurs que GA4 reconnaît automatiquement. Pour cela, essayez d’avoir une matrice d’UTM bien claire et facilement activable par vos partenaires / agences ou responsables acquisition.
Vous pouvez également créer des groupes de canaux personnalisés dans GA4 qui peuvent reconnaître vos valeurs d'UTM personnalisées. Il existe certaines limites à ces custom channels groupings dans GA4 : vous n’avez pas la possibilité aujourd’hui de catégoriser votre trafic grâce à une custom dimension.
Le protocole de mesure (Measurement Protocol) est l'un des moyens annexes d'envoyer des données vers Google Analytics 4. Ça vous permet d’envoyer de la donnée offline qualifiée : par exemple vos conversions back-offce, vos données CRM etc. A noter cependant, que cet outil est principalement là pour enrichir les données que vous collectez déjà sur votre site web dans Google Analytics 4. Il ne permet pas de créer de nouvelles sessions.
Ainsi, si vous souhaitez mettre en place le Measurement Protocol, il faut que chaque événement envoyé via l’outil contienne les paramètres suivants : client_id et session_id. Si ça n’est pas le cas, GA4 ne sera pas en mesure d'envoyer l’événement avec la donnée déjà envoyée à l’outil. Ainsi, la source de trafic de ce nouvel événement ne sera pas définie.
Si vos développeurs envoient des données via MP à la session actuellement active sur votre site, chaque événement doit contenir les paramètres client_id, session_id et timestamp_micros (si la session a plus de 72h). Si le paramètre session_id n'est pas inclus (ou si le paramètre session_id ne correspond pas à l'ID de la session actuellement active), la source de trafic de cette session ne sera pas définie.
Il faut bien faire attention lors de la mise en place de son set-up GA4 dans Google Tag Manager. En effet, nous avons identifié que si une balise d'événement GA4 se déclenche avant la balise de configuration Google, cela peut augmenter le volume du trafic "Unassigned".
Ainsi, nous vous conseillons de configurer la balise Google pour qu'elle se déclenche le plus tôt possible dans les limites techniques rencontrées sur l’ensemble de vos pages. A noter qu’il faut également vraiment prendre ce point en compte lors de la mise en place de GTM server side.
En effet, c’est dans le tag de configuration que l’on définie notamment l’URL du serveur qui va recevoir l’ensemble des données. Si une balise événement se déclenche avant la balise Google, vous allez perdre les informations relatives à cet événement et donc, en conclusion, avoir un trafic “Unassigned” élevé dans vos rapports.
Certains outils t permettent d’envoyer la donnée vers Google Analytics 4. Comment ça se passe ? Ils utilisent tout simplement le protocole de mesure GA4 dont on a parlé un peu plus haut.
Or, ces outils sont dans l’incapacité d’envoyer l’identifiant de la session (session_id) et les autres paramètres évoqués. Ainsi, chez Smart Bees, nous vous incitons à passer par une autre solution lorsque vous utilisez ce type de connexion par défaut car sinon votre trafic “Unassigned” va exploser ! Aie ! Vous devez passer par une installation standard de GA4 : c’est à dire via GTAG ou Google Tag Manager.
Ça, c’est un des gros points noirs de Google Analytics 4 et pour les impatients comme moi ! GA4 met un certain temps à traiter les données (entre 24 et 48 heures). Par conséquent, si vous consultez vos rapports d’acquisition pour check vos données d'hier ou tout simplement d'aujourd'hui, il se peut que vous constatiez un pic de trafic non attribué.
C'est normal dans GA4, la solution chez Smart Bees : s’armer de patience ! D’ici quelque temps, ce trafic “Unassigned” n’existera plus…
Il s'agit là aussi d’un grand mystère de GA4. Lorsque je trouve des sessions qui ont des sources de trafic "Unassigned" et que je creuse davantage dans BigQuery, elles n'ont souvent pas l'événement session_start (qui est pourtant censé être envoyé automatiquement avec GA4).
Est-ce que c’est dû au point évoqué tout à l’heure sur notre tag de configuration Google qui se déclenche plus tard ? Peut-être, peut-être pas, nous échangeons avec les équipes Google sur ce KO.
Maintenant je vous propose de regarder un point spécifique, outre les sujets évoqués précédemment : Measurement protocol, des événements de session_start manquants etc. Il existe un cas particulier pouvant amener à une source de trafic en “not set”. Nous l’avons vu sur nos clients utilisant Google Consent Mode et la méthode de reporting identity "Blended". Si vous n'avez pas Google Consent Mode, vous pouvez passer directement à la partie 4 expliquant nos solutions.
Le consent mode ajoute un paramètre appelé Google Consent Storage (GCS) au hit de collecte. Ce paramètre indique quels types de cookies sont consentis. Les valeurs G100, G110, G101 et G111 décrivent respectivement les cookies essentiels, analytics et de retargeting.
Pour autant, on va le voir mais la remontée d’un simple hit ne garantit pas la remontée de toutes les informations nécessaires à la bonne lecture des données dans les rapports. En effet, si un utilisateur refuse le consentement, on se rend compte qu’il devient impossible de recueillir tous les paramètres du hit, y compris l'origine du trafic.
Pourtant, la problématique est plus importante que ça … car en principe, si un individu refuse de donner son consentement, ses données ne devraient pas être présentes dans Google Analytics. Sauf qu’avec Google Analytics 4, vous avez la possibilité de choisir une “identité de reporting”. L'option "Blended" propose de modéliser des données afin de reconstituer les sessions d'utilisateurs ayant rejeté les cookies. Selon la documentation de Google, ce modèle est construit à partir de sessions similaires. Toutefois, il semble qu'un certain nombre de sessions soient “artificiellement” générées à partir des hits non consentis !
Quand on a comparé les données de BigQuery avec celles de l'interface GA4, l'événement de page vue est équivalent entre les deux : c’est-à-dire qu’il correspond à la somme des hits de page vue des utilisateur ayant consentis et non consentis. Cependant, pour les utilisateurs n’ayant pas donné leurs consentements, ces pages vues ne peuvent être associées à des sessions réelles (collectées avec le consentement de l’utilisateur). GA va donc extrapoler des sessions mais pour lesquelles il n’aura pas certaines informations comme la source. Ainsi, ces sessions tombent dans le groupe de trafic “Unassigned”.
Vous l’avez compris, le choix du reporting identity "Blended" peut entraîner la création artificielle de sessions à partir des hits non consentis. Ces sessions, sans source d'acquisition, sont regroupées en "Unassigned".
L'alignement des paramètres UTM sur la nomenclature définie par défaut dans GA4 est essentiel pour éviter que le trafic ne soit regroupé en "Unassigned". Travailler sur une architecture propre des UTM peut entraîner l’augmentation de la part du trafic Unassigned dans les rapports.
L’utilisation et la création de custom channels groups permettant de personnaliser vos règles de groupement de canaux est une des solutions proposées par GA4 pour ranger correctement les UTMs égarés.
En étant sur de bien déclencher le tag de Configuration GA4, on évite l’envoi d’événements sans information d’acquisition.
En optant pour le “reporting identity” de type “Device-Based” plutôt que "Blended". Cela vous donne davantage les données brutes réelles des utilisateurs ayant consenti à leur collecte. De plus, ce changement étant rétroactif, vous avez la possibilité de modifier l'historique des données sans le perdre. Vous pouvez changer de reporting identity autant de fois que nécessaire !
La gestion efficace du trafic dans Google Analytics 4 est cruciale pour des analyses précises et des campagnes optimisées. En suivant les meilleures pratiques, en ajustant les paramètres de suivi et en comprenant les mécanismes internes, vous pouvez minimiser cette part du trafic "Unassigned" qui crée un si grand malaise aujourd’hui dans la lecture des données.
En appliquant les solutions évoquées et en faisant appel à Smart Bees, vous serez en mesure de tirer le meilleur parti de GA4 et d'optimiser vos campagnes digitales à partir des insights tirés de cet outil. Contactez-vous !
