Polar.sh Revenue Tracking: How to Attribute Every Subscription to a Channel

About 68% of Polar.sh subscriptions land in your dashboard with no marketing source attached — no UTM, no referrer, no channel, just a customer email and an amount.

That gap exists because Polar operates as a Merchant of Record: the checkout is hosted on Polar's infrastructure, the payment settles under Polar's Stripe account, and the redirect between your marketing site and the hosted checkout quietly drops the referrer and any query state you didn't explicitly carry forward.

The revenue is real and recurring. The story of where it came from is gone by the time the order.created webhook fires.

Polar's Merchant-of-Record model is a gift for tax and compliance and a landmine for attribution, because the same abstraction that files your VAT also stands between the click and the charge.

Most teams discover this the first time a founder asks 'which channel is our Polar MRR actually coming from?' and the honest answer is a shrug.

Polar.sh revenue tracking is the practice of binding every checkout, subscription, and renewal in your Polar account to the specific marketing channel that originated it — using Polar's metadata object and webhooks rather than a client-side pixel that the checkout redirect breaks.

Why This Matters for Your Revenue

Attribution error on subscription revenue compounds in a way one-time-purchase error never does.

If a channel drives a $29/month plan that a customer keeps for 22 months, that click was worth $638 in lifetime revenue — but your Polar dashboard credits nothing, so you underfund the channel, cut the budget, and starve your highest-LTV acquisition source while pouring money into whatever last-click happens to over-report.

The mistake isn't a rounding error; it's a systematic misallocation that gets worse every renewal cycle.

The money question is concrete. A seed-stage SaaS doing $40K MRR on Polar with 68% of subscriptions unattributed is flying blind on roughly $27K of monthly recurring revenue.

You cannot calculate blended CAC, you cannot compute payback period per channel, and you cannot answer the one question every investor asks — what does it cost to acquire a dollar of Polar MRR, and from where.

Fixing attribution at the Polar layer turns that $27K of dark revenue into a channel P&L you can actually run the business on.

Why Polar.sh Breaks Standard Attribution

Polar is not Stripe with a nicer UI. It is a Merchant of Record layered on top of Stripe, and that architectural choice reshapes what attribution data survives the funnel. Understanding exactly where the signal dies is the whole game.

The Merchant-of-Record redirect severs the referrer

When a visitor clicks 'Subscribe' on your site, Polar's SDK creates a checkout session and redirects the browser to polar.sh (or your custom checkout domain). That cross-origin navigation is where attribution unravels.

The referrer header gets downgraded on many browsers, any client-side state in window is gone, and cookies scoped to your marketing domain do not travel to Polar's checkout origin.

By the time the customer pays, the payment event originates from Polar's domain with no memory of the ad, email, or affiliate link that started the session.

This is the same cross-domain failure that plagues other hosted checkouts.

We covered the general pattern in cross-subdomain conversion tracking, but Polar's case is more severe because the checkout lives on an entirely separate registrable domain, not just a subdomain of yours.

UTMs die at the checkout boundary unless you carry them

A visitor arrives at yoursite.com/?utm_source=newsletter&utm_campaign=launch. Those parameters live in your page's URL. When you call polar.checkouts.create(), nothing automatically forwards them to the checkout session.

Unless you explicitly read the UTMs off the landing URL, stash them, and pass them into the checkout's metadata, they evaporate the moment the redirect happens.

This is why teams that rely on GA4's default channel grouping see almost all Polar revenue as 'Direct' — GA4 never observed the payment event at all, and even the pre-checkout session loses its UTMs at the boundary.

The mechanics of that loss are worth understanding; our guide to why UTM parameters get stripped walks through every layer where it happens.

Recurring revenue exposes the single-touch fallacy

Even if you capture the first-touch channel perfectly, Polar's business model surfaces a deeper problem: a subscription is not one payment, it's a stream.

A channel that acquires customers who churn in month two looks identical to one that acquires 18-month customers if you only credit the first invoice.

Attributing recurring revenue correctly means propagating the origin channel across every renewal, which we detail in subscription LTV attribution.

The Correct Polar.sh Attribution Architecture

The reliable pattern has three stages: capture the source on your marketing site, write it into Polar's metadata at checkout creation, and read it back server-side from the webhook. Each stage has a specific failure mode if you skip it.

Stage 1 — Capture attribution before the redirect

The moment a visitor lands, read the UTM parameters, any click ID, the referrer, and a first-party visitor ID off the URL and document, then persist them.

