Usage-Based Billing Attribution: How to Credit Channels When Revenue Is Metered

61% of SaaS companies now run at least one usage-based or hybrid pricing plan, and for those companies the single most expensive attribution mistake is crediting the channel that drove the signup instead of the channel that drove the consumption.

A metered account is worth exactly $0 at the moment it converts.

Its real value shows up weeks later, as API calls, seats provisioned, gigabytes stored, messages sent, or compute minutes burned, each one billed on an invoice your marketing tools never look at.

When your attribution report says paid search drove 40% of new accounts, it is describing a population of customers whose actual revenue you have not measured yet.

This is not a rounding error.

In usage-based businesses the gap between account count and account value is enormous: the top decile of accounts often generates 50 to 70% of metered revenue, and those accounts do not distribute evenly across channels.

Attribution that stops at the conversion event is measuring the wrong quantity entirely.

Attribution for usage-based billing is the practice of linking a marketing touch to a durable customer identity and crediting that channel with every metered invoice line the customer generates over its lifetime, not just the value present at signup.

Why This Matters for Your Revenue

When revenue is metered, the channel that acquires your cheapest accounts and the channel that acquires your most valuable accounts can look identical in a signup-based report, because at signup every account is worth the same nothing.

Budget flows toward whichever channel produces the most conversions per dollar, which is frequently the channel that produces the lowest-consumption accounts. You scale the wrong source and starve the one quietly bringing in the whales.

The financial damage compounds monthly, because usage-based revenue is recurring and expanding: a mis-scaled channel does not cost you one bad month, it costs you the entire future consumption curve of every account you failed to acquire.

Getting this right changes the unit of decision from cost per signup to revenue per channel over the metered lifetime. That is the number that maps to your actual Stripe deposits.

A channel with a high cost per trial can be your most profitable source once you count the consumption its accounts generate in months two through twelve, and a cheap channel can be a net loss once you subtract the accounts that sign up, ping the API twice, and never spend again.

You cannot manage what you measure at the wrong moment.

Why Signup-Time Attribution Breaks on Metered Revenue

Every standard attribution setup fires its conversion at a discrete event: a form submit, a checkout, a subscription create. That model assumes the revenue is known at the event.

Usage-based billing violates the assumption at its root, because the event and the revenue are separated in time and the revenue is not a single figure but a stream.

The revenue is a stream, not a point

A seat-based or flat subscription creates one predictable recurring charge you can attribute the instant it is created.

A metered plan creates a base charge (often $0) plus a variable component computed at the end of each billing period from recorded usage.

Stripe models this with metered subscription items and usage records, Paddle with billing based on reported quantities, and Polar and Lemon Squeezy with their own metering primitives. The invoice line that actually carries the revenue does not exist at signup.

It is generated later by the billing engine, which means an attribution tool listening only for checkout.session.completed or customer.subscription.created captures the touch but attaches $0 to it forever.

If you are already attributing subscription revenue through webhooks, the usage-based case demands you listen for a different, later set of events.

See our walkthrough on Stripe webhooks for marketers for the event plumbing, and the deeper treatment in subscription LTV attribution for why crediting only the first payment understates every recurring model.

The attribution window expires before the revenue arrives

Most tools default to a 30-day attribution window. Metered accounts routinely take 30 to 90 days to ramp: a developer signs up, builds an integration, ships it, and only then does usage climb to a level that generates meaningful invoices.

By the time the first material invoice posts, the click that drove the account has aged out of the window and the revenue is credited to nobody, or worse, to whatever late-funnel touch happened to be inside the window.

If your window logic is fuzzy, read how to set an attribution window before you touch a metered model, because the standard 30-day default is actively wrong here.

Expansion and contraction are unattributed by default

Usage revenue moves up and down every billing cycle. An account can 10x its consumption in month four with no new marketing touch at all.

Standard tools have no concept of crediting that expansion to the original acquiring channel, so the growth shows up as unattributed net revenue and your best channels look weaker than they are.

The mirror problem, contraction, is equally invisible until it becomes churn.

The Data Model That Actually Works

Attribution for metered revenue requires three joins that most stacks never make: touch to identity, identity to billing customer, and billing customer to every metered invoice line. Get those three joins right and the rest is arithmetic.

Bind the touch to a durable identity, not a session

Cookies and sessions do not survive the 30-to-90-day ramp. The marketing touch must be written to something permanent the moment the account is created, and the natural home is the billing provider's customer object.

Store the first-touch and last-touch source, campaign, and click identifier in Stripe customer metadata (or Paddle custom_data, or the equivalent) at signup. Our guide to storing the marketing source on every charge covers the exact field layout.

Once the source lives on the customer, it is available on every future invoice that customer generates, no cookie required.

Handle the anonymous-signup-then-pay gap

A common metered flow lets users self-serve for weeks before a Stripe customer object exists.

Stamp the touch onto a session token at first visit, then copy it onto the customer the instant billing is created, so the join survives the anonymous window that precedes the first invoice.

Attribute the invoice line, not the subscription

The unit of revenue in a metered model is the invoice line item, because a single subscription produces many of them over time with wildly different amounts.

