Tokens
Every macro UTMCAP substitutes into an offer or landing page URL, what each one resolves to, and what happens to one it does not recognise.
A token is a placeholder UTMCAP replaces at the moment of the redirect. Write them into an offer URL or a landing page URL and the visitor's own values go out with them.
https://network.example/offer/9?aff_sub={click_id}&geo={country}&dev={device_type}
Every value is URL-encoded on the way out, so a city with a space or a referrer with a query string of its own cannot break the URL it lands in.
Not to be confused with your traffic source's macros, which are the platform's placeholders and arrive on the way in. See traffic sources.
#The click
| Token | Resolves to |
|---|---|
{click_id} |
This click's id — also {clickid}, {cid} |
{timestamp} |
Unix seconds |
{cost} |
What this click cost |
{currency} |
The campaign's currency |
{click_id} is the one that must be in every offer URL. Without it a
conversion cannot be joined back to the click that earned it.
#What it belongs to
| Token | Resolves to |
|---|---|
{campaign_id} {campaign_name} |
The campaign this click belongs to |
{source_id} {source_name} |
The traffic source it was bought from |
{offer_id} {offer_name} |
The offer, empty unless routed to one |
{lander_id} {lander_name} |
The lander, empty unless routed to one |
{payout} |
What the destination pays |
The offer and lander pairs are exclusive: a click being sent to a lander has no offer yet, and the offer tokens resolve to empty rather than to something wrong.
#Who the visitor is
| Token | Resolves to |
|---|---|
{country} {region} {city} |
Where, by IP |
{isp} {asn} {connection_type} |
Whose network |
{device_type} {device_brand} |
Phone, tablet, desktop — and make |
{os} {os_version} |
Operating system, and its version |
{browser} {browser_version} |
Browser, and its version |
{language} |
Their browser's language |
{ip} {user_agent} |
The raw address and browser string |
{referrer} |
Where they came from |
Passing {ip} and {user_agent} on to a network is often required for their
own fraud checks. Both identify a person: send them where you have a reason to,
not by default.
#Whatever came in
| Token | Resolves to |
|---|---|
{sub1} … {sub10} |
The sub slots, as filled by the source's macros |
{query.NAME} |
Any query parameter on the incoming URL, by name |
{query.…} is the escape hatch for a value no slot is holding — a platform
parameter you did not map, or something you appended yourself. {query.gclid}
passes Google's own click id straight through.
#Random
{random:N} produces N random lowercase letters and digits, up to 32.
For a cache-buster on a network that caches too aggressively, or a unique value a destination requires and nothing else supplies.
#An unknown token
It is replaced with nothing.
Not left as literal text, not an error — removed. So {clickid} works,
{click-id} does not, and the difference between them is a parameter that
silently arrives empty.
That is worth knowing because it fails in the quietest possible way: the redirect works, the visitor reaches the offer, the network records the conversion against an empty sub-id, and nothing attributes. If a network says your click ids are blank, a misspelled token is the first thing to check — against the table above, character by character.
The same applies to a token that is spelled correctly but empty for this
visitor: {city} on an IP the geo database cannot place resolves to empty, and
the parameter arrives blank rather than absent.