What is order-anchored attribution? Why the order, not the pixel, should credit your UGC
Order-anchored attribution starts from the order your store records, then works back to the customer content the shopper touched. How it differs from pixel attribution, the identity bridges it uses, and why proven, influenced and unattributed orders stay in separate columns.
A store on our platform was taking orders every day. The dashboard said customer content had influenced none of them. Not few: none. The gallery was being seen and tapped, add-to-carts were arriving, and then the trail went cold at the checkout. Nothing was broken in the gallery. The checkout script that was supposed to report each order was simply never running, and every number built on top of it read zero.
In this article
Order-anchored attribution, defined
Order-anchored attribution is a way of crediting sales to marketing that starts from the order your store has already recorded, rather than from an event reported by the shopper's browser. The store sends the order to the attribution system server to server, the system looks for identifiers on that order that link it to earlier activity (a visit, a tap on a customer video, an add-to-cart from a gallery) and credits the order accordingly. If no link is found, the order is still counted, as unattributed.
The difference sounds technical. It is really a difference in what can go missing. In a pixel model, an order the pixel never saw does not exist as far as the report is concerned. In an order-anchored model, every order exists, and the open question is only how much of it the content can honestly claim.
Why pixel attribution misses orders
A checkout pixel is JavaScript that runs in the shopper's browser at the end of checkout and reports the purchase. It is the default way apps measure sales, and it has three blind spots on Shopify that are structural rather than bugs.
- It needs the newer checkout. App pixels run on Shopify's current checkout. Stores or orders outside it are invisible.
- Consent can switch it off. Shopify's customer privacy settings gate pixels on the shopper's consent. A shopper who declines tracking completes the order and the pixel stays silent.
- Some orders never touch a browser checkout. Point-of-sale orders in a shop and draft orders created by staff are real orders a pixel cannot see.
Each gap is small on its own for some stores and total for others. The store in the opening paragraph was an extreme case: plenty of orders, zero pixel checkout events. Nothing in the gallery could have fixed that report, because the report was built on the wrong end of the transaction.
The same store, measured two ways
Pixel-anchored
- Orders exist only if the checkout script ran in the shopper's browser.
- Declined consent, older checkouts and in-store orders drop out of the report.
- A store can show galleries being used and zero orders influenced.
- Missing orders are invisible, so nobody knows how many there are.
Order-anchored
- Every order the store records arrives from the store, server to server.
- Each order is matched back to content through the identity bridges it carries.
- Orders with no match are still counted, as unattributed, in their own column.
- The checkout pixel becomes a second signal, reconciled against the order.
How an order finds its way back to a customer post
The order arrives with no idea that a customer video was involved. The work is in finding identifiers on the order that also appear on earlier activity. In Idukki these are the bridges, tried from strongest to weakest:
Identity bridges, strongest first
- 01
Visitor id in the cart
When a shopper sees or adds from a gallery, the widget writes an anonymous visitor id into the cart attributes. It comes back on the order.
Exact
- 02
Logged-in customer
If the shopper was signed in when they tapped the content, the customer id on the order matches.
Exact
- 03
Cart token
The cart the shopper built while browsing is the cart that became the order.
Exact
- 04
Salted fingerprint
A one-way hash of network and browser signals, used only when the product also matches, and always labelled an estimate.
Estimated
Once a bridge is found, the system looks at what that shopper did with customer content before the order: a click-through to the product that was bought, a video they watched, a gallery that showed a post tagged with that product. That history decides which bucket the order lands in.
Proven, influenced and unattributed: why the columns stay apart
The fastest way to make attribution meaningless is to add every kind of credit into one headline. Order-anchored attribution keeps them apart on purpose, and Idukki's definitions are fixed so the same number reads the same on every page.
| Bucket | What it means |
|---|---|
| Proven orders | A click-through from customer content that ended in an order, resolved by the checkout pixel or the order webhook to an add-to-cart from UGC. |
| Influenced, by tier | Other store orders the model can tie to UGC: click-attributed, content-assisted, or view-attributed. Each order is counted once, at its strongest tier. |
| Store orders seen | Every order Idukki received from the store, matched or not. |
| Unattributed | Store orders seen minus influenced orders. Shown, not hidden, and split into shoppers identified with no UGC touch and shoppers not identified at all. |
Conversion rate follows the same discipline: proven orders divided by engaged visitors, the people who actually interacted with customer content. It is deliberately stricter than dividing by add-to-carts or clicks, which both read far above any store's real conversion rate.
We learned the value of this the hard way in our own case studies. The July 2026 cohort on our case-study pages reports checkout click-throughs rather than orders, and says so in its measurement notes, because the order join was not available when those numbers were pulled. That caveat is exactly what order-anchored attribution removes.
What it cannot do
It cannot prove causation on its own. An order from a shopper who watched a customer video is influenced by the video in the sense that the video was part of the path; whether the shopper would have bought anyway is a question only a controlled test answers. That is why proven orders sit apart from influenced ones, and why an A/B test remains the strongest evidence you can collect.
It also has a reach limit for history. Re-fetching past orders from Shopify is capped by the order-reading permission at about 60 days, so Idukki re-attributes older orders from the copies it already stores rather than asking Shopify again. And an order with no bridge at all stays unattributed: the model does not guess a shopper into existence.
Questions to ask any attribution report
- Where do the orders come from? The store, or a script in the shopper's browser?
- Are unattributed orders shown? If the report only shows the orders it credits, you cannot tell how much it missed.
- Are proven and influenced kept apart? One blended figure hides the difference between a click that became an order and a gallery someone scrolled past.
- Which matches are estimates? Fingerprint matches should be labelled as such.
- What is the lookback window? Idukki credits store orders through UGC touches in the 30 days before.
Questions merchants ask
What is order-anchored attribution?
A way of crediting sales that starts from the order the store has recorded, sent server to server, and matches it back to earlier activity through identifiers on the order, instead of relying on a script in the shopper's browser to report the checkout.
Why does my UGC app show zero orders when I have sales?
Usually because it depends on a checkout pixel. On Shopify, app pixels run only on the newer checkout, can be silenced when a shopper declines tracking, and never fire for point-of-sale or draft orders.
Does order-anchored attribution need cookies?
It matches orders using identifiers that travel with the order itself (a visitor id in the cart attributes, the customer id, the cart token). A salted fingerprint is used only as a last resort and is always marked as an estimate.
Is influenced revenue the same as revenue caused by UGC?
No. Influenced means customer content was on the shopper's path. Only a controlled test shows what would have happened without it, which is why proven and influenced orders are reported separately.
Further reading
- 1Shopify: web pixels and customer privacy · How app pixels run and how consent gates them.
- 2Shopify: orders/create webhook topic · The server-to-server order event.
- 3Idukki attribution · The product page.
- 4Idukki: how to measure UGC ROI
Continue reading
2 pieces in this clusterThese long-form pieces on the Idukki blog link back to this article, go deeper on the cluster.
- Strategy
How to choose a UGC gallery app: ten questions to ask before you install
A buyer's checklist for UGC gallery apps: sources, product tagging, rights, moderation, page weight, measurement, pricing shape, platforms, exit and support. With a decision tree and the demo questions that expose a weak app.
- Strategy
Idukki vs Syncly vs Emplifi UGC: finding customer content, managing it, or selling with it
Syncly listens inside social video, Emplifi UGC is one module of an enterprise CX suite, and Idukki turns customer content into shoppable galleries on your store. A side-by-side comparison, with a table and sources. We make Idukki.
More from Rohin Aggarwal
- Strategy
How UGC and shoppable video software is priced in 2026: six models, one comparison
Per seat, per view, per impression, per order, revenue share, flat. Each pricing model rewards a different behaviour and punishes a different kind of growth. Here is how to read a quote and what to ask before signing.
- Strategy
PDP before and after UGC: what actually changes on the page
Add verified customer photos, video and reviews to the middle scroll of a brand-only PDP and conversion lifts. Here is what moves, scroll by scroll.
- Strategy
A kitchen table in Egham, why I built Idukki
Day job: SAP architect on UK government software. Night job: founder of a UGC platform. The Venn diagram of those two communities is roughly one person.