Troubleshooting

The most common situations, from symptom to cause. The platform's golden rule: collection never returns a visible error to your visitors; rejections are silent on the page side, but always diagnosable here.

No data is showing up

In order:

1. The key. Does the data-site (or the SDK/plugin key) exactly match the key from the installation screen? An unknown key → silent 403.
2. Is the script loading? Browser Network tab: qm.js returning 200, then a POST …/collect returning 202 when you navigate. No request at all? Check defer, the script inclusion and window.__qmDisable.
3. CSP. A strict Content-Security-Policy blocks the load or the POST; see the script-src / connect-src directives in Installation.
4. Self-exclusion. You enabled owner self-exclusion, checked your role in the WordPress plugin, or set the opt-out marker by visiting the site with ?qm_ignore=1: your own visits don't count. Test in private browsing or from another device, and see the next section.
5. The installation screen checks reception live: keep it open during the test.

I don't see myself in my own statistics

Your own visits can be filtered out by three distinct mechanisms, none of which announces itself:

1. The opt-out marker. You loaded a page of the site with ?qm_ignore=1: this browser is no longer counted on this site, for five years. Reload any page with ?qm_ignore=0, from the same browser, to come back into measurement. Since the marker is never transmitted, the platform does not know it exists: it cannot warn you, and you are the only one who can remove it.
2. Owner self-exclusion enabled in the dashboard, or your role checked in the WordPress plugin.
3. window.__qmDisable = true set by an extension, a staging environment or the console.

If none of the three applies, the cause is elsewhere: go back through the list above, where a missing or wrong key remains the most common one.

My numbers differ from Google Analytics

That's expected. The definitions differ, in both directions:

• You may see more: server-side tracking reduces the effect of ad blockers and loading rules may differ from GA; only compare scopes subject to the same consent choices.
• You'll see less: known bots are filtered out; visitors from the same household/office behind the same IP and the same browser merge.
• Multi-day uniques are overestimated: without a persistent identifier (that's the point), a visitor who returns on another day counts again. Accurate per day, standard for the category.
• Sessions expire after 30 minutes of inactivity, and the duration of a session's last page is unknown.

Full details: the public "How we count" page.

The hit is rejected (network diagnostics)

The endpoint always responds, but the status tells you why a hit doesn't count:

The p.gif pixel always responds 200; its actual status is in the X-QM-Status header.

Invalid signature in signed mode

The HMAC signature is rejected if the timestamp drifts more than ±5 minutes (anti-replay). Cause #1: the clock of the sending server (container, frozen VM). Synchronize via NTP. Also check that the secret key in use is the one for the right site, and regenerate it if it has leaked.

Trial expired or quota exceeded

• Trial expired: hits are accepted (202) but counted as dropped, visible as such in the dashboard, not in your statistics. Move to a plan to resume counting.
• Monthly quota: grace zone up to ×1.2 of the plan, alert emails at 80% and 100%. Beyond the grace zone, nothing is silently lost in the current month: the limit is only activated after two consecutive months of overage, it is announced, and hits that stop being analysed are still counted and shown.

Duplicates or extra page views

• Script included twice (layout + bundler): harmless, the tracker locks itself (window.__qmLoaded).
• SPA: navigating to the same URL doesn't emit a duplicate; pushState tracking can be disabled with data-spa="false".
• WordPress "both" mode: identical page views received less than 2 s apart are deduplicated on the service side.
• Real reloads (F5): these are legitimate page views; GA counts them too.

An event doesn't appear in conversions

An event-type goal matches the exact name (purchase ≠ Purchase). A page-type goal matches the path with wildcards (/thank-you, /docs/*). Also check the limits: name ≤ 120 characters, ≤ 30 properties; beyond that, truncated.

The event itself appears in the Events panel from the first send; the conversion only appears if the goal exists (create it before your test, or re-test after creating it).

Dev or staging traffic in the stats

Four safeguards, which can be combined: a separate key for staging (or no key at all: without a key, nothing is sent), excluded paths in the site settings, window.__qmDisable = true set by the environment, and the opt-out marker set once per browser (?qm_ignore=1). On the WordPress side, administrator/editor roles are excluded by default.