Elle sert le même objectif que pose GA4 pour Google Ads : rendre lisible ce que la balise Ads ne rapporte pas dans ses colonnes natives, campagne par campagne, canal d’acquisition par canal d’acquisition.
Qu'est-ce qu'une dimension personnalisée GA4 fait réellement ?
Le malentendu d'abord. Vos événements GA4 arrivent avec des paramètres : la gamme de l’article consulté, le type de formulaire envoyé, le statut du client. Ces données existent déjà dans Google Analytics et restent invisibles dans vos analyses tant qu'elles ne sont pas enregistrées.
La déclaration GA4 est cet enregistrement : une clé collectée, associée à la portée adaptée, devient filtrable, croisable et lisible.
Donc : cet enregistrement ne génère rien, il rend exploitable ce que vous collectiez déjà. Conséquence immédiate, que les tutoriels prennent à l'envers : tout le travail est en amont, collecter la bonne information, proprement, via le dataLayer et son plan de variables e-commerce et le plan de collecte. La déclaration dans l’interface est la dernière marche, pas le projet.
L'enregistrement n'est pas rétroactif : il devient exploitable à partir de sa création, pas en arrière. Raison de plus pour déclarer tôt ce dont on sait qu'on aura besoin.
Avant de créer de nouveaux champs dans Google Analytics 4, partez des questions à résoudre. Quels utilisateurs atteignent le contenu clé ? Leur navigation passe-t-elle par le menu, une recherche interne ou des liens de campagne ? Le niveau d’engagement change-t-il selon le segment de trafic ? Ces questions désignent les informations utiles à exposer dans Analytics ; elles évitent de déclarer des champs simplement parce qu’ils sont disponibles.
Cette logique sépare aussi collecte et lecture. La balise ou le code du site envoie les valeurs ; Google Analytics les reçoit ; la définition personnalisée les rend disponibles dans les explorations. Aucun outil de création de rapport ne peut reconstruire une information que la collecte n’a jamais fournie.
Les trois portées : événement, utilisateur et article
Google Analytics 4 distingue trois portées de dimensions personnalisées. La plupart des équipes n'en utilisent que deux et manquent le troisième type, le seul qui lit l'intérieur du tableau items[] d'une transaction.
Portée événement et portée utilisateur : le socle commun
La portée événement attache la valeur à chaque occurrence d'une action : gamme vue, version de formulaire soumise, type de page consulté. La valeur peut changer plusieurs fois par session. La portée utilisateur, elle, conserve l’information sur les sessions de la personne : statut client, segment tarifaire, groupe d'attribution de cohorte.
La frontière à respecter : si la valeur décrit quelque chose de transitoire (une page, un clic, un contenu consulté), choisissez la portée événement. Si elle décrit la personne durable (son plan, son statut, son canal d'origine), choisissez la portée utilisateur. Mélanger les deux donne des analyses incohérentes et consomme le quota au mauvais endroit.
Portée article : le troisième type souvent oublié en e-commerce
La portée article est distincte des deux autres : elle lit les attributs portés par chaque objet dans le tableau items[] des événements e-commerce, add_to_cart, purchase, view_item. Couleur, taille, gamme, collection, catégorie : ces informations existent déjà dans votre dataLayer e-commerce mais restent invisibles tant qu'elles ne sont pas déclarées en portée article.
Ce que ça permet concrètement : croiser le taux de conversion par couleur ou par gamme sans créer un champ artificiel au niveau de l'action entière. La valeur appartient à l'article. Vous savez quels attributs convertissent sans polluer l'espace de nommage de votre collecte.
Le quota de cette portée est distinct des deux autres dimensions personnalisées : la portée article a son propre plafond, séparé des dimensions événement et utilisateur.
| Portée | Ce que la valeur représente | Cas d'usage typique | Quota standard |
|---|---|---|---|
| Événement | Valeur attachée à l'action | Gamme consultée, version de formulaire | 50 |
| Utilisateur | Propriété attachée à la personne | Statut client, segment tarifaire | 25 |
| Article | Attribut d'un objet dans items[] |
Couleur, taille, collection produit | 10 |
Les cas d'usage qui paient pour un annonceur
Trois familles rentables, toutes au service d'une décision, toutes exploitables ensuite par vos campagnes.
Segmenter la qualité du trafic payant : une valeur « type de prospect » ou « gamme consultée » croisée avec le canal d'acquisition, vos annonces amènent-elles les bons profils, ou seulement du volume ?
Comparer des versions entre deux campagnes : la variante de page d’arrivée ou de formulaire devient lisible dans une analyse A/B. Le même réflexe vaut pour les paramètres d'engagement profond, qui ne servent à rien tant qu'ils restent dans la collecte sans être exposés.
Porter le contexte métier : client nouveau ou existant, segment tarifaire, catégorie de contenu consultée, catégorie d'application pour ceux qui suivent une application mobile, des informations que GA4 ne peut pas déduire seul mais que votre site collecte déjà. Le test d'admission est toujours le même : quelle décision ce champ éclairera-t-il ? Pas de réponse en une phrase, pas d'enregistrement.
Trois segments suffisent souvent à cadrer le besoin. Le segment d’acquisition décrit la source ou la campagne. Le segment de navigation décrit le chemin, le type de lien cliqué ou l’élément d’interface utilisé. Le segment métier décrit le statut du client ou la catégorie d’achat. Dans Google Analytics, croisez ensuite ces informations avec des métriques de trafic, d’engagement et de conversion ; si aucun croisement n’éclaire une décision, la nouvelle définition n’a pas à être créée.
Dans Google Analytics, les dimensions décrivent le contexte et les mesures chiffrent le résultat. Les dimensions personnalisées peuvent ainsi ventiler une métrique existante, pas inventer une mesure absente. Croisez quelques dimensions stables avec des mesures de volume, d’engagement et de conversion : cette grille fournit davantage d’information qu’une longue liste de champs jamais utilisés.
Cas concret : un rapport de navigation. Placez en lignes le type de lien et la zone de contenu, puis comparez les utilisateurs, les événements et les mesures d’engagement. Ce rapport montre quels liens orientent réellement la navigation et quels utilisateurs quittent le parcours. Un second rapport peut rapprocher les événements d’achat du segment client : il décrit le comportement d’achat sans enregistrer l’adresse complète de chaque page.
Deuxième cas : le contrôle des campagnes marketing. Un rapport dédié compare les utilisateurs issus du trafic payant, les événements de formulaire et le comportement après le clic. Ces informations permettent de distinguer un problème marketing d’un problème de navigation. Les dimensions fournissent le contexte ; les métriques gardent la responsabilité du calcul.
Les outils comme Looker Studio consomment ensuite les données d’Analytics, ils ne réparent pas la collecte. Des rapports personnalisés dans Looker Studio restent vides si les définitions n’ont rien reçu. Commencez donc dans Analytics, validez les valeurs, puis construisez les tableaux personnalisés destinés aux équipes marketing.
Ces outils fournissent un contrôle simple : le comportement attendu doit rester cohérent entre les liens de navigation et les conversions observées.
Cardinalité et quotas : pourquoi vos dimensions GA4 dégradent les rapports ?
La cardinalité : des catégories qu'un humain peut énumérer
La cardinalité. Une définition sur mesure se juge au nombre de valeurs distinctes qu'elle prend, session après session. « Gamme » : quelques dizaines, parfait. « ID de session », « URL complète avec paramètres » : des milliers, à éviter.
Trop de valeurs distinctes font exploser les combinaisons à agréger, et GA4 répond en compactant l'excédent dans la ligne « (other) » : le champ censé affiner l’analyse la rend illisible.
Règle simple : exposez des catégories qu'un humain peut énumérer. Une fois propres, elles remontent dans les rapports de cheminement de GA4, croisées avec vos canaux d'acquisition. Les identifiants uniques, eux, n’ont pas leur place dans ces champs : envoyez-les vers l'export GA4 vers BigQuery, adapté à la lecture fine des données brutes.
Les quotas GA4 standard vs 360 : les seuils qui font décider
Le nombre de dimensions enregistrables est limité par portée et par version de propriété. C'est ce tableau que les équipes cherchent au moment de décider si le passage à Analytics 360 se justifie :
| GA4 standard | GA4 360 | |
|---|---|---|
| Dimensions portée événement | 50 | 125 |
| Dimensions portée utilisateur | 25 | 100 |
| Dimensions portée article | 10 | 25 |
| Métriques personnalisées | 50 | 125 |
À noter : supprimer une définition libère une place dans le quota, mais sans restaurer les données historiques collectées avec l'ancienne définition. Il faut aussi prévoir un délai avant de pouvoir réutiliser proprement le même espace. Autrement dit, une mauvaise décision coûte du temps, raison de plus pour formuler la question avant d'enregistrer.
Irréversibilité : ce qu'on ne peut plus changer après enregistrement
Contrainte que la plupart des équipes découvrent trop tard : une fois le champ créé, GA4 ne permet pas de modifier sa portée après création (on ne peut pas passer de portée événement à portée utilisateur) ni la clé liée. Seul le nom affiché dans l'interface est modifiable.
Conséquence directe : une erreur de portée ne se corrige pas, elle se paie deux fois, une place de quota mal utilisée et la nécessité de créer une deuxième définition pour la même donnée. C'est pourquoi l'étape de sélection (étape 2 ci-dessous) n'est pas une formalité.
L’erreur classique : enregistrer en portée événement une valeur qui devrait être en portée utilisateur parce qu'elle décrit le statut durable du client. Elle s'affiche action par action au lieu de s'agréger par personne, l’analyse devient illisible et la place est perdue.
- Inventaire. Listez les valeurs déjà envoyées. Pour chacune : quelle décision éclaire-t-elle, combien de variantes prend-elle, depuis quand est-elle propre ?
- Sélection. Ne gardez que les survivantes de cette grille : décision formulée, cardinalité faible, clé stable. Choisissez la portée définitivement : elle et la clé liée ne sont plus modifiables après enregistrement.
- Enregistrement. Dans GA4 : Admin > Définitions personnalisées > Créer une dimension personnalisée. Nommez-la lisiblement, choisissez la portée puis liez la clé exacte.
- Vérification. Contrôlez d’abord la valeur dans DebugView ou le Temps réel. Pour la retrouver dans les tableaux standards et les explorations, comptez généralement 24 à 48 heures après l’envoi des données et la création. Ce délai est distinct de la non-rétroactivité : aucune donnée historique ne sera remontée.
Le contrôle de la collecte vient avant l’interface. Dans Google Tag Manager, vérifiez que le code envoie des paramètres portant exactement le même nom sur tous les événements concernés. Des paramètres homonymes, des casses différentes ou des valeurs vides créent plusieurs séries difficiles à rapprocher. Une fois le code stabilisé, les dimensions peuvent exposer ces clés sans retraitement.
Le garde-fou : GA4 expose la valeur telle qu'elle est collectée. Des libellés incohérents en entrée (« B2B », « b2b », « pro » pour la même réalité) restent incohérents en sortie. La normalisation se gagne au dataLayer, pas dans l'interface.
- L’enregistrement n'ajoute aucune donnée : il expose une valeur que vous collectez déjà. Sans collecte propre en amont, rien d’utile à afficher.
- Non rétroactif : il devient lisible à partir de sa création. Déclarez tôt ce dont vous connaissez l'utilité.
- Trois portées : action, personne et article. Le choix est irréversible après enregistrement.
- Cardinalité faible nécessaire : des milliers de valeurs distinctes finissent dans la ligne (other). Les identifiants uniques vont à BigQuery.
- Les quotas sont finis. Chaque enregistrement inutile consomme une place et encombre les analyses.
Une dimension personnalisée peut-elle alimenter une audience Google Ads ?
Oui, et c'est l'usage que beaucoup d'annonceurs découvrent tard. Une fois la donnée exposée dans les analyses, elle devient un critère de segmentation dans le menu Audiences de GA4 : vous construisez une audience sur la valeur collectée (le segment tarifaire, la gamme consultée, le statut client), puis vous l'exportez vers votre compte Google Ads lié pour du remarketing ciblé ou de l'exclusion de campagne.
Le point que les tutoriels sautent : cette audience n'est pas plus rétroactive que la définition qui la nourrit. Elle se remplit avec les personnes qui génèrent l'action porteuse de la valeur après la création de l’audience et son enregistrement exploitable. Une audience « segment tarifaire = premium » construite le jour même restera limitée tant que l’information correspondante n'aura pas circulé quelques jours dans la collecte.
Ce que ça change concrètement pour vos campagnes, sur le web comme en application :
- une valeur durable comme le statut client fait une meilleure base d'audience qu'une donnée transitoire, parce qu'elle s'attache à la personne et non à une action isolée ;
- l'audience créée dans GA4 se comporte ensuite comme n'importe quelle liste de remarketing côté Ads : elle s'assigne à un groupe d'annonces, s'exclut d'une campagne d'acquisition, ou sert de signal d'audience pour l'apprentissage automatique des stratégies d'enchères, vos annonces gagnent en pertinence sans effort de ciblage manuel supplémentaire ;
- la cardinalité compte ici aussi. Une liste de valeurs propre donne des audiences lisibles ; une collecte polluée produit des audiences dont vous ne savez plus qui elles contiennent réellement.
L'articulation complète entre les segments prédictifs que GA4 calcule seul et les audiences que vous construisez à la main sur vos propres dimensions, c'est le terrain des audiences prédictives GA4 : la donnée déclarée reste la matière première, l'audience est ce que vous en faites une fois exposée.
Dimension personnalisée GA4 et colonne personnalisée Google Ads : est-ce la même chose ?
Non, et la confusion coûte du temps à qui cherche la fonctionnalité au mauvais endroit. Les deux portent le mot « personnalisé », les deux vivent dans une interface Google, et c'est à peu près là que s'arrête la ressemblance.
Une colonne personnalisée, côté Google Ads, recombine des métriques que la plateforme calcule déjà : elle affiche le CTR mobile seul, ou soustrait deux colonnes existantes. Rien n'est collecté, rien n'est déclaré en amont, c'est une opération arithmétique sur des mesures déjà présentes dans le compte.
Côté GA4, le champ expose une information que votre site ou application a collectée et que Google Ads ne voit pas telle quelle dans ses colonnes natives : la gamme consultée, le statut du client, la variante de formulaire soumise. Il ne s’agit pas d’un calcul sur des métriques publicitaires existantes, mais de l'exposition d'une donnée métier que seule votre collecte connaît, la première brique d'un ciblage propre à votre activité.
La frontière pratique : si la donnée que vous cherchez existe déjà dans les rapports Google Ads (impressions, clics, coût, conversions), c'est une colonne personnalisée qu'il vous faut, pas une dimension GA4. Si la donnée vient de votre site, un champ applicatif, un élément de contexte que votre dataLayer connaît et qu'aucune plateforme publicitaire ne devine, c'est le terrain des dimensions personnalisées GA4, avec leur enregistrement, leur portée et leur quota.
À trancher
Ce réglage n'est pas un projet en soi : c'est une brique de votre plan de mesure et de suivi Google Ads, et il vaut ce que vaut la collecte en amont.
Si la donnée n'existe pas encore dans la collecte, le travail commence dans Google Tag Manager (GTM), avec ses balises, déclencheurs et variables, pas dans l'interface GA4. Et si votre besoin réel concerne des identifiants uniques ou des croisements lourds, la bonne réponse est BigQuery. Si vous constatez des écarts entre les sources d'acquisition dans GA4 et les tableaux Google Ads, le sujet dépasse cette page : voir les écarts de conversion Ads vs GA4.
