nod.

How nod. attribution works

The full path from pixel event to a credited dollar in your dashboard.

Updated July 31, 2026

When a number in nod. doesn't match what you expected, it helps to know where it came from. This article walks the full path: a pixel event on your storefront, through touch-building and identity stitching, to an order, to a credited dollar in a report.

The pipeline, in order

  1. Pixel events. Your storefront (and any connected funnel) fires consented page views, active-engagement checkpoints, explicit milestones, purchases and leads to the nod. pixel.
  2. Touches. A derivation job turns raw events into a visitor's touch path — the sequence of channel entries that make up their journey.
  3. Identity stitching. When a Shopify order or CRM lead comes in, nod. resolves who placed it and attaches the right touch history.
  4. Orders join. The order itself — revenue, refund state, cancellation — is recorded from the source that owns it.
  5. One shared scorer allocates credit. Every app surface, agent read and browser-extension response resolves the workspace's active method on the server and scores the same frozen evidence snapshot.

That last point matters: nod. does not accept a method version from the browser. An immutable active config revision, its data revisions and the requested reporting window form one stable read. If anything changes during the read, nod. retries instead of combining two states.

What counts as a touch

Not every pixel event becomes a touch. Some are folded into the touches around them:

EventBecomes a touch?What happens instead
A new channel entry (ad click, organic visit, direct load)YesStarts a new touch
Active-time checkpointNoAdds visible, focused active seconds to the page view and owning touch
Explicit newsletter_subscribed, account_created, lead_created, demo_requested, quote_requested, add_to_cart or checkout_started milestoneNoCan select Intent Capture when it has a stable event ID and an eligible observed-touch link
A repeat ping on the same session, same channel, same landing URLNoCollapses into the touch already open — ten pings on one page is one touch
A self-referral (referrer host = landing host)NoDropped — it's internal navigation, not a new entry
purchase or leadNoThese are conversions, not touches — they close the path, they don't extend it

A session carries two different time values. Wall-clock duration remains diagnostic. Active engagement counts only while the page is visible and the window is focused. It is frozen as of the conversion, capped at 600 seconds, neutral at 60 seconds and applied with a square-root curve. Missing active time is neutral, never zero.

Active engagement feeds exactly one decision in nod. Mix V3: the split between competing observed Creation candidates. It activates only when the fixed 28-day health epoch and the complete-path gate pass. A sole candidate still receives the same Creation pot whether the session lasted one minute or seven. A generic form or a long session never becomes an intent milestone by inference.

Evidence classes stay separate

nod. Mix V3 can use two evidence classes for credit: first-party observed events and eligible conversion-linked verified exposure. Verified exposure requires a real provider contract, a stable conversion match, sufficient time precision, a healthy feed and the provider's release rules. When that feed is not available, nod. stays clicks-only and labels verified exposure unavailable. It does not infer a view from aggregate video-watch metrics.

Platform-reported conversions and revenue remain Platform Claims. They can be compared beside nod. credit, but never enter the scoring path. Google Search Console is aggregate Search Demand. It has no user, session or conversion join, never creates a Journey touch and never receives credit.

Google paid touches carry one extra classification step. nod. splits them into brand and generic by matching the campaign name against your workspace's brand terms (seeded from your brand name, editable in settings) and reading the search term when the click passes one. A campaign that labels itself non-brand or generic lands in generic; a campaign carrying one of your brand terms lands in brand. When a touch arrives with neither a campaign name nor a term to read, it stays a plain Google paid touch. nod. never guesses brand, because an inflated brand row is the exact bias this split exists to expose. Both rows then report separately, under every model.

Identity stitching: matching an order to a journey

When an order or lead comes in, nod. tries to resolve it against a visitor's touch history, in order of confidence:

  1. Cart-attribute stitch (deterministic). If your storefront or checkout writes the visitor id onto the order (Shopify order note attributes), that's a direct link — no guessing involved. This is the highest-confidence tier and the one to aim for.
  2. Email-hash graph. If the order's hashed email matches a hashed email seen on a pixel event, nod. treats every visitor id that ever shared that email hash as the same person. This is also how cross-device journeys work — a phone click and a desktop purchase reconcile if the same email ties them together.

Heuristic links such as IP plus recency are classified as modeled context. They cannot enter the deterministic nod. Mix V3 score or appear as an observed Journey sequence. A conversion without an eligible deterministic link stays unattributed instead of being silently upgraded.

Orders that don't match any tier still show up — under a channel called unattributed. By default nod. doesn't redistribute that revenue onto other channels to make totals look cleaner, and the redistribution lens that estimates where it might belong is optional and labeled. If your unattributed share is high, that's the coverage number to watch (see the related article on coverage).

Lookback window

The default observed-click window is 7 days. A report can narrow it to 1 day or request 28 days/full, but it can never widen the active workspace method. Eligible verified views use a separate 1-day window. An exact-time view and click from the same provider/entity within 30 seconds collapse to the stronger event. The retained Journey horizon is 90 days by default; retention never makes an old event eligible for credit.

When numbers appear

Attribution doesn't recompute in real time on every page view. It runs on three triggers:

  • Shopify webhook. The moment an order webhook arrives, nod. re-derives that workspace. This is the fastest path.
  • Scheduled derive. A background job runs every 30 minutes and catches anything the webhook didn't — pixel-only purchases, CRM leads, and any workspace with fresh activity since its last run.
  • Manual recompute. Available to workspace admins if you need to force a refresh.

In practice: Shopify orders show up close to real time. Pixel-only purchases and CRM leads can take up to about 30 minutes to appear, since they wait for the next scheduled tick.

Day bucketing matches your Shopify admin

Every day boundary in nod. is computed in your shop's own timezone, not UTC — so a sale at 11:30pm local time lands on the day you'd expect, matching what you see in Shopify admin. If your store's timezone hasn't been captured yet, nod. falls back to Europe/Berlin until it is. This also means daylight-saving transitions are handled correctly: the day you switch clocks is genuinely 23 or 25 hours in the bucketing, not a UTC day pretending otherwise.

Honest edge cases

  • Data-driven attribution is not a distinct model yet. Selecting it currently returns the same numbers as U-Shape. It's labeled honestly in the dashboard rather than presented as a finished feature.
  • Verified exposure may be unavailable. No private provider feed means observed-only scoring, not a modeled substitute.
  • Privacy suppression returns Withheld. A restricted low-volume cell is null, not zero. Order Journey never reveals an aggregate-only provider match.
  • Cancelled orders never carry revenue or count as orders, on any report.
  • Refunds are not always netted off. Some views show gross credited revenue with refunds broken out separately; others show net (gross minus refunds). If two reports disagree, check which basis you're looking at.