Le trafic non attribué dans GA4 peut être un problème déroutant pour de nombreux propriétaires de sites Web et spécialistes du marketing. Il est essentiel de comprendre pourquoi ce problème survient et comment y remédier pour une analyse précise des données.
Dans cet article, nous allons explorer les causes du trafic non attribué et non défini et proposer des solutions pratiques. À la fin, vous saurez comment vous assurer que vos données de trafic sont correctement attribuées.
«Trafic non attribué» fait référence aux sessions et aux événements qui ne peuvent être attribués à aucun groupe de canaux par défaut dans Google Analytics 4.
En soi, cela ne constitue pas un gros problème, contrairement aux indicateurs «non définis» dans la source / le support. Par conséquent, nous traiterons ci-dessous séparément les problèmes «non attribué» et «non défini».
GA4 détermine la source de trafic particulière du trafic de session avec 2 paramètres : tout d’abord, la présence de paramètres UTM dans l’URL au début de la session utilisateur. Si ces éléments sont absents, le référent est vérifié pour déterminer la source du trafic vers votre site. Si le référent est également vide, le trafic est alors classé comme direct.
Lorsque des paramètres UTM sont présents, Google Analytics 4 utilise utm_source et utm_medium pour déterminer à quel groupe de canaux attribuer la source de trafic. Si vous n’avez pas de groupes de canaux personnalisés dans GA4, les groupes de canaux par défaut sont utilisés. Vous trouverez la liste officielle des règles pour les valeurs dans utm_source et utm_medium pour déterminer leurs groupes respectifs ici: https://support.google.com/analytics/answer/9756891?hl=en.
Par exemple, si vous utilisez utm_source=facebook&utm_medium=paid dans les publicités Facebook, cette source sera automatiquement classée comme « Réseaux sociaux payants » selon les règles standard.
Cependant, si vous utilisez quelque chose de personnalisé, tel que utm_source=stape&utm_medium=sst, ces valeurs ne correspondent à aucune règle standard. Donc cette session tombera dans la catégorie «Non attribué».
1. Assurez-vous que le problème est bien lié à des valeurs non standard dans les paramètres UTM.
Pour ce faire, vous pouvez basculer votre rapport d’acquisition de trafic sur source/support de session ou l’ajouter comme colonne supplémentaire.
2. Vérifiez que votre source/support ne comporte pas un grand nombre de valeurs (non définies). Si tout est en ordre, vous pouvez voir quelles sources et quels supports réels sont utilisés.
3. Accédez à Google Analytics 4 → Admin → Groupe de canaux. Ajoutez votre nouveau groupe de canaux personnalisé qui prendra en compte et distribuera correctement vos paramètres UTM dans les groupes nécessaires.
Nous vous recommandons de ne pas le créer à partir de zéro (cela prendra beaucoup plus de temps), mais de copier le groupe de canaux par défaut, de le renommer et d’ajouter les règles de distribution source nécessaires.
Si vous voyez de nombreuses valeurs (non définies)» dans la source/le support, cela signifie qu’il y a un problème avec votre configuration de suivi GA4:
Il s’agit de la raison la plus fréquente pour la plupart des utilisateurs. Ce problème devient souvent perceptible après le passage au suivi côté serveur, même si vous ne l’aviez peut-être pas remarqué auparavant.
Symptôme: Certains événements GA4 sont envoyés à votre conteneur GTM côté serveur, tandis que d’autres sont envoyés directement à google-analytics.com.
Causes: Dans Google Tag Manager, vous initialisez gtag avec le paramètre server_container_url. Toutefois, ce paramètre est écrasé par une autre initialisation effectuée dans le code du site ou via un plugin / une intégration. Étant donné que le suivi côté serveur et le suivi Web dans Google Analytics 4 utilisent des cookies différents pour déterminer l’identifiant client (le cookie «_ga» est utilisé pour les événements Web, le FPID est utilisé pour les événements serveur), les événements envoyés par le même utilisateur via le Web et le serveur seront considérés par GA4 comme des événements provenant d’utilisateurs différents, dont l’un n’avait pas d’événement session_start pour déterminer la source de la session, ce qui fait qu’une telle session est non définie.
Comment vérifier cela:
Ouvrez l’outil de développement réseau dans votre navigateur, activez l’option «conserver le journal» pour ne perdre aucun événement lors du basculement entre les pages. Dans le filtre, pour plus de commodité, spécifiez l’identifiant de mesure de votre GA4 pour faciliter la recherche des requêtes nécessaires.
Voici un exemple d’événement qui fonctionne correctement et qui est envoyé à l’URL du conteneur du serveur:
Et voici un événement qui est envoyé directement à GA suite à des problèmes de configuration:
Vérifiez que tous vos événements GA4 sont envoyés à l’URL de votre conteneur de serveur et non à google-analytics.com.
Comment résoudre ce problème:
Si vous trouvez des scripts gtag dans le code de votre site, supprimez-les en totalité.
Idéalement, utilisez une seule balise Google avec GA4 configuré via votre conteneur GTM.
Cela est dû soit au fait que certains événements de la couche de données se déclenchent trop tôt, soit souvent à une configuration incorrecte de l’opération de la balise par rapport au consentement.
Les symptômes et les vérifications sont exactement les mêmes que dans le premier point : certains événements sont envoyés directement à google-analytics.com.
Vérifiez ceci dans le mode aperçu de votre conteneur Web GTM. Vous pouvez souvent voir une situation comme dans l’exemple ci-dessous:
Dans cet exemple, la balise Google avec la configuration GA4 utilise un déclencheur de mise à jour du consentement pour fonctionner lorsque le statut du consentement est déjà connu. Cet événement apparaît assez tard dans la page.
Mais avant cela, il y a un autre événement dans la couche de données (view_item dans l’exemple ci-dessus) sur lequel la balise d’événement est déclenchée. Étant donné qu’au moment du déclenchement de l’événement, il n’existe aucun paramètre de configuration permettant d’envoyer des données à l’URL du conteneur du serveur, cet événement sera envoyé directement à Analytics, ce qui entraînera des problèmes pour déterminer la source des sessions pour un tel événement.
Si vous rencontrez des situations similaires, assurez-vous que vos balises d’événement Google Analytics 4 sont toujours déclenchées après la balise Google.
L’utilisation d’un groupe de déclencheurs peut souvent contribuer à la résolution de ce problème. Par exemple, pour résoudre un problème comme ci-dessus, vous pouvez utiliser un groupe de déclencheurs qui inclut view_item et cookie_consent_update. Cela garantira que l’événement view_item GA4 est toujours déclenché après la configuration.
Si vous utilisez le protocole de mesure pour envoyer certains événements, assurez-vous que client_id et session_id sont utilisés avec le format et les cookies corrects. De cette façon, les événements envoyés via le protocole de mesure seront associés à la session de l’utilisateur et ils auront la source adéquate.
Souvent, ce point est négligé lors du passage au côté serveur GA4 et lorsque vous continuez d’utiliser le cookie _ga dans les événements du protocole de mesure.
Le cookie «FPID» est utilisé pour le suivi côté serveur afin de déterminer l’identifiant client. Utilisez la valeur sans sa première partie.
Exemple de cookie d’identifiant utilisateur FPID:
FPID2.4.dPX9iPhlXAv0WNrJhUjaaNZ5L6jyyqqDV80n24P%2BV04%3D.1716821491
Format pour l’utilisation MP:
dPX9iPhlXAv0WNrJhUjaaNZ5L6jyyqqDV80n24P%2BV04%3D.1716821491
Le cookie _ga_yourMeasurementId est utilisé pour déterminer session_id. Utilisez uniquement la partie après le deuxième point.
Exemple de cookie de session:
GS1.1.1717673857.4.1.1717674043.0.0.803799365
Format pour l’utilisation MP:
1717673857
Assurez-vous également que vous utilisez le décodage/encodage correct de la valeur du cookie.
En général, le moyen le plus simple de vérifier cela est de consulter les rapports GA4 Explore sur les valeurs des cookies pour les événements Web et les événements du serveur afin de s’assurer que tout est correct.
En cas de problèmes inexpliqués, une journalisation supplémentaire des données dans une base de données tierce et leur vérification dans celle-ci peuvent toujours être utiles.
La compréhension et la configuration correcte de GA4 pour le suivi et la catégorisation avec précision de vos sources de trafic est essentiel pour une analyse digitale efficace. En vous assurant que vos paramètres UTM sont correctement définis et en évitant les pièges des valeurs (non définies) dans vos rapports source / support, vous pourrez avoir une idée plus claire de la provenance de votre trafic dans Google Analytics et de son comportement sur votre site.
En abordant des problèmes tels que l’initialisation supplémentaire de gtag, la synchronisation des balises d’événement et l’utilisation appropriée des identifiants de session et client, vous pouvez améliorer la précision de vos données d’analyse. Cela vous permettra de prendre de meilleures décisions et d’élaborer des stratégies marketing plus efficaces. Prendre le temps de configurer correctement votre GA4 vous permettra de tirer le meilleur parti de vos analyses, ce qui vous permettra d’obtenir de meilleurs résultats pour votre business.
Nous espérons que cet article sera utile à ceux qui rencontrent des problèmes de trafic GA4 non attribué. En comprenant ses causes et en appliquant les correctifs suggérés, vous pouvez améliorer la précision de vos données et obtenir de meilleures informations sur les performances de votre site Web.
Il est toutefois important de garder à l’esprit que le problème peut parfois se résoudre de lui-même au fil du temps, à mesure que les processus de collecte de données se normalisent. La patience peut souvent s’avérer tout aussi efficace qu’une action immédiate. Nous vous remercions pour votre intérêt et nous vous souhaitons beaucoup de succès dans la gestion de votre trafic dans Google Analytics.
Nous en sommes ravis ! Cliquez sur Essai gratuit pour vous inscrire et vérifier toutes les possibilités.