# How Idukki decides a sale came from UGC

The rule book behind every proven order. The order is the anchor and a widget add-to-cart is the bar. Assisted and unattributed orders keep their own columns.

By Rohin Aggarwal · 2026-11-15

It is Monday and your dashboard says customer posts drove 14 sales last week. Your finance lead asks the obvious question. Which 14, and how do you know? You should be able to answer with one order number and one rule.

**Quick answer**

- **The order is the anchor.** Shopify sends each order to Idukki server to server. No browser script has to run.
- **Proven** needs a widget add-to-cart of a product the shopper bought, in the 30 days before.
- Seeing a post, or clicking one, never makes an order proven.
- Orders that fall short go to one of four assisted tiers: click, cart, content or view.
- Store orders seen and unattributed orders are shown too. Nothing is added into one figure.

## Why the rule matters more than the number

Any tool can put a revenue figure on a dashboard. What matters is the test an order had to pass to get there. If the test is loose, the figure grows with traffic. Sales can stay flat.

So here is our test, rule by rule. It is the same test on every report, email and admin screen. Our KPI definitions fix it in one place.

- **30 days** — Lookback before the order (For proven and every assisted tier)
- **4** — Assisted tiers (Click, cart, content, view)
- **1** — Bucket per order (Each order counts once, at its strongest tier)

_The fixed numbers in the rule book, from Idukki's KPI definitions._

## Rule one: start from the order

On Shopify, every new order fires the orders/create webhook. It goes from Shopify's servers to ours. The shopper's browser plays no part.

That matters for three kinds of order. A shopper who declines the consent banner silences checkout pixels. Point-of-sale and staff draft orders never touch a browser checkout. The webhook still reports all three.

Checkout pixels still run as a second signal. Their reports are checked against the webhook rows in both directions.

**One order, from webhook to bucket**
1. **Order arrives** — Shopify sends orders/create to Idukki, server to server. (Every order)
2. **Find the shopper** — Match the order to earlier visits through an identity bridge. (Four bridges)
3. **Look back** — Read that shopper's widget activity in the 30 days before. (30 days)
4. **Test for proven** — Did they add a product they bought from the widget? (Add-to-cart)
5. **Pick one bucket** — Proven, one assisted tier, or unattributed. Never two. (Once)
_The order arrives first. Every later step looks back from it._

## Rule two: find the shopper

An order carries clues that also appear on earlier visits. Idukki tries four, strongest first.

| Bridge | What it is | How it counts |
| --- | --- | --- |
| Visitor id | An anonymous id the widget writes into the cart | Exact match |
| Customer account | The logged-in customer id on the order | Exact match |
| Cart token | The cart built while browsing became the order | Exact match |
| Salted fingerprint | A one-way hash of network and browser signals | Product-matched tiers only; always marked estimated |

_Identity bridges, from Idukki's order attribution code. Strongest first._

Finding the shopper proves nothing on its own. The widget writes the visitor id when a gallery loads. So it only shows that the shopper saw a page with a gallery.

## Rule three: proven means a widget add-to-cart

An order is proven when the same shopper added a product they bought from the widget. The add must fall in the 30 days before the order. The pixel path and the webhook path use this one rule.

A pixel checkout with no matching widget add-to-cart is filed as a store order. It can still land in an assisted tier.

One narrow extension came in on 18 October 2026: same style. Say a shopper adds the blue shirt from a post, then buys the green one. The titles match once colour words are removed, with at least 3 words left. That order counts as proven too. It applies on the webhook path only and carries its own flag.

Add-to-carts from the Guided Shopping Quiz are stored apart. A quiz pick involves no customer post, so it never makes an order proven.

**Where one order lands**
Q: Did this shopper add a product they bought from the widget in the last 30 days?
- Yes: **Proven** — The strictest bucket. It feeds conversion rate and proven revenue.
  - Same product, or same style in another colour: Proven order
- No, but they touched UGC: **Assisted** — Strongest tier first.
  - Clicked a post for the product they bought: Click-assisted
  - Added a different product from the widget: Cart-assisted
  - Clicked customer content for another product: Content-assisted
  - Was shown a post tagged with what they bought: View-assisted
- No UGC touch, or no shopper found: **Unattributed** — Shown, never hidden.
  - Shopper found, no UGC touch: Unattributed, identified
  - No bridge on the order: Unattributed, not identified

