Si tu as deja ouvert une heatmap Matomo et trouve ta sidebar tronquee, la moitie basse d'une modal manquante, ou des marqueurs de clics qui flottent au-dessus de contenus auxquels ils ne semblent pas appartenir, sache que les clics eux-memes sont corrects. Matomo les a enregistres aux bonnes coordonnees. Ce qui est casse, c'est la capture d'ecran en dessous. Un wrapper quelque part sur la page a overflow: hidden, overflow: auto ou overflow: scroll de defini, et le renderer de Matomo traite tout ce qui depasse le bord visible de ce wrapper comme si ca n'existait pas. La heatmap te montre donc un morceau de la page au lieu de la page que tes visiteurs ont reellement vue.
Le correctif le plus rapide est une extension Chrome gratuite qu'on maintient, Matomo Heatmap Helper. Elle neutralise les conteneurs overflow juste avant chaque capture, laisse le renderer voir l'integralite du document, puis restaure les styles d'origine. La suite de cet article explique comment faire la meme chose sans extension, ainsi que quelques correctifs permanents qui meritent d'etre deployes.
Comment corriger ca sans l'extension
Il y a un snippet de console qui colmate le probleme juste avant chaque capture, et quelques correctifs permanents deployables directement sur le site. Choisis ce qui correspond a tes contraintes.
Lister tous les elements avec overflow restreint sur la page
Avant de toucher quoi que ce soit, identifie les wrappers qui tronquent. Ouvre la page dans Chrome, appuie sur F12 pour ouvrir les DevTools, passe sur la Console et colle :
// Lists every element that's currently clipping content
Array.from(document.querySelectorAll('*')).filter(el => {
const s = getComputedStyle(el);
return ['hidden','auto','scroll'].includes(s.overflow)
|| ['hidden','auto','scroll'].includes(s.overflowY);
});Ca te donne la liste exacte des noeuds que le renderer Matomo va traiter comme des boites de taille fixe. Les suspects habituels : sidebars, modals, wrappers de defilement personnalises autour de <main>, et vieux wrappers clearfix qui portent un overflow: hidden pour des raisons de mise en page qui n'ont plus lieu d'etre depuis des annees.
Le correctif rapide : supprimer les restrictions overflow depuis la console
C'est le snippet qu'on colle dans la console du navigateur juste avant de declencher la capture heatmap de Matomo. Il parcourt tous les elements qui tronquent actuellement et passe leur overflow et overflow-y a visible. Le temps que Matomo serialise le DOM, rien ne se cache au-dela d'un bord visible.
// Paste into the browser console right before capture.
// Turns every overflow container on the page into 'visible'.
document.querySelectorAll('*').forEach(el => {
const s = getComputedStyle(el);
if (['hidden','auto','scroll'].includes(s.overflow) ||
['hidden','auto','scroll'].includes(s.overflowY)) {
el.style.overflow = 'visible';
el.style.overflowY = 'visible';
}
});La page va avoir l'air bizarre pendant un moment. Les sidebars s'etendent a leur hauteur de contenu complete, les modals debordent du viewport, et tout ce qui dependait d'un conteneur de hauteur fixe n'en a soudainement plus un. C'est normal. Tu es en train de capturer la heatmap, pas de naviguer sur le site. Rafraichis quand tu as fini.
C'est le chemin rapide. Ca marche pour les captures ponctuelles et les cycles de revue ou tu as besoin d'une capture propre maintenant sans attendre une modification de code. Pour tout ce que tu vas recapturer regulierement, deploie l'un des correctifs permanents ci-dessous.
Correctif CSS permanent scope au mode capture
La reponse la plus propre quand tu controles la feuille de styles, c'est un override reserve a la heatmap qui desactive chaque conteneur overflow des que le tracker Matomo est charge. Un bloc CSS, une ligne JS, et c'est regle.
/* Edit the selectors to match the wrappers on your site */
html.heatmap-mode .sidebar,
html.heatmap-mode main,
html.heatmap-mode .modal-shell {
overflow: visible !important;
overflow-y: visible !important;
height: auto !important;
max-height: none !important;
}// Add to your site. Flips the class on whenever Matomo's tracker is on the page.
if (window._paq) document.documentElement.classList.add('heatmap-mode');L'override ne s'active que sur les pages ou Matomo se charge de toute facon, ce qui convient parfaitement pour une revue heatmap et reste invisible pour le reste de ton trafic. Si tu preferes un perimetre plus etroit, conditionne-le a un parametre de requete (?heatmap=1) ou a une feuille de styles separee incluse uniquement sur la copie staging que tu pointes vers Matomo.
Supprimer purement et simplement le conteneur de defilement imbrique
Si ta page a un overflow: auto sur <main> ou un autre wrapper pour des raisons de "scrollytelling", le correctif architectural est de le supprimer et de laisser le document defiler. Le renderer de Matomo peut reproduire le defilement de document, il ne peut pas reproduire la position de defilement d'un conteneur imbrique. Tu en tires aussi une meilleure UX mobile (iOS Safari a ses propres opinions sur les conteneurs de defilement imbriques) et l'accessibilite s'ameliore parce que le defilement au clavier et la navigation par lecteur d'ecran commencent a fonctionner comme les utilisateurs s'y attendent.
C'est une modification plus importante que l'override CSS, mais c'est celle qui empeche le probleme de revenir la prochaine fois que quelqu'un ajoute une nouvelle section a la mise en page.
Remplacer overflow: hidden de clearfix par display: flow-root
Les vieux wrappers clearfix avec overflow: hidden etaient un contournement pour contenir des enfants en float. display: flow-root fait la meme chose sans rien tronquer, et c'est utilisable en toute securite sur tous les navigateurs qui comptent depuis 2018.
/* Edit the selector to match your clearfix wrapper */
.row-with-floats {
display: flow-root;
}Meme comportement de confinement, aucun tronquage, et tu arretes de te battre avec la capture d'ecran. Le moyen le plus rapide de trouver des candidats, c'est de grep-er ton CSS pour overflow: hidden et de verifier si chacun est reellement cense tronquer quelque chose. La plupart du temps, non.
Une note sur le compromis
Quel que soit le correctif permanent que tu choisis, scope l'override (une classe, un parametre de requete, une feuille de styles reserve a la heatmap) plutot que de changer les styles en production pour tout le monde. Tes visiteurs voient la mise en page que tu as concue pour eux, et la modal qui est censee defiler dans sa propre boite doit continuer a le faire pour eux. L'override n'a besoin d'exister que pour le renderer que Matomo pointe vers la page.
Pourquoi Matomo ne peut pas rendre tes conteneurs overflow
La capture d'ecran de Matomo est un processus en deux etapes. D'abord, le tracker serialise ton DOM en direct en HTML et l'envoie. Ensuite, ton serveur Matomo re-rend ce HTML a un viewport fixe pour produire la capture que tu vois dans la vue heatmap. Pas de session navigateur, pas de position de defilement heritee de ton visiteur, pas d'ajustements de mise en page pilotes par JS. Juste un fichier HTML rendu a froid depuis une IP differente.
Le renderer peut reproduire le defilement de document, c'est pourquoi les pages longues se capturent bien. Ce qu'il ne peut pas reproduire, c'est la position de defilement interne d'un conteneur overflow: auto imbrique, parce que ca vit dans le navigateur du visiteur et ne passe jamais dans le DOM serialise. Quand le renderer tombe sur un wrapper overflow: hidden, il fait ce que fait n'importe quel navigateur et tronque. Le resultat est une capture qui ressemble au morceau visible de la page a un instant precis, tout le reste ayant disparu.
Les coordonnees des clics aggravent les choses. Matomo enregistre les clics par rapport au document, pas par rapport a la position de defilement interne du conteneur que l'utilisateur faisait defiler. Un clic sur le troisieme element d'une sidebar avec defilement est stocke a la coordonnee y qu'il occupait au moment du clic. Quand le renderer capture la sidebar a scroll-top zero, cette coordonnee y appartient maintenant au premier element. Le marqueur se place la. Le clic a l'air d'avoir atterri sur le mauvais lien.
Ce qui echoue vraiment
Quelques patterns qu'on croise en boucle :
- Les sidebars et modals avec leurs propres barres de defilement. Le wrapper a une hauteur fixe et
overflow: auto, la liste interieure est plus haute, et seule la partie visible au moment de la capture passe dans la capture. - Les pages "scrollytelling" avec
overflow: autosur<main>ou un wrapper similaire. Le body ne defile pas, l'element interieur oui, et la heatmap capture l'equivalent d'un viewport de contenu. - Les vieux wrappers clearfix avec
overflow: hiddenqui ne sont pas censes tronquer quoi que ce soit. Ils etaient la pour contenir des floats. Ils tronquent toujours, et ils continuent a faire disparaitre du contenu de la capture. - Les menus deroulants personnalises ou les accordeons qui s'animent en tronquant leur contenu avec
overflow: hiddenplus une transition de hauteur. C'est l'etat ferme que Matomo voit. - CSS
maskouclip-pathsur un conteneur. Propriete differente, meme effet sur la capture. Le correctif est le meme : desactive-les en mode capture.
Si ta heatmap manque de contenu ou que les marqueurs de clics ne s'alignent pas avec les elements auxquels tu t'attendrais, tu tombes sur au moins l'un d'eux. Souvent plus d'un sur la meme page.
C'est aussi la meme famille de probleme qui casse les polices, les images et les en-tetes sticky dans la meme capture. On a ecrit un article plus long sur les captures heatmaps Matomo cassees qui passe en revue le reste, et des articles separes sur pourquoi les polices ne se chargent pas et pourquoi les images ne se chargent pas vu que ce sont des cas presque aussi frequents.
Ce qu'on ferait vraiment
Si tu controles la feuille de styles, deploie l'override reserve a la heatmap. Un bloc CSS scope a une classe que tu actives quand le tracker Matomo est charge. C'est le plus petit diff qui resout le probleme definitivement et ca ne touche pas a ce que les visiteurs voient.
Si la mise en page a un conteneur de defilement imbrique qui te posait deja des problemes pour d'autres raisons, prends le correctif architectural et laisse le document defiler. Tu t'epargnes ce probleme sur chaque future capture heatmap, et tes utilisateurs mobiles t'en remercieront.
Si aucune des deux options n'est atteignable (pas d'acces a la feuille de styles, widgets tiers que tu ne peux pas re-styler, CMS qui ne te permet pas de deployer du CSS personnalise), l'extension Chrome Matomo Heatmap Helper est ce qu'on utilise sur les sites clients ou on ne peut pas toucher a la stack. Elle parcourt les memes conteneurs overflow que le snippet trouve, les neutralise pour la capture, puis les restaure apres, de sorte que la page est intacte pour le visiteur suivant. Gratuite, open source, code sur GitHub.
Martez est le projet plus large dont est issue l'extension. Il connecte Matomo avec Meta Ads et Google Ads pour que le ROAS, la CLV et l'attribution se retrouvent a cote de tes analytics web plutot que dans un tableur separe. Il est en beta privee. Rejoins la liste d'attente si ca te parle.
La plupart du temps, c'est a une modification de feuille de styles pres. Ca vaut le coup de le faire une bonne fois.