Why aren't my subscription renewals tracked?
A subscription renewal happens on a schedule inside a billing system, with no customer, no browser and no page load anywhere near it. Anything that fires from a page therefore cannot see renewals at all, which is why subscription businesses routinely report only their first payments and undercount lifetime revenue by whatever their retention is worth. The fix is to send renewals from the billing system's webhook. The harder question, which most guides skip, is whether renewals should be sent to ad platforms as conversions at all — sending them against the original click distorts bidding, and sending them as new conversions inflates acquisition. Both answers can be right; the choice needs to be deliberate.
Free30 minutesNo obligation
Subscription renewals not tracked · what breaks
What this looks like when it's happening to you — Subscription renewals not tracked
- 01
Only first payments appearing anywhere
Reported revenue equals new business, and the recurring base is invisible.
- 02
Reported LTV that never grows
Because nothing after the initial purchase is ever recorded.
- 03
Ad platforms and the billing system diverging steadily over time
The gap widens every month as the subscriber base grows.
- 04
Renewals appearing but attributed to nothing
The event was sent without an identifier, so it lands under direct.
Subscription renewals not tracked · the fix
What changes once it's fixed — Subscription renewals not tracked
Renewals sent from the billing system
On the invoice or subscription webhook, which is the only place they exist.
A deliberate decision about where they go
Reporting always. Ad platform bidding only if it has been thought through.
Cancellations and failed payments handled
A subscription that lapses should stop contributing revenue you are still reporting.
Acquisition and recurring revenue reported separately
So neither number hides inside the other.
Subscription renewals not tracked · architecture
Why your conversion data was wrong in the first place — Subscription renewals 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 subscription renewals 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.
Subscription renewals not tracked · normal or broken
Some of this is supposed to happen — Subscription renewals 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
Renewals sent from the billing system on payment, with the original identifier available, cancellations reversed, and a written decision about which destinations receive them.
Broken
Only first payments exist. Recurring revenue is invisible and LTV cannot be measured.
Broken in the other direction
Every renewal sent to every ad platform as a fresh conversion, inflating reported acquisition performance by the size of the subscriber base.
Actually broken
No browser present at renewal
Structural, not a bug. No page-based tracking of any kind can solve it.
The billing webhook never subscribed to
The event exists and nothing is listening for it.
The original identifier not stored on the subscription
Captured at signup and discarded, so renewals have nothing to attribute to.
Renewals sent against the original click
Which credits a one-year-old click with revenue and skews bidding toward whatever produced it.
Failed payments and dunning counted as renewals
An invoice created is not an invoice paid, and dunning retries can produce several events for one period.
Subscription renewals not tracked · diagnose
How we find out why aren't my subscription renewals tracked
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Compare billing system revenue to reported revenue for a closed month
The gap is your renewal blind spot, and it is usually the largest single discrepancy in a subscription business.
- 02
Check whether any renewal event exists anywhere at all
Frequently the answer is no, which makes the rest of the diagnosis short.
- 03
Look at a subscription record and check for a stored identifier
If it is absent, renewals cannot be attributed no matter how they are sent.
- 04
Check what happens on a failed payment and a retry
Dunning can generate several invoice events for one billing period.
- 05
Check whether cancellations reverse anything
Almost never wired, and it means reported recurring revenue is permanently overstated.
- 06
Ask what the renewal is meant to be used for
Reporting and bidding need different answers, and conflating them is the actual mistake underneath the technical one.
Subscription renewals not tracked · prove
How we prove it's actually fixed — Subscription renewals not tracked
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
The billing system — paid invoices by payment date for the same window, net of refunds and failed payments
- A real renewal followed from the billing webhook through to wherever it was decided it should land.
- Billing system revenue reconciled against reported revenue for a closed month, with the acquisition and recurring components separated.
- Reconciled against the billing system — paid invoices by payment date for the same window, net of refunds and failed payments 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.
Subscription renewals not tracked · free audit
What we check in the free audit
- Compare billing system revenue to reported revenue for a closed month
- Check whether any renewal event exists anywhere at all
- Look at a subscription record and check for a stored identifier
- Check what happens on a failed payment and a retry
- Check whether cancellations reverse anything
- Ask what the renewal is meant to be used for
Checked against
The billing system — paid invoices by payment date for the same window, net of refunds and failed payments
Free30 minutesNo obligation
Subscription renewals not tracked · when not to buy
When you don't need us for this — Subscription renewals not tracked
Most of these you can do yourself, and we would rather you did.
- Compare last month's billing system revenue to what your analytics reported. The gap is the renewal blind spot.
- Open a subscription record and look for a stored click identifier. If it is not there, renewals cannot be attributed.
- Check whether a cancellation does anything at all in your reporting. Usually it does not.
Subscription renewals not tracked · what we deliver
What we do about it — Subscription renewals not tracked
Subscribe to the billing system's recurring invoice webhook
Stripe, the subscription app, or whatever holds the schedule. It is the only source that knows a renewal happened.
Carry the original identifier on the subscription record
Stored once at signup, available on every renewal thereafter.
Decide, in writing, what goes to ad platforms
The default recommendation: acquisition to the ad platforms, full recurring revenue to your own reporting.
Wire cancellation and dunning failure
Otherwise reported recurring revenue only ever rises, which nobody's actually does.
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
Subscription renewals not tracked questions, answered
Usually not as acquisition conversions. Sending a renewal against the original click credits a click from a year ago with revenue it did not just produce, which distorts bidding toward whatever was running then. The cleaner structure is to optimize on acquisition and report recurring revenue separately. If you do want renewals in the platform, use a separate conversion action that is excluded from bidding.
By expected lifetime value — your average revenue per subscriber over your average tenure, calculated from your own billing history and documented. That puts the full value of a subscriber into the acquisition conversion where bidding can use it, without pretending each renewal is a new sale.
They change the recurring amount, so they belong in your revenue reporting. They are not acquisition events and should not be sent as conversions.
Whichever actually takes the payment. If the subscription app bills the customer, its records are authoritative and the store's order list will not contain renewals at all — which is often the reason the gap went unnoticed.
More on Subscription renewals not tracked
Free · 30 min
Get subscription renewals not tracked diagnosed properly
WhatsAppFree30 minutesNo obligation
