Reference8 min read

Troubleshooting

Find the symptom that matches, then work down the checks in order. They are ordered by how often they turn out to be the cause.

#No data at all

Confirm the script tag is present and its data-site matches your actual site id. See verify your install.
Open the browser console and Network tab: a CSP blocking the script, or a 404 on it, means nothing ever loaded.
If you're testing from localhost or a staging domain that isn't your site's configured domain, events are silently discarded with reason origin-mismatch. This is the most common cause of "it works in prod but not in dev."
An ad blocker can block a directly-embedded mrkr.app script on some blocklists. If that's a concern, the managed proxy serves the tracker from your own domain instead.

Check whether the tool you're comparing against filters bots at all, or with a different list. See accuracy.
Check your excluded-paths patterns for anything broader than intended. A pattern like /* excludes the entire site, not just one section.
If your workspace is grandfathered onto the retired free plan, exceeding its monthly quota doesn't error: it silently stops recording new events for the rest of the billing period. Check usage in Settings. Current plans meter overage instead of blocking, so this cannot happen on them.

On a cookieless site, visitor counts over a multi-day range are expected to run higher than the same population would show in cookie mode. See the cookieless-vs-cookie section of accuracy.
Check for a built-in outbound or download event firing alongside a manually instrumented data-mrkr-event element or a manual track() call on the same link. See the double-counting section of accuracy.

Check the name isn't one of the five retired autocapture names (click_link, click_button, submit_form, select_change, toggle_change). Those are refused at ingest and are never stored at all.
Check the name isn't one of the structural internal names (pageview, page_leave, scroll, engaged_time, signup, purchase, goal, revenue, outbound, file). Those are stored, but they don't register a new entry in the Events catalog under your name: they're already accounted for by the built-in rows.
Confirm the tracker had a chance to flush. Events are queued and sent about a second after they fire, or immediately when the tab is hidden or closed. A track() call followed instantly by location.href = … in the same tick still goes out, because the pagehide flush uses sendBeacon, but a call made after the page has already unloaded is lost.
Confirm property keys use only letters, numbers, _, ., :, -. Anything else is dropped without an error, so a typo'd key just silently disappears from the payload.
The event itself is stored on first sight regardless; only its appearance in pickers and the catalog can lag up to 5 minutes behind, since new-event discovery is cached.

Confirm replay is enabled and the sample rate is above 0 in Settings. The tracker only learns this from the server's reply to the first pageview of a page load. If you enable replay while a tab is already open, that tab won't start recording until it reloads.
Sampling is a coin flip per page load. A low sample rate can look identical to "broken", and on a multi-page site it can also record one page of a visit and not the next, so check the configured rate before assuming a fault.
Check the console for [mrkr] replay capture unavailable: failed to load …. That means the replay script itself couldn't load, usually a CSP block or network error.
Input masking is on by default and intentionally never records typed free-text values. That is expected behaviour, not a bug.

Check the conversion window is long enough for the real behaviour. It defaults to 14 days if unset, which is too short for some sales cycles and too long for others.
If you're using strict order mode, remember it only disqualifies a visitor who triggers *another funnel step* out of order, not any event, but that is still easy to trip accidentally. Try sequential mode first.
Check the step's match type (exact / contains / prefix / regex) against what's actually being sent. An exact match on a path fails silently if the real path carries a query string or a trailing slash the step didn't account for.
Confirm your selected date range actually covers when the behaviour happened. The funnel only reads events inside the selected range.

Realtime is not backfilled from history. If nobody has produced an event in the last 5 minutes, the correct and honest answer is that nobody is currently on the site.
The same origin/domain-mismatch causes as "no data at all" apply here too, since realtime rides the same ingest gate as every other write.