Full Answer

Standard UTM parameters follow a well-known naming convention: utm_source, utm_medium, utm_campaign, utm_term, and utm_content. This predictability is both their strength and their vulnerability. Strength, because every analytics platform recognises them automatically. Vulnerability, because every privacy tool, browser extension, and platform-level stripping rule also recognises them. Safari strips query decorations matching known tracking patterns. Firefox Enhanced Tracking Protection does the same. Browser extensions like uBlock Origin and ClearURLs explicitly target utm_ prefixed parameters.

Coded UTMs solve this by encoding the same attribution data into a parameter name and value that privacy tools do not recognise. The encoding scheme maps each UTM field to a compact token — fb for facebook, c for cpc, sum2025 for summer-2025 — and concatenates them into a single parameter with a neutral name like ref or src. To an ad blocker scanning the query string, ref=fb_c_sum2025 looks like an internal reference parameter, not a tracking decorator. It passes through untouched.

The decoding happens server-side, at the first point of contact between the visitor's request and your infrastructure. A lightweight mapping function translates each token back into standard UTM values, which then flow into GA4, Meta CAPI, BigQuery, or any configured destination exactly as if the URL had carried conventional parameters. This means no changes are required to downstream analytics configuration — reports, segments, and attribution models all see standard utm_ values. The encoding exists purely as a transport-layer defence against parameter stripping.