Ecommerce Revenue Attribution: How to Tie Every Order to a Traffic Source and Ad Campaign

How to attribute ecommerce revenue to traffic sources and ad campaigns: the attribution models in plain terms, the three ways to link an order to a visit, what Shopify, WooCommerce, Stripe and Foxy each support, and how to compare your numbers with Meta and Google Ads.

Ecommerce Revenue Attribution: How to Tie Every Order to a Traffic Source and Ad Campaign

The short answer: As of October 8, 2026, ecommerce revenue attribution takes two links and one rule. Link one: record where every visit came from, using UTM parameters on every campaign link plus the referrer. Link two: connect each order to the visit that produced it, either with a purchase event that carries the order value on the thank-you page, with a session ID stored on the payment in your processor, or by matching the buyer's email. The rule is the attribution model, which decides which visit gets credit when a buyer came more than once. Last click on your own data is the simplest model to trust. Expect Meta and Google Ads to report more revenue than your store, because they use their own windows, including view-through.

This guide is for store owners and marketers who want to know which channels, campaigns and ads actually produce orders, not just clicks. It covers the models, the tracking methods, what each major platform gives you out of the box, and how to read your numbers next to what the ad platforms claim.

TL;DR

  • Attribution is only as good as the link between an order and a visit. Fix that before you argue about models.
  • Three ways to make the link: a purchase event with value on the confirmation page, a session ID saved on the payment server side, or an email match. Server-side is the most reliable.
  • Shopify and WooCommerce both ship order attribution reports. Shopify defaults to last non-direct click; WooCommerce uses last click.
  • Name UTM campaigns once, in lowercase, and never rename them mid-flight. Untagged paid traffic shows up as direct.
  • Meta and Google Ads use their own windows (Meta: up to 7-day click plus 1-day view; Google Ads: 30-day click by default). Their totals will not match yours. Compare the gap, per campaign, not the totals.

What ecommerce revenue attribution is

Ecommerce revenue attribution assigns the money from each order to the marketing source that brought the buyer: a Google Ads campaign, a Meta ad, an email, an affiliate, an organic search. The output is a table of revenue by source, campaign or ad, which you can divide by spend to get return on ad spend.

It is different from conversion tracking. Conversion tracking counts that a purchase happened. Revenue attribution answers which visit, from which source, gets credit for that purchase and how much of it.

Every setup has the same three parts:

Part What it does Where it usually breaks
Source capture Records UTM parameters and referrer when a visit starts Untagged links, mistyped campaign names, referrers stripped by apps
Order link Connects a completed order to that visit Checkout on another domain, buyer switches device, thank-you page never loads
Attribution model Decides which visit gets credit when there were several Comparing reports that use different models as if they were the same

If the first two parts are weak, no model will rescue the numbers. Most "attribution problems" are order-link problems.

Attribution models: first touch, last touch, multi-touch and data-driven

An attribution model is the rule for splitting credit when a buyer visited more than once before ordering. The common models, described fairly:

Model Who gets credit Good for Weakness
First touch (first click) The visit that introduced the buyer Seeing which channels find new customers Ignores everything that closed the sale
Last touch (last click) The visit right before the order Simple, auditable, each order counted once Undervalues channels that start journeys
Last non-direct click The last visit that was not direct Stops returning buyers who type your URL from erasing the campaign that sent them Still single-touch
Linear (multi-touch) Equal share to every visit A balanced view of long journeys Treats a stray visit like the one that mattered
Data-driven A model estimates each touchpoint's contribution from your data Uses more of the path; the default in Google Ads A black box you cannot audit, and it only sees the platform's own data

Two things have changed recently that many guides miss:

  • Google Ads now offers only two models. First click, linear, time decay and position-based are no longer supported; conversion actions that used them were moved to data-driven, and last click is still available. Data-driven is the default for most conversion actions (Google Ads Help, About attribution models).
  • Meta separates the model from the window. Ads Manager offers a standard model, where you choose the click, view and engagement windows, and an incremental model that optimizes and reports on conversions it predicts the ad caused. Meta warns that results from ad sets with different attribution models cannot be compared in the same table (Meta Business Help Center, About attribution models and attribution settings).

