Why Recharge Stores Double-Count Conversions (And How to Fix It)

What changed

Two things moved under subscription brands this year, and together they explain most of the duplicate-conversion reports we see in Recharge stores.

First, the old checkout tracking surface is gone. Shopify's documentation lists checkout.liquid as deprecated, with support for the thank-you and order-status pages — including Additional Scripts on those pages — ending 28 August 2025, and script tags on those pages ending 28 August 2025 for Plus merchants and 26 August 2026 for non-Plus merchants. The replacement path is checkout extensibility and the Web Pixels API, where pixels run inside a sandbox and subscribe to a published set of customer events such as page_viewed, product_viewed and checkout progression events, rather than executing arbitrary script on the order page.

That migration is where duplicates get created. Teams add a Web Pixel to restore purchase tracking, but the legacy tags, app embeds and GTM containers that fired the same purchase often stay installed. For non-Plus stores the legacy path keeps working until August 2026, so both layers can fire side by side for months without anything visibly breaking.

Second, subscription orders are not one order. Recharge's documentation on subscription models describes checkout charges and upcoming recurring bills as separate charges on separate dates, and Littledata's Recharge-to-Google-Analytics documentation splits subscription revenue by an order affiliation so first orders, recurring orders and prepaid orders can be told apart in reporting. Recharge's own analytics documentation adds a second wrinkle: it notes that active subscriber counts are net totals based on subscription status, so prepaid gifts fall out of the active count and land in churn instead. If your ad platform, your analytics tool and your finance report each draw a different line around "a purchase," you get three different conversion counts from the same week of trading.

On the deduplication side, the mechanics have not changed and are worth restating because most broken setups violate them. Meta's Conversions API parameter documentation states that event_id and event_name are used to deduplicate events sent by both the browser Pixel and the Conversions API, and that although event_id is marked optional it is recommended for deduplication. Practitioner write-ups go further: Daniil Maximkin's guide claims Meta only collapses a browser event and its server twin when both carry the same event_id and the same event_name and arrive within 48 hours, and that mismatched or per-pageload-regenerated IDs cause Meta to keep both. We could not confirm the 48-hour figure in the Meta page we read, so treat it as a practitioner claim rather than documented behaviour.

Why it matters to a brand at this spend level

At $50K+/month, a duplicate purchase event is not a reporting annoyance. It is a bidding input.

UpStack Data's Michael Alt frames the failure as over-attribution: duplicate event triggering from multiple trackers recording the same event, incorrect pixel placement causing extra fires, and cross-domain issues misattributing sessions. The consequences he lists are the ones that cost money — inflated ROAS leading to over-investment, budget pushed toward ads that are not incremental, and reporting discrepancies across Shopify, GA and Ads Manager that erode trust in the numbers. The same article names the opposite failure, under-attribution, driven by lost tracking parameters, cookie blocking and attribution windows too short for longer consideration cycles. Subscription brands frequently run both at once: duplicated first orders and invisible recurring ones.

Cometly's write-up on duplicate conversion counting describes how these stacks form — a developer installs the pixel, a marketer adds it again through a tag manager, an agency layers on a third implementation, and nobody removes the old one. TrueROAS makes the same diagnosis for Meta, Google and Shopify double-counting and concludes the fix is a code audit rather than a settings change. Neither is a primary source, but both match what we find in audits: the duplicate is almost never a platform bug, it is an inventory problem.

Recharge adds a specific measurement gap on top. Its analytics documentation states that when a customer declines analytics tracking, the Recharge pixel does not fire and that activity is excluded from subscription widget and cart performance metrics. That is a systematic under-count concentrated in exactly the surface — the subscribe-and-save widget — that subscription brands use to justify offer changes. Order-level data does not have the same gap, which is why widget conversion rates and order reports disagree.

The financial consequence is asymmetric. If first orders are double-counted and recurring revenue is unattributed, blended acquisition cost looks better than it is and lifetime value by channel looks worse than it is. Both errors push budget toward prospecting campaigns that win on a metric you have inflated.

