Mieux mesurer la résolution d'écran avec GTM

Arrêtez de prendre de mauvaises résolutions

Mesurer la résolution d’écran dans un outil de webanalytics, c’est bien. Mesurer la résolution d’écran dans un outil de webanalytics, c’est utile. Mesurer la résolution d’écran dans un outil de webanalytics, ça permet notamment d’expliquer à vos designers d’agence de pub sous amphètes que l’entièreté du monde n’utilise pas un iMac Retina de 16K et qu’il était possiblement un peu présomptueux de leur part de faire de maquettes de 19663 pixels de large (le responsive, c’est pour les pauvres).

Prenons un exemple, que vous avez sans doute déjà croisé au hasard de vos pérégrinations dans Google Analytics ou outil équivalent :

Nous sommes bien d’accord, cette résolution de 390x844 pixels, digne du Blackberry de votre DAF, ne peut pas raisonnablement être celle d’un iPhone décent datant d’il y a moins de 10 ans : il suffit de se rendre sur le site du constructeur pour voir que l’iPhone 16 plafonne à 2 556 x 1 179 pixels, soit pas loin de l’équivalent de la résolution de l’énorme TV de 65 pouces sur laquelle vous regardez Top Chef chaque semaine.

Donc, concrètement, il se passe quoi ? Eh bien il se passe que GA vous ment. Enfin, vous ment un peu. Ce qui se passe, c’est que GA mesure la résolution en faisant quelque chose comme ceci, que vous pouvez tout à fait vous amuser à taper dans les Chrome Dev Tools :

const logicalWidth = window.screen.width;
const logicalHeight = window.screen.height;
console.log(logicalWidth+'x'+logicalHeight);

Mais l’information qu’il nous manque, et dont GA ne tient pas compte, c’est le devicePixelRatio. Que vous pouvez tout à fait obtenir de la même façon, dans votre console :

window.devicePixelRatio

En l’occurrence et pour la petite histoire, sur la machine de guerre qui me sert à écrire cet article, le Device Pixel Ratio est de 1.25, pour la bonne et simple raison que j’ai un écran 4K de 48 pouces, que j’ai réglé avec un mise à l’échelle de 125%, ce que je trouve plus lisible :

Mais pourquoi je vous raconte ma vie à ce point ? Eh bien parce qu’en réalité, la plupart des smartphones font exactement la même chose, mais par défaut. Et pour reprendre l’exemple des iPhone récents, ils ont un device pixel ratio qui est en général autour de 3.

Nous allons donc parler de Résolution logique pour ce que mesure GA, et de Résolution physique lorsqu’on ajoute la notion de device pixel ratio.

On s’enjaille dans GTM

Maintenant, vous vous en doutez, je ne vous raconte pas ça pour le simple plaisir de flex mes connaissances en CSS (c’est faux, je n’ai jamais rien capté à ce langage de l’enfer), mais parce qu’il va bien sûr être intéressant de collecter ceci.

La variable côté GTM est d’une simplicité enfantine :

On vient garer ceci dans notre Gtag préféré (ou dans une variable de conf) :

On s’ambiance dans BQ

Et en tant que chad data analyst alpha on s’en va directement vérifier les remontées dans la table intraday de BQ (rappel : l’interface de GA4 n’existe pas)

SELECT
  (SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'physical_resolution') AS physical_resolution,
FROM
  `ga-might-and-metrics.analytics_486264732.events_intraday_20250602`
  -- Vous me ferez bien évidemment le plaisir de changer le nom de la table pour l'adapter à votre projet BQ, merci de votre compréhension
ORDER BY
  event_timestamp desc
LIMIT 1000

Et d’ailleurs, pour être tout à fait honnête avec vous, je me suis rendu compte en écrivant cet article que la résolution d’écran (la vraie. Enfin la fausse. Enfin celle qu’on a dans GA quoi) n’était tout simplement pas remontée dans BQ. Alors j’imagine que cela est dû aux habituelles raisons CNILesques (rappel : collecter la résolution d’écran de vos utilisateurs peut faire intervenir la CIA, le KGB, et Justin Bridou dans le cadre d’une intervention armée au domicile de vos utilisateurs, source webinar privé CNIL x Geste), mais j’ai envie de dire YOLO, profitons de ce moment d’allégresse pour collecter également la résolution d’écran dans un paramètre de GTAG que l’on viendra gentiment UNNESTer d’une façon similaire.

function(){
 return window.screen.width + "x" + window.screen.height
}

Je vous fais grâce du branchement dans GTAG, et du screenshot dans BQ, vous êtes de grandes personnes, vous y arriverez, j’en suis sûr.

Variations

