You report MRR by acquisition channel by stamping one channel onto each customer the moment they first arrive, freezing it, and grouping your billing system’s normalised monthly recurring revenue by that stamp. MRR is monthly recurring revenue: the normalised monthly value of every active subscription. The join key is the person, not the payment.
That sounds obvious until the first renewal. A renewal is a machine event — no click, no session, no campaign near it. Any report that decides a channel at charge time moves your recurring revenue into Direct, one billing cycle at a time.
Why do finance and marketing report different recurring revenue numbers?
Because they are measuring two different things with the same word. Finance reports a run rate: what the active subscription base is worth per month, at a point in time. Marketing reports collected cash inside a window, credited to a touch. Same customers, two different arithmetic operations.
One annual plan shows the gap. A customer pays $1,200 in September for twelve months. Finance books $100 of MRR and carries it through August. Marketing books $1,200 of September revenue against September spend. Neither is wrong; nobody says which question they asked.
The second gap is ownership. Finance has a subscription table with a customer id on every row and no idea where those customers came from. Marketing has campaign data and no subscription table. The report everyone wants needs one field neither system holds.
What does “MRR by acquisition channel” actually measure?
It measures the normalised monthly value of every active subscription, grouped by the channel that acquired that customer. Not the channel that touched them last, or the one running when the card was charged: the channel that produced the original relationship, fixed at acquisition and never recalculated.
There are two reports hiding in that sentence, and you need both:
- MRR held by channel — a stock. What your paid social, paid search, organic and referral cohorts are worth per month right now. It tells you how much of the business depends on a channel you might be about to cut.
- New MRR by channel — a flow. What each channel added this month. This is what you rank acquisition on, because it is the only one that moves with this month’s spend.
Reporting the stock and calling it performance is the common mistake. A channel you stopped running in March still holds MRR in September, and keeps looking strong until those customers churn.
Which touch should own a subscription: the first click or the last?
First touch, frozen at acquisition. Last-touch attribution answers “what closed this sale” — a sensible question for a one-off purchase, a meaningless one for the fourteenth renewal of a subscription that has been billing itself since last year.
Watch what last touch does over time. Month one, the customer arrives from a Meta ad and the charge is credited to Meta Ads. Month two, the renewal fires at 03:00 with no session attached, so it lands in Direct. Month three, they click a billing receipt and it lands in Email. Eighteen months later your channel mix says the business runs on Direct traffic, and all that happened is that people kept paying.
So: one channel per customer, written once, when the relationship starts. Every renewal inherits it. If the same person buys a second product two years later, that is a new acquisition event worth recording separately — it does not rewrite the first.
Keep the last-touch view for the acquisition event itself. First versus last on the signup is a real comparison and it is where budget decisions live; read both models side by side when you read an attribution report, the same way you would for ecommerce revenue attributed back to the ad click. The mistake is letting last touch decide a recurring charge.
How do you normalise MRR so the channel split is honest?
Convert every plan to a monthly figure with one written rule set, applied to all channels identically. The rules are boring on purpose:
- Annual plans divided by twelve; quarterly by three; weekly multiplied by 52 and divided by 12.
- One-time charges out — setup, implementation, onboarding, overage invoices. Revenue, not recurring revenue.
- Tax out. Discounts counted at the amount actually billed, not at list price.
- Currency converted on one stated rate and date, for every channel in the same report. Mixed-currency subscription bases are where two honest analysts produce two different MRR figures from one database.
- Failed payments in dunning: pick in or out, write it down, never change it mid-quarter.
- Trialing and paused subscriptions excluded until a successful payment lands — a trial-to-paid conversion arriving weeks later is its own problem.
The point is not accuracy in the abstract — it is that channel A and channel B get measured the same way. Two channels can hold an identical $10,000 MRR while one is annual-prepaid and the other monthly: different cash profiles, same run rate. If your normalisation favours one billing interval, your channel ranking is measuring contract shape rather than marketing.
How do you attach a channel to a subscription that started weeks after the click?
Store the first touch against the person as soon as you can identify them, on your server, and join the billing record back to that person later by email or customer id. Click identifiers expire, cookies get cleared, people switch devices — the email on the invoice is the one they typed on the landing page.
What to capture at the first pageview, before anyone has filled in anything:
utm_source,utm_medium,utm_campaign,utm_content,utm_term(UTM: the tagging parameters on a campaign link).- The referrer and the landing page URL — your fallback when a link was never tagged.
- The platform click identifiers:
gclid,gbraidandwbraidfor Google,fbclidfor Meta,msclkidfor Microsoft,ttclidfor TikTok,epikfor Pinterest. - The timestamp, so first touch and last touch stay distinguishable.
Write that to the user record at signup, not to a cookie you hope survives. Then match each payment to the person rather than to a session: email first, then phone, then whatever platform customer id you hold. This is the same join that makes attributing Stripe payments to marketing campaigns work, and it is why the join still holds on renewal number eighteen.
If your subscriptions live in WooCommerce rather than a payments platform, the ingestion side comes first — tracking a WooCommerce subscriptions business end to end covers getting those records in.
What is the difference between new, expansion and churned MRR by channel?
They are the four movements that make up the change in your run rate, and splitting them by channel is where the report earns its keep. New MRR is a first payment from a new customer. Expansion is an upgrade or added seats. Contraction is a downgrade. Churn is a cancellation, or a payment that finally gave up in dunning.
Net new MRR per channel is new plus expansion, minus contraction, minus churn. Ranking on the first term alone is how teams buy churn at scale.
Two channels over one month, with round illustrative numbers: channel A adds $8,000 in new MRR and loses $3,100 to churn and downgrades, netting $4,900. Channel B adds $5,200 and loses $600, netting $4,600. On new MRR, A wins by more than 50%. On net they are within a rounding error — and if A’s churn concentrates in month three, next quarter reverses the order.
This is deciding which attribution channel to scale carried into recurring revenue: the single number flatters the channel with the loosest audience.
Why won’t your channel MRR ever match your ad platform’s numbers?
Because the platform reports cash it can claim, inside its own attribution window, using its own model, on the day the payment happened. Your MRR report shows a normalised run rate owned by a first touch that may be two years old. Those two things cannot agree. The mismatches worth knowing by name:
- Interval. A $1,200 annual payment is one purchase in the platform’s September column and $100 a month in yours for a year.
- Window. A renewal fourteen months after the click sits outside every click and view window in the industry, so no platform claims it — and your first-touch report still does.
- Model. A platform credits its own touch; your report credits the first. Where a paid social click and a paid search click sit in one journey, both platforms may claim the customer. Reconcile cash to cash — matched payments against the platform’s reported revenue, same dates, same currency — and never a run rate against cash. What is left after that is real attribution disagreement, which is worth investigating.
How does PartialLeads report recurring revenue by acquisition channel?
It supplies the field your billing system is missing: one acquisition channel per person, resolved from the whole journey rather than from the session that happened to be open at checkout, with every payment matched back to that person.
How the stamp gets created. The tag captures UTMs, the referrer, the landing page and the click identifiers — gclid, gbraid, wbraid, fbclid, msclkid, ttclid, epik — on the first pageview, and the visitor id is set as a first-party cookie by the server rather than by script, so Safari’s cap on script-written cookies does not expire it. Field capture on input records the email and phone as they are typed, before submit, so a person becomes identifiable earlier than the signup form suggests.
How it survives to the payment. The identity layer unions a person’s sessions across six tiers — visitor id, email, phone, IP with user agent, device hash and click id — so a phone click in March and a laptop signup in April resolve to one person. Stripe, Shopify, WooCommerce, GoHighLevel and a universal inbound webhook feed purchases into one pipeline that normalises the identity, deduplicates idempotently on client, source, order id and status phase, matches to a session in confidence tiers (visitor-id echo first, then email, phone, IP), and writes both a first-touch and a last-touch attribution row for every matched payment. Refunds arrive as their own status-phase rows and net against revenue.
Because both rows are written per payment, a renewal keeps the acquisition channel on its first-touch row even though its last-touch row holds nothing useful. That is the stamp, for the life of the account.
Where you read it. The Attribution report carries a channels table with First Touch, Last Touch and PartialLeads Resolved side by side, each with its own purchase count and per-channel split, and columns for revenue, purchases, average order value, average lag, visitors, visitor-to-lead rate and return on ad spend. Paid channels expand into their campaigns. The Recovered Attribution panel itemises revenue a raw last-click view loses, including sessions with no utm_source that the classifier resolved to a real channel.
The honest constraints. PartialLeads reports matched payments and their attribution, not subscription state: no plan object, no normalised MRR figure, no movement split, no cohort report. The normalisation above is arithmetic you run in your billing system or a spreadsheet. What it removes is the hard half — knowing which channel each paying customer came from, and keeping that answer stable across devices, months and renewals. The second constraint is matching: a payment from someone whose sessions were never seen has nothing to join to, so it lands as unmatched revenue rather than being assigned to a channel by guesswork. That unmatched share is visible, and it is a better number to track than a padded channel total.
| What breaks | The mechanism | Where you see it in the dashboard |
|---|---|---|
| Renewals drift into Direct because no click precedes them | First-touch and last-touch rows written for every matched payment | Attribution report, First Touch model |
| The payment arrives with no campaign data on it | Purchase sources matched to a session in confidence tiers: visitor id, email, phone, IP | Purchases ledger, Revenue column |
| Clicked on a phone, signed up on a laptop, paid weeks later | Six-tier identity cluster unions the sessions into one person first | Journey ribbon on the Leads list |
| The link was never tagged, so the channel reads as Direct | Session classification plus referrer and landing-page fallback | Attribution report, Recovered Attribution |
| Two models disagree and nobody knows which to believe | First Touch, Last Touch and Resolved side by side, each with its own purchase count | Attribution report, model comparison |
| A refund inflates a channel’s revenue | Refund rows carry their own status phase and net against the paid row | Purchases ledger |
Tell us what's broken. We'll fix your tracking — free.
Describe the tracking/attribution problem you're stuck on and we'll map it to a fix: server-side conversions to Meta, Google, TikTok and Pinterest, plus first-party tracking that survives Safari. No code required.
Sources
- Meta for Developers — Conversions API overview: https://developers.facebook.com/docs/marketing-api/conversions-api
- Meta for Developers — Customer information parameters: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters
- Meta for Developers — Deduplicate Pixel and Conversions API events: https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events