Server-side tracking for Recharge
Recharge gives you good webhooks and no way to send a conversion anywhere, which makes the server-side build unusually clean here: subscribe to subscription and charge events, store the click identifier on the subscription rather than the order, and decide in writing what happens at renewal. The one Recharge-specific trap is that every charge also creates a Shopify order, so your store's existing integration is probably already firing on the same commercial event.
Free30 minutesNo obligation
Recharge server-side · what breaks
What goes wrong on Recharge
- 01
Renewals invisible to every ad platform
They happen on a cron, with no customer present. Nothing that fires from a page can see them, and no amount of pixel work changes that.
- 02
The first order double-counted
Recharge creates a Shopify order, so the store's native integration and a Recharge-aware setup can both fire for the same purchase.
- 03
Churn never reversed
A subscription that cancels stops producing revenue, and almost nobody wires the cancellation back to anywhere.
- 04
Acquisition valued at one box
A subscriber worth twelve shipments optimized as though they were a single-purchase customer.
Recharge server-side · the fix
What changes — Recharge server-side
Acquisition and recurring revenue separated
One is what you bid on; the other is what you report. Conflating them is the standard mistake.
First order sent once, at lifetime value
Deduplicated on the Shopify order ID, valued at expected subscriber lifetime rather than one shipment.
Cancellations reversed
So reported subscriber value can go down, which is the only way it stays honest.
Recharge server-side · architecture
What Recharge exposes to a server container
The server-side build on Recharge specifically.
- 1
Source events from Recharge webhooks
Not from the thank-you page. A subscription customer who closes the tab has still subscribed.
- 2
Store the click identifier on the subscription
Not on the order. The subscription is the object that persists across every renewal.
- 3
Decide the renewal policy before building
Reporting always; bidding only deliberately. Write the decision down.
- 4
Deduplicate against the Shopify order
Recharge creates one, and your store's existing integration probably already fires on it.
- 5
Wire cancellation as a reversal
Available and almost never implemented.
Recharge server-side · diagnose
Where Recharge 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
Compare Recharge revenue against reported revenue for a closed month
The gap is your renewal blind spot and it is usually the largest discrepancy in the business.
- 02
Check whether a subscription carries a click identifier
If the identifier is on the order and not the subscription, renewals can never be attributed.
- 03
Look for double counting on the first order
Recharge creates a Shopify order, and your store integration probably already fires on it.
- 04
Check whether cancellation does anything at all
Almost never wired, and it means reported subscriber value only ever rises.
- 05
Ask what the renewal number is for
Reporting and bidding need different answers, and conflating them is the real mistake under the technical one.
Recharge server-side · prove
The QA evidence — Recharge server-side
Run on Recharge specifically, on a live conversion rather than in preview mode.
Source of truth
Recharge's own subscription and order records, cross-checked against the Shopify orders they create
- A test subscription created, with exactly one conversion firing and the identifier confirmed on the subscription rather than the order.
- A renewal processed and confirmed to land wherever the written policy says it should — and nowhere else.
- A cancellation confirmed to reverse at each destination that accepts one.
- Recharge revenue reconciled against reported revenue for a fully closed month, with acquisition and recurring separated.
- The lifetime value model shown as a calculation from your own churn data, not asserted.
- Reconciled over a fully closed window, matched per record rather than on totals.
- Re-checked 30 days later, and after any platform update.
Recharge server-side · free audit
What we check in the free audit
- Compare Recharge revenue against reported revenue for a closed month
- Check whether a subscription carries a click identifier
- Look for double counting on the first order
- Check whether cancellation does anything at all
- Ask what the renewal number is for
Checked against
Recharge's own subscription and order records, cross-checked against the Shopify orders they create
Free30 minutesNo obligation
Recharge server-side · when not to buy
When you don't need this on Recharge
Worth reading before you buy anything, from us or anyone.
- If you sell one-off products with a small subscription tail, the store's native integration may already be adequate. Measure the recurring share first.
- If your churn data is too young to model lifetime value, say so and use a conservative figure rather than an invented one.
- If Recharge revenue and reported revenue already agree within a few percent, this is working and there is nothing to buy.
- If you are not running paid media at meaningful spend, the reporting fix matters and the ad-platform work does not.
Recharge server-side · what we deliver
What the server-side build gives you on Recharge
Container on your own subdomain
Your domain, your certificate, hosting in an account you control.
Money events from Recharge's subscription records
Recharge's subscription and charge records are authoritative for recurring revenue; the Shopify order list is authoritative for what the store banked. They should agree, and reconciling them against each other is the first thing worth doing.
Deduplicated at every destination
On a shared event ID, verified before any existing path is removed.
Consent enforced before dispatch
A denied destination receives nothing, verified by capture rather than configuration.
Written guarantee
95%+ tracking accuracy
Measured against Recharge's own subscription and order records, cross-checked against the Shopify orders they create. 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
Recharge server-side questions, answered
You need a server-side event source, which the Recharge webhooks already give you. A container is useful when you are feeding several destinations from one place; for a single destination a direct webhook handler is simpler and does the same job.
Yes, for the funnel above purchase where volume is high and stakes are low. The subscription event itself should come from the webhook, because a customer who closes the tab has still subscribed.
It runs on a Recharge domain, so your first-party cookies do not follow the customer there. Anything you need from portal activity has to come from the webhooks rather than from tracking the page.
Two to four days for the implementation, plus a closed month of reconciliation before we would call it verified — because the renewal behaviour only shows up over a full billing cycle.
Free · 30 min
Move Recharge events off the browser
WhatsAppFree30 minutesNo obligation