Store platforms keep it simpler. Shopify Analytics supports last non-direct click, last click, first click, any click and linear (Shopify Help Center, Marketing reports). WooCommerce's built-in order attribution uses last click (WooCommerce, Order Attribution Tracking).

Which attribution model an ecommerce store should use

Use last click, or last non-direct click, on your own first-party data as the number you run the business on. Every order is counted once, the total matches your order count, and anyone can trace an order back to the visit that got credit.

Then add views, not replacements:

  1. First click to see which channels introduce new buyers. If a channel looks weak on last click and strong on first click, it is starting journeys that others finish.
  2. Any click in Shopify to reconcile with a single ad platform. Shopify notes this model allocates more credit than orders you received, so use it one channel at a time.
  3. Data-driven inside Google Ads, for bidding. Let the platform optimize on it, but do not use it to settle budget arguments between platforms, because it only sees Google's touchpoints.
  4. Holdout or lift tests when a large budget decision depends on whether a channel causes sales or just sits on the path. No click-based model answers that.

Multi-touch tools are worth paying for when journeys are long, several paid channels overlap, and spend is large enough that a 10% reallocation matters. For most small and mid-size stores, a clean last-click setup with good UTMs beats a sophisticated model on dirty data. Our comparison of revenue attribution tools for ecommerce covers the multi-touch options.

There are three ways to connect an order to the visit that caused it. They differ in reliability and in how much code they need.

Method How the link is made Reliability Effort Breaks when
Purchase event on the thank-you page Your analytics script fires a purchase event with order ID, value and currency when the confirmation page loads Medium Low The page does not load, an ad blocker stops the script, or the checkout is on a domain you cannot add scripts to
Server-side processor metadata Your server writes the visitor's session ID onto the payment object; analytics reads it from the processor High Medium You forget to pass the ID on one checkout path
Email or customer match Your site identifies the visitor by email; the order is matched on the same email Medium Low to medium The buyer uses a different email, or never identifies before paying

1. Purchase event with value on the thank-you page

This is the method most analytics tools document first. When the confirmation page loads, fire a purchase event that includes the order total and currency. In GA4 the purchase event takes a transaction_id, value and currency:

gtag("event", "purchase", {
  transaction_id: "T_12345",
  value: 72.05,
  currency: "USD",
});

Three details from Google's reference matter for revenue accuracy (Google Analytics, Recommended events):

  • transaction_id is required and is what prevents a duplicate purchase when the buyer reloads the page.
  • currency is required whenever you set value, or revenue metrics will not compute correctly.
  • value should be the sum of item price times quantity, without shipping or tax.

Fire it on the confirmation page, not on the "Place order" click. A click records intent, not a completed payment. The weak spot is that this method trusts the browser: if the page never loads or the script is blocked, the order is invisible.

2. Server-side processor metadata

This is the most reliable method because the link lives on the payment record itself, not in the buyer's browser. Your page reads an ID for the current session, sends it to your server with the checkout request, and your server saves it in the payment's metadata. Your analytics tool reads the payment from the processor and joins it to the session.

Stripe is the common case. Two rules from Stripe's documentation shape how you do it (Stripe Docs, Metadata):

  • Metadata does not copy between related objects by default. Put the ID on the object your analytics tool reads.
  • When you create a Checkout Session, payment_intent_data.metadata sets metadata on the underlying PaymentIntent, and subscription_data.metadata sets it on the Subscription. Never store card or bank details in metadata.
// Stripe Checkout Session with the visitor's session ID attached
const session = await stripe.checkout.sessions.create({
  line_items,
  mode: "payment",
  success_url: "https://yourstore.com/thank-you",
  metadata: { humblytics_view_id },
});

The advantage: if the buyer closes the tab before the thank-you page, the payment still carries the ID and is still attributed.

3. Email or customer match

If you cannot change the server code, identify the visitor by email on your site, for example when they enter it at checkout, and match it to the email on the order. This works for embedded checkouts such as Stripe Elements and for flows where you control the page but not the backend. It fails when the buyer uses a different email at payment, or never enters one before paying.

