Skip to content
NewProduct Q&A: shoppers ask on your product page and get your answers.See how it works
IdukkiIdukki
Strategy

What is order-anchored attribution? Which post sold the bag, step by step

Order-anchored attribution starts from the order your store records and works back to the customer post. How the match works, and what "proven" means.

A store on our platform was taking orders every day. Our dashboard said customer content had influenced none of them. The gallery was being seen and tapped. Add-to-carts were arriving. Then the trail went cold at checkout. The checkout script that should report each order never ran. Every number built on it read zero.

Order-anchored attribution credits sales starting from the order your store has already recorded. The store sends each order to the attribution system, server to server.

The system then looks for identifiers on that order that also appear on earlier activity. A visit, a tap on a customer video, an add-to-cart from a gallery. If it finds no link, the order still counts, as unattributed.

So the difference is in what can go missing. In a pixel model, an order the pixel never saw does not exist. In an order-anchored model every order exists. The open question is how much of it the content can claim.

The gap pixels leave

A checkout pixel is JavaScript that runs in the shopper's browser at the end of checkout. On Shopify it has three blind spots.

  • It needs the newer checkout. App pixels run on Shopify's current checkout. Orders outside it are invisible.
  • Consent can switch it off. Shopify gates pixels on the shopper's privacy choice. Decline tracking, and the pixel stays silent.
  • Some orders skip the browser. Point-of-sale orders and staff-made draft orders never touch a browser checkout.

The store in the opening had plenty of orders and zero pixel checkout events. No gallery change could have fixed that report. It was built on the wrong end of the sale.

CompareThe pixel view and the order view
1Pixel-anchored

Starts in the browser

An order exists only if the checkout script ran.

Wins at

  • Fires within seconds of checkout
  • Easy to install as an app pixel

Struggles with

  • Silent when the shopper declines tracking
  • Blind to point-of-sale and draft orders
  • Missing orders never show up as missing
2Order-anchored

Starts at the store

Every order the store records arrives, server to server.

Wins at

  • Counts orders the pixel never saw
  • Shows unmatched orders in their own column
  • Uses the pixel as a second signal

Struggles with

  • Needs an id on the order to match it
  • Shopify re-fetch reaches about 60 days back
  • Shows influence; only a test shows cause

The same store, measured from each end of the sale.

How an order finds its way back to a post

Here is the path from a gallery view to a credited order in Idukki, on Shopify.

From impression to credit

  1. 01

    Impression

    The gallery shows customer posts. The widget writes an anonymous visitor id, _idk_vid, into the cart.

    Identifies

  2. 02

    Add to cart from a post

    The shopper adds a product from a customer post. Idukki records it against the same visitor id.

    Proves intent

  3. 03

    Checkout

    The browser pixel may fire, or may stay silent. Nothing depends on it.

    Optional

  4. 04

    Order webhook

    Shopify sends orders/create to Idukki. The visitor id rides on the order.

    Every order

  5. 05

    Credit

    Idukki matches the order to the visitor's history and picks a bucket.

    30-day lookback

The visitor id identifies the shopper. Only the add-to-cart from a post proves the sale.

The visitor id is the strongest bridge, but not the only one. Idukki tries them in this order:

BridgeWhere it comes fromMatch type
Visitor id (_idk_vid)Written into the cart by the widget, returned on the orderExact
Logged-in customerThe customer id on the order matches an earlier signed-in visitExact
Cart tokenThe cart built while browsing is the cart that became the orderExact
Salted fingerprintA one-way hash of network and browser signals, used only when the product matchesAlways marked estimated
Identity bridges Idukki uses to match an order, strongest first.

What "proven" means

An order is proven when the same visitor added a purchased product from a customer post. That add-to-cart must fall in the 30 days before the order.

The visitor id alone is not enough. The widget writes it on impression, so it only says the gallery loaded for that shopper.

The same rule applies whether the pixel or the order webhook reports the sale. A pixel checkout with no matching add-to-cart is filed as a store order.

Proven, influenced and unattributed: why the columns stay apart

Adding every kind of credit into one headline makes attribution meaningless. Idukki keeps the buckets apart, with fixed definitions.

