traffic.cx blog

https://traffic.cx/blog traffic.cx blog Tested guides for connecting your marketing to revenue. 2026-10-22T00:00:00.000Z traffic.cx https://traffic.cx/blog/revenue-attribution-for-saas Revenue attribution for SaaS: which traffic actually pays 2026-10-22T00:00:00.000Z 2026-10-22T00:00:00.000Z Karthick

Tie Stripe, Lemon Squeezy, Polar or Dodo payments to the traffic that earned them, pick an attribution model, and know which numbers to trust.

<p>Revenue attribution credits each payment to the marketing source, campaign or page that brought the customer. You see revenue by channel instead of visits by channel. For a SaaS, that means connecting your analytics to your payment provider and deciding which visit gets the credit.</p> <h2 id="what-is-revenue-attribution" tabindex="-1">What is revenue attribution?</h2><p>Revenue attribution, sometimes called SaaS marketing attribution when it's applied to subscriptions, answers one question: which traffic paid you? It joins two records that normally live apart: the visit (where someone came from) and the payment (what they paid).</p> <h3 id="revenue-attribution-vs-traffic-analytics-vs-product-analytics" tabindex="-1">Revenue attribution vs traffic analytics vs product analytics</h3><ul> <li><strong>Traffic analytics</strong> counts visits: sources, pages, campaigns, countries. It tells you what brings people in.</li> <li><strong>Product analytics</strong> follows signed-in users inside your app: feature use, retention, activation.</li> <li><strong>Revenue attribution</strong> sits between them. It takes the payment and traces it back to the visit that started the journey.</li> </ul> <p>A channel can send lots of visitors and no customers. Revenue attribution shows that.</p> <h3 id="why-saas-is-harder" tabindex="-1">Why SaaS is harder</h3><p>A shop sale usually happens in one visit. SaaS purchases rarely do:</p> <ul> <li><strong>Trials and delays.</strong> People sign up, try the product and pay days or weeks later.</li> <li><strong>Renewals.</strong> Most revenue arrives months after the first visit, with no visit attached.</li> <li><strong>Refunds.</strong> A payment can be partly or fully reversed later.</li> <li><strong>Several devices.</strong> Someone reads your blog on their phone and buys on their laptop.</li> </ul> <p>Each breaks the simple "visit then purchase" link.</p> <h2 id="why-your-analytics-and-stripe-don-t-agree" tabindex="-1">Why your analytics and Stripe don't agree</h2><p>Your analytics tool knows sources but not payments. Your billing tool knows payments but not sources. One founder described it on Hacker News:</p> <blockquote> <p>"We're living in this unfortunate split where tools like Google Analytics tell you where people came from, and Stripe tells you who paid, but there's no simple way to connect the two." (<a href="https://news.ycombinator.com/item?id=44756020">Lrodd, HN</a>)</p> </blockquote> <p>The same post adds: "UTMs and custom attribution params get lost after signup. Stripe doesn't track attribution."</p> <p>There's a second problem: "direct" inflation. A customer finds you through a Reddit thread, comes back two weeks later by typing your URL, and pays. A tool that credits the last visit says "Direct". The Reddit thread that did the work gets nothing.</p> <h2 id="how-revenue-attribution-works-step-by-step" tabindex="-1">How revenue attribution works, step by step</h2><h3 id="1-capture-the-visit" tabindex="-1">1. Capture the visit</h3><p>Record where each visit came from: referrer, UTM tags (<code>utm_source</code>, <code>utm_medium</code>, <code>utm_campaign</code>) and landing page. Tag your own links consistently. <code>Newsletter</code> and <code>newsletter</code> become two rows in most tools, so pick lowercase names and keep a list. Never put an email address or customer ID in a UTM tag; links get shared and logged.</p> <h3 id="2-carry-an-identifier-into-checkout" tabindex="-1">2. Carry an identifier into checkout</h3><p>The payment provider doesn't know which visit started checkout. You have to tell it. When the visitor starts checkout, read an identifier in the browser (a visit ID, or the UTM values themselves) and pass it to your server. Your server adds it to the checkout's metadata.</p> <p>Do this when checkout starts, not on the thank-you page, which may belong to a later visit.</p> <h3 id="3-match-the-payment-to-the-visit" tabindex="-1">3. Match the payment to the visit</h3><p>When the payment succeeds, the provider sends a webhook. The payment carries the metadata you added. Your system, or your tool, looks up the visit by that identifier.</p> <h3 id="4-credit-a-source-under-a-model-and-lookback-window" tabindex="-1">4. Credit a source under a model and lookback window</h3><p>If the customer visited more than once, a <strong>model</strong> decides which visit gets credit. A <strong>lookback window</strong> decides how far back to look. Both should be explicit settings, not hidden defaults.</p> <h3 id="5-handle-renewals-refunds-and-payments-you-can-t-match" tabindex="-1">5. Handle renewals, refunds and payments you can't match</h3><ul> <li><strong>Renewals:</strong> credit them to the source that won the customer. The renewal was earned by whatever brought them in.</li> <li><strong>Refunds:</strong> subtract them, and credit them against the original payment's source.</li> <li><strong>No match:</strong> keep the payment in your totals as "unattributed". Don't assign a guess.</li> </ul> <h2 id="attribution-models-for-small-saas" tabindex="-1">Attribution models for small SaaS</h2><p>An attribution model is the rule that decides which visit gets credit when a customer visited more than once.</p> <h3 id="last-non-direct" tabindex="-1">Last non-direct</h3><p>Credit the most recent visit before the payment that didn't come straight in (typed URL or bookmark). If every visit was direct, the payment counts as Direct.</p> <p>This fixes the "direct" inflation problem. It shows you what closes sales.</p> <h3 id="first-touch" tabindex="-1">First touch</h3><p>Credit the earliest visit in the lookback window. This shows you what finds customers in the first place. It's useful for judging content and SEO, which often start journeys but rarely finish them.</p> <h3 id="multi-touch-models" tabindex="-1">Multi-touch models</h3><p>Linear models split credit evenly across visits. Time-decay models give more to recent visits. Position-based models weight the first and last.</p> <p>They pay off with many paid channels and enough data to trust small differences. Most small SaaS teams aren't there yet; two simple models compared side by side teach more.</p> <h3 id="choosing-a-lookback-window" tabindex="-1">Choosing a lookback window</h3><p>The window should cover your normal time from first visit to first payment. If most customers pay within a week of signing up, 30 days is plenty. If buyers research for months, go longer. Too short, and early sources lose credit. Too long, and an old visit gets credit for a sale it had little to do with.</p> <p>Check how long your trials take to convert and set the window a bit beyond that. A window longer than the checkout visit only helps if earlier visits are linked to the buyer by a stored identifier, such as a first-party cookie.</p> <h3 id="worked-example-one-customer-three-visits-two-models" tabindex="-1">Worked example: one customer, three visits, two models</h3><p><em>This is an illustrative example with made-up numbers, not customer data.</em></p> <p>A customer makes three visits before subscribing at $29 a month:</p> <div class="docs-table" tabindex="0" role="region" aria-label="Reference table"><table><thead><tr><th scope="col">Visit</th><th scope="col">When</th><th scope="col">Source</th></tr></thead><tbody><tr><td>1</td><td>Day 1</td><td>Google organic search, lands on a blog post</td></tr><tr><td>2</td><td>Day 12</td><td>Your newsletter (<code>utm_source=newsletter</code>)</td></tr><tr><td>3</td><td>Day 15</td><td>Types your URL, starts checkout, pays $29</td></tr></tbody></table></div><ul> <li><strong>Last non-direct</strong> credits the <strong>newsletter</strong>. Visit 3 was direct, so the model skips it.</li> <li><strong>First touch</strong> credits <strong>Google organic search</strong>.</li> </ul> <p>Now follow the subscription. The customer renews for five more months, then asks for a refund on month 3. Under either model, every renewal inherits the first payment's source:</p> <div class="docs-table" tabindex="0" role="region" aria-label="Reference table"><table><thead><tr><th scope="col"></th><th scope="col">Amount</th></tr></thead><tbody><tr><td>Six payments × $29</td><td>$174</td></tr><tr><td>Refund of month 3</td><td>−$29</td></tr><tr><td>Net revenue credited to the source</td><td>$145</td></tr></tbody></table></div><p>Same $145, two answers, neither wrong: the newsletter closed the sale, search found the customer.</p> <p>One catch: this example needs the three visits linked to one person across 15 days. That takes a stored identifier, such as a first-party cookie. Without one, only visit 3 is linked to the payment, and it would count as Direct.</p> <h2 id="the-metrics-that-matter" tabindex="-1">The metrics that matter</h2><div class="docs-table" tabindex="0" role="region" aria-label="Reference table"><table><thead><tr><th scope="col">Metric</th><th scope="col">What it tells you</th></tr></thead><tbody><tr><td>Revenue by source, campaign and landing page</td><td>Where money comes from (payments minus refunds)</td></tr><tr><td>Paying customers</td><td>How many distinct customers each source brought</td></tr><tr><td>Conversion rate</td><td>First-time buyers ÷ unique visitors</td></tr><tr><td>Revenue per visitor (RPV)</td><td>Revenue ÷ unique visitors, for the same period and segment</td></tr><tr><td>LTV by first source</td><td>All revenue so far from customers first won through that source</td></tr><tr><td>Unattributed</td><td>The share of revenue you couldn't link to a visit</td></tr></tbody></table></div><p>Revenue per visitor is the fairest way to compare sources of different sizes.</p> <h2 id="three-ways-to-set-it-up" tabindex="-1">Three ways to set it up</h2><h3 id="diy-utms-into-stripe-metadata" tabindex="-1">DIY: UTMs into Stripe metadata</h3><p>The cheapest route. Read UTM values in the browser when checkout starts, send them to your server, and add them to the Checkout Session's <code>metadata</code>. For subscriptions, add them to the subscription's metadata too, so renewal invoices carry them. Then export payments and group by source in a spreadsheet or SQL.</p> <p>Stripe Payment Links also accept <code>utm_source</code>, <code>utm_medium</code>, <code>utm_campaign</code>, <code>utm_content</code> and <code>utm_term</code> in the link URL and pass them to your redirect URL (<a href="https://docs.stripe.com/payment-links/url-parameters">Stripe docs</a>, accessed 22 Oct 2026). Stripe warns never to put sensitive information such as card or bank details in metadata (<a href="https://docs.stripe.com/metadata">Stripe docs</a>, accessed 22 Oct 2026).</p> <p>What DIY doesn't give you: multiple visits, models, refunds netted against the right source, or an unattributed line. You build those yourself.</p> <h3 id="ga4-stripe" tabindex="-1">GA4 + Stripe</h3><p>Google Analytics 4 can record ecommerce purchase events (<a href="https://support.google.com/analytics/answer/9267735">Google Analytics help: recommended events</a>, accessed 22 Oct 2026). To use it for SaaS revenue, you send purchase events with amounts, usually from your server after Stripe confirms payment, and handle renewals and refunds yourself. It works, but it's a real project for a small team. As the same Hacker News post puts it, "wiring together GA, BigQuery, and Stripe is way too much for a small team" (<a href="https://news.ycombinator.com/item?id=44756020">HN</a>).</p> <h3 id="a-revenue-attribution-analytics-tool" tabindex="-1">A revenue-attribution analytics tool</h3><p>These tools sync payments from your provider and do the matching for you. When comparing them, check:</p> <ul> <li><strong>Payment-provider sync</strong> for the provider you use, not just an events API.</li> <li><strong>Renewals and refunds:</strong> do renewals keep their source? Are refunds subtracted?</li> <li><strong>Unattributed handling:</strong> are unmatched payments shown, or quietly assigned?</li> <li><strong>Model choice:</strong> can you compare at least two models? Is the lookback window a setting?</li> <li><strong>Privacy default:</strong> cookieless or cookie-based by default, and what each mode can link.</li> <li><strong>What the price is based on:</strong> sites, team members or event volume.</li> </ul> <h3 id="how-traffic-cx-does-it" tabindex="-1">How traffic.cx does it</h3><p>traffic.cx is one tool built for this. You connect <a href="/integrations/stripe">Stripe</a>, <a href="/integrations/lemon-squeezy">Lemon Squeezy</a>, <a href="/integrations/polar">Polar</a> or <a href="/integrations/dodo">Dodo Payments</a>, or send payments through the <a href="/docs/payments-api">Payments API</a>. Your checkout passes a pageview ID in its metadata.</p> <p>It offers two models, last non-direct (default) and first touch, with a toggle. The lookback window is 90 days by default and can be set from 7 to 365 days. In the default cookieless mode, a payment links only to the visit where checkout started; a longer lookback needs cookie mode (same browser only). Renewals and repeat customers inherit the attribution of the customer's first payment. Refunds are subtracted on the day they happen and credited to the original payment. Payments it can't match stay in totals as "Unattributed" (<a href="/docs/revenue">how it works</a>).</p> <p>Plans start at $5 a month for 5,000 events, as of 22 October 2026, with unlimited sites and team members on every paid plan (<a href="/pricing">pricing</a>). For side-by-side comparisons, see traffic.cx against <a href="/compare/plausible-alternative">Plausible Analytics</a> and <a href="/compare/datafast-alternative">DataFast</a>.</p> <blockquote> <p><strong>See which traffic pays.</strong> Start a 7-day trial, no card needed (up to 10,000 events). Connect Stripe, Lemon Squeezy, Polar or Dodo from Settings → Revenue. <a href="https://app.traffic.cx/signup">Start your trial</a></p> </blockquote> <h2 id="what-to-trust-and-what-not-to" tabindex="-1">What to trust, and what not to</h2><p>Attribution describes the recorded journey; it doesn't prove a campaign caused a purchase.</p> <h3 id="unattributed-is-not-a-failure" tabindex="-1">Unattributed is not a failure</h3><p>An unattributed payment is real revenue with no visit you can prove. Showing it keeps your total equal to what your provider received. Common causes, in order:</p> <ol> <li>No identifier reached the payment. Check the payment's metadata in your provider's dashboard.</li> <li>The visit wasn't recorded (ad blocker, missing tracker on that page).</li> <li>The identifier came from a different visit, such as a thank-you page on another device.</li> <li>The buyer came back on a later day or another device with no stored identifier.</li> <li>The visit fell outside the lookback window.</li> </ol> <h3 id="direct-vs-unattributed" tabindex="-1">Direct vs Unattributed</h3><p>They're different. <strong>Direct</strong> means a visit was matched, and it had no source to credit: a typed URL or bookmark. <strong>Unattributed</strong> means no visit was matched at all. A high Unattributed share usually means a broken handoff into checkout.</p> <h3 id="cookieless-vs-cookie-mode-the-cross-day-tradeoff" tabindex="-1">Cookieless vs cookie mode: the cross-day tradeoff</h3><p>Cookieless analytics avoids storing an identifier in the visitor's browser. The tradeoff: it can link a payment to the visit where checkout started, but not to a visit on an earlier day. traffic.cx's default cookieless mode rotates visitor identity daily, so it doesn't build a journey across days (<a href="/docs/revenue">docs</a>). Other vendors describe the same tradeoff for their cookieless scripts (<a href="https://datafa.st/docs/gdpr-cookieless-tracking">DataFast docs</a>, accessed 22 Oct 2026).</p> <p>A cookie mode links visits across days on the same browser, so a long lookback window can do its job. Nothing links a different device. In the worked example above, cookieless mode would credit Direct, and cookie mode would credit the newsletter.</p> <h3 id="privacy-and-consent" tabindex="-1">Privacy and consent</h3><p>Linking payments to visits goes further than counting pageviews. Whether you need consent depends on your setup, the mode you use and where your visitors are. This isn't legal advice; check with your adviser before switching on cookie-based tracking. For what traffic.cx collects in each mode, see its <a href="/privacy">privacy notice</a>.</p> <h2 id="a-30-minute-setup-checklist" tabindex="-1">A 30-minute setup checklist</h2><ol> <li>Install your analytics script on every page, including pricing and checkout (<a href="/docs/getting-started">getting started</a>).</li> <li>Verify that a test visit shows up with the right source.</li> <li>Agree on UTM naming: lowercase, underscores, one shared list.</li> <li>Connect your payment provider (or plan your webhook handler for DIY).</li> <li>In your checkout code, read the visit identifier when checkout starts.</li> <li>Add it to the checkout's metadata, and to the subscription's metadata for subscriptions.</li> <li>Open a tagged link, such as <code>?utm_source=setup-check&utm_medium=email&utm_campaign=test</code>.</li> <li>Complete a test payment in your provider's test mode.</li> <li>Confirm the payment appears once, with the expected source and campaign.</li> <li>Test a refund and check that revenue drops on the refund date.</li> <li>Pick a default model and lookback window, and write them down.</li> <li>Check the unattributed share weekly for the first month.</li> </ol> <h2 id="faq" tabindex="-1">FAQ</h2><h3 id="what-is-revenue-attribution-2" tabindex="-1">What is revenue attribution?</h3><p>Crediting each payment to the source, campaign or page that brought the customer. It lets you compare channels by revenue rather than visits.</p> <h3 id="what-is-a-revenue-attribution-model" tabindex="-1">What is a revenue attribution model?</h3><p>The rule that decides which visit gets credit when a customer visited more than once, such as last non-direct or first touch.</p> <h3 id="first-touch-or-last-touch-which-should-a-small-saas-use" tabindex="-1">First touch or last touch: which should a small SaaS use?</h3><p>Start with last non-direct to see what closes sales, then check first touch to see what finds customers. Compare both before moving budget.</p> <h3 id="how-do-i-know-which-marketing-channel-produces-my-paying-customers" tabindex="-1">How do I know which marketing channel produces my paying customers?</h3><p>Carry a visit identifier from your site into checkout, then match each payment back to that visit. Do it yourself with UTMs in Stripe metadata, or use a tool that syncs your payment provider.</p> <h3 id="why-do-customers-who-found-me-weeks-ago-show-up-as-direct" tabindex="-1">Why do customers who found me weeks ago show up as "direct"?</h3><p>Their last visit was typed or bookmarked. Last-touch models credit it unless they skip direct visits, and linking visits across days needs a stored identifier.</p> <h3 id="doesn-t-stripe-show-where-customers-came-from" tabindex="-1">Doesn't Stripe show where customers came from?</h3><p>Not by itself. Stripe records payments, not marketing sources. You pass source data into checkout metadata or use a connected analytics tool.</p> <h3 id="what-should-a-revenue-attribution-report-show" tabindex="-1">What should a revenue attribution report show?</h3><p>Revenue, paying customers, conversion rate and revenue per visitor by source, campaign and landing page, plus an unattributed line.</p> <h3 id="what-is-revenue-per-visitor" tabindex="-1">What is revenue per visitor?</h3><p>Revenue divided by unique visitors, for the same period and segment.</p> <h3 id="should-renewals-be-credited-to-the-original-source" tabindex="-1">Should renewals be credited to the original source?</h3><p>For subscription businesses, usually yes. The renewal was earned by whatever acquired the customer.</p> <h3 id="is-how-did-you-hear-about-us-enough" tabindex="-1">Is "how did you hear about us?" enough?</h3><p>It's a useful cross-check, but answers are incomplete and fuzzy. Use it alongside tracked attribution.</p> <h3 id="do-i-need-consent-for-revenue-attribution" tabindex="-1">Do I need consent for revenue attribution?</h3><p>It depends on your setup and where your visitors are. Linking payments to visits is more than counting pageviews, so check with your adviser.</p> <h2 id="see-revenue-by-source-on-your-own-site" tabindex="-1">See revenue by source on your own site</h2><p>Start a 7-day trial, no card needed, with up to 10,000 events.</p> <p><a href="https://app.traffic.cx/signup">Start your trial</a> · <a href="https://demo.traffic.cx">See the live demo</a> · <a href="/features/revenue-attribution">How revenue attribution works</a> · <a href="/blog/utm-revenue-attribution">Track a UTM campaign through to revenue</a></p> https://traffic.cx/blog/utm-revenue-attribution Track a UTM Campaign Through to Revenue 2026-10-15T00:00:00.000Z 2026-10-15T00:00:00.000Z Karthick

