How it works

One reference crosses the gap. Everything else is bookkeeping.

The click is recorded here. The sale happens on the merchant’s own domain. Nothing a browser stores survives that hop, so attribution rests on one reference they carry across it and hand back. This is that mechanism, and its failure mode.

What crosses, and what does not

goreign.co
the click is recorded here
the merchant’s own domain
the sale happens here
?rgn=<click id>
→ Arrives in the URL. Their page reads it and keeps it first-party as reign_click.
aff_… cookie
Scoped to goreign.co and SameSite=lax. Their server is never sent it.
IP + user-agent fingerprint
At the sale it describes their server, or Stripe’s. Never the shopper.
referrer
Long gone by the time the visitor reaches a checkout.
← returned at the sale
click_id in the body X-Reign-Click on the header reign_click_id on a Stripe session
If nothing comes back the sale is still recorded — as no_touchpoints, attributed to nobody, paying nobody. A reference stays valid on the merchant’s site for 90 days, deliberately longer than any offer’s cookie window: we decide whether a touchpoint is still in window at conversion time, and can only do that if they still have it to send.
Why we do not claim cookieless attribution, or ITP resilience

Every network in this category claims both. The cookie we set on redirect is scoped to this domain and marked SameSite=lax — a merchant cannot read it and it does not travel to their server, which is not a setting we could turn off but what the same-origin rules mean. What is actually true is narrower and more useful: they carry a reference across the boundary themselves and hand it back. A network that says otherwise is guessing.

What happens when the reference comes back

Resolved, scoped to the merchant
The reference is looked up against that merchant’s own clicks. A reference from another merchant on the network attributes to nobody rather than to the wrong person.
Widened to the same visitor
We then add the merchant’s other clicks sharing that click’s fingerprint, so a multi-touch journey is visible rather than a single point. Last click can therefore award a later publisher than the one the merchant referenced. That is correct: the merchant tells us which touch they saw, not which one wins.
A model is applied
Inside the programme’s click window. The models are listed below; there are four routes to a decision and no more than four.
Calculated
The programme’s commission rules — percentage, fixed or tiered, with per-plan overrides and lifetime-volume tiers.
Written as one transaction
The commission and its double-entry ledger accrual are written together. Neither can exist without the other, and neither can be edited afterwards.
Held, then released
A commission sits pending for the offer’s stated period so refunds land first, then becomes payable. A refunded sale voids it and posts a reversing entry.

The attribution models

All of them
Last click
The default. The most recent eligible click inside the programme’s window takes the sale.
First click
Per programme. The earliest eligible click takes it instead.
Coupon priority
Optional, per programme. A coupon tied to a partner wins over the click order, but only if that partner also has a click in window — a coupon alone does not manufacture a touchpoint.
Cross-device email match
When the merchant sends a customer email, it is hashed and matched against the hash recorded on a click. That is what lets a phone click and a desktop purchase resolve to one person.
What the IP fingerprint is not

It is recorded from the IP address, user agent and accept-language of the request, and on a postback or webhook that is the merchant’s own server or Stripe’s. So it groups a merchant’s clicks that plausibly belong to one visitor, and never decides on its own who earned a sale. A network that attributes on a fingerprint at conversion time is attributing to a data centre.

What we will not tell you

How fast you can launch
The install is small — a script tag and one field at checkout — but it lands in somebody else’s release process and we do not control that. No timescale is promised here because we have no basis for one.
That stats are live
Offer performance is recomputed hourly, on a schedule. Clicks are recorded as they happen; the figures derived from them can be an hour behind, and the offer page prints the timestamp of the last recompute.
That you can hand us your tax and contracts
There is no tax profile, no partner contract store and no document workflow in this product. Some competitors have them. We do not, and this page is not going to imply otherwise.
That attribution is a solved problem
It rests on one reference surviving a hop between two domains, and the weakest link is a change on the merchant’s site that quietly stops sending it. That is why the offer screens show what was attributed and what was not.
Read the developer docs Browse offers →