Google Analytics : tout ce que vous avez toujours voulu savoir sur les scopes

Une fois n’est pas coutume, aujourd’hui, je vais écrire un article qui ne parlera (presque) pas de Google Tag Manager. Bon, je suis un fou dans ma tête mais pas trop, donc ne rêvez pas d’un article sur mes meilleures recettes de salades de quinoa ou, encore plus YOLO, sur AT Internet. Non non non, rassurez vous, aujourd’hui, on reste en terrain connu, puisqu’on va parler de ce bon vieux Google Analytics.

Les internets disent souvent (à raison) que je ne fais la promo que des outils Google. Alors, oui, ils sont quand même puissants et flexibles. Oui, je touche 10% de commission pour toute souscription à une licence GA360. Oui, j’ai planqué des liens d’affiliation un peu partout dans mon blog… Mais qui aime bien châtie bien : j’ai toujours trouvé que GA se tapait une sacrée dette technique sur deux points : la gestion des campagnes et le scope de ses dimensions.

Pour ce qui est desdites campagnes, je ne vous la fais pas : les UTMs présentent sont peu flexibles, limités en nombre, et globalement pas super élégants. Adobe Analytics, que je n’ai malheureusement pas utilisé depuis bien trop longtemps, possède pour moi une approche beaucoup plus custom et sympa : on tracke ses campagnes via un seul paramètre d’URL, par exemple « campaign ». Ainsi, plutôt que de se trimbaler des URLs du type http://www.riouandriouconsulting.biz?utm_source=email_retargeting&utm_medium=crm&utm_campaign=rioucamp2019&utm_term=prospects_chauds_mais_pas_tant_que_ca&utm_content=liste_achetee_en_loosede_pas_tres_halal_avec_la_rgpd, un simple http://wwwriouandriouconsulting.biz?campaign=152 fera l’affaire. L’enrichissement se fait ensuite, server side, via les Classifications d’Adobe :

L’avantage de cette méthode, c’est qu’on peut attacher autant de dimensions (chez Adobe, on dit des eVars ou des sProps) que l’on veut à une campagne, et, accessoirement, que c’est rétroactif. Vous n’êtes donc pas cloisonnés avec ces fu***** UTMs dont les noms dans les rapports ne sont pas les mêmes que dans les URLs, avec leur règle d’attribution étrange…Bref, pas foufou.

/* Soit dit en passant, les plus pointus d’entre vous noteront qu’il est possible de le faire dans GA, en utilisant la fonction de data import. Petite subtilité, pour que ça soit rétroactif, il faut être client GA360 (mais bon, hein, aujourd’hui, QUI n’est pas GA360, sérieusement?). */

Mais je digresse, puisque ce n’est absolument pas le sujet de cet article (ça fait du bien quand même), puisque c’est le second gros défaut de GA qui va nous intéresser, à savoir les scopes des dimensions. Mais pour comprendre de quoi il s’agit, il va falloir mettre un peu les mains dans les tréfonds de Google Analytics.

Petite précision : pour cet article, nous allons une nouvelle fois utiliser le merveilleux compte de démo de Google, dont je vous invite à récupérer les accès sans plus attendre si ce n’est déjà fait.

Les bases : dimensions et métriques

Commençons par les bases, pour les utilisateurs qui ne seraient pas (encore) très familiers de GA, et d’une notion assez fondamentale, les dimensions et metrics. Tous les rapports que vous consultez, dans GA, affichent des données quantitatives comme le taux de rebond, le temps passé, le nombre de sessions…que l’on peut sommer, diviser, sur lesquelles on peut faire des ratios : il s’agit de metrics. La plupart des rapports découpent ces metrics selon des axes d’analyses : le device, la source de trafic, le pays, etc… Évidemment, il s’agit là de dimensions. OK, tout le monde suit?

Typiquement, les rapports en tableaux que vous connaissez par cœur affichent les metrics en colonnes, et les dimensions en lignes :

Si je voulais vous embrouiller un peu (mais juste un peu, dans le respect de la personne), je pourrais aussi vous dire que l’on peut fabriquer des dimensions grâce à des metrics. Par exemple, le temps passé par session est une metric, nous sommes bien d’accord là-dessus, mais en revanche, il est possible de faire des intervalles à partir de ce temps passé, et donc, d’obtenir une dimension « Durée de la session » selon les intervalles sus-mentionnés :