Comme vous avez pu le voir, il n’y a franchement rien de compliqué dans ce setup, et il y a une vraie utilité, en termes d’UX, à réellement connaître le nombre de pixels disponibles sur les devices de vos visiteurs pour leur vendre vos produits chinés avec amour sur Aliexpress.

Mais tant que nous sommes dans la thématique, allons résolument (vous l’avez ? Vous l’avez ?) creuser le sujet, parce qu’il y a finalement pas mal de choses nous permettant de pousser l’idée un peu plus loin, toujours sur ces questions de trucs liés à la résolution :

Le pourcentage visible

Toi aussi, tu as passé 6 heures consécutives à assister à un copil avec ta direction, pour décider quelle allait être la taille du logo “Instagram” dans la barre du footer ? Grâce à tonton Aristide, humilie ton boss et ton graphiste en direct grâce à 2 variables Javascript 🚀🚀

La variable document.body.scrollHeight remonte la hauteur totale de la page, tandis que window.innerHeight remonte la hauteur totale du viewport. Vous le voyez venir ? Sur un principe similaire à ce que nous avons vu ci-dessus, on peut tout à fait mesurer le pourcentage de page visible par l’utilisateur, en faisant le ratio à la volée ou bien via BQ :

function(){
 return window.innerHeight / document.body.scrollHeight
}

Évidemment, cela viendra en complément des astucieuses mesures de scroll et de visibilité que vous ne manquerez pas de mettre en place, j’en suis convaincu, mais on ne renie pas ce genre de petit plaisir (ou alors on prend ContentSquare et on a le même genre de réponse, mais pour 80 000€ par an)

Portrait ou paysage (dans BQ ?)

Tant qu’on y est, et plus pour votre culture générale, parlons de la variable JS ‘window.screen.orientation.type’, qui peut vous renvoyer un tas de choses intéressantes, notamment portrait-primary, ou encore landscape-primary. Même si on peut partir du principe que vos utilisateurs utilisent leur smartphone en mode portrait, et leur ordinateur en mode paysage, cela peut être utile d’avoir une idée de la proportion d’utilisateurs qui ne suivent pas la “norme” (surtout en smartphone, mais également en desktop, si jamais vous avez un public de devs avec un écran vertical, qui sommes-nous pour juger ?)

Pour la petite histoire, vous pouvez aussi vous retrouver avec des choses comme landscape-secondary, à savoir un device tenu à l’envers, ce qui peut éventuellement servir si vous voulez tracker la part d’utilisateurs sous l’emprise de substances illicites (j’ai envie de dire pourquoi pas).

Le zoom

Continuons avec une spéciale dédicace pour les boomers qui n’ont jamais réussi à avoir un RDV chez l’ophtalmo, et qui doivent utiliser un zoom de l’espace pour être capable de lire leur site d’actualité préféré : le ratio window.outerWidth / window.innerWidth va tout simplement remonter le niveau de zoom utilisé par l’utilisateur.

Cela n’a l’air de rien, mais beaucoup de layouts CSS peuvent se comporter de façon extrêmement étrange, pour peu que l’utilisateur s’amuse à zoomer de simplement 10%.

Remonter les breakpoints

Enfin, finissons avec un petit biscuit qui n’est pas anodin. Il est possible que vous utilisiez une librairie CSS comme Tailwind, Bootstrap, ou bien quelque chose de custom, qui utilise des viewports précis.

Prenons par exemple ce que dit la doc de Bootstrap pour ce qui est des breakpoints.

Eh bien

function() {
  var w = window.innerWidth;

  if (w < 576) {
    return "Extra small (<576px)";
  } else if (w < 768) {
    return "Small (≥576px)";
  } else if (w < 992) {
    return "Medium (≥768px)";
  } else if (w < 1200) {
    return "Large (≥992px)";
  } else if (w < 1400) {
    return "Extra large (≥1200px)";
  } else {
    return "Extra extra large (≥1400px)";
  }
}

La totale dans Gtag

Et voilà, si vous avez pris le menu entrée / plat / dessert / digestif / 2 cafés l’addition, vous devriez vous retrouvez avec un Gtag (ou une variable “Paramètres d’événement”) qui ressemble à ceci

Et dans BQ, nous retrouvons l’habituelle smoothitude de ces paramètres :

Bien évidemment, est ce que je conseille de collecter systématiquement tout ceci ? Bien sûr que non, je pense qu’il s’agit typiquement de petits trucs et astuces, qui peuvent dépanner et aider à prendre une décision éclairée de design (oui je sais c’est un oxymore mais l’espoir fait vivre). Et bien sûr, il y a bien d’autres choses à faire avec ces variables, l’imagination (et MDN) est votre limite.