How attribution actually works for Agentic AI.

April 22, 2026 8 min read rifref Team

Traditional affiliate attribution was designed for a single primitive: a human browsing in a single tab, with a cookie that survives long enough to be read at checkout. That model is older than most of the merchants relying on it. It works because the assumptions are stable: one user, one device, one browser session, one referrer, one window in which to credit a sale.

None of those assumptions hold for an autonomous agent. An agent does not browse. It synthesizes. It may produce a recommendation in a chat surface that the user opens hours later on a different device. It may compare ten merchants in a single response. It may run in a container that has no cookie jar at all. If you try to graft cookie based attribution onto this world, you lose most of the conversions and credit the survivors to the wrong party.

rifref’s attribution model is built on cryptographic provenance instead of browser state. Every link is a receipt the agent can hand off; every conversion is reconciled back to a specific operator using identifiers we control end to end. Here is how it works.

The click lifecycle, end to end

agent → rifref/generate_link
          ↓
      routing engine selects network (highest paying, in-policy)
          ↓
      short URL minted on go.rifref.ai with our click_id
          ↓
      signed disclosure block attached (publisher, operator, timestamp, sig)
          ↓
      user clicks
          ↓
      302 to merchant with upstream network's click_id appended
          ↓
      both ids logged to event store
          ↓
      merchant reports conversion → upstream network postback to rifref
          ↓
      reconcile click_id → credit operator's earnings ledger (pending)
          ↓
      verification window expires → status flips to confirmed
          ↓
      (reversals, if any) → ledger records debit, audit trail preserved

Every arrow is a database write. Every database write is queryable by operator, by merchant, by network, and by time.

The routing decision

When an agent calls rifref/generate_link, the routing engine has one job: pick the network through which this specific link should be issued. Most merchants are reachable through more than one network. Some are direct. Some are on CJ, Awin, Impact, and a private SaaS marketplace simultaneously. Some have geographic restrictions or operator tier requirements.

The routing table is a per-merchant configuration that lists every network we are approved through, the current effective commission rate, any active geo or category restrictions, and the network’s specific click identifier scheme. When a request comes in, the engine filters the list by the operator’s tier and the merchant’s current eligibility, then ranks the survivors by effective payout. The highest paying eligible network wins, the link is minted there, and the routing decision itself is written to the event log alongside the click identifier. If a network reviewer later asks why a specific conversion was routed their way, we can show them the full decision tree.

This matters for two reasons. First, operators do not need to know anything about the underlying network. They make one API call and they get the best available link. Second, if a network’s payouts change or an approval is suspended, we can reroute traffic on the next request without any change on the operator’s side.

The short URL and the click identifier

The short URL lives on go.rifref.ai. The path encodes a click identifier we generate ourselves. This is the identifier we treat as canonical for all internal reconciliation; the upstream network’s identifier (CJ’s pid, Awin’s awc, Impact’s irgwc, etc.) is added at redirect time as a query parameter on the final URL.

By controlling our own identifier end to end, we are not at the mercy of any single network’s session model. If a network has a 30 day cookie window and the user converts on day 31, our identifier still resolves; the upstream conversion just will not be reported and the credit will not be created. If a network changes its identifier scheme, our identifier is unaffected. If a user clears cookies between click and conversion, we still know who clicked. The upstream window still governs when and whether the commission is paid; what we own is the audit trail.

The disclosure block

Attached to every generated link is a JSON disclosure block:

{
  "publisher": "rifref",
  "operator": "agent_01HZX7M3R9Q4VW2KCJYBT4FH2N",
  "operator_org": "acme-labs",
  "type": "affiliate",
  "network": "cj",
  "issued_at": "2026-04-21T17:32:14Z",
  "click_id": "clk_01HZX7M3R9Q4VW2KCJYBT4FH2N",
  "context": "saas_comparison",
  "signature": "ed25519:b3a91c..."
}

Each field has a job.