Your attribution join must be customer to invoice-line, summed over the account lifetime, and grouped by the source stored on the customer.

This is the same shape as attributing Stripe revenue to marketing channels, extended so that each new metered invoice re-credits the original channel rather than being dropped as an untracked event.

Handle refunds, credits, and proration honestly

Metered billing generates credit notes, proration adjustments, and usage-dispute refunds far more often than flat subscriptions. If your attribution counts gross invoice lines and never subtracts these, your channel revenue is inflated and your CFO will catch it.

Net every credit note back against the channel that got the original credit. The mechanics mirror Stripe refund attribution, applied at the invoice-line grain rather than the payment grain.

What the Numbers Look Like in Practice

The table below is the reconciliation that matters: signup share versus realized metered revenue share, by channel, over a 12-month window. The divergence between the two columns is the entire reason usage-based attribution exists as a discipline.

Why cost per signup lies in this table

Paid search and paid social together drove 60% of signups and 28% of metered revenue. If you optimized on cost per signup, you would pour budget into exactly the two channels bringing in the lowest-value accounts.

The channels that actually pay the bills, developer content and community, look small in a signup report and enormous in a revenue report.

This is the same trap that makes founders chase the cheapest click, explored in which marketing channel is most profitable for SaaS.

Connecting metered revenue back to spend

Once each channel carries its true 12-month metered revenue, you can finally compute an honest return on spend: ad cost in, realized consumption out, over the lifetime rather than the first invoice.

That closed loop, from ad click to accrued Stripe usage, is the subject of tracking marketing spend to revenue, and it only works when the revenue side counts metered lines instead of signups.

Why the Popular Tools Fail at This Specifically

The failure here is not a bug, it is an architectural assumption.

Most attribution tools were built to read revenue from ad platforms or from a single conversion event, and metered billing has neither a clean ad-platform conversion value nor a single event.

Ad-platform-first tools never see the meter

Triple Whale, HYROS, and Northbeam are engineered around ad spend and ad-platform conversions. They pull a conversion value from Meta or Google at the moment of purchase, which for a usage-based account is $0 or a nominal base fee.

They have no mechanism to reach back into Stripe months later and add the metered invoice lines to the channel, because their world model is ad-click to immediate purchase value.

For an e-commerce store buying a $60 product that model is fine. For a metered SaaS account whose value materializes over 90 days, it reports near-zero and calls the channel unprofitable.

The conversions API deadline that erases the touch

Meta's Conversions API accepts server events for only 7 days after the click, and Google Ads caps offline conversion uploads at 90 days.

A metered invoice that posts in month four falls outside both, so even a manual upload cannot re-attach that revenue to the paid click that earned it.

GA4 attributes events, not accrued invoices

GA4 can record a purchase event with a value you pass it, but it has no native concept of a customer that keeps generating revenue on a meter.

You would have to fire a synthetic purchase event every billing cycle with the computed usage amount, deduplicate it against the account, and reconcile it against Stripe, a fragile pipeline that breaks the first time a credit note posts.

This is one more entry in the long list of reasons GA4 struggles with SaaS revenue, covered in GA4 not showing revenue by channel.

Link-level tools stop at the click

ClickMagick and PixelMe are strong at attributing clicks and conversions, but their revenue picture ends at the tracked conversion.

They cannot join a click to a Stripe customer object and then to twelve months of metered invoice lines, because they do not model a persistent billing identity.

They tell you which link drove the signup, which in a usage-based business is precisely the number that does not correlate with revenue.

How TrackRev Handles This

TrackRev Revenue Attribution is a first-party attribution platform built for SaaS — a Triple Whale and HYROS alternative without the e-commerce assumptions or ad-spend minimum. Connects Stripe, Paddle, Polar, and Lemon Squeezy. $19/month.

Because it reads the billing provider directly rather than an ad platform, TrackRev sees the metered invoice lines that other tools never touch.

The marketing touch is written to the customer at signup as first-party server-side data, so it survives the 90-day ramp that expires cookie-based windows.

Every metered invoice that customer generates, month after month, is re-credited to the original acquiring channel, with credit notes and proration netted out so the channel revenue reconciles to your actual Stripe deposits.

The result is a report that shows revenue per channel over the metered lifetime, the number the table above proves you cannot get from signup counts.

It works the same way across providers, so a hybrid stack billing base fees in Stripe and overages in Paddle still rolls up to one channel view.

If you are wiring this into your own app, the Next.js revenue attribution setup shows the first-party capture step, and attributing revenue without GA4 explains why the first-party model is the one that holds up as third-party tracking degrades.

When NOT to Use TrackRev for This

If your entire business is flat, non-metered subscriptions with revenue fully known at signup, the sophistication of lifetime invoice-line attribution is overkill, and a simpler subscription-revenue setup will serve you fine.

TrackRev is also the wrong tool if you sell one-time physical products through Shopify with no recurring or metered component, because that is genuinely the world Triple Whale and Northbeam were built for and their ad-platform integrations will beat a billing-native model there.

And if you have no marketing attribution problem at all, a single channel, no paid spend, and every customer arriving by direct word of mouth, then you do not need attribution software of any kind yet; you need it the month you start spending to acquire accounts whose value you cannot see at signup.