Ah oui, aussi. Il convient de préciser que j’utilise sciemment les termes anglais de metrics et dimensions car ils font partie de ces éléments que Google n’a pas daigné traduire correctement : ainsi, si vous regardez dans la littérature, « Metrics » a été traduit par « Statistiques »…

POURQUOI? Ils auraient aussi bien pu traduire par « chiffre », ça aurait été aussi clair (ou « saucisse », tant qu’à faire marrer tout le monde). Donc, nous parlerons bien de metrics tout au long de notre petite affaire, c’est comme ça et puis c’est tout.

Avouez que ça a plus de gueule là, non?

Les scopes des metrics et des dimensions

Jusqu’ici, rien de bien compliqué. Les notions de saucisses metrics et de dimensions relèvent du bon sens. Nous allons légèrement compliquer les choses, avec un concept là encore fondamental pour tout utilisateur de GA, à savoir, les scopes, ou portées si vous tenez à vous exprimer en bon Français de France (le truc un peu à l’Est de Rennes, là).

Il faut savoir que les dimensions peuvent s’appliquer, au choix :

• A des données qui sont uniques à l’utilisateur : son navigateur, son pays, sa tranche d’âge…
• A des données qui concernent simplement une session donnée : sa page de destination par exemple
• A des données qui sont propres à une seule interaction, donc une page vue ou un event : un nom de page, un titre de page, une catégorie d’événement…

Les dimensions ont donc 3 scopes : utilisateur, session, hit.

En ce qui concernent les metrics, c’est la même : les metrics sessions, pages vues, événements totaux, utilisateurs sont bien évidemment la référence pour les 3 scopes, mais certaines metrics en sont dérivées :

• Metrics de scope utilisateur : nombre de sessions par utilisateur, pourcentage de nouveaux utilisateurs, pourcentage de nouvelles sessions…
• Metrics de scope session : taux de rebond, durée de la session, taux de conversion des objectifs (eh oui, ne jamais oublier que les objectifs sont scopés à la session).
• Metrics de scope hit : temps passé moyen sur une page, valeur d’événement…

D’ailleurs, la documentation sur le sujet est assez claire et exhaustive, et il est toujours bon de garder cette page dans un bookmark de son navigateur préféré (Internet Explorer 10.1 pour ma part, mais après je ne juge pas si vous faites un choix différent).

Encore une fois, tout ceci paraît tout ce qu’il y a de plus logique, et d’ailleurs, c’est bien pour ça que les rapports de GA sont construits de la sorte : les bonnes metrics sont associées au bonnes dimensions, donc n’importe quel utilisateur peut s’y retrouver sans aucun problème.

Les scopes des segments

Oui, il faut aussi aborder ce point. Vous avez sans doute l’habitude d’utiliser des segments pour affiner vos analyses. Et, en analystes élégants que vous êtes, vous utilisez très probablement des segments custom (par exemple pour isoler toutes les sessions entrées par une page donnée) :

Ce que l’on a souvent tendance à ignorer (et, si je ne m’abuse, c’est une feature plutôt récente de GA), c’est que les segments aussi possèdent aussi, en quelque sorte, une notion de scope (session ou utilisateur) :

On peut donc choisir de prendre uniquement les sessions rentrées par une page en question, ou bien l’ensemble des utilisateurs dont au moins une session est entrée par cette page. Comme ça, cela semble simple, mais gardez bien ça en tête, parce que ça va bien nous servir pour la suite.

Cas des custom dimensions

Vous connaissez ma passion sans limite pour les custom dimensions. Les dimensions, c’est cool. Le custom, c’est bien. Donc, les custom dimensions, c’est trop choupi. Une fois que l’on a bien compris comment fonctionnait le principe des scopes, créer une CD est un jeu d’enfant : on se rend bien compte que la dimension en question concernera un hit (par exemple, une catégorie de page), une session (par exemple, le fait qu’elle ait été « logguée » ou pas) ou carrément un utilisateur (son segment dans la base CRM ou son ID client si on est pote avec son DPO) :

J’ai d’ailleurs volontairement laissé de côté le cas du scope produit, qui est un peu particulier. Il est proposé à la création d’une custom dimension, mais concerne certaines dimensions natives propres au enhanced e-commerce.

Une fois notre custom dimension implémentée, et envoyée en surcharge d’un tag (page ou event), nous pourrons très naturellement faire deux choses :

1/ Utiliser gracieusement un dimension secondaire dans un rapport de type « Toutes les pages » (avec un exemple très classique de custom dimension de scope hit pour du contenu édito, la date de publication) :