Platform notes: Shopify, WooCommerce, Stripe and Foxy

What you can do depends on who runs the checkout. If the checkout runs on a domain you control, all three methods are open to you. If the platform hosts it, you get what the platform exposes.

Platform Built-in attribution Model What an outside analytics tool can see
Shopify (Shopify Payments, Shop Pay) Marketing reports by channel and campaign, with ad spend and ROAS for connected ad platforms Last non-direct click by default; five models available Checkout pixels run in a sandbox; only tools built on Shopify's order data or pixel API see orders
WooCommerce Order Attribution, built in, with origin, UTMs, device and session page views per order Last click Full access; you control the site and the confirmation page
Stripe Checkout and Payment Links None for traffic source Not applicable Session ID in metadata (Checkout via API), or Checkout Session ID on the return URL (Payment Links)
Foxy None for traffic source Not applicable Transaction webhook joined to the site session

Shopify

Shopify's own reports are the starting point for a Shopify-only store. The Performance by marketing channel report shows sessions, sales, orders, ad spend, ROAS and CAC per channel, split into paid, organic and direct, and defaults to the last 30 days on last non-direct click. Performance by marketing campaign groups the same metrics by campaign (Shopify Help Center, Marketing reports).

Three details to know before trusting the totals:

  • Canceled, pending and unpaid orders are included in the marketing reports. Test and deleted orders are not.
  • Sales are not payments. Shopify's sales reports show the value of goods sold, not money received, and chargebacks are not included.
  • First interaction resets after 30 days. If a visitor does not buy within 30 days of a session, the next referrer becomes their first interaction.

For outside tools, the constraint is the checkout. Shopify loads custom pixels in a sandbox, and not all pixel functionality works there (Shopify Help Center, Custom pixels). A general analytics script on your storefront can still measure product pages, carts and A/B tests, but it cannot read Shop Pay or Shopify Payments transactions. If you need more than Shopify's reports, use an attribution app built on Shopify's order data.

WooCommerce

WooCommerce has built-in order attribution. Turn it on at WooCommerce > Settings > Advanced > Features > Order Attribution. Each order then stores the referring source, the UTM source, medium, campaign, content and term, the device type, and the number of page views in the session (WooCommerce, Order Attribution Tracking).

Its rules are worth knowing because they differ from most analytics tools:

  • UTM and organic sources always override an earlier source.
  • A direct visit never overrides an earlier source.
  • A referral overrides the earlier source only if no session is active; a session lasts 30 minutes.
  • The cookies expire with the session, so it cannot follow a buyer across sessions. A buyer who clicks an ad today and returns tomorrow by typing your URL is recorded as direct.

That last rule is the main reason to add an analytics tool that keeps the source across sessions if your buyers rarely order on the first visit.

Stripe records payments, not traffic sources, so you add the link yourself. With Stripe Checkout created through the API, put the session ID in metadata as shown above. With Payment Links, where you cannot run server code, set the confirmation page to redirect to your site with the Checkout Session ID on the URL, for example https://yourstore.com/thank-you?stripe_session_id={CHECKOUT_SESSION_ID}. Your analytics script reads it on arrival and joins it to the session. This only works when the buyer finishes on the same browser that started the visit.

For subscription businesses, renewals and trial lag change the picture; see how to track Meta and Google Ads ROAS through to Stripe subscriptions.

Foxy

Foxy sends each completed transaction to a JSON webhook. An analytics tool that receives the webhook, with line items and customer details, can join it to the visit its site script recorded, so the order is attributed even if the receipt page never loads.

UTM hygiene: the cheapest attribution fix