## Rule four: assisted orders keep their own column

Most orders that touch UGC never pass the proven test. They land in one of four assisted tiers, strongest first. In the dashboard these add up to influenced orders, with proven.

- **Click.** The shopper clicked a post for a product they bought. They never added it from the widget.
- **Cart.** They added a product from the widget, then bought a different one.
- **Content.** They clicked customer content for some other product.
- **View.** The gallery showed them a post tagged with a product they bought.

A view also counts when the impression was on the bought product's own page. A gallery that loaded no posts earns nothing. A fingerprint match never makes an order cart-assisted.

## Rule five: show the rest, and add nothing together

| Bucket | What it counts |
| --- | --- |
| Proven orders | Passed the widget add-to-cart test in the 30 days before |
| Assisted orders | Touched UGC in one of the four tiers, without passing the test |
| Influenced orders | Proven plus assisted, each order once |
| Store orders seen | Every order the store sent, matched or not |
| Unattributed | Store orders seen minus influenced orders |

_Order buckets in the Idukki dashboard, from its KPI definitions._

Conversion rate uses proven orders only. It is proven orders divided by engaged visitors, the people who interacted with customer posts.

Add-to-cart value from the widget is shown as intent. It is never added to any revenue figure. Every definition is on [how we measure](/how-we-measure).

## Three orders, traced

> **Fictional examples:** These shoppers and orders are made up to show the rules. No real customer data is used.

| What happened | Bridge found | Bucket |
| --- | --- | --- |
| Declined cookies, added a linen dress from a reel, bought it two days later | Visitor id on the order | Proven |
| Added the navy tote from a post, bought the olive tote | Visitor id on the order | Proven, same style |
| Saw a candle post while logged in; bought it in store a week later | Customer account on the order | View-assisted |

_Fictional orders run through the rules above._

In the third order the shopper never added anything from the widget. So the till sale lands as assisted, in its own column.

## Fixing the past, in the open

Until 30 September 2026, one pixel path treated the visitor id as proof. That counted orders from shoppers who had only seen a gallery. We changed the rule and relabelled those orders as store orders. They now go through the assisted tiers like any store order.

Shopify lets an app re-fetch about 60 days of orders. Older orders we already store are re-attributed from our own copies, daily. An order with no bridge stays unattributed. Nothing guesses a shopper into existence.

## What proven does not prove

Proven shows the post was on the path to the sale. It does not show the shopper would have walked away without it. Only a holdout test answers that. Our guide to [holdout tests for UGC](/blog/holdout-tests-ugc-incrementality-without-lying) shows how to run one.

**The question to ask any vendor:** Pick one order from last week and ask which rule credited it. A good answer names the bridge, the touch and the date. If the answer is a model name, keep asking.

### Questions merchants ask

**Q: What makes an order proven in Idukki?**

A: The same shopper added a product they bought from the widget. The add came in the 30 days before the order.

**Q: Does a view or a click count as proven?**

A: No. Views and clicks land in assisted tiers. Only a widget add-to-cart of a bought product is proven.

**Q: Do consent banners hide UGC sales from Idukki?**

A: No. Orders arrive through Shopify's orders/create webhook, server to server. A declined banner silences pixels. The webhook still arrives.

**Q: Are in-store orders counted?**

A: Yes. Point-of-sale orders arrive through the same webhook. They match a shopper only if the order carries a bridge.

**Q: Does Idukki add proven and assisted revenue together?**

A: Influenced orders count proven plus assisted, each once, in its own tile. Proven revenue is always shown on its own.

### Further reading
- [Idukki: what is order-anchored attribution?](/blog/what-is-order-anchored-attribution) — Pixels vs orders, with one order traced end to end.
- [Idukki: how we measure](/how-we-measure) — Every metric in plain words, with an example each.
- [Idukki attribution](/features/attribution) — The product page.
- [Idukki: attribution comparator](/tools/attribution) — Free tool. Compare models on your own numbers.
- [Shopify: webhooks](https://shopify.dev/docs/api/webhooks) — The server-to-server order event.
- [Shopify: web pixels API](https://shopify.dev/docs/api/web-pixels-api) — How app pixels run and how consent gates them.

---
Canonical: https://idukki.io/blog/how-idukki-decides-a-sale-came-from-ugc
Tags: attribution, order-attribution, proven-revenue, ugc-roi, analytics, explainer