Revenue attribution

Which traffic actually makes money

XPmetric links each Stripe or Polar payment to the visit that brought the buyer, so you can see revenue by channel, referrer and campaign instead of traffic alone. Connect a read-only key, pass the visitor ID when you create checkout, and every sale lands under the source that started it, net of refunds.

It credits the first visit, and in the default cookieless mode it matches within a day. The limits are listed below, before you build on it.

The XPmetric Channels card switched to Revenue, ranking traffic channels by the revenue of the payments they brought, next to the visitors view.
The Channels card, switched from Visitors to Revenue. Sample data from a demo site.

How does a payment get a traffic source?

Per payment, not per visitor. Four steps, and only the second one needs code.

  1. Connect your provider. Add a Stripe restricted read key or a Polar Organization Access Token in Settings → Integrations. XPmetric syncs payments, renewals and refunds on a schedule, and Sync Now runs it on demand.
  2. Pass the visitor ID at checkout. After its first pageview response the tracking script exposes the visitor and session IDs. Send them to your server and put them in the checkout metadata, as below.
  3. XPmetric looks up the first visit. It reads the IDs back from the payment, finds that visitor's first visit and stores its channel, referrer, UTM campaign and landing page on the payment.
  4. Revenue shows up next to traffic. Once a site has attributed payments, the Channels card gets a Revenue view beside Visitors, and revenue appears on the chart.
Browser
// Browser: read the IDs once tracking is ready, send them with your checkout request
const { v, s } = (await window.xpmetric?.ready?.()) ?? {};
await fetch("/api/checkout/subscription", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ xpm_visitor_id: v, xpm_session_id: s }),
});
Server: Stripe Checkout, subscription
// Server: put the same two keys on the Checkout Session and on the subscription
const metadata = { xpm_visitor_id, xpm_session_id };
const session = await stripe.checkout.sessions.create({
  mode: "subscription",
  line_items: [{ price: process.env.STRIPE_SUBSCRIPTION_PRICE_ID!, quantity: 1 }],
  success_url: `${process.env.APP_URL}/success`,
  metadata,
  subscription_data: { metadata },
});

For a one-time payment, put the keys on payment_intent_data.metadata instead of subscription_data.metadata. Polar takes the same two keys in its checkout metadata. The full routes, with a sandbox test you can run, are in the Stripe guide and the Polar guide.

What does it read from Stripe and Polar?

  • New subscriptions, renewals and one-time payments

    Each is its own payment. Renewals carry the same metadata as the first invoice, so they land under the same source.

  • Refunds

    A refund reduces net revenue under the source of the original payment. It does not add to the payment count.

  • Stripe

    A restricted read key, which cannot change anything in your Stripe account. The sync reads Charges, Invoice Payments, Invoices, PaymentIntents and Refunds.

  • Polar

    An Organization Access Token with read scopes. Create checkout sessions through the Polar API: static Checkout Links cannot carry per-visitor metadata.

  • Any other provider

    Report payments from your own backend through the Payments API, with the same optional visitor ID.

What are the limits of first-touch attribution?

Worth reading before you rely on a number. Settings → Integrations shows how many of your payments are linked to a traffic source, so a gap is visible.

  • First touch only

    The first visit XPmetric recorded for a visitor ID gets the credit. It does not split credit across several visits or channels.

  • Cookieless mode matches within a day

    In the default cookieless mode the visitor ID changes every UTC day. A payment is matched to the visit on the day its ID was issued, so a buyer who first arrived last week and pays today cannot be traced back to the original source. Daily totals and same-day purchases are unaffected.

  • Cookie mode reaches across days

    A site in cookie mode stores a random ID in a first-party cookie, so first touch holds across days. Depending on where your visitors are, a cookie may need a consent banner, and that banner is yours to provide. Compare the tracking modes.

  • No visitor ID, no source

    Payments from static Payment Links, Polar Checkout Links or no-code flows cannot carry the ID. They still count in your revenue totals, but not under any channel. An opt-in email fallback exists for them; it is off by default and needs your own legal basis.

  • Stripe key scope matters for one-time payments

    If the restricted key lacks PaymentIntents read, one-time payments still sync but arrive without a source. Reconnect the key with that permission to link them.

  • Filters show attributed payments only

    With a dashboard filter active, revenue counts only the payments that carry a source, because filters match on the visit.

What happens when the revenue grows?

Real revenue becomes Milestones: your first sale, your 10th sale, your first $1,000 and a ladder of MRR rungs. Rungs from $100 MRR up come with a share card for X, and every number on it is read from your own site.

  • $50MRR
  • $100MRR
  • $250MRR
  • $500MRR
  • $1,000MRR
  • $2,500MRR
  • $5,000MRR
  • $7,500MRR
  • $10,000MRR
  • $25,000MRR
  • $50,000MRR
  • $100,000MRR

Two real cards from proofswap.me: a first sale of €29, 24 days after its first visitor, and €58 of MRR from 2 paying subscriptions.

Common questions

Does XPmetric attribute revenue on its own?

Not by itself. Stripe and Polar never see your visitors, so XPmetric needs the visitor ID at checkout. You pass it as checkout metadata, a few lines on your server, and each payment is then linked to the visit that brought the buyer. A payment that arrives without an ID still counts in your revenue totals, but it does not appear under any channel.

Stripe Checkout guide

Does attribution work with cookieless tracking?

Yes, within a day. In the default cookieless mode the visitor ID changes every UTC day, so a payment is matched to the visit on the day the ID was issued. A buyer who first visited last week and pays today carries a new ID and cannot be traced back to the original source. For first-touch across days, switch the site to cookie mode, which stores a first-party cookie and may need a consent banner depending on where your visitors are.

Tracking modes

What happens to refunds and renewals?

Renewals carry the same metadata as the first invoice, so they land under the same source. A refund reduces net revenue under that source and does not add to the payment count.

Which payment providers work?

Stripe and Polar connect directly with a read-only key or token. Any other provider can report payments through the Payments API, with the same optional visitor ID.

Payments API

Can I attribute payments without changing my checkout code?

There is an opt-in email fallback for payments that arrive without a visitor ID. It is off by default and needs one call on your thank-you page, so it still involves a little code. Update your privacy notice and establish a legal basis before you use it.

Email attribution fallback

See which traffic pays you

Install the script, connect Stripe or Polar and see revenue next to your visitors.

Start free trial

14-day free trial · No credit card · then from $7/mo