Documentation

AI assistant

Metrics

Acquisition tracking

See which channel produced each sale. A small script on your site remembers where a visitor came from; when they buy, Metricneed connects the two.

What it does — and what it never does

Metricneed already knows exactly how much money you made, because it reads it from your payment provider. What it can't know on its own is where that money came from. Acquisition tracking fills in that one missing piece.

Your revenue figures never change. The amount of every sale always comes from Stripe, Polar, Creem and the rest — this feature never adds, recalculates or estimates revenue. It only attaches context to money that a payment provider already confirmed.

It is also deliberately narrow. It does not identify anyone, build profiles, track page views, record what people do inside your product, or follow anyone across other websites. It records the acquisition context of a visit — UTM parameters, the referring domain, the landing page — against a random id, and nothing else. No IP address, no email, no fingerprint.

1. Install the snippet

Create a site key in Settings → Tracking, listing the domains your site runs on. Then paste this into the <head> of every page, including your pricing page: 

<script defer src="https://metricneed.com/mn.js" data-key="mnp_YOUR_KEY"></script>

The key is not a secret — it ships in a public script tag, and it can only ever record a visit. What protects it is the list of domains you declared: events from anywhere else are ignored.

On arrival the script generates a random session id, stores it in localStorage, and remembers the visit's UTM parameters and referrer. A later visit with different UTM parameters updates the last touch but never overwrites the first — Metricneed keeps both, so you can look at either without deciding up front.

2. Connect it to your checkout

The session id has to survive all the way to the payment. How much work that is depends entirely on how your checkout works.

If you use a hosted payment link — nothing to do

If your buy button is a plain link to a Stripe Payment Link or a Polar checkout link, the script handles it. When the visitor clicks, it appends the reference id to the URL (client_reference_id for Stripe, reference_id for Polar). You write no code at all. If the link already carries one of those parameters, yours always wins.

If you create the checkout on your server — a few lines

A custom flow never navigates to a link we can decorate, so you pass the id yourself. Read it on the front end: 

const referenceId = window.metricneed?.getReferenceId()

await fetch('/api/checkout', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ priceId, referenceId })
})

Then attach it when you create the checkout. Stripe:

// your backend
const session = await stripe.checkout.sessions.create({
  line_items: [{ price: 'price_123', quantity: 1 }],
  mode: 'payment',
  success_url: 'https://acme.com/thanks',
  client_reference_id: referenceId   // <- from metricneed.getReferenceId()
})

Polar:

// your backend
const checkout = await polar.checkouts.create({
  products: ['product_123'],
  successUrl: 'https://acme.com/thanks',
  metadata: { referenceId }          // <- from metricneed.getReferenceId()
})

That's it — Metricneed picks the reference up on its next sync and attributes the sale. Nothing needs to happen at the moment of purchase.

Provider support

Attribution needs the provider to carry a reference id from checkout through to the sale. Not all of them do, and we'd rather say so than let you assume otherwise:

  • Stripe — fully supported. Payment Links and API-created Checkout Sessions both carry client_reference_id.
  • Polar — fully supported. Checkout links accept reference_id directly, and API-created checkouts accept it in metadata.
  • Lemon Squeezy, Creem, Gumroad — not yet. Their sales keep counting toward your revenue, and show up as not attributed.
  • RevenueCat — not planned. Purchases happen inside a mobile app, so there is no web visit to connect them to.

Why some revenue says “not attributed”

Some of it always will, and that's the honest answer rather than a problem to hide. Expected causes:

  • the sale happened before you installed the snippet;
  • the buyer blocked the script, or cleared their browser storage;
  • they bought through a checkout the snippet doesn't cover;
  • the provider has no reference-id support (see above);
  • more than 90 days passed between the first visit and the purchase.

Metricneed never guesses. It does not match on IP address, timing, amount or browser fingerprint — if the reference id isn't there, the sale stays unattributed. A confidently wrong channel would be worse than an honest gap, because you'd make decisions on it.

Unattributed revenue is always shown as its own line in the acquisition widget, counted in the total, and never hidden.

Subscriptions and renewals

A renewal has no checkout of its own, so it inherits the channel that won the customer in the first place. If someone signed up from a newsletter link, every month they renew keeps counting toward that newsletter.

The script stores one random id in localStorage. It sets no cookies and sends nothing to any third party. Even so, storing an identifier on a visitor's device generally requires consent under the ePrivacy Directive and the GDPR, so the script can wait for it: 

<script defer src="https://metricneed.com/mn.js" data-key="mnp_YOUR_KEY" data-require-consent></script>

// later, when the visitor accepts:
metricneed.consent('granted')

// if they decline (also clears anything already stored):
metricneed.consent('denied')

With data-require-consent, nothing is read, written or sent until you call metricneed.consent('granted'). Calling it with anything else stops tracking and erases what was stored. Without the attribute, the script starts immediately — use that only if your own consent banner already gates when the script loads.

We are not your lawyers, and which regime applies depends on where your visitors are. What we can tell you precisely is what the script collects: UTM parameters, the referring domain, the landing path, and a random id. Nothing else ever leaves the browser.

Script API

  • metricneed.getReferenceId() — the current session id, for a server-created checkout. Returns null before consent is granted.
  • metricneed.consent('granted' | 'denied') — start or stop tracking.
  • metricneed.reset() — forget the current session; the next visit starts a new one.

Two optional attributes on the script tag: data-require-consent (above) and data-reference-id, which makes the script use an id you already generate instead of creating its own — useful if your site has its own anonymous session concept.

Seeing the results

On your dashboard, add the Revenue by acquisition widget. You can group by channel, source, medium, campaign or referrer, and switch between first and last touch — both are always recorded, so switching costs you nothing.

Acquisition data is intentionally not available on public dashboards. Sharing your MRR is one thing; publishing your campaign names and referring domains would hand out your growth playbook to anyone with the link.