The query parameters ad platforms append to a destination URL, and what each one means.
This table is the reason pixelex can answer "where did this person come from"
without anyone configuring a UTM tag. An ad platform already stamps its own
identifier on every click it sells; reading it is strictly more reliable than
asking a marketer to hand-build utm_source on every creative, because the
platform cannot forget and cannot typo.
It is also the only piece of reference data pixelex maintains itself.
Referrer classification is ref_inspector's job and user agents are
ua_inspector's, both actively maintained with databases updated daily. No
such database exists for click ids, so this is forty lines of table — small
enough to own, and the part that changes when a network launches a new one.
The click id is not just a source label
It is the join key for a server-side conversion. Meta will only match an
offline Purchase back to the ad that paid for it if the event carries
fbc, built from the fbclid captured at the click. Same for TikTok's
ttclid and Snap's sccid. So this table feeds two things: the attribution
report, and Pixelex.Destinations.
Summary
Functions
The whole table, as %{param => {network, medium}}.
The first recognised click id in a decoded query map.
Every recognised click-id parameter name.
Functions
The whole table, as %{param => {network, medium}}.
The first recognised click id in a decoded query map.
Returns {param, value, network, medium} or nil. When a URL carries more
than one — a Google click landing on a page whose link still has an old
fbclid — the paid-search and paid-social ids are preferred over the softer
social and native ones, because that is the click someone was actually
charged for.
@spec params() :: [String.t()]
Every recognised click-id parameter name.