Dépannage

Les situations les plus fréquentes, du symptôme à la cause. Règle d'or de la plateforme : la collecte ne renvoie jamais d'erreur visible à vos visiteurs : les refus sont silencieux côté page, mais toujours diagnosticables ici.

Aucune donnée n'apparaît

Dans l'ordre :

1. La clé. Le data-site (ou la clé du SDK/plugin) correspond-il exactement à la clé de l'écran d'installation ? Une clé inconnue → 403 silencieux.
2. Le script se charge-t-il ? Onglet Réseau du navigateur : qm.js en 200, puis un POST …/collect en 202 quand vous naviguez. Pas de requête du tout ? Vérifiez defer, l'inclusion du script et window.__qmDisable.
3. CSP. Une Content-Security-Policy stricte bloque le chargement ou le POST : voir les directives script-src / connect-src dans Installation.
4. Auto-exclusion. Vous avez activé l'auto-exclusion propriétaire, coché votre rôle dans le plugin WordPress, ou posé le marqueur d'exclusion en visitant le site avec ?qm_ignore=1 : vos propres visites ne comptent pas ; testez en navigation privée ou depuis un autre appareil, et voyez la section suivante.
5. L'écran d'installation vérifie la réception en direct : gardez-le ouvert pendant le test.

Je ne me vois pas dans mes statistiques

Vos propres visites peuvent être écartées par trois mécanismes distincts, dont aucun ne s'annonce :

1. Le marqueur d'exclusion. Vous avez chargé une page du site avec ?qm_ignore=1 : ce navigateur n'est plus compté sur ce site, pendant cinq ans. Rechargez n'importe quelle page avec ?qm_ignore=0, depuis le même navigateur, pour revenir dans la mesure. Le marqueur n'étant jamais transmis, la plateforme ignore qu'il existe : elle ne peut pas vous le signaler, et vous seul pouvez le retirer.
2. L'auto-exclusion propriétaire activée dans l'espace membre, ou votre rôle coché dans le plugin WordPress.
3. window.__qmDisable = true posé par une extension, un environnement de préproduction ou la console.

Si aucun des trois ne s'applique, la cause est ailleurs : reprenez la liste ci-dessus, où une clé absente ou fausse reste la plus fréquente.

Mes chiffres diffèrent de Google Analytics

C'est attendu, car les définitions diffèrent, dans les deux sens :

