Debug Mouseflow in Chrome DevTools

What Mouseflow traffic looks like

Mouseflow uses two hosts and nothing else, which makes it one of the easier replay tools to read on the wire. The website id sits in the tag URL, so identifying which Mouseflow account a page belongs to takes one look.

Endpoint pattern

The tag loads from cdn.mouseflow.com, typically as projects/<website-id>.js; recording and behaviour data are ingested at o2.mouseflow.com

Transport

Script load followed by a continuous stream of ingest requests carrying page structure, pointer movement, scrolling, and form interaction for as long as the session is recorded

Client API

The _mfq queue, pushed to for custom variables, tags, and manual page-view signals in single-page applications

Cookies

Mouseflow's own mf_* cookies, carrying the visitor and session identifiers, appear in the Cookies section of any Mouseflow event

The two hosts, and what each one means when it appears:

cdn.mouseflow.com/projects/<website-id>.js   tag loaded, account identified
o2.mouseflow.com                              session being recorded

Debugging Mouseflow with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Mouseflow, badged with the Session Replay category, and shown with parsed query and body parameters plus cookies set and sent.
• The website id in the tag URL is the fastest confirmation of which Mouseflow account a page reports to. Two ids in one session means two tags.
• Ingest traffic to o2.mouseflow.com is the signal that recording is actually happening. A tag that loads without any ingest traffic is a sampling or configuration question, not a deployment one.
• Single-page applications are where Mouseflow most often goes wrong, because page changes have to be signalled through _mfq rather than detected. Grouping the stream by Page shows whether Mouseflow's idea of the page boundaries matches the site's.
• Script Tree attributes the tag to the site's template, a tag manager, or another script.

Mouseflow and consent

Event Watcher checks Mouseflow against the analytics consent category.

Mouseflow's distinguishing feature is form analytics: field-level timing, which field a visitor abandoned, how long each one took. That is more intrusive than a heatmap by design, and it means the tool is observing interaction with exactly the inputs most likely to contain personal data. Field content should be excluded by configuration, but that is a setting rather than a default, and the setting is not visible from the outside. What you can verify here is the timing: that no o2.mouseflow.com ingest exists before analytics consent, on forms as well as on ordinary pages.

Common debugging scenarios

• No recordings appear. Check for o2.mouseflow.com traffic. A tag load on its own means recording did not start, commonly due to the recording quota or sampling rate.
• Recordings stop partway through a single-page app. Mouseflow needs the virtual page change pushed to _mfq. Group by Page to see where its page boundaries actually fall.
• The wrong website id is reporting. Read the id from the cdn.mouseflow.com tag URL.
• Form analytics show nothing. Confirm ingest traffic continues while the form is being filled, rather than stopping at page load.
• Mouseflow fires before consent. Filter to Mouseflow and read the consent verdict on the first ingest request.