2/ Carrément aller taper un custom report (Rapport personnalisé), en prenant bien soin d’utiliser la même metric, et ce afin d’avoir les données globalement segmentées sur cette custom dim :

Pour les petits nouveaux qui n’y auraient jamais touché, les custom reports se trouvent ici :

Et le sujet des custom reports tombe fort à propos, puisque c’est précisément ici que les choses vont se corser.

Les rapports personnalisés

Ici, fini les rapports bien cadrés de l’interface de GA, on est désormais dans la cour des grands, et GA nous laisse jouer avec les dimensions / metrics que l’on veut lorsqu’on configure notre rapport. Et, évidemment, on peut y commettre les pires horreurs du monde :

(je n’ai pas osé appuyer sur « Enregistrer », j’avais beaucoup trop peur de casser Internet)

Soyons clair, si jamais vous décidez d’arrêter la lecture de cet article genre là, maintenant, tout de suite, ne retenez qu’une seule chose :

Ne. Mélangez. Pas. Les scopes.

Quand vous triez vos chaussettes, est ce que vous mettez une bleue avec une verte? Une rouge avec une orange? Non? Sauf éventuellement pour vous donner un style rebelle. Eh bien dans GA c’est un peu pareil. Faire le cool kid, c’est un métier. Un métier qu’il faut pratiquer avec délicatesse. Sinon on finit par faire partie d’une team de tektonik.

L’idée va donc être d’étudier tous les cas de croisements de dimensions et de metrics, afin de remplir la matrice suivante, qui va nous servir de fil rouge pour la suite de l’article :

Vous allez voir, dans moins de 30 minutes, vous l’aurez imprimée en A2 et accrochée au-dessus de votre bureau (l’espoir fait vivre).

Nous allons donc procéder pas à pas, ou plutôt case par case :

Cas 1 : Metric de scope hit x dimension de scope user

Allons donc chercher une dimension de scope user (le navigateur) et une metric de scope hit (pages vues), et mélangeons ça dans un custom report qui s’annonce croquant et fondant :

Roulements de tambour…

Ma foi, tout semble bien se passer. Nous avons les pages vues totales par navigateur, ce qui semble au fond assez logique. Pour s’en assurer, on peut faire un petit segment du charisme avec « Navigateur = Firefox », qui nous permet de vérifier, via le rapport habituel, que nous sommes cohérents avec ce que l’on a vu dans notre custom report :

Notre premier cas est donc réglé en deux temps trois mouvements :

Cas 2 : Metric de scope utilisateur x dimension de scope hit

Faisons donc l’inverse, avec une dimension de scope hit (titre de page, pour faire un peu original), et une metric de scope user (utilisateurs, pas trop le choix là, pour le coup) :

Et regardons sans plus attendre le résultat :

Encore une fois, notre intuition semble nous dire que tout ceci relève du bon sens, et qu’avoir le nombre d’utilisateurs (de cookies, pour ainsi dire) ayant consulté une même page (enfin, une même balise title unique ici). Mais la grande rigueur propre à tout bon data analyst qui se respecte (ou alors qui ne se respecte pas, mais qui doute encore de ce que je raconte) consiste à créer un nouveau segment pour vérifier une des lignes de ce rapport :

Apparté : vous avez bien noté que le segment est de « scope » utilisateur, right?

Tout va bien, les amis, nous pouvons donc officiellement mélanger du scope utilisateur et du scope hit sans craindre le courroux divin du Head of Digital Insights EMEA APAX BZH LATAM. Et accessoirement compléter une seconde case de notre matrice :

Mais vous vous souvenez le moment où j’ai dit que ça allait un peu chauffer? Parce que non, je ne vous ai pas menti, ça va chauffer. Puisqu’on va s’intéresser au cas particulier des sessions.

Apparté : nous sommes de toute façon bien d’accord (enfin, je suis d’accord avec moi-même), la session est de toute façon une abstraction, trop souvent utilisée sans être réellement comprise. Sa durée est de toute façon customisable, et sa pertinence très variable selon le type de site. De plus, GA rapporte beaucoup trop de choses (les objectifs, rien que ça) à la session, et ça me rend souvent un peu triste.

Apparté dans l’apparté : Firebase (oups, un autre outil de Google) ne possède pas de notion de session (ni de page vue / screens, d’ailleurs). Tout n’y est qu’event et users, et, franchement, on s’y marre bien.

Cas 3 : Metric de scope utilisateur x dimension de scope session

