Referral parameters
The parameter carrying the affiliate’s code. Your program uses exactly one, chosen from this fixed list, andref is the default.
Names are case-sensitive, and the value must be in the query string — anything after a
# is
invisible to the tracker. A link using a name on this list that is not the one your program is
configured for is recognised as a candidate but resolves to nobody.
Program identification
The tracker needs to know which program it is running for before it reads anything else.
Without one of these the tracker exits immediately and records nothing.
External click ID
Your own identifier for the click, for reconciling Referly against an ad platform or a sub-affiliate
network:
{extClickid}.
See External click IDs.
UTM parameters
Captured verbatim from the query string when a click is recorded. They never affect attribution.
Each is indexed, so all five work as breakdown dimensions in analytics.
Ad platform click IDs
Also captured verbatim, and also irrelevant to attribution.li_fat_id is the only one whose stored field name differs from the parameter name.
The presence of any of these classifies the click as paid traffic — referrerType is set to paid
regardless of which domain referred the visit. See
UTMs and ad click IDs.
Cross-domain handoff
Written by Referly, not by you. Never add them by hand.
When a visitor with active attribution follows a link to a domain on your cross-tracking list, the
tracker appends both. The receiving domain reads them, writes the attribution into its own storage,
and strips them from the address bar with
history.replaceState. They are also appended to form
actions pointing at approved domains.
See Cross-domain tracking.
What the browser stores
Three keys per program, each prefixed with your program ID. Cookies are used when available, with localStorage as the fallback when they are not.
Cookies are written on the registrable domain, so attribution is shared across subdomains without
any extra configuration. Details in
Cookies and storage.
Values exposed on the page
Once the tracker has resolved attribution it puts two values onwindow and fires an event. These
are what you pass to your backend at checkout.
Server-side attribution parameters
When you report a conversion from your backend there is no URL to read, so you name the affiliate explicitly. These fields do the work the query parameters do in the browser. Creating a referral:
One of the three is required.
affiliateId is overloaded on purpose: a value made entirely of
digits is looked up as a click ID first, which is why passing window.affiliateId straight
through ties the conversion to the exact click that produced it. A non-numeric value is treated as an
affiliate ID or a link slug.
Creating a sale:
One of the three is required here too. See
Reporting sales.
Captured without a parameter
Several click fields have no parameter behind them. They are derived from the request or the browser, so they are populated on every click whatever the URL looks like.queryString keeps the entire query string, so a parameter Referly does not read by name is still
recoverable from the click.
Precedence
Postbacks
Postback URLs are the reverse direction — Referly filling parameters into a URL you own. The two that carry click identity are{clickid}, the Referly click ID, and {extClickid}, the value you
sent as rsubID. The full macro list is in
Postback URL.
Related
URL parameters
How the referral parameter is matched, and how to change it.
What gets captured
Every field stored on a click, with example values.
Data model
The objects these fields belong to.
Debug mode
Watch the tracker report which parameters it found.