Conversion tracking for React
A React single-page application breaks the assumption almost every tracking tool is built on: that navigation means a page load. Route changes fire nothing, so a container configured for page views records one view per session and then goes quiet. Add hydration timing, StrictMode double-invoking effects in development, and conditional rendering, and the failures are all timing rather than configuration.
Free30 minutesNo obligation
React tracking · what breaks
What goes wrong on React
- 01
Route changes fire no page views
A client-side navigation isn't a page load.
- 02
Hydration timing
Events firing before data exists dispatch empty values.
- 03
Effects double-firing
StrictMode in development, and sometimes carelessness in production.
- 04
Ad blockers hitting client-side tags
More effective against SPA bundles than against server calls.
React tracking · the fix
What changes — React tracking
Route changes emitting proper events
Bound to the router.
Events firing after data is available
Not before.
Money events from your API
Removing client-side fragility entirely.
React tracking · architecture
What React actually lets you do
You control everything, and none of the usual defaults apply.
- 1
Router events
The hook everything depends on. Available in every router.
- 2
Full control of timing
Which means the timing is your responsibility.
- 3
Your own API
The right source for money events.
- 4
No platform defaults
Nothing is automatic.
- 5
StrictMode
Double-invokes effects in development, which surfaces deduplication bugs early if you're paying attention.
React tracking · diagnose
Where React tracking breaks, in diagnostic order
Each check rules out a class of cause, so by the last one there is usually a single explanation standing.
- 01
Navigate between routes and watch for events
Nothing firing is the classic SPA fault.
- 02
Check whether first events have empty values
A hydration timing signature.
- 03
Grep for duplicate pixel initialisations
Components mounting more than once.
- 04
Confirm where the money event is emitted
Client or API.
- 05
Reconcile against your backend records
For a closed month.
React tracking · prove
The QA evidence — React tracking
Run on React specifically, on a live conversion rather than in preview mode.
Source of truth
your backend order or CRM records
- Route changes confirmed emitting events on a real navigation.
- First-render events confirmed carrying populated values.
- No duplicate events from remounting components.
- Money events confirmed arriving from the backend.
- Counts reconciled against backend records for a closed month.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
React tracking · free audit
What we check in the free audit
- Navigate between routes and watch for events
- Check whether first events have empty values
- Grep for duplicate pixel initialisations
- Confirm where the money event is emitted
- Reconcile against your backend records
Checked against
your backend order or CRM records
Free30 minutesNo obligation
React tracking · when not to buy
When you don't need this on React
Worth reading before you buy anything, from us or anyone.
- If your React app already emits route-change events and sources money events from the API, the SPA-specific problems don't apply.
- Your own engineers can do all of this — it's their codebase and there are no platform constraints.
- If your app is a single-page marketing site with no routing, the route-change problem doesn't exist.
- Reconcile against your backend before assuming anything is broken.
React tracking · what we deliver
The event map on React
Route change
Bound to the router, explicitly. Nothing does this for you.
Interaction events
Client-side, after hydration.
Money event
From your backend API, not the client.
Refund or cancellation
Backend, as a reversal.
Click identifiers
Captured on first load, stored, sent with backend events.
Written guarantee
95%+ tracking accuracy
Measured against your backend order or CRM records. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies the browser-side setup you already have, on a live conversion. Honest about its ceiling on this platform.
- Root cause fixed, not worked around
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, so the browser can no longer lose them.
- First-party server container on your own subdomain
- Money events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, with monitoring so the next break surfaces in days.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring on every destination
FAQ
React tracking questions, answered
Because a client-side route change isn't a page load. Route-change events have to be emitted explicitly and nothing does it for you.
They're firing before hydration completes. Emit after hydration or use server-rendered values.
No. It should come from your API, where the transaction is actually recorded and where blockers and hydration are irrelevant.
No — it double-invokes in development only. But it surfaces deduplication bugs that would otherwise reach production, so it's worth heeding.
WhatsApp