How to Track Polar Revenue by Marketing Channel

Polar-native products convert at 3.8% from first link click to first payment — but without channel attribution, founders know only their total conversion rate, not which community post, newsletter, or Twitter thread drove each sale. Polar attribution works the same way as Lemon Squeezy or Paddle: pass a session ID into the Polar Checkout via metadata, read it back from the checkout.updated or order.created webhook, match it to the originating click. Polar's API is the cleanest of the three — proper REST with typed responses — so the integration is the shortest. This guide covers the setup for indie founders using Polar for subscriptions, digital products, or one-time sales.

Why This Matters for Your Revenue

3.8% conversion rate is invisible by channel without attribution — and a single headline number flattens five very different channels into one indistinguishable average. A Hacker News post that converts at 9% looks identical to a Twitter thread that converts at 0.4%, because both vanish into the same total. The result is the smallest possible marketing surface — one solo founder, maybe a few hours a week — being spent on the loudest channel rather than the one quietly compounding. For a Polar product doing $5K/month, redirecting two hours a week toward the channel that actually converts is the difference between a side project and a sustainable income.

Once each Polar order carries its originating channel through the metadata bridge, that 3.8% splits cleanly into per-channel conversion rates and revenue-per-click numbers you can actually compare. A Discord that quietly produces 30% of revenue at 8% conversion becomes obvious instead of invisible, and a Twitter strategy that has produced zero paid customers in six months becomes hard to defend. The same Stripe-style attribution mechanics — see Stripe revenue attribution — apply here with even less plumbing, because Polar embeds on your own domain.

Why Polar attribution matters for indie founders

Polar is built for solo founders, indie hackers, and small dev teams selling subscriptions, digital products, and one-time purchases. Its core audience runs lean — usually one or two people splitting product, marketing, and support — which means every promotional hour has to compete with feature work, not against another marketer's calendar. Attribution is the difference between knowing where to spend the next week and guessing.

Knowing whether your Product Hunt post or your Twitter thread drove more paying customers determines where you spend the next week of promotional effort. Without that data, a founder might double down on the loudest channel rather than the highest-converting one — and "loudest" and "highest-converting" almost never agree at indie scale.

If you're driving traffic from a newsletter, a YouTube channel, X, an affiliate, and a Product Hunt launch, you want to know which one is actually paying. Polar's default dashboard shows revenue by product and customer — never by acquisition source. The data exists; it just isn't joined to the click that earned it.

Why every promotional hour competes with feature work

At indie scale, marketing and product are the same person — usually the founder. An hour spent writing a Twitter thread is an hour not spent shipping a feature, and an hour spent on a YouTube video is an hour not spent fixing a customer support ticket. That makes the cost of misallocating promotional time genuinely high, because there is no marketer to absorb the wasted effort. Knowing which channel actually drives paying customers is the difference between writing the next thread because it works and writing it because it's a habit. Attribution converts a high-stakes guess into a one-line dashboard query.

Why "loudest" and "highest-converting" rarely match

The channels that produce the most visible engagement — likes, retweets, comments — almost never produce the most paying customers. A Twitter thread that goes viral routinely drives 50,000 impressions, 200 link clicks, and zero subscriptions; a quiet Hacker News post that no one shares can drive 80 clicks and 8 paying customers in the same week. Without attribution the founder sees only the viral thread's surface metrics and concludes Twitter is the channel that works. The dashboard tells the opposite story once revenue per click is the comparison metric — and that reversal usually persists across months.

The three-step setup

Step 1 — Tracking link per channel. Newsletter, X profile bio, YouTube description, each partner. Why this matters: without a unique tracking link per channel, the cookie has no source value to record. Skipping this step means every conversion gets tagged (direct) regardless of where the click actually came from — and the entire attribution chain becomes useless.

Step 2 — Pass metadata into Polar Checkout. Polar Checkout accepts a metadata field in the create-checkout API. Stuff the visitor ID into it at the moment you create the checkout, on the server, after reading the cookie from the request. Why this matters: Polar's checkout runs on your domain (Polar embeds rather than redirects), but the metadata bridge is still the cleanest way to carry the visitor ID through to the webhook payload without depending on cookie state at checkout completion time.

Step 3 — Listen for order.created and read the metadata. Match it back to the click. Why this matters: the webhook is the only signal that fires reliably on every successful payment, including renewals and webhook retries after a transient failure. Skipping the webhook (and trying to attribute on the success_url redirect instead) loses any conversion where the user closes the tab before redirect, plus every recurring payment after the first.

