Built for a live storefront
Monitoring should
never be the incident.
Dozenfold runs on stores that take orders every minute. Here is exactly what the script does to stay out of the way, which traffic it never collects, and what it never records.
- Own requestsNative fetch
- Search-engine rendersNot started
- Headless & automationNot started
- Bots at the collectorDropped
What the script never does to your store.
These are properties of the code, not settings. They hold on Shopify and on custom storefronts.
Our requests skip your wrappers.
Themes and apps often wrap window.fetch to track or retry requests. Dozenfold sends its events, config and replay uploads with the browser’s own fetch, so your wrappers never see our traffic and a bug in one of them cannot loop through us.
Your beacons keep their room.
Browsers allow about 64 KB of keepalive requests per page, shared by every script that reports as the shopper leaves. Dozenfold uses at most 32 KB and 8 requests of it, replay included. Your analytics and ad conversion beacons keep the rest.
Wrappers return your result.
Where Dozenfold observes requests, listeners or timers, it passes your code’s original return value and re-throws your original error. If our bookkeeping fails, your call still completes. window.open always opens the popup.
No events dispatched into your page.
Dozenfold reads consent and page state but never fires DOM events other scripts listen to, such as Shopify’s consent event, so it cannot re-trigger your theme’s or your apps’ handlers.
Replay backs off.
Error-session replay is a separate script that loads only when you turn it on. On a flood of page changes or a collector rate limit, it stops recording for that page or session instead of competing with the shopper for the main thread.
Quiet failure, by design.
Once started, no Dozenfold method throws into your code. If our CDN or collector is unreachable, the storefront behaves exactly as it would without Dozenfold.
Shoppers, not bots.
Googlebot and other search engines render storefronts in a real browser, so they run every script on the page. On one store we measured, a search-engine renderer produced over a fifth of a day’s errors, none of them from a shopper.
Dozenfold does not start in search-engine renderers, headless browsers, browser automation, Lighthouse or synthetic monitors. The collector also drops browser requests whose user agent identifies a known bot.
Never a session. Bot visits do not appear in Sessions, the audience or a funnel.
Never an issue. A crawler’s failed request does not open or inflate an issue.
Never billed. They do not use your plan’s session allowance.
Test with a real browser. Playwright, Puppeteer and headless Chrome runs show nothing on purpose.
What it records, and what it doesn’t.
Anonymous sessions with errors, failed requests, page views, Core Web Vitals, friction patterns and funnel stages, plus coarse context: country from the network edge, device, browser, connection and device-memory bands. Collection follows the visitor’s analytics consent.
Privacy and data collection ↗- No input values or keystrokes
- No fingerprinting or cross-session shopper profile
- No request or response bodies and no auth headers
- No screen recording unless you turn on error-session replay, and then masked, and only around an error
- No shopper-facing UI of any kind
Bring your security questions.
We review integration, consent and access with your team before rollout, and can switch collection off remotely if anything looks wrong.