Klaviyo + Recharge revenue attribution skewed

---

title: "Klaviyo + Recharge revenue attribution skewed" description: "Why ReCharge subscriptions double-count or under-count in Klaviyo attribution — event mapping, renewal handling, subscription-state sync, and the fix." slug: "klaviyo-recharge-attribution" publishedAt: "2026-05-19" updatedAt: "2026-05-19" painCluster: 6 intent: 7 tier: 4 faq:

• q: "Why does ReCharge revenue look wrong in Klaviyo?" a: "Three common patterns. ReCharge subscription renewals fire as Placed Order events in Klaviyo, which credits any recent campaign or flow that the customer touched — even though the customer didn't take any new action. Or renewals don't fire as Placed Order at all, meaning attribution shows zero revenue from subscription renewals. Or the events fire but with wrong values (missing line items, wrong prices, no currency)."
• q: "Should ReCharge renewals fire as Placed Order in Klaviyo?" a: "Most operators conclude: no, not as Placed Order specifically. The renewal isn't driven by a new customer decision — it's an automatic recurring charge. Crediting marketing for renewals that would have happened anyway inflates marketing's apparent ROI. The cleaner pattern is to fire renewals as a custom event (Subscription Renewal) that doesn't enter Klaviyo's standard attribution path."
• q: "How do I separate one-time-order revenue from subscription-renewal revenue in Klaviyo?" a: "Configure the ReCharge integration to fire one-time orders as Placed Order (which enters Klaviyo's attribution) and subscription renewals as a separate custom event like Subscription Renewal Order. Then attribution numbers reflect actual marketing-driven new revenue, and subscription renewal revenue is tracked separately."
• q: "What about the initial subscription signup — is that a Placed Order?" a: "Yes, typically. The initial subscription purchase is a new customer decision that marketing influenced; it should fire as Placed Order so it enters attribution. Only the recurring renewals after the initial signup should fire as the custom event. Configure ReCharge's webhook mapping accordingly."
• q: "Why might my replenishment flow be broken because of ReCharge?" a: "If ReCharge renewals fire as Placed Order, your replenishment flow's timer resets every time the customer's subscription renews. The customer keeps receiving replenishment reminders even though they're on auto-ship. Configuring renewals as a separate event fixes both the attribution issue and the replenishment-flow issue."
• q: "Does ReCharge sync subscription state to Klaviyo profiles?" a: "Yes, via a profile property like subscription_status or similar. The property updates when subscriptions change state (active, paused, cancelled). If this sync is broken or lagging, your flows that filter on subscription status (excluding active subscribers from replenishment, for example) will be wrong."
• q: "How do I check if ReCharge is double-counting in Klaviyo?" a: "Pull a sample of customer profiles who have active subscriptions. Look at their Placed Order event history in Klaviyo. Compare against their actual order history in ReCharge or Shopify. If Klaviyo shows more Placed Order events than the actual unique orders, double-counting is happening — usually because both ReCharge's renewal events and Shopify's order events are firing as Placed Order in Klaviyo for the same renewal."
• q: "Will Playbook detect ReCharge attribution issues?" a: "Yes. We monitor for Placed Order event patterns that suggest double-counting (unusual ratios of events to actual unique orders) and flag flows whose trigger logic interacts badly with subscription renewals. The deep link goes to the integration configuration where the event mapping is set." related:
• klaviyo-revenue-attribution-missing
• klaviyo-google-analytics-revenue-mismatch
• klaviyo-replenishment-flow-not-firing
• klaviyo-flow-stopped-generating-revenue

---

ReCharge (and its peers — Skio, Bold, Loop, Stay AI) handle subscriptions for Shopify stores. The integration with Klaviyo is functional but the event mapping has nuances that produce a class of attribution and flow-logic issues specific to subscription brands. This page covers the common patterns and how to configure them sensibly.

The core issue: what counts as a "new order"

Klaviyo's attribution model is built around the Placed Order event. When a customer places an order, Klaviyo credits whichever marketing touchpoint (campaign, flow) most recently engaged them within the attribution window. The model assumes that a Placed Order represents a customer decision that marketing potentially influenced.

This model works cleanly for one-time orders. It breaks down for subscription renewals because a renewal isn't a customer decision — it's an automatic recurring charge that happens regardless of what marketing did or didn't do. Crediting marketing for renewals inflates marketing's apparent ROI in a way that doesn't reflect actual driven revenue.

The question every subscription brand has to answer in their Klaviyo + ReCharge configuration: do subscription renewals fire as Placed Order events?

If yes (default in many ReCharge integrations): Renewals enter attribution. Recent campaigns and flows get credit for renewals they didn't actually drive. Replenishment flow timers reset on every renewal. Customers on auto-ship may receive replenishment reminders inappropriately.

If no (the cleaner configuration): Renewals fire as a separate custom event. They don't enter attribution. Replenishment flows aren't disrupted. Attribution numbers reflect actual new-order revenue.

Most subscription brands at scale eventually configure the "no" pattern. The "yes" default is easier to set up but produces persistent attribution skew that becomes harder to unwind the longer it's in place.

The recommended configuration

The pattern most subscription brands converge on:

Initial subscription signup → fires as Placed Order. This is a new customer decision that marketing influenced. It should enter attribution.