Do this server-side or in a first-party cookie you control — not in ephemeral JavaScript state that dies on navigation. This is the same first-party capture discipline that keeps link tracking working after iOS 17.

• UTM set: utm_source, utm_medium, utm_campaign, utm_content, utm_term
• Click IDs: gclid, fbclid, ttclid, plus any affiliate ref code
• Context: document.referrer, landing path, and a stable first-party visitor ID
• Timestamp: first-touch time, so you can honor your attribution window later

Stage 2 — Write attribution into Polar metadata at checkout

Polar's checkout API accepts an arbitrary metadata object. This is the load-bearing step: whatever you write here persists onto the resulting order and subscription and shows up verbatim in the webhook payload.

Pass your captured attribution when you create the session.

1import { Polar } from '@polar-sh/sdk';2 3const polar = new Polar({ accessToken: process.env.POLAR_ACCESS_TOKEN });4 5// attribution was captured on the landing page and read from your cookie/session6const checkout = await polar.checkouts.create({7  products: [priceId],8  successUrl: 'https://yourapp.com/welcome',9  metadata: {10    utm_source: attribution.utm_source ?? 'direct',11    utm_medium: attribution.utm_medium ?? '',12    utm_campaign: attribution.utm_campaign ?? '',13    click_id: attribution.gclid ?? attribution.fbclid ?? '',14    referrer: attribution.referrer ?? '',15    visitor_id: attribution.visitor_id,      // first-party ID for cross-device stitching16    first_touch_at: attribution.first_touch_at,17  },18});19 20return Response.redirect(checkout.url);

Stage 3 — Read attribution back from the webhook

Never confirm the sale with a client-side success-page pixel — that path loses a fifth to two-fifths of conversions to Safari ITP and ad blockers, and it fires before you can trust that money actually moved.

Instead, subscribe to Polar's webhooks and read the metadata off the server-verified event. The relevant events are order.created (a payment succeeded) and subscription.created / subscription.updated (lifecycle changes).

1// POST /api/webhooks/polar2import { validateEvent } from '@polar-sh/sdk/webhooks';3 4export async function POST(req) {5  const event = validateEvent(6    await req.text(),7    Object.fromEntries(req.headers),8    process.env.POLAR_WEBHOOK_SECRET,9  );10 11  if (event.type === 'order.created') {12    const { metadata, amount, customer } = event.data;13    await recordRevenue({14      channel: metadata.utm_source || 'direct',15      campaign: metadata.utm_campaign,16      clickId: metadata.click_id,17      visitorId: metadata.visitor_id,18      amountCents: amount,19      customerId: customer.id,20      recurring: event.data.billing_reason !== 'purchase',21    });22  }23  return new Response('ok', { status: 200 });24}

Why server-side is non-negotiable here

The Polar checkout redirect plus Safari's Intelligent Tracking Prevention is a worst-case combination for client-side tracking. WebKit's ITP caps script-writable storage and strips referrers, so a pixel on your success page starts blind.

Reading from the signed webhook payload sidesteps all of it because the event is generated by Polar's servers and delivered to yours. For the full trade-off, see server-side vs client-side tracking.

Handling renewals, upgrades, and refunds

The order.created event fires on every renewal, not just the first payment, and Polar copies the subscription metadata onto each one — so if you wrote your attribution at checkout, every renewal invoice carries the origin channel.

Handle order.refunded and subscription.canceled too, or your channel revenue will overstate as customers churn. Keeping that ledger honest is the subject of refund attribution handling.

Test the metadata round-trip before you trust it

The single most common Polar attribution bug is writing metadata that never comes back.

Run one real checkout end to end in test mode, then inspect the raw order.created payload in your webhook logs and confirm every field you set on checkouts.create() is present and spelled identically.

Metadata keys are case-sensitive and silently dropped if the SDK version mismatches, so a typo like utm_soure produces zero errors and 100% unattributed revenue. Verify the round-trip once and you avoid weeks of silently broken reporting.

Store amounts from the event, not your price table

Because Polar is a Merchant of Record, the amount your customer actually paid can differ from your list price after VAT, currency conversion, discount codes, and proration on upgrades.

Always record amount from the webhook payload rather than the price you think you charged, and keep it in minor units (cents) in the subscription's settlement currency.

Reconciling channel revenue against a hard-coded price table is how attribution reports drift out of sync with your actual Polar payouts by the end of the first quarter.

