How Revenue Attribution Works

traffic.cx shows which traffic makes money: revenue, customers, revenue per visitor (RPV) and conversion rate by channel, source, campaign, landing page, country and device.

Choose how to send payments

Way	Best for	Guide
Stripe	Checkout, Payment Links, PaymentIntents and subscriptions	Stripe
Dodo Payments	One-off payments and subscriptions	Dodo Payments
Lemon Squeezy	Orders and subscriptions	Lemon Squeezy
Polar	Orders and subscriptions	Polar
Payments API	Any other provider, or your own billing	Payments API
The script	Sites with no server code at checkout	Purchases from the script

You can use several. A payment the script reports is replaced by a verified one with the same ID, so it is never counted twice.

How a payment finds its visit

The payment type and available identifiers determine the link:

Refunds inherit attribution from the original payment they reference. Without that original, the refund is unattributed.
Renewals for a known customer inherit the customer's first earlier payment's attribution, even if a new visit ID is supplied.
Other payments use the pageview ID (tcx_pvid, from trafficcx.pageviewId()) to find a recorded pageview and its visitor. A cookie-mode visitor ID (tcx_vid) can also identify the visitor. Their eligible visits are evaluated within the lookback window, 90 days by default.
Earlier customer payments provide a fallback when no visit is matched and an earlier attributed payment exists for that customer.
No match: the payment remains in the totals as "Unattributed". Direct is different: it is a matched visit with no non-direct source to credit.

Pass identifiers to checkout

Install and verify the tracker first. At checkout time, read the IDs in the browser and pass them to your existing checkout endpoint. Do not capture them before the tracker has loaded. The visitor ID is available only in cookie mode; the pageview ID also works in cookieless mode.

// In the browser, when the visitor starts checkout
const tcx = {
  tcx_vid: window.trafficcx?.visitorId?.() ?? '', // cookie mode only
  tcx_pvid: window.trafficcx?.pageviewId?.() ?? '',
};

For a server-created checkout, send this tcx object to your own server:

// Extend your existing authenticated checkout request with attribution metadata.
const response = await fetch('/api/checkout', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ tcx }),
});
if (!response.ok) throw new Error('Checkout could not be created');
const { url } = await response.json();
window.location.assign(url);

On your server, keep your existing authentication, cart validation and error handling. Select products and prices from your trusted catalogue. Only accept the two expected attribution fields; a pageview ID is 16 hex characters and a visitor ID is 32. These identifiers are attribution hints, not proof of identity or payment. Keep provider credentials on the server. Each provider guide shows how the validated tcx object fits into its checkout request.

Cookieless (the default) has no visitor cookie. A valid pageview ID can link a payment to a recorded visit, but daily visitor-identity rotation does not establish a journey across days. Missing or blocked tracking can leave a payment unattributed.
Cookie mode uses a visitor cookie with a lifetime of up to 400 days; attribution still uses the configured lookback window. Browser deletion, tracking protections and device changes can break the link. Switch it on in Settings → Tracking → Visitor identity only after considering your privacy and consent responsibilities.

Attribution models

The Revenue page has a toggle for two models:

Last non-direct (the default): the latest visit before the payment that didn't come straight in (typed URL, bookmark). If every visit was direct, the payment counts as Direct.
First touch: the visitor's earliest visit in the lookback window.

Both are worked out when the payment arrives and stored with it, so switching is instant. Settings → Revenue sets the lookback window (7 to 365 days); changing it credits past payments again.

Events take a few seconds to reach the database. traffic.cx therefore checks each payment again a minute and ten minutes after it arrives, in case its visit wasn't stored yet.

What the numbers mean

Metric	Definition
Revenue	Payments minus refunds, in the site's currency, by payment time
Paying customers	Distinct customers who paid in the period
Conversion rate	First-time buyers ÷ unique visitors
Revenue per visitor	Revenue ÷ unique visitors
Average order value	Revenue ÷ payments that aren't refunds
LTV	All the revenue so far of the customers first won in the period, per customer

Currencies. Payments retain their original amount and currency. Supported currencies are converted to the site's reporting currency using historical European Central Bank reference rates, rather than today's rate. Missing rates can delay conversion; changing your site's reporting currency recalculates reporting amounts.
Refunds are subtracted on the day they happen, credited to the payment they refund.
Tax. Dodo Payments, Lemon Squeezy and Polar collect sales tax and VAT as the merchant of record, so their revenue leaves that tax out. Stripe and the Payments API count the amount you send.
Shared links don't show revenue.

Verify and diagnose attribution

Use a separate test site and your provider's test or sandbox environment to keep test payments out of your business reports. Test-mode connections still import their payments into the selected traffic.cx site.

Open a tagged page on your installed site, for example https://example.com/?utm_source=setup-check&utm_medium=email&utm_campaign=integration-test.
Confirm a pageview ID is available, then start checkout from that visit with the identifiers attached.
Complete the provider's test checkout. In Settings → Revenue, check the connection and webhook log, then find the payment in Revenue.
Check its source/campaign, amount, currency and selected attribution model. Test a refund too; it should reduce revenue on the refund date. For subscriptions, verify a renewal for the same customer without a fresh visit link.

If no payment appears, check test/live mode, credentials, webhook errors and the connection's sync status. If the payment appears as Unattributed, check the metadata on the provider's actual payment/order, whether the visit was recorded, and the lookback window. Imported historical payments usually lack identifiers from before installation. Retry attribution can help late events, but cannot reconstruct missing visits.