Most revenue that ends up "unattributed" or "direct" was paid for. The fix costs nothing but discipline.

  • Tag every paid, email, social and affiliate link with at least utm_source, utm_medium and utm_campaign. Build them with a UTM builder so the format stays consistent.
  • One spelling per campaign. Spring_Sale, spring-sale and springsale are three campaigns in most reports. Pick lowercase with hyphens or underscores and stick to it.
  • Do not rename live campaigns. If spend is matched to revenue by campaign name, a rename splits one campaign into two rows.
  • Keep utm_medium honest. Use cpc or paid for paid traffic, email for email. Channel groupings depend on it.
  • Never put UTMs on internal links. A UTM on your own homepage banner starts a new attributed visit and steals credit from the source that brought the buyer.
  • Click your own ads after launch and check the landing URL carries the tags you expect.

When UTMs are missing, paid traffic often lands in direct. Our guide to what direct traffic really is explains how to find revenue hiding there.

Refunds, cancellations and net revenue

Attributed revenue should be net of refunds, or your best-looking campaign may be the one with the most returns.

  • Tracking-script methods count the sale when it happens and do not learn about the refund unless you send one. GA4 has a refund event that takes the original transaction_id and, optionally, the refunded items (Google Analytics, Measure ecommerce).
  • Store reports can include orders that never paid. Shopify's marketing reports include canceled, pending and unpaid orders, so compare them with net sales before you report ROAS.
  • Ad platforms do not see refunds unless you send adjustments. A campaign that drives high return rates looks better in Ads Manager than in your bank account.

A practical rule: report gross attributed revenue weekly for speed, and net attributed revenue monthly, once refunds for that period have settled. If a campaign's refund rate is well above your store average, judge it on net.

Cross-device journeys and other limits of click-based attribution

Click-based attribution follows a browser, not a person. Some journeys will always break:

  • Cross-device. A buyer clicks an ad on their phone and orders later on a laptop. The laptop visit has no campaign, so the order is credited to direct or to whatever source the laptop visit had. Server-side metadata does not fix this, because the link starts in the browser.
  • View-through. Someone sees an ad, never clicks, and searches your brand later. Your data credits the search. Meta may credit the ad.
  • Long gaps. Session-scoped tracking, such as WooCommerce's, forgets the source between sessions.
  • Stripped referrers. In-app browsers, privacy tools and some email clients drop the referrer, so untagged visits arrive as direct.
  • Offline and phone orders. Orders entered by staff have no web visit to attach to.

None of these makes the data useless. They make it a consistent undercount for upper-funnel and view-driven channels. Know which way the bias runs and correct for it with tests, not guesses.

How to compare your numbers with Meta and Google Ads

Expect Meta and Google Ads to report more revenue than your store attributes to them. They count conversions inside their own windows, they can count views, and each platform claims the order for itself.

Source Default counting What it can include that your store data does not
Meta Ads Manager (standard model) Click-through within 1 or 7 days of a link click; view-through within 1 day of an impression; engage-through within 1 day of a non-link interaction Views without a click, the same order claimed by other platforms
Google Ads Data-driven model for most conversion actions; click-through window 30 days by default (1 to 90 depending on source); view-through 1 day; engaged-view 3 days Credit split across Google touchpoints, longer window, views
Your store or analytics tool Usually last click or last non-direct click on first-party UTMs Only orders it can link to a tagged or referred visit

Window defaults are from Meta Business Help Center, About attribution models and attribution settings and Google Ads Help, About conversion windows.

How to run the comparison so it means something:

  1. Use the same dates and the same campaigns. Match on utm_campaign, which means the names in your ad accounts and your UTMs must be identical.
  2. Compare per campaign, not account totals. A steady gap is normal. A campaign whose gap is far larger than the others is the one being credited for sales your data cannot trace to it.
  3. Watch the gap over time. If a campaign's platform revenue rises and your attributed revenue does not, the platform is likely counting views or overlapping with other channels.
  4. Never add the platforms together. Meta, Google and your email tool can each claim the same order. Their sum will often exceed your actual revenue.

A worked example, with hypothetical numbers: in September a store spends $6,000 on a Meta prospecting campaign. Ads Manager reports $21,000 in purchase value, a ROAS of 3.5. The store's own last-click data attributes $9,600 of orders to visits tagged with that campaign, a ROAS of 1.6. Meta's number includes 1-day view-through and orders also credited to Google and email. Neither number is wrong. The store's number is the floor it can verify; the gap tells it how much it is taking on faith. For the arithmetic of ROAS itself, see how to calculate return on ad spend.

