Skip to content
Browse documentation

Affiliate tracking links (/r)

The partner link /r/{offer}/{partner} — format, the /click alias, what the server checks, how the destination is built, unique clicks, deep links and every status reason.

Last updated 4 min read

On this page

The affiliate tracking link is the standard partner link. The server decides where the visitor goes: the offer's destination (or a landing page), or a fallback when the click cannot be accepted.

URL
https://trackcrown.com/r/OFFERCODE/PARTNERCODE?sub1=campaign&sub2=creative&source_id=site-42
PartMeaning
OFFERCODEThe offer's public code (shown in the offer header). Numeric IDs are not accepted on /r.
PARTNERCODEThe affiliate's public code.
QuerySub IDs and parameters, plus url_id=, prl=1 and optionally url=.

A trailing slash (/r/OFFERCODE/PARTNERCODE/) is accepted.

  • Staff: offer → Tracking tab → Affiliate tracking link. Choose Tracking domain, Landing page (if the offer has some), Affiliate, an optional Traffic source template, sub1…sub5 and source_id. Copy Tracking link; QR code and Impression pixel (1×1 GIF) are next to it.
  • Partners: portal → Offers → the offer → link builder, type Tracking link.
  • API: GET /api/v1/tracking-link?offer=…&affiliate=…&sub1=… (REST API).

Values such as {campaign} typed into sub fields stay literal in the link for the traffic source to fill in.

The /click alias#

For systems that can only pass IDs as parameters:

URL
https://trackcrown.com/click?oid=OFFERCODE&aid=PARTNERCODE&sub1=campaign

oid (or offer_id) and aid (or affiliate_id, aff_id) accept the public code or the numeric ID. Otherwise /click behaves exactly like /r.

What the server does#

  1. Looks up the offer by code. Unknown offer → a "not found" page (HTTP 404); nothing is redirected.
  2. Looks up the partner by code in the offer's workspace. An unknown partner code is treated as "not approved".
  3. Applies the offer's forwarding rules.
  4. Runs the checks; the first failure sends the click to the fallback chain with a reason:
CheckReason
Workspace activeworkspace_inactive (always the neutral page)
Offer active and inside its schedule, and its advertiser not Paused or Inactivepaused
Partner active and approved (or offer public and partner not blocked/rejected), offer terms accepted when requirednot_approved
Countries, devices, OS, extended targetingtargeting
Traffic controlstraffic_control
The partner's forced traffic-source templatetraffic_source
Click caps (partner on offer, then offer), hourly click capcap
Duplicate click when the offer sends duplicates to the fallbackduplicate
Destination is not a safe absolute URL after macro expansionbad_destination
  1. Picks the destination: a pre-lander (prl=1), the landing page in url_id=, a weighted landing page, or the offer's Destination URL (Landing pages).
  2. Expands macros in the destination (values percent-encoded).
  3. Answers with the offer's redirect mode: a 302 (default) or a 200 page that hides the referrer.

Every response carries Cache-Control: no-store and Referrer-Policy: no-referrer-when-downgrade. The redirect never waits for the click to be written.

Example#

Destination URL https://shop.example.com/?cid={click_id}&src={source_id}&geo={country}, click from Germany with source_id=blog-7:

URL
HTTP/1.1 302 Found
Location: https://shop.example.com/?cid=0192a6c3f1e04b7e9c2d8a1f3b5c7d9e&src=blog-7&geo=DE
Cache-Control: no-store

Fallback chain#

A refused click goes to the first of: a matching fail route → the offer's Fallback URL → (smart links: the smart link's fallback) → the workspace Default fallback URL → a neutral "link not available" page (HTTP 200, no redirect). Fallback URLs support macros.

Unique clicks#

A click is unique when the same visitor has not clicked the same offer through the same partner within the offer's unique window. Configure it on the offer's Advanced tab:

SettingDefaultOptions
Unique window (hours)241–720
Identify visitors byIP + user agentIP address; Cookie (falls back to IP + UA)
Duplicate clicksRecord and redirectSend to the fallback

With Cookie, an atk_uq cookie (1 year) is set on the tracking domain at redirect. Unique clicks drive CVR, CPC money and the duplicate setting; non-unique clicks are still logged.

Methods#

GET and HEAD are served; POST gets the same answer as GET (the body is never read). Other methods get 405 with an Allow header.

A partner may add url= to send the visitor to a specific page:

URL
https://trackcrown.com/r/OFFERCODE/PARTNERCODE?sub1=x&url=https%3A%2F%2Fshop.example.com%2Fsale

The link then behaves as a transparent link for that offer and partner: the target must be on the allowlist (workspace, offer destination host, Allowed transparent destinations, landing-page hosts) or the visitor gets a 403 page. Checks are recorded but never change the destination: a paused offer or advertiser, a cap or targeting only adds a reason to the click, and the forced traffic-source template is not checked.

Cookies#

/r sets no cookie unless you enable First-party pixel cookie (atk_cid, 30 days) in workspace settings or use the Cookie unique-click identifier. Clicks requested as hidden images or iframes never receive the pixel cookie.

Fraud signals#

Bot, datacenter, proxy, headless, prefetch, embedded-request and rate (more than 60 clicks a minute from one address) signals are stored on the click for reports. They never change the response.

Something unclear or missing in this article?Tell us