Why one tracking link per channel is non-negotiable

The instinct at indie scale is to share one Polar buy-link across the newsletter, the Twitter bio, the YouTube description, and every Discord — fewer links to manage, less surface area for typos. That collapses every channel into one undifferentiated bucket on the dashboard, and attribution is impossible no matter how clean the rest of the integration is. A unique tracking link per channel writes a distinct UTM source into the first-party cookie at landing time, which is the value you ultimately credit the sale to. Without distinct links the metadata still flows through, but every channel points to the same anonymous source.

Why metadata is set server-side, not client-side

Polar's create-checkout call accepts metadata from any source, but setting it server-side from the cookie on the inbound request is the only failure-proof option. Client-side reads can race with a not-yet-set cookie on first-page-load conversions, and a value that depends on a JavaScript bundle that has not fully hydrated will be empty more often than teams expect. Reading the cookie inside your /api/checkout route, where you have full request context and a deterministic execution order, eliminates the race condition entirely. The server-side read also lets you cross-reference the visitor ID against your own database before passing it through.

Why order.created beats the success_url redirect

The success_url redirect runs in the buyer's browser and depends on them not closing the tab after payment — and a meaningful percentage of buyers close the tab the moment they see the confirmation page render, before any JavaScript fires. Attribution that depends on the redirect therefore loses every one of those conversions. order.created fires from Polar's infrastructure regardless of what the buyer does next, and re-fires on every renewal afterward, which is what lets LTV per channel update automatically. Use the redirect for the user-facing thank-you experience and the webhook for the actual attribution write.

Access-token scopes you need

The server-side polar.checkouts.create call needs an access token with at least checkouts:write, and the webhook needs the matching webhooks:read scope so you can pull event history if a delivery is missed. Generate a server-only token in the Polar dashboard, never a client-side one — a leaked client token lets anyone create paid checkouts against your products.

Passing metadata into Polar Checkout

// Using polar-sh SDK
const checkout = await polar.checkouts.create({
  product_id: "prod_01h...",
  customer_email: user.email,
  metadata: {
    vid: user.visitorId ?? "",
  },
  success_url: `${process.env.SITE_URL}/welcome`,
});

// Redirect the visitor to checkout.url

Webhook event types worth subscribing to

Polar exposes a granular event stream: order.created for one-time and first-cycle subscription payments, subscription.created for the subscription record itself, subscription.updated for plan changes, and subscription.canceled for churn. Attribute revenue on order.created only — the others are state transitions, not money movements. Subscribing to all of them is fine, but route only one to your attribution writer.

Reading metadata from the Polar webhook

// POST /api/polar/webhook
const event = JSON.parse(rawBody);

if (event.type === "order.created") {
  const vid = event.data?.metadata?.vid;
  const email = event.data?.customer?.email;
  const revenue = (event.data?.amount ?? 0) / 100;

  attributeOrder({ vid, email, revenue });
}

Webhook signature verification with standard-webhooks

Polar follows the standard-webhooks spec: every delivery includes webhook-id, webhook-timestamp, and webhook-signature headers. Verify against the secret you set when registering the endpoint, and reject anything older than five minutes to block replay attacks. Polar's official SDK exposes a validateEvent helper that does both checks in one call.

Polar vs Stripe vs Lemon Squeezy: attribution complexity compared

Polar's attribution setup is actually simpler than Lemon Squeezy's because checkout happens on your own domain — the cookie does not have to survive a cross-domain redirect. Here is how the three platforms compare on the variables that affect how you wire up tracking.

Why Polar's same-domain embed simplifies the integration

Because Polar embeds checkout in an iframe on your own domain rather than redirecting to a separate one, the visitor ID is in scope at checkout creation time without any cross-domain gymnastics. There is no URL-encoding step, no truncation risk, no JSON-string-inside-a-query-param dance — you read the cookie server-side, pass it as a typed metadata field, and the webhook returns it parsed. The integration code is shorter than the equivalent Lemon Squeezy or Paddle setup by roughly a third, and the silent-failure surface is correspondingly smaller. This is the structural reason Polar's setup complexity sits at "Low" in the comparison table while Lemon Squeezy sits at "Medium".

Why a typed metadata field beats a stringified payload