What this approach does not measure

Be precise about the limits so nobody reads more into an attribution report than it contains.

  • Single-touch credit. Last click and last non-direct click give one visit all the credit. They do not show what started the journey.
  • No incrementality. An attributed order shows a campaign was on the path, not that the sale would not have happened without it. Holdout or geo lift tests answer that.
  • No view-through. First-party click data cannot see people who only saw an ad.
  • Cross-device gaps undercount mobile-first and social channels.
  • Brand and offline effects. Podcasts, TV, word of mouth and in-store sales show up as direct or organic search, if at all. Media mix modeling estimates these from spend and sales over time; it is a different tool for a different question.

How Humblytics fits

Humblytics connects ad spend, site behavior, A/B tests and processor-verified revenue in one place. Here is exactly what it covers for ecommerce:

  • Revenue verification: Stripe and Foxy. For Stripe it reads a humblytics_view_id stored in metadata on a PaymentIntent, Invoice, Subscription, Checkout Session or Customer; supports Payment Links through the stripe_session_id redirect; and supports email match with trackCustomer. Foxy connects through its transaction webhook. A custom purchase event exists for other providers where you control the confirmation page, with caveats listed in the docs.
  • Shopify: storefront analytics, funnels, heatmaps and A/B tests work. Shop Pay and Shopify Payments revenue is not supported, because Shopify's checkout runs where the script cannot reach it. If your store sells only through Shopify checkout, use Shopify's marketing reports or a Shopify attribution app for revenue.
  • Ad spend: Meta and Google Ads, read-only, matched to revenue by utm_campaign. TikTok, LinkedIn and Microsoft Ads are not connected.
  • Model: last touch on first-party UTM and session matching. No multi-touch, no view-through, no media mix modeling.
  • Pricing: Business is $79 a month, Scale is $279 a month, with a 14-day trial and no free tier. See pricing.

See how the Stripe link works on the revenue attribution page, or start a 14-day trial and connect Stripe with a restricted read-only key.

Sources and freshness

  • Shopify Help Center, Marketing reports, retrieved October 8, 2026. Supports the five attribution models, the last non-direct click default, report contents, inclusion of canceled, pending and unpaid orders, the 30-day first-interaction reset, and sales versus payments.
  • Shopify Help Center, Custom pixels, retrieved October 8, 2026. Supports custom pixels loading in a sandbox with limited functionality.
  • WooCommerce, Order Attribution Tracking, retrieved October 8, 2026. Supports the last-click model, override rules, 30-minute session, stored fields, settings path and session-only cookies.
  • Google Analytics, Recommended events and Measure ecommerce, retrieved October 8, 2026. Supports purchase event parameters, transaction_id deduplication, the currency requirement, value excluding shipping and tax, and the refund event.
  • Google Ads Help, About attribution models, retrieved October 8, 2026. Supports last click and data-driven as the available models, data-driven as the default for most conversion actions, and the retirement of first click, linear, time decay and position-based.
  • Google Ads Help, About conversion windows, retrieved October 8, 2026. Supports the 30-day click-through default, the 1 to 90 day range, and the 1-day view-through and 3-day engaged-view defaults.
  • Meta Business Help Center, About attribution models and attribution settings, retrieved October 8, 2026. Supports standard and incremental models, the click-through, view-through and engage-through windows, and the warning against comparing ad sets with different models.
  • Stripe Docs, Metadata, retrieved October 8, 2026. Supports metadata not copying between objects by default, payment_intent_data.metadata and subscription_data.metadata, and the rule against storing sensitive data.
  • Humblytics Docs, How to track purchase events, Stripe API, Stripe Payment Links and Foxy, retrieved October 8, 2026. Supports supported processors, the objects checked for humblytics_view_id, the Payment Links redirect, and the Shop Pay and Shopify Payments limitation.

The worked example uses hypothetical numbers. Platform reports, defaults and menu paths change; check the linked pages before you rely on a specific setting.