publisher identifies rifref as the publisher of record. This is the entity holding the network agreement.
operator identifies the specific agent that produced the link. This is the entity bound to rifref’s operator agreement and subject to our verification tier policy.
operator_org identifies the organization the operator belongs to. Useful for network reviewers who want to roll up reporting at the organization level.
type is always affiliate today; future surfaces (sponsorships, paid placements) will have their own type.
network is the upstream network the link is routed through, so a downstream party can verify the click identifier scheme.
issued_at is the link issuance timestamp, used to bound staleness checks.
click_id is our internal canonical identifier, the same one the redirect server keys off of.
context is an optional string the operator passes when generating the link (e.g. saas_comparison, product_review). It is opaque to rifref but useful for operators auditing their own production.
signature is an ed25519 signature over a canonical encoding of the rest of the block, produced with rifref’s publisher signing key.

The public verification key is published as a JWKS document at /.well-known/jwks.json. The endpoint currently serves a placeholder; the production key will be published in the same document on launch. Once live, any party that holds a link with a disclosure block can verify the signature offline, with no network round trip to us. A merchant inspecting suspicious traffic, a network reviewer auditing a sub affiliate channel, or a regulator investigating an FTC complaint can all confirm provenance independently.

This is the part of the system that makes scale safe. As the number of agents and operators grows, the cost of being able to answer “did rifref actually issue this link, and which operator was on the other end of it?” stays flat. The block tells you, and the math proves it.

The reconciliation step

When a user clicks, the redirect server resolves the click identifier, attaches the upstream network’s identifier to the final URL, and issues a 302. The merchant sees a normal affiliate referral. When the merchant reports a conversion, the upstream network posts back to a webhook at rifref. The postback carries the upstream identifier, which we map to our canonical identifier, which we map to the operator and the original routing decision.

The credit is written to the earnings ledger immediately, with a pending status. Operators see it in their dashboard as soon as the postback lands. The status flips to confirmed once the network’s verification window closes; for most networks that is 30 to 90 days, during which the merchant can flag a conversion as fraudulent, returned, or otherwise reversible.

Reversals are a first class event, not an exception. If a conversion is reversed, we receive a second postback and write a debit to the ledger that mirrors the original credit. The original event is not deleted or edited; the audit trail preserves both. Operators see the reversal in their dashboard with the original conversion clearly linked.

How this differs from traditional affiliate attribution

The shorthand:

Aspect	Traditional	rifref
Attribution primitive	Browser cookie set on click	Cryptographic click identifier in the URL
Identity of publisher	Implicit (the cookie’s source domain)	Explicit, signed in the disclosure block
Identity of operator	Not represented	Explicit, signed in the disclosure block
Window	30 to 90 days, cookie dependent	Bounded by the upstream network’s verification window, but our identifier is permanent
Cross device	Lost when the cookie is	Preserved, since the identifier lives in the URL
Reviewer verifiability	”Trust us”	Verifiable offline via published public key
Reversals	Sometimes propagated, sometimes lost	First class ledger event

Cookie based attribution was a clever hack for a world of browsers. Cryptographic attribution is the equivalent primitive for a world of Agentic AI.

What this enables

Three things become tractable that previously were not.

First, sub affiliate networks at scale. rifref is a super affiliate: we hold one network agreement, then re distribute access to many operators. Networks have historically been cautious about super affiliates because they cannot see who is at the end of the chain. With architectural disclosure, they can. Every link carries the operator identifier. Operator level reporting is available on request under NDA. No black boxes.

First party FTC compliance is the second. The disclosure block makes every link a receipt the operator can show to a regulator, a platform, or an auditor. The operator still needs to honor the FTC’s “clear and conspicuous” rule in the surface where the recommendation is shown, but the proof of the underlying relationship is no longer hand wavy. It is signed bytes.

Third, programmatic settlement. Because every credit and debit is keyed to a known operator, payouts can be issued without manual reconciliation. The ledger is the source of truth; payouts run against the confirmed balance on a fixed schedule. No spreadsheets, no email threads, no quarterly reconciliation meetings.

Closing

Most affiliate networks were designed to survive in a world where attribution was lossy and provenance was implicit. The bar for being a credible publisher was: do not commit fraud, send some traffic, hope the cookies hold. That bar does not scale to a world where the publishers are software.

rifref raises the bar by raising the proof. Every link is verifiable. Every operator is identified. Every credit and debit is in a single ledger that the network, the merchant, the operator, and (where appropriate) the regulator can inspect. This is what makes the agentic economy settleable.

If you want to go deeper on the disclosure block or the routing engine, the Network Compliance page is the canonical reference. If you want to integrate, the quickstart walks through the full flow in about five minutes.