What to do this month

1. Inventory every purchase-firing surface, then delete instead of adding

List every place a purchase event can fire: theme code, app embeds, Shopify's Facebook and Google channels, any Web Pixel in the pixel manager, GTM containers, server-side containers, Recharge's own scripts and any surviving Additional Scripts. For each one, record the pixel ID it sends to, the event name and whether it sets an event_id. Then pick one owner per destination and remove the rest. Shopify's Web Pixels documentation is the right place to start because custom pixels are configured in the admin pixel manager and are easy to enumerate, unlike scripts buried in theme files.

If you are non-Plus, do not treat the August 2026 script-tag date as breathing room. It is the window in which two layers can quietly run in parallel.

2. Make the order ID the deduplication key, on both sides

Set event_id to the Shopify order ID for the Purchase event, and send the identical value from the browser Pixel and from the Conversions API, with the same event_name. Meta's parameter documentation is explicit that both fields are what the deduplication logic reads. Avoid generating the ID at pageload, because a refreshed thank-you page produces a new ID and Meta keeps both events. Scandiweb's setup walkthrough covers the same ground for merchants who want a step-by-step version, and it also describes the fallback matching on fbp and external ID.

Then verify in Events Manager rather than trusting the implementation. You are looking for the deduplicated state on Purchase, and for a Purchase count that tracks your Shopify order count within a small, stable gap — not an exact match, because consent and blocking will always take some events.

3. Separate first orders from recurring orders in every destination

Decide explicitly what a recurring Recharge charge should do in each system, and make the three answers consistent. A defensible default: recurring charges are excluded from ad-platform Purchase optimisation, sent to analytics as a distinctly labelled order type, and counted in full in finance. Littledata's Recharge connection documents the affiliation approach for Google Analytics, and Recharge's API reference gives you the charge and subscription objects to drive a server-side rule.

Two practical notes. Prepaid subscriptions need their own rule, because Recharge's documentation treats prepaid differently in subscriber counts, and because a single prepaid charge covers several shipments. And whatever you decide, write the rule down next to the pixel inventory from action one, so the next agency or contractor does not re-derive it.

What we'd watch next

• The 26 August 2026 script-tag sunset for non-Plus stores. Shopify's documentation sets the date. Expect a second wave of tracking regressions from brands that migrated the thank-you page but left script tags in place.
• Recharge platform changes that touch order data. The Recharge changelog logged a September 2026 fix for Shopify discount codes and automatic discounts restricted to specific customer segments, which were previously skipped on import and could not be applied to recurring subscription orders. Discount logic changes move order values, and order values move reported ROAS.
• Consent-driven gaps widening. Recharge already documents that its pixel does not fire when analytics tracking is declined. As consent enforcement tightens, the gap between widget metrics and order-level truth grows, and order-level reconciliation stops being optional.
• Attribution-window discipline. AdLibrary's 2026 guide to Meta attribution covers windows, modeled conversions and UTM hygiene. For subscription brands with long consideration cycles, window choice changes the answer as much as deduplication does.
• Subscription lifecycle events as an input, not an output. Cancellations and failed payment retries tied back to the acquiring session are the only honest way to compare channels on lifetime value. Very few stacks do this today.

What we could not verify

• The 48-hour deduplication window for matching Pixel and Conversions API events. It appears in a named practitioner guide, not in the Meta parameter documentation we read.
• Any figure for how common duplicate purchase events are across Recharge stores. We found no public dataset and did not estimate one.
• Recharge's Shopify Checkout Integration overview page did not return readable content for us, so claims about how that integration fires tracking on the Shopify checkout are drawn from adjacent Recharge documentation and third-party integration docs rather than that page.
• Whether Meta's modeled conversions interact with duplicate raw events in a way that amplifies or damps the error. No primary documentation we found addresses it.