An analytics integration can load successfully while still reporting the wrong journey. To make our Next.js guidance easier to verify, we tested one production-built App Router fixture with the Databuddy tracker enabled and disabled, then deliberately interrupted delivery.
In the final configured batch, all ten enabled journeys delivered one initial pageview and one client-route pageview to a local synthetic collector. All ten baseline journeys delivered zero tracker pageviews. A separate interruption test recovered both views after the collector became available again. These results establish behavior in this fixture, not a capture rate for real visitors or proof of hosted report visibility.
Download the evidence and reproduce the journey
The source and results archive includes the fixture, lockfile, protocol, per-run JSON, summary CSV, pinned tracker artifact, and the earlier failed setup batches. Databuddy conducted this check; it is not an independent review or a comparison with other vendors.
The fixture uses Next.js 16.4.2, React 19.3.1, and Databuddy SDK 3.3.0. It runs a production build, loads a home page, follows a Next.js link to a plans page, and records requests received by the local collector. The final configuration sets the tracker queue timeout to 250 milliseconds and waits 1.5 seconds after each navigation.
| Condition | Journeys | Observed local pageviews | JavaScript exceptions |
|---|---|---|---|
| Tracker disabled in the same built app | 10 | 0 | 0 |
| Tracker enabled with the disclosed configuration | 10 | 20, with two per journey | 0 |
| Initial collector requests blocked, then restored | 1 | 2 after recovery | 0 |
The recovery run recorded two deliberately failed collector attempts, which produced expected network errors in the console. The application remained usable and the test reached the plans page. A JavaScript-exception count of zero does not mean that the network had no errors.
Why we retained the unsuccessful setup batches
Our first batch used localhost. The production tracker intentionally skips local hostnames, so those enabled journeys delivered no pageviews. That was an invalid setup for testing the production artifact, and we retained the results instead of reporting them as dropped production traffic.
We then used a reserved test hostname, with every request intercepted and routed to the loopback fixture. That avoids public DNS and hosted collection while letting the production artifact execute. The second batch received engagement requests, but its short observation windows ended before the artifact's default five-second pageview queue timeout. It also retained zero pageviews within those windows.
Inspection showed that setting enableBatching=false did not bypass the pageview queue in this artifact. For the final batch, we removed that ineffective option and explicitly configured batchTimeout=250. We rebuilt the app and repeated the declared windows. The successful results apply to that configuration; they do not establish default delivery latency or a performance improvement between batches.
If you adapt this test, choose a window that includes the queue and retry behavior you intend to measure. Distinguish an event that has not yet flushed from an event that was rejected or never created.
What the browser stored
No cookies were present in the final batch's browser contexts. The enabled configuration did use browser storage, including a did local-storage entry. Avoiding cookies does not mean avoiding all storage, identifiers, or privacy review. Inspect the actual options and payloads of your installation rather than inferring those properties from a product label.
For collection settings and review questions, read the cookieless analytics guide. This test does not establish a legal consent exemption or anonymity.
What the measurements do not establish
The pinned production tracker file contained 45,577 decoded bytes. That is the size of the artifact used in this check, not a measurement of compressed CDN transfer size, the complete SDK bundle, or the resources loaded by every optional feature. The archive records its SHA-256 and exact test configuration.
The baseline retains the application's SDK import and other code. It measures the same fixture with its browser tracker disabled, rather than a separately optimized application without the SDK. The runner records exploratory browser CPU counters, but this small desktop lab sample does not establish a speed winner, field Core Web Vitals, or an effect on conversions. We do not make those claims from it.
The collector accepts synthetic local requests. It does not exercise Databuddy's hosted ingestion pipeline, database persistence, dashboard processing, or funnel reports. If you are validating a real deployment, separately check that its reports display the known journey and the expected event properties.
Apply the checks to your application
Start with one initial pageview, one client-side navigation, and one confirmed application outcome. Write down the expected events before running the journey. Inspect duplicates, failed actions, collector rejection, and recovery separately. An installed script, a sent request, and a visible report are different checkpoints.
Use the Next.js integration guide for setup and the signup-to-paid example for synthetic completion events and server-side recovery. If you are replacing another tracker, the Plausible migration guide and Matomo migration guide explain how to preserve old reports and verify the cutover.