On a mis trois heures à comprendre pourquoi le nombre de visiteurs uniques avait triplé sur la version AMP d’un site e-commerce, alors que Google Analytics affichait un trafic stable. Le coupable n’était pas un bug de Matomo. C’était l’AMP Viewer, ce conteneur que Google plaque par-dessus vos pages quand un utilisateur clique depuis les résultats de recherche mobiles.
Le constat est brutal : vous croyez suivre des visites, vous enregistrez des fragments. Les intégrations officielles amp-analytics pour Matomo donnent l’illusion que tout fonctionne. Le tag se charge, les événements remontent, le tableau de bord se remplit. Sauf que les identifiants de visiteur ne survivent pas au passage d’une page à l’autre. Résultat : vos indicateurs d’engagement sont une fiction statistique.
Et c’est là que le bât blesse. L’écosystème AMP a été pensé pour la vitesse de chargement, pas pour la précision du tracking. Si vous traitez vos pages AMP comme des pages web classiques dans Matomo, vous additionnez des visiteurs uniques qui n’en sont pas, vous écrasez le taux de rebond et vous faussez la durée des sessions. La documentation de Matomo le mentionne à peine. Même Google, lorsqu’il a poussé le format AMP, est resté très discret sur l’impact analytique de son cache et de son viewer.
Le cache AMP n’est pas un hébergeur neutre
Ouvrez une page AMP servie par le cache de Google. La console réseau vous montrera que tous les appels à matomo.php transitent par l’origine cdn.ampproject.org si vous ne configurez pas de proxy. Le navigateur considère alors que votre domaine de suivi est celui d’AMP, pas le vôtre. Les cookies first-party déposés par Matomo sur votresite.com ne sont tout simplement pas envoyés. Pire : le navigateur, par sécurité, bloque le cookie tiers que tenterait d’écrire un pixel hébergé sur un domaine différent.
Ce n’est pas un détail technique que l’on règle en cochant une case. C’est une coupure franche dans l’identité du visiteur. Chaque chargement de page produit un nouveau _pk_id, et Matomo enregistre mécaniquement un visiteur unique supplémentaire. Vous obtenez un ratio pages vues / visiteurs artificiellement bas, et vos indicateurs de fidélité deviennent inexploitables.
Ce comportement est encore accentué par le fait que le cache AMP peut servir une version légèrement différente de votre balisage amp-analytics. Le système de validation AMP impose des règles de syntaxe strictes. Si votre configuration embarque un paramètre exotique ou un séparateur non standard, le tag sera dégradé silencieusement. L’erreur n’apparaîtra pas dans vos logs Matomo. Vous ne verrez qu’un trou dans vos données de provenance, car le référent est réécrit par le cache au lieu de transmettre la page source réelle.
Ces dégradations silencieuses nous rappellent les pièges d’intégration que l’on rencontre lorsqu’on configure un suivi côté client sur des architectures complexes. C’est un problème de state management distribué, aussi vicieux qu’un store Zustand mal hydraté côté serveur dans une application React. L’état du visiteur est perdu entre deux rendus, et ce que vous croyez persistant n’est qu’une illusion maintenue par le client, que le cache AMP vide à chaque rechargement.
Pourquoi le amp-analytics officiel entretient le faux confort
La documentation technique de Matomo propose un exemple standard pour amp-analytics. Il s’appuie sur une requête GET vers votre instance Matomo, avec le idsite et le rec=1. Visuellement, le hit remonte. Les pages vues s’incrémentent. Mais le paramètre cid qui identifie le visiteur n’est jamais géré automatiquement par la librairie AMP. C’est à vous de le générer, de le stocker et de le faire persister.
Or, AMP interdit tout JavaScript personnalisé. La persistance d’un identifiant repose uniquement sur le amp-user-notification ou les cookies locaux du navigateur, inaccessibles depuis le cache. La plupart des intégrations laissées par défaut se contentent d’envoyer un new_visit=1 à chaque appel. Matomo interprète alors chaque hit comme le début d’une nouvelle session. Le taux de rebond enregistré frôle les 100 %. Ce n’est pas votre trafic qui est mauvais, c’est votre instrumentation qui simule un visiteur qui rebondit après une seule page vue.
Les pages AMP ont pourtant un besoin crucial de métriques comportementales fiables, surtout lorsqu’elles représentent une part significative du trafic mobile organique. L’obsession des Core Web Vitals ne doit pas occulter le fait que la performance de chargement et la précision du suivi sont deux faces de la même pièce. Un LCP sous la seconde ne sert à rien si vous ne savez pas ce que l’utilisateur fait ensuite.
Le piège se referme quand vous croisez les données. Matomo vous dit que la page AMP convertit à 0,2 %, là où la version canonique atteint 2,5 %. En réalité, le suivi des objectifs est cassé : le cookie de session qui porte l’identifiant du visiteur ne survit pas au clic sur le CTA si celui-ci ouvre une nouvelle page sur votre site hors cache. La conversion est attribuée à un nouveau visiteur, et la chaîne d’attribution est rompue. Vous pourriez passer des semaines à optimiser une landing page AMP sur la base de données corrompues.
Reconstruire un tracking fiable en passant par le serveur
La seule architecture qui tient la route consiste à sortir le suivi du navigateur pour le ramener dans un environnement que vous contrôlez. Concrètement, vous allez intercaler un proxy entre le tag amp-analytics et votre instance Matomo. Le proxy, hébergé sur votre domaine, reçoit la requête émise par AMP, l’enrichit avec les en-têtes HTTP réels (User-Agent, IP, Referer), génère un identifiant visiteur stable et transmet l’ensemble à Matomo via l’API de tracking.
La mise en place n’est pas magique, mais elle est parfaitement documentée dans les bonnes pratiques d’hébergement de Matomo. Vous devez pointer l’URL de tracking amp-analytics vers https://votresite.com/proxy/matomo.php plutôt que vers l’URL de votre instance Matomo. Le script côté serveur, un simple fichier PHP ou une fonction serverless, va recalculer le _pk_id à partir d’un cookie dédié ou d’une empreinte combinant l’IP et le user agent. Il envoie ensuite une requête classique matomo.php avec tous les paramètres consolidés.
Ce mécanisme a un avantage collatéral considérable : vous contournez les restrictions de cookies tiers imposées par Intelligent Tracking Prevention sur Safari. Même en dehors du cache AMP, le suivi devient plus robuste. Le coût supplémentaire en termes d’infrastructure est modeste. Une Cloudflare Worker ou une fonction Vercel suffit à relayer les hits sans introduire de latence significative.
La configuration du proxy doit impérativement désactiver le cache HTTP pour cette route. Un hit mis en cache serveur serait rejoué à l’identique pour plusieurs visiteurs, ce qui fausserait les visites. On règle cela avec un en-tête Cache-Control: no-store et un contrôle de signature sur la requête. Le travail d’intégration s’apparente à l’assemblage d’une chaîne d’outils où chaque maillon a sa spécificité, un exercice qui rappelle le niveau d’attention requis lorsqu’on compare Claude Code et Cursor IDE : la différence entre un flux fonctionnel et un flux fiable tient souvent à trois lignes de configuration.
L’implémentation du proxy va normaliser les idsite et les action_name. Elle va aussi extraire le vrai referrer fourni par l’en-tête AMP Referer, qui est souvent écrasé lorsqu’on passe par le viewer. Sans cette étape, la source de trafic associée à une visite AMP est enregistrée comme direct ou comme venant de google.com/amp, ce qui rend impossible toute analyse d’acquisition correcte.
Les métriques qui survivent (et celles qu’il faut abandonner)
Toutes les métriques ne se valent pas lorsqu’on parle de trafic AMP. Même avec un proxy correctement configuré, la nature fragmentée de la navigation AMP rend illusoire l’ambition d’avoir des parcours utilisateur aussi précis que sur la version canonique.
Ce qui fonctionne : les pages vues, les événements déclenchés dans la même page (clic sur un bouton, lecture vidéo), le temps passé sur une page isolée. Ces données reposent sur des actions atomiques que le tag amp-analytics peut transmettre sans état. Vous pouvez aussi suivre les conversions directes si le formulaire ou le paiement reste dans l’écosystème AMP ou si vous transmettez un identifiant côté serveur au moment de l’atterrissage post-conversion.
Ce qu’il faut abandonner ou traiter comme une estimation très grossière : la notion de session multi-page, le taux de rebond basé sur deux pages vues, le parcours de navigation de l’utilisateur à travers plusieurs articles AMP. Ces indicateurs resteront structurellement imprécis, parce que l’AMP ne garantit pas la continuité du contexte utilisateur lorsqu’un lien emmène vers une autre page servie par le cache. Plutôt que de déployer des contournements fragiles, mieux vaut basculer votre analyse comportementale sur la version canonique et ne conserver qu’un suivi parcimonieux sur les pages AMP.
Questions fréquentes
Faut-il déployer un proxy même si mon trafic AMP est marginal ?
La question ne se pose pas en volume mais en proportion de trafic non fiable. Dix pour cent de trafic AMP mal mesuré peut suffire à fausser un test A/B ou une décision budgétaire sur un canal d’acquisition. Un proxy léger est rapide à mettre en place et protège l’intégrité de l’ensemble du reporting Matomo.
Puis-je utiliser Google Analytics en parallèle pour corriger les écarts ?
Croiser les outils sans comprendre la divergence des modèles de collecte ne corrige rien. Google Analytics sur AMP utilise lui aussi un mécanisme de client ID qui peut être fragilisé par le cache, même si Google optimise en interne son propre écosystème. Un proxy unique pour Matomo reste la solution la plus transparente.
L’abandon progressif du format AMP par certaines plateformes change-t-il la donne ?
Le retrait du carrousel AMP dans la recherche réduit mécaniquement l’exposition des pages AMP, mais des millions de pages restent indexées et servies. Tant qu’il existe un cache AMP et un viewer Google, le problème de tracking demeure identique. La prudence consiste à maintenir un suivi hybride jusqu’à ce que le format ne génère plus aucun trafic mesurable.
