Résoudre le (not set) dans GA4 : 5 causes et leurs solutions

Le (not set) dans GA4 pollue vos rapports. Voici les 5 causes principales (paramètres, cardinalité, scope, server-side, Enhanced Measurement) et les solutions techniques.

Le label (not set) dans Google Analytics 4 signifie que GA4 n’a pas reçu de valeur pour la dimension demandée dans le contexte du rapport. Ce n’est pas un bug : c’est un symptôme. Le problème, c’est que les causes sont multiples et souvent subtiles.

Contrairement à ce que beaucoup pensent, (not set) ne signifie pas toujours que le tracking est cassé. Parfois, c’est un problème de configuration des dimensions custom. Parfois, c’est un désalignement de scope. Et parfois, c’est Google qui agrège vos valeurs dans un bucket générique parce que vous avez trop de variations distinctes.

Comprendre la cause précise est indispensable pour appliquer la bonne correction. Voici les cinq situations les plus fréquentes et leurs solutions.

L’essentiel
  • Le (not set) a 5 causes principales et chacune a sa propre solution technique.
  • Le diagnostic commence par DebugView + le rapport Source/Medium.
  • Sur les setups server-side, c’est presque toujours la Cause 4 (attribution perdue) qui domine.
  • Sans diagnostic précis, on patche au hasard et le problème revient.

Les 5 causes en un coup d’œil

CauseSymptôme typiqueSolution clé
1. Paramètres custom non enregistrésDonnée visible en DebugView, absente des rapportsEnregistrer la dimension dans Admin
2. High cardinality (bucket “(other)“)Perte de granularité sur dimensions à fort volumeNormaliser les valeurs ou passer par BigQuery
3. Désalignement de scope(not set) sur certains croisements seulementAligner scope dimensions / scope métriques
4. Attribution server-side perdue30 à 50 % de conversions sans sourceCookie d’attribution + dimensions custom
5. Enhanced Measurement mal configuréDoublons + valeurs vides sur events autoAudit DebugView + nommage strict

Cause 1 — Paramètres custom non enregistrés

C’est la cause la plus courante et la plus simple à corriger. Vous envoyez un paramètre custom via GTM ou gtag.js, mais vous n’avez pas enregistré la dimension correspondante dans Admin → Définitions personnalisées. GA4 reçoit bien la donnée (visible dans DebugView), mais elle n’apparaît pas dans les rapports standards.

La solution : rendez-vous dans Administration → Définitions personnalisées, et enregistrez chaque paramètre que vous souhaitez exploiter dans vos rapports.

Attention aux limites : GA4 impose 50 dimensions event-scoped et 25 dimensions user-scoped par propriété. Planifiez votre plan de mesure en conséquence — c’est l’un des points que je traite systématiquement en début d’audit.

Cause 2 — High cardinality et le bucket (other)

Quand une dimension dépasse environ 500 valeurs distinctes dans un rapport, GA4 regroupe les valeurs les moins fréquentes sous le label (other). Ce n’est pas exactement du (not set), mais l’effet sur vos analyses est similaire : vous perdez en granularité.

Solutions :

  • Réduire la cardinalité en regroupant les valeurs similaires avant l’envoi (par exemple, normaliser les URLs en supprimant les query strings)
  • Utiliser BigQuery pour accéder aux données brutes sans cette limitation — c’est l’un des cas d’usage couverts dans la petite-fille BigQuery du cocon GA4

Cause 3 — Désalignement de scope

C’est le piège le plus technique. GA4 fonctionne avec quatre niveaux de scope : user, session, event et item. Si vous croisez une dimension event-scoped avec une métrique session-scoped, GA4 ne peut pas toujours établir la correspondance et affiche (not set).

Exemple concret : vous croisez le nom d’un événement custom (scope event) avec le nombre de sessions (scope session). Les sessions qui ne contiennent pas cet événement afficheront (not set).

La solution : vérifier systématiquement que le scope de vos dimensions correspond au scope de vos métriques dans chaque rapport. Pour le reporting Looker Studio, c’est une vérification systématique à intégrer dans votre méthodologie de construction de dashboard.

Cause 4 — Attribution server-side perdue (la plus impactante)

Quand vous utilisez le Measurement Protocol ou le tracking server-side, les hits arrivent sans le contexte habituel du navigateur. Pas d’UTM, pas de referrer, pas de client_id natif. Résultat : toute la partie attribution tombe en (not set).

Sur les setups e-commerce server-side, ce mécanisme produit souvent 30 à 50 % de conversions Not Set. Sur un compte que j’ai audité, le ratio mesuré était de 48 % — 410 achats sur 862 sans source identifiée.

La solution consiste à mettre en place une couche d’attribution parallèle :

  1. Capturer les paramètres UTM côté client dans un cookie first-party (durée 30 jours typiquement)
  2. Renvoyer ces UTM via des dimensions custom event-scoped sur chaque hit (y compris server-side)
  3. Exploiter les dimensions custom en remplacement des dimensions natives dans le reporting

La procédure technique complète — code JavaScript du cookie, variables GTM, mappings dimensions, validation DebugView — est détaillée dans l’article dédié : cookie d’attribution + dimensions custom GA4. C’est exactement le type de configuration que je mets en place lors d’un audit tracking.

Cause 5 — Enhanced Measurement et conflits d’events

Le Enhanced Measurement de GA4 génère automatiquement des événements comme scroll, file_download ou outbound_click. Mais si vous avez aussi des événements custom qui portent les mêmes noms avec des paramètres différents, vous créez des conflits qui produisent du (not set) sur certaines dimensions.

La première étape de diagnostic est toujours DebugView. Activez le mode debug via l’extension Chrome GA Debugger ou via le paramètre debug_mode dans votre configuration GTM. Vérifiez que chaque événement envoie bien tous les paramètres attendus, avec les bonnes valeurs.

Si vous constatez du (not set) persistant malgré ces vérifications, la cause est probablement dans la configuration initiale de votre setup GA4 et GTM. Un plan de mesure bien structuré, avec des conventions de nommage strictes et un mapping scope par scope, élimine la quasi-totalité des cas de (not set). Pour les fondamentaux, consultez aussi notre guide de configuration GA4.

Aller plus loin sur l’attribution

Une fois la donnée propre, deux chantiers naturels s’enchaînent :

Sur les setups complexes, l’enchaînement des trois (collecte propre → classifications corrigées → modèle d’attribution adapté) est au cœur de la méthodologie d’audit tracking.

En synthèse

Le (not set) est presque toujours résoluble — mais seulement après diagnostic précis. Patcher au hasard ne marche pas. Identifier laquelle des 5 causes domine, appliquer la solution correspondante, et valider en DebugView avant d’attendre 24-48h pour confirmer dans les rapports.

Besoin d'aide sur ce sujet ?

Je peux vous accompagner sur la mise en place ou l'optimisation de votre tracking.

Sans surprise : forfaits affichés en clair, devis validé avant kick-off, pas d'avenant.