A tested walkthrough: tag a campaign link, carry the visit into checkout, see which campaign earned the payment, and fix revenue that shows as Unattributed.

<p>Campaign tags tell you which link brought a visitor. Revenue attribution tells you which of those visitors paid. This guide connects the two with one tagged link, one visit, one checkout and one payment, then shows the report and what to check when a payment arrives without its campaign.</p> <p>We ran every step below on a traffic.cx test site on 15 October 2026, with the real tracker in a browser and a payment sent through the Payments API. The amounts are test payments, not customer results.</p> <h2 id="what-you-need" tabindex="-1">What you need</h2><ul> <li>The traffic.cx tracker on your site. See <a href="/docs/getting-started">install and verify your first visit</a>.</li> <li>A way to send payments: a connected provider (<a href="/integrations/stripe">Stripe</a>, <a href="/integrations/dodo">Dodo Payments</a>, <a href="/integrations/lemon-squeezy">Lemon Squeezy</a> or <a href="/integrations/polar">Polar</a>) or the <a href="/docs/payments-api">Payments API</a>.</li> <li>A campaign link you control, such as a newsletter, a social post or an ad.</li> </ul> <h2 id="1-tag-the-link" class="step-heading" tabindex="-1"><span class="sr-only">1. </span>Tag the link</h2><p>Add three tags to the link you share:</p> <div class="code-example"><div class="code-head"><p class="code-language">text</p></div><pre tabindex="0" aria-label="text example"><code>https://example.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=october_newsletter</code></pre></div><ul> <li><code>utm_source</code> names where the link was placed: <code>newsletter</code>, <code>x</code>, <code>producthunt</code>. traffic.cx uses it as the visit's source, ahead of the referrer.</li> <li><code>utm_medium</code> names the kind of traffic. It decides the channel: <code>email</code> groups the visit under Email, and mediums such as <code>cpc</code>, <code>ppc</code> or <code>paid_social</code> group it under a paid channel.</li> <li><code>utm_campaign</code> names the campaign. This is the row you will look for in the revenue report.</li> </ul> <p><code>utm_content</code> and <code>utm_term</code> are optional and are recorded too, for telling apart two links in the same campaign.</p> <p>Tag values are stored as you write them, so <code>Newsletter</code> and <code>newsletter</code> become two campaigns. Pick lowercase names with underscores and keep them in one place. Never put an email address, name or customer ID in a tag: campaign links get shared, logged and forwarded.</p> <h2 id="2-check-that-the-visit-arrived" class="step-heading" tabindex="-1"><span class="sr-only">2. </span>Check that the visit arrived</h2><p>Open the link in a normal browser window, then open <strong>Overview</strong> in traffic.cx for today. The sources panel lists the visit's source, and its campaign tab lists <code>october_newsletter</code>. The tags belong to the visit's first page, so the visit should show:</p> <div class="docs-table" tabindex="0" role="region" aria-label="Reference table"><table><thead><tr><th scope="col">Field</th><th scope="col">In our test</th></tr></thead><tbody><tr><td>Source</td><td>newsletter</td></tr><tr><td>Channel</td><td>Email</td></tr><tr><td>Campaign</td><td>october_newsletter</td></tr><tr><td>Landing page</td><td>/pricing</td></tr></tbody></table></div><p>If the visit is missing, check that the tracker loads on that page and that no ad blocker or excluded path is stopping it. The <a href="/docs/getting-started">getting started checks</a> cover this.</p> <h2 id="3-carry-the-visit-into-checkout" class="step-heading" tabindex="-1"><span class="sr-only">3. </span>Carry the visit into checkout</h2><p>A payment provider doesn't know which visit started the checkout. Give it the visit's pageview ID when the visitor starts checkout, not later on a thank-you page:</p> <div class="code-example"><div class="code-head"><p class="code-language">js</p></div><pre tabindex="0" aria-label="js example"><code>const tcx = { tcx_pvid: window.trafficcx?.pageviewId?.() ?? '', tcx_vid: window.trafficcx?.visitorId?.() ?? '', // cookie mode only }; // Send tcx to your server with the checkout request.</code></pre></div><p>Your server puts these values in the provider's checkout metadata, or saves them with the order to send through the Payments API later. Each <a href="/docs/revenue#pass-identifiers-to-checkout">provider guide</a> shows where they go.</p> <p>In the default cookieless mode, the pageview ID links a purchase made during the same visit. If people often leave and come back days later to buy, cookie mode's visitor ID also links their earlier visits. See <a href="/docs/revenue#cookieless-mode-versus-cookie-mode">cookieless mode versus cookie mode</a>.</p> <h2 id="4-record-the-payment" class="step-heading" tabindex="-1"><span class="sr-only">4. </span>Record the payment</h2><p>With a connected provider, the payment arrives on its own. With the Payments API, your server sends it once the payment has succeeded:</p> <div class="code-example"><div class="code-head"><p class="code-language">bash</p></div><pre tabindex="0" aria-label="bash example"><code>curl -X POST https://api.traffic.cx/v1/payments \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "site": "tcx_yoursite", "transaction_id": "order_1001", "amount": 49, "currency": "USD", "pageview_id": "THE_SAVED_TCX_PVID" }'</code></pre></div><p>In our test, the answer confirmed the link straight away:</p> <div class="code-example"><div class="code-head"><p class="code-language">json</p></div><pre tabindex="0" aria-label="json example"><code>{ "ok": true, "transaction_id": "guide_order_…_1", "attributed": true, "amount_reporting": "49.0000", "currency_reporting": "USD", "channel": "Email", "source": "newsletter" }</code></pre></div><p>To see what a broken handoff looks like, we also sent a $29 payment without a pageview ID. It was recorded with <code>"attributed": false</code>.</p> <h2 id="5-read-the-report" class="step-heading" tabindex="-1"><span class="sr-only">5. </span>Read the report</h2><p>Open <strong>Revenue</strong> and choose <strong>Campaigns</strong> in the attribution table. Each campaign shows its revenue, paying customers, visitors, revenue per visitor (RPV), conversion rate (CR) and lifetime value (LTV). Recent payments below list each payment with its source and landing page.</p> <figure class="screenshot"><img src="/images/guides/utm-revenue-light.png" alt="The traffic.cx Revenue page from our test: october_newsletter earned $49 from one visitor, and a $29 payment without a pageview ID shows as Unattributed." width="2056" height="816" loading="lazy" decoding="async"></figure> <p>The $49 payment is credited to <code>october_newsletter</code>, with newsletter and Email as its source and channel. The $29 payment stays in the total as Unattributed instead of being given a source we can't prove.</p> <p>The table uses <strong>last non-direct</strong> attribution by default: the most recent visit before the payment that wasn't direct gets the credit, so a visitor who comes back by typing your address doesn't erase the newsletter. Switch to <strong>First touch</strong> to credit the earliest visit instead. <a href="/docs/revenue#attribution-models">Attribution models</a> explains both.</p> <h2 id="what-we-expected-and-what-we-saw" tabindex="-1">What we expected and what we saw</h2><div class="docs-table" tabindex="0" role="region" aria-label="Reference table"><table><thead><tr><th scope="col">Step</th><th scope="col">Expected</th><th scope="col">Observed on 15 October 2026</th></tr></thead><tbody><tr><td>Visit from the tagged link</td><td>Source newsletter, channel Email, campaign october_newsletter</td><td>All three recorded, landing page /pricing</td></tr><tr><td>$49 payment with the pageview ID</td><td>Credited to october_newsletter</td><td><code>attributed: true</code>, source newsletter, channel Email</td></tr><tr><td>$29 payment without an ID</td><td>Kept in revenue as Unattributed</td><td><code>attributed: false</code>, listed as Unattributed</td></tr><tr><td>Revenue page, Campaigns</td><td>october_newsletter $49, Unattributed $29</td><td>As expected; total $78</td></tr></tbody></table></div><h2 id="when-revenue-shows-as-unattributed" tabindex="-1">When revenue shows as Unattributed</h2><p>Work through these in order. The first one is the most common.</p> <ol> <li><strong>No ID reached the payment.</strong> Open the payment in your provider's dashboard and look for <code>tcx_pvid</code> in its metadata. For the Payments API, log the body you send. An empty value usually means the checkout code ran before the tracker loaded, or didn't run at all.</li> <li><strong>The visit wasn't recorded.</strong> An ad blocker, an excluded path or a page without the tracker means there's no visit for the ID to point to. Check that the visit appears in Overview while you test.</li> <li><strong>The ID came from a different visit.</strong> An ID read on a thank-you page can belong to a later visit than the one that started checkout, for example when the buyer finishes paying on another device. Save the ID when checkout starts and send that one.</li> <li><strong>The buyer came back later.</strong> In cookieless mode, a purchase on a later day or another device has no link to the campaign visit. Cookie mode helps with later days on the same browser; nothing links a different device.</li> <li><strong>The visit is outside the lookback window.</strong> The default is 90 days. You can set 7 to 365 days in <strong>Settings → Revenue</strong>.</li> </ol> <p><a href="/docs/revenue#verify-and-diagnose-attribution">Verify and diagnose attribution</a> covers provider-specific checks.</p> <h2 id="when-the-campaign-is-missing-or-wrong" tabindex="-1">When the campaign is missing or wrong</h2><ul> <li><strong>The tags were stripped.</strong> Link shorteners, redirects and some email tools can drop the query string. Open the link as a reader would and check the address bar on the page that loads.</li> <li><strong>The values don't match.</strong> <code>October_Newsletter</code> and <code>october_newsletter</code> are separate rows. Fix the link and use one spelling from then on.</li> <li><strong>The visit was credited to something else.</strong> Under last non-direct, a later visit from another campaign or search takes the credit. Switch to First touch to see whether your campaign started the journey.</li> <li><strong>The medium put it in a different channel.</strong> A medium such as <code>newsletter</code> instead of <code>email</code> won't group under Email. Use the standard medium names for your channel reports.</li> </ul> <h2 id="next-steps" tabindex="-1">Next steps</h2><ul> <li>Set up your provider: <a href="/integrations/stripe">Stripe</a>, <a href="/integrations/dodo">Dodo Payments</a>, <a href="/integrations/lemon-squeezy">Lemon Squeezy</a>, <a href="/integrations/polar">Polar</a> or the <a href="/docs/payments-api">Payments API</a>.</li> <li>Read <a href="/docs/revenue">how revenue attribution works</a> for refunds, renewals and repeat customers.</li> <li>See <a href="/features/revenue-attribution">what revenue attribution shows</a>, or compare <a href="/pricing">plans and the free trial</a>.</li> </ul>