Choosing an Attribution Model for Recurring Polar Revenue

Once the plumbing works, the model you apply to the data decides whether your decisions are right. For subscription revenue, the choice matters more than most teams assume.

Last-touch under-credits long consideration cycles

Polar is popular with developer-tools and indie SaaS, where buyers discover you through a blog post or an open-source repo months before they subscribe.

Last-touch attribution hands all the credit to whatever they clicked right before checkout — usually a branded search or a direct visit — and erases the content that actually created demand. First-touch overcorrects the other way.

The comparison in last-touch vs first-touch vs linear lays out when each is defensible.

Multi-touch fits developer-led Polar funnels

Because you captured a stable visitor_id in metadata, you can stitch every touch that visitor made before subscribing and distribute credit across them.

For product-led and developer-led motions this is the honest model; we cover it in depth in multi-touch attribution for SaaS and the free-to-paid variant in PLG attribution.

Let sales-cycle length pick the model

There is no universally correct attribution model — the right one is a function of how long your buyers take to decide.

If a typical Polar customer subscribes within a day of first contact, last-touch is roughly honest and cheap to run.

If evaluation stretches over weeks of reading docs and trialing, single-touch throws away most of the signal and a position-based or time-decay model reflects reality far better.

Because you stored a first-touch timestamp and a visitor ID in metadata, you can measure your actual median consideration window and let the data choose, instead of defaulting to whatever your billing dashboard happens to show.

Long B2B cycles break this further, as we cover in B2B SaaS attribution.

How TrackRev Handles This

Building the capture-write-webhook pipeline by hand works, but you then own the metadata schema, the webhook signature verification, the renewal and refund ledger, the cross-device stitching, and the model math forever. TrackRev does it as a product.

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.

You connect your Polar account, TrackRev subscribes to the order.created and subscription.created webhooks, and it reads the attribution metadata you write at checkout — or, if you use TrackRev's first-party link tracking, it injects and captures that metadata for you so you never touch the SDK.

From there it credits the originating channel across the entire subscription lifecycle: first payment, every renewal, upgrades, and clawbacks on refund.

Because the capture is first-party and the ingestion is server-side, it survives the Safari ITP and ad-blocker losses that gut pixel-based tools.

You get a channel-level P&L on your Polar MRR — CAC, payback, and LTV per source — instead of a wall of 'Direct'. The same pipeline underpins our dedicated guide to tracking Polar revenue by marketing channel.

Why the incumbents fail at Polar specifically

The reason you can't just point an existing tool at Polar is that most attribution tools were built for a different revenue shape.

• Triple Whale is built around Shopify and e-commerce orders. It has no native Polar Merchant-of-Record ingestion and models one-time purchases, not multi-invoice subscription streams — so recurring Polar MRR simply doesn't fit its data model.
• HYROS centers on ad-spend attribution for info-products and coaching funnels, carries a meaningful ad-spend minimum, and offers no first-class Polar connector — you'd be reconciling exports by hand.
• Northbeam is a media-mix and paid-social measurement platform priced for brands spending six figures a month on ads; a $40K-MRR Polar SaaS is far below its floor and its model ignores organic and dark-social sources.
• GA4 never sees the Polar payment event at all — it lives on Polar's domain — so revenue collapses into 'Direct'. Our teardown of GA4 not showing revenue by channel explains exactly why.
• ClickMagick and PixelMe track clicks and pixel-based conversions well, but they have no server-side hook into Polar's subscription webhooks, so renewals, upgrades, and refunds go uncounted after the first click.

When NOT to Use TrackRev for This

TrackRev is the wrong tool if your Polar account is pure one-time digital sales with no marketing spend and no channels to compare — if everything comes from a single Product Hunt launch or word of mouth, there is nothing to attribute and a spreadsheet against the Polar dashboard is enough.

It is also not the right fit if you need Polar primarily for invoicing and tax compliance rather than growth measurement; TrackRev is an attribution platform, not a billing or accounting system, and it will not file your VAT or replace Polar's Merchant-of-Record function.

Finally, if your entire go-to-market is a large paid-media operation spending well into six figures monthly and you need media-mix modeling with incrementality testing, a heavier MMM platform is a better match than a first-party attribution tool priced for lean SaaS.

TrackRev earns its keep the moment you run more than one acquisition channel into recurring Polar revenue and need to know, honestly, which one is paying for itself.