BucketWhat it means
ProvenSame visitor added a purchased product from a customer post in the 30 days before.
Click-attributedClicked a customer post for a product they bought, without adding from it.
Content-assistedClicked customer content, but for a different product.
View-attributedWas shown a post tagged with a product they bought, or saw posts on its page.
Store orders seenEvery order Idukki received from the store, matched or not.
UnattributedStore orders seen minus influenced orders. Shown, split into identified and unidentified shoppers.
The order buckets Idukki reports, from its KPI definitions. Each order counts once, at its strongest bucket.

Conversion rate follows the same rule. It is proven orders divided by engaged visitors, the people who interacted with customer content.

Our July 2026 case studies report checkout click-throughs, and say so. The order join was not live when those numbers were pulled.

One order, traced end to end

  1. 1Day 1, 8:40 pm. Maya opens a canvas tote bag page on her phone. The gallery loads and writes her visitor id into the cart.
  2. 2Day 1, 8:42 pm. She watches a customer video of the bag packed for a weekend. She taps Add to cart on the video's product card.
  3. 3Day 1, 8:43 pm. She declines the cookie banner and closes the tab.
  4. 4Day 3, 7:15 am. She comes back from an email and buys the tote and a keyring. The checkout pixel stays silent.
  5. 5Day 3, 7:15 am. Shopify sends the order to Idukki. Her visitor id is on it.
  6. 6Result. Same visitor, tote added from a customer post two days earlier. The order is proven.

Now change one thing at a time. Here is where the same order would land.

If Maya hadThe order lands in
Added the tote from the customer videoProven
Clicked the video through to the tote page, then added thereClick-attributed
Clicked a customer post for a different bagContent-assisted
Scrolled past a post tagged with the toteView-attributed
Visited, but the gallery showed her no postsUnattributed, identified
Left no id, customer login or cart token on the orderUnattributed, not identified
The fictional order above, with one step changed each time.

Under a pixel-only report, every row in that table reads the same: nothing. She declined tracking, so the order was never seen.

What you see in the dashboard

  • Proven orders and revenue in their own tile.
  • Influenced orders by tier: click, content and view.
  • Store orders seen, so you can check the total against Shopify.
  • Unattributed orders, shown, never hidden.
  • Estimated matches flagged wherever the fingerprint bridge was used.

What it cannot do

It cannot prove cause on its own. A shopper who watched a customer video may have bought anyway. Only a controlled test answers that, which is why proven and influenced stay apart.

History has a reach limit too. Shopify lets an app re-fetch about 60 days of orders. Older orders Idukki already stores are re-attributed from its own copies. An order with no bridge 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 not, you cannot tell how much it missed.
  • Are proven and influenced kept apart? One blended figure hides the difference.
  • What counts as proven? A page view, a click, or an add-to-cart?
  • Which matches are estimates? Fingerprint matches should be labelled.
  • What is the lookback window? Idukki uses 30 days.

Questions merchants ask

  • What is order-anchored attribution?

    Crediting sales from the order your store records. Ids on the order link it to earlier activity.

  • Why does my UGC app show zero orders when I have sales?

    It probably relies on a checkout pixel. Consent choices, older checkouts and in-store orders all silence it.

  • What makes an order proven in Idukki?

    The same visitor added a purchased product from a customer post. It happened in the 30 days before the order.

  • Does order-anchored attribution need cookies?

    It uses ids that travel with the order. A salted fingerprint is a last resort, always marked estimated.

  • Is influenced revenue the same as revenue caused by UGC?

    No. Influenced means content was on the path. Only a controlled test shows cause.

Further reading

  1. 1Shopify: web pixels API · How app pixels run and how consent gates them.
  2. 2Shopify: webhooks · The server-to-server order event.
  3. 3Idukki: attribution comparator · Free tool. Compare models on your own numbers.
  4. 4Idukki attribution · The product page.
  5. 5Idukki: how to measure UGC ROI
#attribution#order-attribution#ugc-roi#shopify#analytics#explainer

Continue reading

4 pieces in this cluster

These long-form pieces on the Idukki blog link back to this article, go deeper on the cluster.

More from Rohin Aggarwal