Voici la configuration de mon custom report pour ce premier test touchant aux sessions :

Bon, nous connaissons par cœur la page de destination, dimension classique nous permettant de classifier nos sessions par landing page. Mais qu’est ce qu’on attend de ce custom report, au fait?

• Un compte doublonné d’utilisateurs passés par une landing page donnée? Concrètement, si je suis entré par la page A lors de ma 1ère session, puis par la page B lors de la seconde, chaque ligne est incrémentée de 1?
• Ou alors une règle d’attribution type last touch selon laquelle la landing page de ma dernière session est rattachée à mon cookie de façon rétroactive?

Ainsi, avant de faire tourner notre custom report (même je sais que vous attendez ça fébrilement) prenons l’exemple de la home (page « /home »). Un petit segment fait au niveau de l’utilisateur nous permet rapidement de savoir que nous avons 33 233 utilisateurs ayant fait une session en entrant via la home, et potentiellement d’autres trucs.

C’est donc le chiffre que, à mon sens, on attendrait dans ce custom report.

Sauf que…Voici ce que nous sort GA :

33 591…WTF?

Immédiatement, le premier réflexe est d’aller voir le rapport des pages de destinations, en le raccrochant à sa metric habituelle (les sessions) :

J’ai donc moins d’utilisateurs dans mon custom report que de sessions entrées par la home.

C’est là que je fais une ellipse et que je vous épargne mes heures (minutes, en vrai) passées à comprendre le truc et à me rouler par terre en criant « JE VEUX ALLER SUR COREMETRICS ». En fait, il existe une façon assez simple de trouver d’où vient ce fameux 33 591 :

Et c’est là qu’on va voir si vous avez suivi (voire si vous n’êtes juste pas en PLS, ce qui serait déjà pas mal) : ce segment semble être le même, sauf que cette fois, il est fait en n’incluant que les sessions entrées par la home. N’hésitez pas à relire la partie sur le scope des segments plus haut si vous avez un doute.

Donc, concrètement, mes deux hypothèses initiales étaient bien à côté de la plaque : notre chiffre représente le nombre d’utilisateurs rentrés par une page donnée (ici la home) durant chacune de leurs sessions. Relisez le. Deux fois. Réalisez à quel point c’est tordu. Passez à la suite.

Mais avant, n’oublions pas de compléter notre matrice :

Cas 4 : Metric de scope session x dimension de scope utilisateur

Nous allons utiliser ce custom report :

Nous avons un résultat qui semble assez conforme à nos attentes, à savoir le nombre de sessions réalisées par navigateur :

Pour s’assurer de la véracité du rapport, notre rigueur scientifique et notre désormais ceinture noire en scopage de segments nous incite à vérifier ceci sur un cas (celui de Firefox), où on s’attend à retrouver la valeur 2 031 :

Rhoo, 2 028, 2 031, on va pas pinailler, hein? ça doit être l’échantillonnage? Hein? Non? Oh, on est web analystes, pas garagistes (ou dir conseil d’agence média). Parce que c’est plus compliqué que ça, en fait.

Eh oui, c’est plus compliqué que ça. Et pour le comprendre, nous allons imaginer un cas d’une custom dimension de scope user (comme le navigateur) qui tracerait le segment CRM : « prospect », « client », ou « client sympa ».

