Why aren't route changes tracked in my single-page app?
A single-page app changes the URL without reloading the document, so anything tied to page load fires exactly once — on the first view — and never again. Every subsequent navigation is invisible, which makes a multi-step funnel look like a single-page bounce. The fix is to hook the framework's own router rather than the browser's load event, fire on the navigation the router reports, and guard against the two failure modes that immediately follow: double-firing on re-render, and firing before the new page's title and path have actually updated.
Free30 minutesNo obligation
SPA route change not tracked · what breaks
What this looks like when it's happening to you — SPA route change not tracked
- 01
One pageview per session no matter how much the user browses
The signature symptom. Sessions look like bounces even when engagement is high.
- 02
A funnel that shows the first step and nothing after it
Because only the entry page ever fired.
- 03
Conversions on later steps not firing at all
A thank-you route reached by client-side navigation never triggers a load-based tag.
- 04
Bounce rate that looks impossibly high
Often the first thing anyone notices, and usually misdiagnosed as a content problem.
SPA route change not tracked · the fix
What changes once it's fixed
Every route change tracked once
Fired from the router, not from page load, and not twice.
Correct path and title on each event
Captured after the navigation has committed, not during it.
Conversions on client-side routes firing reliably
Including thank-you and confirmation routes reached without a reload.
SPA route change not tracked · architecture
Why your conversion data was wrong in the first place — SPA route change not tracked
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to spa route change not tracked, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
SPA route change not tracked · normal or broken
Some of this is supposed to happen — SPA route change not tracked
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
Working
One event per navigation, with the correct path and title, including query-only changes, and no duplicate on the first load.
Broken
One event per session. Everything after the landing page is invisible.
Overcorrected
Two events on the first view and duplicates on re-render — which then reads as a traffic increase rather than a bug.
Actually broken
Tracking bound to the browser load event
The default assumption of almost every tag manager tutorial and the reason this is so widespread.
History Change triggers configured but firing on the wrong moment
The trigger fires as the URL changes, before the app has rendered the new view, so the title and content captured belong to the old page.
The router doing a shallow update that no listener sees
Query-parameter-only navigation and shallow routing often bypass the events people subscribe to.
Effects re-running on re-render
Producing duplicates that look like a different bug entirely.
A hard-navigation fallback masking the problem in testing
Typing the URL directly triggers a real load, so manual tests pass while real user journeys fail.
SPA route change not tracked · diagnose
How we find out why aren't route changes tracked in my single-page app
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Navigate through the app by clicking, not by typing URLs
Typing a URL causes a real page load and hides the entire problem. This is why it survives QA.
- 02
Watch the network tab or DebugView while clicking through three pages
One event for three navigations is the diagnosis.
- 03
Check whether the path on each event matches where you actually are
A correct count with the previous page's path means the timing is wrong, not the trigger.
- 04
Click the same link twice in a row
Confirms whether re-render duplication exists and whether the guard works.
- 05
Test the initial load specifically
Two events on first view is the usual overcorrection once the router hook is added.
- 06
Test navigation that only changes a query parameter
Frequently missed by the listener that handles path changes.
SPA route change not tracked · prove
How we prove it's actually fixed — SPA route change not tracked
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your own click-through of the app with the network tab open, compared against what the analytics tool received
- A three-page click-through producing exactly three events, each with the correct path.
- A repeated navigation to the same route producing exactly one additional event.
- Reconciled against your own click-through of the app with the network tab open, compared against what the analytics tool received for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
SPA route change not tracked · free audit
What we check in the free audit
- Navigate through the app by clicking, not by typing URLs
- Watch the network tab or DebugView while clicking through three pages
- Check whether the path on each event matches where you actually are
- Click the same link twice in a row
- Test the initial load specifically
- Test navigation that only changes a query parameter
Checked against
Your own click-through of the app with the network tab open, compared against what the analytics tool received
Free30 minutesNo obligation
SPA route change not tracked · when not to buy
When you don't need us for this — SPA route change not tracked
Most of these you can do yourself, and we would rather you did.
- Click through three pages of your app while watching DebugView. If you see one event, you have confirmed it in a minute.
- Check whether the path on the event matches the page you were on when it fired — a timing bug looks like success in the event count.
- Test by clicking links, never by typing URLs. Typing causes a real load and hides the problem entirely.
SPA route change not tracked · what we deliver
What we do about it — SPA route change not tracked
Subscribe to the router's navigation event
Each framework exposes one. Use it rather than listening for popstate, which misses programmatic navigation.
Fire after the navigation commits
Firing during the transition captures the previous path and title, which is worse than not firing because it looks like it worked.
Guard against re-render
React in particular can re-run an effect. Key the guard to the path, not to a component's lifecycle.
Decide whether the initial load is one event or two
The first view often fires both the load handler and the router handler. Pick one and suppress the other.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
SPA route change not tracked questions, answered
It handles the detection of a URL change. What it does not handle is timing — it fires when the URL changes, which in most frameworks is before the new view has rendered. Tags that read the page title or content at that moment get the previous page's values. The fix is either a small delay or, better, firing from the app's own post-navigation hook where you know the render has completed.
Enhanced measurement includes browser history-based page view detection, and it works for many apps. It shares the same timing caveat, and it will not know about anything your app does that does not change the history entry. Test it in your app rather than assuming — the answer genuinely differs between frameworks.
A pageview, so it lands in standard reporting and your path reports are complete. Add custom events for the steps that matter beyond navigation, rather than replacing pageviews with them.
Safe enough for reporting once the routing hook is right, but a conversion that only exists client-side is still a conversion that disappears when a script is blocked or a user closes the tab early. For anything that represents money, send it server-side from the record instead.
Free · 30 min
Get spa route change not tracked diagnosed properly
WhatsAppFree30 minutesNo obligation