Recurring subscription renewal → fires as a custom event (Subscription Renewal Order). This is an automatic recurring charge. It shouldn't enter attribution because marketing didn't drive it.

Subscription cancellation → fires as a custom event (Subscription Cancelled). Useful for triggering save flows and winback sequences, but not part of attribution.

One-time orders (non-subscription) → fires as Placed Order. Standard ecommerce attribution path.

The configuration lives in ReCharge's settings (Klaviyo integration → event mapping). Each event type can be configured to fire as a specific Klaviyo event. Set the mapping accordingly.

What to do if you've been on the wrong configuration

Many subscription brands run for months or years with renewals firing as Placed Order. The attribution numbers are inflated; the replenishment flow may be broken; the historical data has been recorded that way.

Step 1: Switch the configuration going forward. Update ReCharge's event mapping so future renewals fire as Subscription Renewal Order. Going forward, attribution will be cleaner.

Step 2: Don't rewrite historical data. Klaviyo doesn't make it easy to retroactively change event types, and trying to clean historical data often creates more problems than it solves. Accept that historical attribution numbers are inflated; flag this in any year-over-year comparison.

Step 3: Recalibrate your benchmarks. If you've been comparing flow performance against an inflated baseline, the new numbers will look "worse" because they're more accurate. Adjust expectations.

Step 4: Audit dependent flows. Replenishment flows in particular need a review — if their timer was being reset by renewal events, customers may not have been receiving reminders at the right moments. Fix the flow timing assumptions to reflect the new event reality.

The subscription-state sync layer

Separate from the event-firing question, ReCharge syncs subscription state (active, paused, cancelled, etc.) to Klaviyo profile properties. This sync drives a lot of segmentation logic — "active subscribers" segments, "lapsed subscribers" segments, "VIP subscribers" segments.

When the state sync is broken or lagging, these segments are wrong, and any flow filtering on them produces wrong results.

How to verify. Pull a sample of customers. Compare their actual subscription state in ReCharge to the property values in Klaviyo. They should match. If they don't, the sync is broken.

Common causes. API rate limits hit during a bulk subscription change. Webhook delivery from ReCharge to Klaviyo failing intermittently. Custom property naming mismatch.

Fix. ReCharge has retry logic for failed webhooks but it doesn't cover every edge case. For mission-critical state segmentation, configure a daily reconciliation job that compares ReCharge's API view of subscription state against Klaviyo's profile data and corrects discrepancies.

Replenishment flows on subscription accounts

A specific pattern subscription brands hit. The replenishment flow is meant for one-time buyers who would benefit from a reminder to re-order. Subscribers shouldn't receive it (they're on auto-ship). The exclusion filter is "subscription_status equals active."

If subscription_status isn't updating correctly, subscribers get replenishment emails inappropriately. The complaints aren't huge (customers usually just ignore them) but the operational mismatch erodes trust.

Verification path. Pull a sample of active subscribers. Confirm they're not entering the replenishment flow. Pull a sample of cancelled subscribers from the last 30 days. Confirm they are entering the replenishment flow (they should — they're now one-time buyers again).

Fix. Audit the subscription_status field on the affected profiles. Repair the underlying sync if it's broken.

Currency and price handling

A more technical issue but worth knowing about. ReCharge sometimes fires Placed Order events with missing or incorrect currency and price fields. The order is recorded but the value is wrong, which means attribution numbers don't aggregate correctly.

How to verify. Pull recent Placed Order events from ReCharge-driven orders. Inspect the event payload (in Klaviyo: Analytics → Metrics → Placed Order → click into a specific event). Confirm currency, price, and line-item fields are populated.

Fix. Usually requires re-configuring the ReCharge webhook payload to include the missing fields. Sometimes requires a minor ReCharge integration update.

What other subscription platforms do differently

Skio, Bold, Loop, Stay AI all have analogous integration mechanics but slightly different default configurations.

Skio. Defaults toward firing renewals as a separate custom event (cleaner default than ReCharge's). Subscription state syncs reliably. Generally less attribution-drift work needed at setup.

Bold. More configurable, less opinionated. Default event mapping varies by which Bold product (Subscriptions, Memberships, etc.) is in use. Verify per setup.

Loop. Similar to ReCharge in default configuration. Same recommended adjustments apply.

Stay AI. Newer entrant with cleaner integration defaults. Renewals tend to fire as custom events out of the box.

The pattern across all of them is: verify the event mapping after integration, configure renewals as custom events rather than Placed Orders, and audit subscription-state sync periodically. The platforms differ in their defaults but the operational pattern is identical.

What Playbook flags for ReCharge accounts

A few specific findings:

Placed Order event volume spikes that don't match Shopify order volume. Suggests renewals are double-firing or being attributed wrongly.

Replenishment flow entries for profiles with active subscription status. Indicates the exclusion filter isn't working — possibly because subscription state isn't syncing.

Subscription Renewal event volume dropping unexpectedly. Suggests the ReCharge integration may be broken or the webhook delivery is failing.

Subscription-state sync lag. If property updates lag the underlying ReCharge state by more than 24 hours, we surface this — it affects segment freshness.

The fixes for each are the same as detailed above. The detection is what changes — instead of finding out by symptom (broken attribution, customer complaints, missing replenishment), the operator gets the finding within hours of when it happens.