Pierre se rend sur un site une première fois, il est prospect (session #1). Il réalise 1 nouvelle session en tant que prospect, puis une autre où il achète (#2 et #3). Il réalise ensuite 2 autres sessions (#4 et #5) où il n’achète pas, mais où il est désormais classé comme client. Enfin, lors de sa 6ème et dernière session, il achète un nouveau produit. Il passe donc en « client sympa » (normal, il a acheté 2 produits). Toutes ces sessions ont lieu durant le mois de janvier.

Si on fait un custom report avec les utilisateurs par segment CRM sur la période de janvier, GA classera Pierre seulement en tant que « client sympa ». Oui, GA réattribue dynamiquement par rapport à la dernière valeur prise par la dimension, il faut le savoir et ça a son importance.

Mais que se passe-t-il si on regarde les sessions par segment? Ici, le sujet semble plus complexe que pour le navigateur, puisque ce bon vieux Pierrot (oui, c’est un bon copain à moi, super gars) a changé de segment. Et tuons tout suspense, oui, dans le cas de Pierrot, nous avons 3 sessions pour « prospect », 2 pour « client », et 1 pour « client sympa ».

Si on revient à notre histoire de Firefox, c’est bien normal que l’écart soit si faible : l’utilisateur étant défini par un cookie, et le cookie étant rattaché au navigateur, on peut imaginer que les utilisateurs ayant conservé le même client ID sont soit 1/ Des petits malins ayant modifié leur cookie pour être le même utilisateur sur plusieurs devices soit 2/ Chuck Norris (ou Simo Ahava #pourLesVrais).

Si j’ai volontairement pris un chemin détourné pour expliquer ce point finalement pas si complexe, c’était plus pour insister sur la capacité de GA à attribuer dynamiquement la dernière valeur aux dimensions de scope user.

On complète donc avec enthousiasme notre 4ème case :

Cas 5 : Metric de scope hit x dimension de scope session

Config de notre rapport :

Vous avez désormais l’habitude de la méthodo, nous allons tâcher de vérifier unitairement d’où sort ce 205 876 « pages vues » pour la page de destination « /home » via un segment.

On se fait donc notre petit segment en prenant toutes les sessions entrées par la home :

Une fois ce segment appliqué, regardons ce qu’il donne une fois appliqué sur le rapport « Vue d’ensemble » :

Banco : pour une fois, pas de cas tordu, nous retrouvons bien nos pages vues.

On peut donc conclure que prendre une dimension de scope session et une metric de scope hit nous donnera l’ensemble des hits (pages vues, événements, et tutti quanti) pour une valeur donnée de la dimension. Une case de plus remplie :

Okay, tout le monde est encore là? On enchaîne sur le dernier cas. Clairement le plus WTF :

Cas 6 : Metric de scope session x dimension de scope hit

Celui là est un grand classique de GA, qui, vous allez le voir, met en avant une grosse incohérence de l’outil.

Voici la config utilisée pour ce dernier test, où nous allons une nouvelle fois utiliser le titre de page :

Avant d’aller plonger dans la création de segments pour fact-checker tout ceci, réfléchissons une seconde à ce que nous attendons : il semblerait logique que nous ayons le nombre de sessions passées par la page en question, n’est-il pas?

Ici, on s’intéresse donc à ce 22 767.

Et voyons voir si on retrouve nos petits avec un segment :

Hum. Visiblement, non.

Et c’est là que, derrière votre écran, de l’autre côté de l’interweb, vous n’en pouvez plus, vous piaffez d’impatience à l’idée de savoir ce que cela signifie lorsqu’on utilise la metric de session sur une dimension de scope hit.

Eh bien je n’ai pas la moindre foutue idée. Je suis convaincu qu’il y a une réponse quelque part sur la communauté numérique de la web analyse, quelqu’un saura me donner la réponse à cette mystérieuse question. Auquel cas, comme d’habitude, je lui accorderai ma gratitude éternelle, en plus d’1/2 litre de boisson à base de houblon.

Ehhhh en fait si! Un grand merci à Olivier Chubilleau qui m’a mis sur la voie pour résoudre ce point, cas tordu parmi les cas tordus.

En réalité, ce nombre mystérieux semble correspondre à une metric quelque peu mystique et pas accessible directement dans l’interface, à savoir le nombre d’entrées sur une page donnée moins les sessions qui ont déclenché un tag d’event avant le tag de page.

Je m’explique : les entrées sont une vieille metric de GA, qui a fait des nœuds au cerveaux de pas mal de vieux de la veille de la webanalytics. Les entrées (metric de scope session, kikoo) pour une page donnée nous donnent le nombre de sessions dont la première page vue a été, par exemple , « /home » :

Ce qui revient exactement au même que de passer par le rapport des pages de destination :

Premier reflexe, donc : ajouter sessions et entrées sur un même custom report, afin de voir si on retrouve bien nos petits :

Oui mais non. Nous sommes proches, mais il y a toujours un tout petit peu moins d’entrées que de sessions.

Même si je n’en suis pas sûr à 100%, je pense que la réponse se trouve dans les events. Si je rentre sur un site par la page « /homepage.php », mais qu’un event est déclenché avant le tag de page, je suis dans le cas d’une entrée, et pas d’une session.

Ce qui me permet de valider de façon quasiment scientifique cette hypothèse (en vrai, totalement du doigt mouillé), c’est en me rendant sur un UA où il n’y a absolument aucun event sur une période donnée, et où, dans ce cas, sessions et entrées sont parfaitement équivalents :

Google l’explique d’ailleurs assez clairement dans la doc, la somme des entrées est inférieure à celle des sessions du fait d’events « un peu trop pressés ».

On peut même, pour s’en assurer, croiser la metric session avec une autre dimension de scope hit, l’action d’événement :

Les données obtenues sont cette fois bien loin des événements uniques :

J’ai eu l’occasion de le vérifier sur d’autres cas du GA de Ouest France, où il y a assez peu de cas d’events pouvant partir avant des pages, et mon intuition se confirme : seuls ces rares cas où le tag d’event peut partir en premier ont un nombre de sessions significatif.

Conclusion : utiliser la metric « sessions » sur une dimension de scope hit nous donne donc le nombre de sessions ayant démarré la session par cette valeur de dimension (un nom de page, un libellé d’event…) sur leur premier hit. Pas simple, mais mission accomplie!

Après, ne croyez pas non plus que je vais vous laisser, là, les bras ballants (sisi, je vois bien vos bras baller), parce que je peux vous proposer une solution miracle à cette problématique du « combien de sessions ont eu cette valeur de dimension à un moment donné ».

Evidemment, il est très probable que vous lisiez ma digression en vous disant « attends, patate, tu as les vues uniques pour ça, pourquoi est ce que tu te casses la tête comme ça? ». Et effectivement, GA nous donne, depuis la nuit des temps, des metrics « sessionnisées », c’est à dire dédoublonnées au niveau de la session :

• Les « événements uniques » dans les rapports d’event, qui permettent de comparer, par exemple pour la catégorie d’événements « Clics homepage », le nombre total d’occurences (metric « nombre total d’événements »), et le nombre de sessions où la catégorie d’événement a été populée (metric « événements uniques »).
• C’est exactement la même choses pour les metrics « Pages vues » et « Vues uniques » (je ne vais pas vous la faire).
• Il existe aussi, si vous faites du content grouping, des metrics spécifiques à chaque content grouping que vous avez paramétré dans l’admin (ex : « Vues uniques 1 (Brand) » dans le compte de démo).

Mais comme vous le pensez sûrement, il ne s’agit que de metrics spécifiques à certaines dimensions…Cela ne résout pas notre problème de façon générale, à savoir récupérer n’importe quelle dimension de scope hit dédoublonnée au niveau de la session. Et c’est là que, miracle, il existe une metric magique permettant de répondre exactement à cette problématique. Pour ma part, je l’ai découverte assez récemment, il s’agit de la combinaison de dimensions uniques.

Sans plus attendre, appliquons cette metric providentielle à notre custom report :

Et là, miracle, bonheur, amour, volupté, un petit segment nous permet de bien constater que la combinaison de dimensions uniques fait. son. job.

ça n’a l’air de rien, mais cette metric est en particulier d’une très grande utilité lorsqu’on utilise des custom dimensions de scope hit (ex : auteur d’un article), et que l’on veut savoir le nombre de sessions ayant consulté une page écrite par un auteur donné. A une petite subtilité près.

Sans que j’aie tout à fait réussi à expliquer pourquoi, il semblerait qu’il faille impérativement que la custom dimension soit populée sur l’ensemble des pages. Par exemple, si j’ai un attribut « rubrique » dans le data layer, que je balance dans une CD, mais que ledit attribut n’est pas populé sur l’ensemble des pages (typiquement, me home ou une page de tag), il faut que je force une valeur de type « vide », ce que l’on peut faire très simplement dans ce bon vieux Google Gestionnaire de Balises :

Voilà, j’ai quand même réussi à caser un screenshot de GTM. L’honneur est sauf.

Une fois ceci fait, la metric combinaison de dimensions uniques fait ce qu’on attend d’elle. BIM, vous avez votre réponse, sans avoir besoin de paramétrer un content grouping à chaque fois. Mais de rien.

Voilà, nous pouvons donc apporter la touche finale à notre magnifique matrice :

Pour aller plus loin

Il reste un sujet que je n’ai pas couvert, à savoir le croisement de différentes dimensions / metrics dans les custom reports. Si, typiquement, on utilise deux dimensions de scope session et utilisateur, et que l’on utilise « pages vues » et « sessions » comme metrics, que se passe-t-il? Eh bien, nous aurons sans doute l’occasion d’en parler une autre fois.

Comme d’habitude, c’est à vous de jouer : il est extrêmement probable que certains points soient incomplets, qu’il y ait des sujets à élargir, ou encore que je me sois trompé sur certains cas. Twitter (dézo, j’ai supprimé mon compte Viadeo) sera, comme de coutume, le canal privilégié pour exprimer vos questionnages.