Ecommerce attribution: credit every sale correctly

Which attribution models suit online stores?

Multi-touch models suit stores better than single-touch ones, because store journeys are genuinely multi-visit. Position based and time decay are the two most defensible defaults.

• Position based credits discovery and the closing click, commonly 40% to the first touch, 40% to the last and 20% split across the middle. It fits the typical store pattern: something introduces the product, several visits consider it, one click closes it.
• Time decay weights recent touches more heavily. It suits stores with short consideration cycles and heavy retargeting, where the last week of activity really does carry most of the causation.
• Linear is the safe neutral option when you have no opinion and want to stop arguing. It reliably reveals channels that last touch hides.
• Last non-direct click is what Shopify's marketing reports use by default. Shopify also offers last click, first click, any click and linear, and notes that attribution data in its Growth section is available only from 1 October 2021 (Shopify Help Center).
• First touch is worth running alongside your main model, never as your main model. It tells you which channels create demand you are currently crediting elsewhere.

Whatever you choose, set the lookback window from real data: measure the median days from first session to order, then set the window comfortably above it. Statsy allows 1 to 365 days and defaults to 90, and offers all five models on the same underlying data, so comparing them is a dropdown rather than a migration.

How does Shopify attribute an order?

Shopify builds a customer journey for each order from the sessions that preceded it, and exposes that journey through the Admin API.

The customerJourneySummary object on an order carries the useful fields: firstVisit, the customer's first session going into the shop; lastVisit, the last session before the order; momentsCount, the total number of sessions in the journey; daysToConversion; and ready, a boolean saying whether the attributed sessions have been created yet (CustomerJourneySummary). The moments connection returns the full timeline rather than just the endpoints.

Each session in that timeline is a CustomerVisit, and it carries what you need for channel assignment: landingPage, referrerUrl, source, sourceType, utmParameters gathered from the referrer's URL parameters, referralCode and occurredAt (CustomerVisit). Reading it requires the read_orders scope.

Two practical notes. momentsCount returns null while an order is still being attributed, so a job that reads orders the instant they are created will see incomplete journeys; read again once ready is true. And Shopify documents that sessions and customers can differ between reports because of how sessions are counted and deduplicated (customer and session discrepancies), which is a good reason not to reconcile two tools to the last order.

How do UTM, referrer and payment data combine?

Each of the three answers a different question, and ecommerce attribution needs all three. UTMs say what you intended, the referrer says where the click actually came from, and the payment record says what the order was really worth.

The order of precedence that works in practice:

1. UTM parameters first. They are the only signal you control, and they carry campaign and creative detail nothing else has. The five recognized parameters are utm_source, utm_medium, utm_campaign, utm_term and utm_content (Google's reference).
2. Referrer second, when no UTM exists. Browsers default to a strict-origin-when-cross-origin referrer policy, so you normally receive the origin and not the linking page (MDN). That is enough to name a channel, not enough to name a post.
3. Discount or referral code third, as a tiebreaker for creator and affiliate traffic that arrives untagged.
4. The payment record last, and decisively, for the amount. The order total, the currency and any later refund come from the processor, not from the browser.

That last point is where most store dashboards go wrong. A purchase event fired on a thank-you page can be blocked, missed when a buyer closes the tab, double counted on a refresh, or edited outright. A signed webhook cannot: Stripe includes a signature and timestamp on every event and its libraries verify both (Stripe webhooks). Statsy counts revenue only from signed webhooks from Stripe, Lemon Squeezy, Paddle, Polar and Razorpay, or from its authenticated Payment API, and joins that amount to the session journey the visitor actually took.

Which channels break ecommerce attribution, and how?

Every channel fails in a specific, predictable way. Knowing which failure you are looking at stops you from rebalancing a budget because of a measurement artifact.

Channel	Typical attribution problem	What to do
Paid search and shopping	Platform self-reports more conversions than you sold	Compare platform conversions to net attributed orders monthly
Paid social	View-through credit inflates the platform's own number	Judge on attributed net revenue, not platform ROAS
Organic search	Starts journeys it rarely closes, so last touch zeroes it	Run first touch alongside your main model
Email	Wins last touch on people other channels found	Check its first-touch share before crediting acquisition
Influencers and creators	Links shared in stories and DMs arrive with no referrer	Issue a unique discount code per creator
Marketplaces	Journey happens inside another app	Treat as its own channel, do not force it into web attribution
Direct	Bucket of untagged and dark-social traffic	Audit for missing UTMs before calling it brand demand
Retargeting	Credited for buyers who were already returning	Compare under first touch and position based, never last touch

What do you do with the numbers?

You shift budget, but only after the same model has produced the same answer twice and returns have had time to land.

A workable monthly routine:

1. Wait for the return window. If your policy is 30 days, last month's revenue is not final yet. Compare a closed month to a closed month.
2. Rank channels by net attributed revenue per dollar spent, not by orders and not by gross. A channel with a 30% return rate and one with 5% are not comparable on gross sales.
3. Move money in increments, around 10 to 20% of a channel's budget, and hold everything else steady. Moving three budgets at once makes the result unreadable.
4. Check the two-model gap before cutting anything. If a channel is weak on last touch but strong on first touch, cutting it will quietly reduce the channels that look strong on last touch, and you will not see the connection for a month.
5. Recheck after one full purchase cycle, not after a week. Store data at small volumes is noisy, and a fortnight of orders will not separate a real effect from a good weekend.

The channels worth the most attention are the ones whose rank changes most between models. Those are the ones your current reporting misprices. Statsy's marketing attribution software page covers how the five models are applied, and revenue overlays on session replays and heatmaps show which pages sat inside the journeys that actually converted.

What should you do next?

1. Measure the real length of your buying journey: the median days from first session to order, and the median number of sessions. Set your lookback window above the first number.
2. Audit your untagged traffic. Find the share of orders whose first session has no UTM and no referrer, and fix the links you control before you touch a budget.
3. Move your revenue figure off the browser and onto payment webhooks, and subscribe to refund events so returns reduce the channel that was originally credited.
4. Give every creator, affiliate and offline placement its own discount code, so untagged traffic still resolves to a source.
5. Rebuild last closed month as a channel table in net revenue under two models, one single touch and one multi touch, and start the budget conversation from the rows where the two disagree.