Polar's metadata field accepts a proper JSON object end-to-end — your create-checkout call sends an object and your webhook handler receives the same object, with no JSON.parse step in between. That eliminates an entire class of bugs that plague Paddle Classic and Lemon Squeezy integrations, where a JSON string passed through a URL parameter can truncate, escape incorrectly, or fail to parse on the webhook side. The typed schema also makes IDE autocomplete useful — you discover the available fields by typing rather than by reading the docs, which is the kind of API quality that prevents bugs from being written in the first place.

Channel performance for Polar products

Based on attribution data across TrackRev workspaces using Polar, indie products see very different channel mixes than B2B SaaS. Owned audience and launch-day traffic dominate; paid social barely registers. Newsletter and direct traffic together typically account for 50–65% of attributed revenue on Polar-connected workspaces — a number that would look broken on a B2B SaaS dashboard but is normal for indie distribution.

Direct traffic is unusually high for indie products and represents the strongest growth signal in the data. Most of it is dark social — DMs, Slack pastes, Telegram forwards, screenshot shares — and word of mouth from existing customers. It is the channel you cannot buy and the channel that ranks first on every Polar workspace we have analysed.

Why niche communities outperform larger networks

For Polar and indie products, traffic from Hacker News, IndieHackers, Reddit niches, and small Discord servers consistently outperforms larger paid channels on revenue per click. The clicks are lower in absolute volume but the audience is pre-qualified — they self-selected into the niche your product serves, so the conversion gap closes by 3-5x compared to paid social. "Affiliate / friends" in the table includes informal recommendations from other indie makers, which is why its revenue per click sits at the top. The pattern is consistent across every Polar workspace in the dataset: small, targeted communities convert at rates that make paid social look structurally broken at indie ACVs.

Why direct traffic dominates indie product dashboards

On every Polar workspace we have analysed, the direct channel ranks first by revenue per click — usually by a wide margin. The reason is that almost none of it is truly direct. It is dark social: links pasted into private DMs, Slack threads, Telegram groups, and screenshots shared in WhatsApp; word of mouth from existing customers vouching for the product to a friend; and brand search where the visitor already knew your name from somewhere a tracking link cannot reach. These visitors arrive pre-qualified, which is why their click-to-paid rate sits at 8.1% versus 2.1% for cold Twitter traffic. The implication: invest in being recommendable, not just in being seen.

The Polar audience difference

Polar's typical customer — indie founder, solo developer, two-person SaaS team — is not the same buyer as a mainstream B2B SaaS workspace. The channel mix follows the buyer, not the product. Three structural differences shape which channels actually work for Polar products.

Communities over paid ads. Indie founders are usually targeting developers, designers, no-code builders, and other indie founders — audiences that congregate in niche communities (Hacker News, IndieHackers, niche subreddits, Twitter circles) rather than scrolling Instagram. Paid Facebook/TikTok at indie ACVs ($5–$50/month products) almost never works because CAC sits above LTV on day one. Community presence — answering questions, shipping in public, posting build logs — pays compound returns at zero variable cost.

Word of mouth over partnerships. Formal affiliate programs at indie scale tend to fail the same way: 200 affiliates sign up, three send any clicks, one drives almost all the revenue. What actually works for Polar products is informal recommendations — other indie makers who already use your product telling their followers about it, with or without a referral link. The "Affiliate / friends" line in the table above is mostly that. Plan for it: make your product easy to recommend before you build a tiered commission structure.

Why content marketing is the indie founder's highest-leverage channel

Without a growth team, an indie founder's leverage is one detailed blog post, one good demo video, one open-source library that doubles as a lead magnet. A single tutorial that ranks for a long-tail query keeps generating clicks for years; a Facebook campaign stops the minute the credit card stops. The Polar channel mix reflects this — content and SEO are rarely the top channel by raw clicks but are consistently top three by LTV. The compounding nature of search-indexed content means that the effort invested in month one is still producing attributed revenue in month twelve, which is a payoff curve no paid channel can match at indie scale.

TrackRev and Polar attribution

TrackRev integrates with Polar's checkout and subscription webhooks. Paste your Polar access token into TrackRev's integration settings, and the metadata handshake is wired up at checkout creation time.

Related reading: Lemon Squeezy revenue attribution for the parallel LS flow; Stripe revenue attribution for the simpler Stripe case; Paddle revenue attribution if you also sell through Paddle. TrackRev's free tier covers 1,000 events — usually enough to see channel patterns clearly on a small Polar product.

External references: Polar checkouts API documentation; Polar webhooks documentation; Stripe docs for comparison.