• Vous pouvez voir plus : le suivi serveur limite l'effet des adblockers et les règles de déclenchement peuvent différer de celles de GA ; comparez uniquement des périmètres soumis aux mêmes choix de consentement.
• Vous verrez moins : les robots sont écartés, y compris ceux qui se font passer pour un navigateur ordinaire (un vrai navigateur annonce toujours sa langue, un robot qui recopie son identité l'oublie presque toujours) ; les visiteurs d'un même foyer ou bureau derrière une même IP et un même navigateur fusionnent.
• Les uniques multi-jours sont surestimés : sans identifiant persistant (c'est le principe), un visiteur qui revient un autre jour compte à nouveau. Exact à la journée, standard de la catégorie.
• Les sessions expirent après 30 minutes d'inactivité, et la durée de la dernière page d'une session est inconnue.

Détail complet : la page publique « Comment nous comptons ».

L'envoi est refusé (diagnostic réseau)

Le endpoint répond toujours, mais le statut dit pourquoi un envoi ne compte pas :

Le pixel p.gif répond toujours 200 ; son statut réel est dans l'en-tête X-QM-Status.

Signature invalide en mode signé

La signature HMAC est rejetée si l'horodatage s'écarte de plus de ±5 minutes (anti-rejeu). Cause n° 1 : l'horloge du serveur qui envoie (conteneur, VM figée). Synchronisez via NTP. Vérifiez aussi que la clé secrète utilisée est bien celle du bon site, et régénérez-la si elle a fuité.

Essai expiré ou quota dépassé

• Essai expiré : les envois sont acceptés (202) mais comptés dropped : visibles comme tels dans l'espace membre, pas dans vos statistiques. Passez sur un plan pour reprendre le comptage.
• Quota mensuel : zone de grâce jusqu'à ×1,2 du plan, e-mails d'alerte à 80 % et 100 %. Au-delà de la grâce, rien n'est perdu en silence le mois courant : la limitation n'est activée qu'après deux mois consécutifs de dépassement, elle est annoncée, et les événements qui cessent d'être analysés restent comptés et affichés.

Doublons ou pages vues en trop

• Script inclus deux fois (layout + bundler) : sans conséquence, le tracker se verrouille (window.__qmLoaded).
• SPA : une navigation vers la même URL n'émet pas de doublon ; le suivi pushState se désactive avec data-spa="false".
• WordPress mode « les deux » : les pages vues identiques reçues à moins de 2 s d'écart sont dédupliquées côté service.
• Rechargements réels (F5) : ce sont des pages vues légitimes (GA les compte aussi).

Un événement n'apparaît pas dans les conversions

Un objectif de type événement matche le nom exact (achat ≠ Achat). Un objectif de type page matche le chemin avec jokers (/merci, /docs/*). Vérifiez aussi les limites : nom ≤ 120 caractères, ≤ 30 propriétés ; au-delà, tronqué.

L'événement lui-même apparaît dans le panneau Événements dès le premier envoi ; la conversion n'apparaît que si l'objectif existe (créez-le avant votre test, ou re-testez après création).

Trafic de dev ou de staging dans les stats

Quatre parades, cumulables : une clé séparée pour le staging (ou aucune clé : sans clé, rien ne part), les chemins exclus dans les réglages du site, window.__qmDisable = true posé par l'environnement, et le marqueur d'exclusion posé une fois par navigateur (?qm_ignore=1). Côté WordPress, les rôles administrateurs/éditeurs sont exclus par défaut.

Lire le tableau de bord

Le bandeau temps réel est compact, avec un accès à son écran détaillé. Les visiteurs, pages vues et sessions gardent leurs mini-courbes ; le rebond, la durée et les événements utilisent les mêmes cartes Filament, avec un fond, un contour et une typographie identiques. La courbe d’audience apparaît avant le diagnostic de collecte.

Les nombres de rejets enregistrés et d’envois hors quota restent visibles lorsque le diagnostic est replié. Seul le dépassement de quota reçoit une couleur d’attention : un filtrage normal n’est pas présenté comme un incident.

Une répartition avec une seule catégorie affiche son libellé, 100 % et son volume, sans grand anneau. Les graphiques restent présents dès que plusieurs catégories sont représentées.

Les 404 à corriger

Le tableau « Pages introuvables (404) » présente les dix chemins les plus signalés, leurs occurrences et l’écart en nombre d’événements par rapport à la période précédente. Il suit la période et les filtres du tableau de bord ; couper la comparaison masque les écarts.

Il lit les événements nommés 404, regroupés par le chemin normalisé de leur URL, dans l’historique conservé. Une absence de résultat ne garantit pas l’absence d’erreur : le suivi doit être activé, et les données purgées ne sont pas reconstituées. « Nouveau » indique une base précédente sans événement conservé.

Pour alimenter ce tableau, choisissez une seule méthode sur chaque page d’erreur :

• Laravel : QUIET_METRICS_TRACK_404=true avec le pont 0.4.0.
• Symfony : track_404: true avec le bundle 0.4.0.
• WordPress : activer « Pages introuvables » en mode serveur, à partir de 0.4.0.
• Script JavaScript : data-404="true" sur le script du gabarit 404 uniquement.

L’événement s’ajoute à la page vue et utilise le quota. Une page HTML 404 peut être comptée comme page vue sans apparaître dans ce tableau si l’événement distinct n’est pas activé. Le chemin provient de l’URL de l’événement, pas de sa propriété personnalisée path.