How does Metrunio count subscription renewals?

A customer takes out a subscription in March after clicking an Instagram ad. In April, May and June your shop charges the next payment without her visiting your website. Who gets the revenue from these payments? Metrunio attributes it to the channel the first order is already attributed to: every renewal takes over the shares of the first order of the same subscription.

How to mark renewals

• Server Events API: send each payment as a purchase with its own order number, plus subscription_id and subscription_renewal: true. The first order carries the same subscription_id, without the flag or with subscription_renewal: false.
• Stripe: also select invoice.paid for the webhook. Metrunio then counts every renewal (billing_reason subscription_cycle) as a renewal and recognises the first order by the checkout in subscription mode. The first invoice of a subscription does not count a second time next to the checkout.
• SDK in the browser: metrunio.conversion({ orderId, value, currency, subscriptionId, subscriptionRenewal: true }). You only need this when a renewal is confirmed in the browser; usually it comes from the server.
• Shopware from plugin 1.3.0 (Shopware Subscriptions) and WordPress from plugin 1.0.1 (WooCommerce Subscriptions) send the subscription ID and the flag themselves. A renewal there is created without a visit and therefore arrives without consent, like those from Stripe: measured, flagged, never attributed. The Shopify app does not send the flag yet; until it does, its renewal orders count as ordinary purchases.

{
  "event_id": "abo-77-rate-2026-10",
  "event_type": "purchase",
  "occurred_at": "2026-10-01T06:00:00Z",
  "order_id": "R-2026-10-77",
  "subscription_id": "abo-77",
  "subscription_renewal": true,
  "value": "29.00",
  "currency": "EUR",
  "user_id": "4711",
  "consent_state": "granted",
  "consent_purposes": ["analytics", "marketing"]
}

A renewal is never a customer’s first order. If you send new_customer: true with it, Metrunio does not accept it and names the field; the two fields do not belong on a lead or a funnel step either.

How it is attributed

Metrunio looks for the first order of the same subscription: the earliest purchase with the same subscription_id and without the flag, on the same website and in the same environment. In every model the renewal receives the same shares as that order and distributes its own value with them. If the first order gave 40 percent to Paid Search and 60 percent to Paid Social, a payment of €30 gives €12 to Paid Search and €18 to Paid Social. When the first order is recalculated, its renewals follow.

Touchpoints before the renewal itself do not count for this. If the customer opens her account through your newsletter before the payment, the newsletter gets nothing from that payment: it would have come anyway.

When it is not attributed

• “The first order of this subscription is not known”: the subscription started before Metrunio measured, the subscription_id is missing, or the first order arrived without consent and therefore without the subscription ID. If you report older first orders through a backfill, the renewals are recalculated. The same applies when the first order is deleted, on request or because its retention period ends: its renewals are then recalculated right away and lose the channel they took over.
• “The first order of this subscription is not attributed to any touchpoint”: it has no channel itself. It shows the reason.
• “No consent”: the renewal arrived without consent for revenue reconciliation. It is measured and marked but never attributed, not even through the first order. Every renewal from Stripe arrives this way, because an invoice carries no reference from the browser.

Reporting with consent: what you need to prove

A renewal usually happens without a visit: your server charges the instalment, and no banner asks anyone. If you still report it with consent (consent_state granted or partial), you rely on consent the customer gave earlier. You need to be able to prove it, with three details: that it referred to the subscription, how long it applied and how the customer can withdraw it. Without consent that you can prove and that is sufficient for this renewal, you must not report it as consented measurement.

• Send the consent state you actually know. A known refusal or withdrawal stays denied and does not become unknown. Report unknown only if you genuinely know of no decision.
• Separate revenue reconciliation is only an option under its own conditions. For this separate purpose, check the legal basis, the information given, the retention period and, where applicable, the activated additional instruction (article “Does consent apply to server events too?”). If Metrunio accepts the renewal on that basis, it is measured and flagged, but not attributed to any channel.
• Suppression lists and the rule that withdrawn measurement data must not be moved into revenue reconciliation still apply.

In the reports

• Overview: below the key figures you see how many renewals arrived in the period, with their measured and their attributed revenue. Both are included in the revenue above.
• Attribution: the column “Of which renewals” shows the attributed revenue from renewals for each row.
• Orders & goals: a renewal carries the note “Subscription renewal”; “Renewals only” shows them on their own.
• Export and read API: folgezahlungen_zugeordnet and umsatz_folgezahlungen_zugeordnet in the attribution export, folgezahlung and abo in the conversion export, isRenewal and subscriptionId in the read API. The data assistant and connected AI tools see only the flag, not the subscription ID.
• New customers: CAC and new customer costs do not count renewals. In the new customer share they count as orders by existing customers, in cohorts as repeat purchases. If a customer’s first measured purchase is already a renewal, they are in no cohort.
• Ad platforms: a renewal is not sent back to Google, Meta or others as a conversion; the pushback log names the reason.