Tag your ad links

The parameters the tracker reads

The tracker reads the parameters below from the page's URL on every event. The network is never inferred from a referrer or a cookie: the referrer says that a landing arrived by referrer and where an ad ran, never which network bought the click. A session's tags are the ones its first page view carried — the landing — and a session with no page view is not counted at all.

Click ids are appended by the ad platform itself, so their presence proves who served the click:

UTM parameters are typed into the link by you, so they are a declaration, read against the lists below:

The order of resolution

The same rules, in the same order, give every count in the app and every row of the Realtime screen:

1. A click id. The first one present, tested in this order: gclid, fbclid, ttclid, msclkid, gbraid, wbraid, li_fat_id, oppref. Its presence settles the network; nothing else is read, and no rule can move it.
2. Is the medium paid? Your site's rule on the utm_medium value if there is one, else the built-in list: cpc, ppc, paid, paidsearch, paid_search, paidsocial, paid_social, sponsored, display, affiliate. A landing with no utm_medium is never paid by its tags.
3. Which network? Your site's rule on the utm_source value if there is one, else the built-in lists below, else Other Paid — paid, naming no network.
4. Otherwise, not paid. The landing has no network and sits outside every paid lens.

Built-in sources, by the network they name:

Values are lowercased before they are compared, never trimmed: CPC matches cpc, and a value with a leading space matches no built-in value — only a rule set on it, space included. The UTM tags screen shows how each landing was attributed, as sessions proven by a click id against sessions read from the tag alone.

A change to a rule applies to every window, past ones included.

Untagged landings

A landing that carries neither a click id nor a utm_medium read as paid has no network. It is still collected, on every plan, and nothing is deleted. What changes is where it shows:

• The lenses are read over paid landings only, so it has no row on Overview, Networks or Campaigns.
• The Events screen counts every row the site received, paid or not, and says how many were paid beside the total.
• The Realtime screen shows an arrival only once its landing resolves to a network.

A paid landing with no utm_campaign is a different case. It has a network, so it is in your site and network totals; it has no campaign, so it gets no row on the Campaigns screen and reads as Untagged where a feed names the campaign — and Untagged is not a lens you can select. Missing campaign tagging costs you a name, never a number.

The UTM tags screen

In the rail, under Sources, right after Campaigns. It shows what Intelligence/Ads observed on the site's landings and how it read each tag, on every plan, for the period the picker sets. As on every screen, the plan governs the readable window. Column by column it is on its own page, UTM tags; the short version:

• A filter above the blocks narrows the pairs by their values and always says how many are listed.
• The figures — Tagged pairs, Tagged sessions, Proven by a click id, Read from the tag alone. Sessions are landings in the window.
• Tagged pairs — one row per utm_source and utm_medium pair, values exactly as received (Google and google are two rows), grouped by what the tag reads as: Other Paid first, then the networks by sessions, Not paid last. Each block is headed by what it reads as, with its pairs and sessions in the window. Each row splits its sessions into Click id — a click id proved them, and no rule can move those — and Tag alone — only the tag attributed them. A Why line says which list or which rule decided, with a Built-in or Your rule badge. The 500 pairs with the most sessions are listed; past that, the page says how many pairs the window held.
• A period with no tagged landing says "No tagged landing in this period." A read that fails says the tags, or the rules, could not be read just now.
• Untagged landings never appear here, and a pair carries counts only — never a session, a path or a visitor.

Rules on this site

A rule corrects how Intelligence/Ads reads one value on one site. Two kinds exist:

Each control also offers Built-in, which removes the rule and puts the value back on the built-in lists.

Owners and admins set them from the pencil at the end of a pair's row; a member sees the reading, not the pencil. The editor states each control's reach in the window before you save — every pair tagged with that value follows, with the pairs and sessions it touches — because a rule is per value, not per pair. A pair with no medium gets no pencil: no rule can make it paid.

What a rule can and cannot do:

• A click id always outranks it. Rules act on the tag only.
• A source rule is read only while the medium is paid, by the built-in list or by your rule. A source alone never classifies.
• It matches any case and is never trimmed. Values are plain ASCII, 1 to 200 characters; the editor refuses anything else up front.
• One rule per value: a medium is never both paid and not paid, and a source never names two networks. A site holds at most 100 rules.
• It is shared with the workspace and applies to past windows too.

Rules on this site lists them — Value, Applies to, Reads as, Updated — with a remove control that puts the value back on the built-in lists. Its footnote counts the rules against the cap ("N of 100 rules on this site"); with none, it says every pair is read with the built-in lists. Built-in lists beside it prints what applies when no rule does: the click ids per network, the paid mediums, the sources per network, and the Other Paid fallback.

What tagging does not do

• It is not a UTM builder. The screen shows what was observed and how it was read; the links are yours to write.
• It passes no verdict on a tag. A pair read as not paid is stated as such. Whether that is right is your call, and the pencil is how you make it.
• A rule never outranks a click id, never reaches another site, and never classifies on a source alone.
• Nothing to wait for. A rule shows in every window as soon as it is saved.
• The four GA4-era parameters — utm_id, utm_source_platform, utm_creative_format, utm_marketing_tactic — are kept with the event and read by no screen.
• It never shows a session, a path or a visitor. A pair is its counts; the drill screens are elsewhere.