UTM & Lead Source Tracking Standard

UTM & Lead Source Tracking Standard™

Resource: RLR-09 · Link: 1 — Demand + Source · Playbook: Demand + Source Playbook Loop step: Repair (attribution) · Framework: ShiFt 6-Link Revenue Chain Framework™ Version: 1.0.0-draft

1. Purpose and scope

This Standard makes Revenue Chain attribution possible. Its job is to guarantee that every inquiry can be traced back to the source that created it, and forward to the revenue it produced, so the Lead Source Quality Audit™ (RLR-07) and Lead Source Scorecard & Budget Decision Matrix™ (RLR-08) can be trusted.

If tracking is broken, source decisions are guesses. Most "the leads are bad" and "we don't know what's working" problems are attribution failures, not source failures. Fix this before you cut or scale any budget.

Scope: paid and unpaid digital traffic, phone calls, forms, chat, marketplaces and Local Services Ads (LSA), referrals, and offline sources — through to the appointment and the retained client.

2. The governing rule: Original Source vs Latest Source

Every lead has two source facts, and they are not the same:

• Original Source — the source of the *first* touch that brought this person

into your world. This is the acquisition credit. It answers "who created this opportunity?"

• Latest Source — the source of the *most recent* touch before an action

(e.g. the click on the confirmation email, a later branded search). This answers "what did they do most recently?"

**Rule: the Original Source must never be silently overwritten by a later

touch. Store both. Report source quality (RLR-07/08) on Original Source**

unless you have an explicit, documented reason to use Latest.

Silent overwrite is the single most common cause of a source looking worthless (its clients get re-credited to branded search, direct, or "the confirmation email") — and of a cheap re-engagement touch looking like a hero.

3. Required UTM parameters

Tag every inbound link you control (ads, emails, social posts, partner links, QR codes). Five parameters are required.

Rules:

• Never leave utm_source, utm_medium, or utm_campaign blank on a link you

control.

• Never use different spellings for the same thing (facebook vs fb vs

meta). Pick one and enforce it via §5.

• Never put PII (names, emails, phone numbers) in any UTM value.
• UTMs describe Latest Source of that click; they are an input to Original

Source capture (§7), not a replacement for it.

4. Extended attribution fields

Capture these where applicable, in addition to UTMs, and persist them to the CRM (see §8):

• Landing page — first page URL the lead arrived on.
• Referring URL — the HTTP referrer, where available.
• Original Source — first-touch source (derived, persisted; see §7).
• Latest Source — most-recent-touch source.
• Campaign ID — platform campaign identifier (stable even if names change).
• Ad ID — specific ad/creative identifier.
• Ad set / ad group ID — the grouping level identifier.
• Keyword — search term or targeted keyword.
• Click ID — gclid (Google), gbraid/wbraid, fbclid (Meta), msclkid

(Microsoft), etc. Essential for platform-side reconciliation.

• Call tracking source — dynamic-number-insertion (DNI) source for phone

leads.

• Form source — which form and page produced a form lead.
• Chat source — which chat widget/page produced a chat lead.
• LSA / marketplace source — Local Services Ads or marketplace lead

identifier and the marketplace name.

• Referral source — the referring partner/person for word-of-mouth leads.
• Offline source — event, print, radio, signage, or manual entry origin.
• Appointment source — source carried through to the booked appointment

record.

• Retained-client source — source carried through to the won/retained record.
• Revenue attribution — the source stamped on the revenue/opportunity record.
• Source persistence — the mechanism (cookie/CRM field) that carries Original

Source across sessions (see §7).

Principle: source must travel the whole chain — inquiry → appointment → retained client → revenue. If it stops at the inquiry, RLR-07 cannot compute CAC or gross profit per lead.

5. Naming convention

1. Case: all values lowercase.
2. Spaces: none — use hyphens (-) between words within a value.
3. Separators inside compound values: hyphen within a token; do not invent

new delimiters.

1. Controlled vocabulary: maintain a single approved list of utm_source

and utm_medium values. New values are added deliberately, not ad hoc.

1. Dates: yyyymm (or yyyymmdd) inside utm_campaign for sortability.
2. Stability: prefer IDs (campaign/ad IDs) for reporting joins; names can

change, IDs should not.

1. No PII, no secrets in any parameter, ever.

Approved-vocabulary starter (extend for your business, keep it single-source):

• utm_medium: cpc, paid-social, display, email, sms, organic-social,

referral, affiliate, lsa, offline.

• utm_source: your named platforms and partners (e.g. google, bing, meta,

youtube, lsa, partner-a).

6. Required-fields checklist

Use this as the definition of a correctly tagged link and a correctly captured lead.

For every link you control:

• [ ] utm_source present and from the approved list
• [ ] utm_medium present and from the approved list
• [ ] utm_campaign present and follows the naming convention
• [ ] utm_content present when more than one creative/link exists
• [ ] utm_term present for paid search
• [ ] Click ID passthrough enabled (auto-tagging on / not stripped by redirects)

For every captured lead:

• [ ] Original Source captured and persisted (not overwritten)
• [ ] Latest Source captured
• [ ] Landing page and referring URL stored
• [ ] Channel-specific source stored (call/form/chat/LSA/referral/offline)
• [ ] Source fields mapped to CRM fields (§8)
• [ ] Source carried onto appointment and retained-client records

7. Source-persistence rules

1. On first touch, capture UTMs, click IDs, landing page, and referrer, and

write them to a first-touch (Original Source) store that is never overwritten on later visits.

1. On each subsequent touch, update a separate last-touch (Latest Source)

store.

1. On lead creation, write both Original and Latest onto the lead record

as distinct fields.

1. Direct / unknown must not overwrite a known Original Source. If a later

visit has no UTMs (typed the URL, clicked an untagged email), keep the existing Original Source.

1. Persist across sessions and devices as far as your stack allows (first-party

cookie/local store, plus CRM once identity is known); document the horizon (e.g. cookie lifetime) so decay is understood.

1. When a lead cannot be tied to any source, record an explicit

`unknown` source rather than blank — the size of the unknown bucket is itself an attribution-confidence signal for RLR-07/08.

8. CRM field mapping guidance

*Presented as an implementation example. No specific CRM is required — mirror these fields in whatever CRM you use.*

Mapping rules: set Original-* fields once and lock them; copy source onto the appointment record at booking and onto the opportunity/won record at close so the source survives to revenue.

9. Common tracking failures

• Silent Original-Source overwrite — later touches (branded search, direct,

confirmation-email clicks) replace the acquisition source. Most damaging and most common.

• Redirects stripping query strings — link shorteners or server redirects

drop UTMs and click IDs.

• Auto-tagging off / manual tags conflicting — Google auto-tagging disabled,

or manual UTMs colliding with gclid.

• Inconsistent vocabulary — facebook/fb/meta split one source into

three, understating each.

• Source dies at the inquiry — never copied to appointment/won/revenue, so

CAC and gross-profit-per-lead are impossible.

• Phone/offline invisible — no call tracking or no manual source capture, so

strong offline/referral sources look empty.

• Blank instead of `unknown` — hides the size of the untracked bucket and

inflates apparent quality of tracked sources.

• PII in UTMs — a compliance risk and a data-hygiene failure.

Each failure above maps to an RLR-07 "broken attribution" classification and, in RLR-08, forces INSUFFICIENT EVIDENCE until fixed.

10. QA procedure (ongoing)

1. Weekly: pull recent leads and confirm Original and Latest Source are both

populated and distinct where expected.

1. Weekly: check the size of the unknown source bucket; a growing bucket is

a regression.

1. Per campaign launch: verify every new link passes the §6 checklist before

spend starts (see §11).

1. Monthly: reconcile CRM lead counts by source against platform click/lead

counts; investigate large gaps.

1. Monthly: confirm source survives onto appointment and won records by

sampling recent retained clients.

1. Record QA results and set attribution confidence (High/Medium/Low) that feeds

RLR-07.

11. Pre-launch test procedure

Before any new campaign or link goes live:

1. Build the tagged URL and confirm all required UTMs (§3) are present and valid.
2. Click the live link in a clean session; confirm the landing page records the

UTMs, click ID, landing page, and referrer.

1. Submit a test lead (form/call/chat) and confirm it lands in the CRM with

Original Source, Latest Source, and channel source populated correctly.

1. Confirm redirects/shorteners preserve the query string and click ID

end-to-end.

1. Book a test appointment from that test lead and confirm the source copies

onto the appointment record.

1. Only start spend once the test lead and test appointment carry the correct

source. Delete or flag test records afterward.

12. Validation checklist (definition of done)

• [ ] Approved utm_source / utm_medium vocabulary exists and is enforced
• [ ] All controlled links carry valid required UTMs
• [ ] Click-ID passthrough verified end-to-end (no stripping)
• [ ] Original vs Latest Source both captured; Original never overwritten
• [ ] Phone, form, chat, marketplace/LSA, referral, and offline sources all

captured

• [ ] Source persists onto appointment and retained-client/revenue records
• [ ] CRM fields mapped per §8 with Original-* locked
• [ ] unknown used instead of blank; unknown-bucket size monitored
• [ ] Weekly/monthly QA (§10) running; attribution confidence set for RLR-07
• [ ] Pre-launch test (§11) is a required gate before spend

Installing this Standard is implemented, not verified. It is verified

only when a re-measured Audit (RLR-07) shows attribution confidence has risen

and the unknown bucket has shrunk and held.