Advanced Taxonomy Structures

Your taxonomy is clean. Your reports make sense. Then your boss asks: “Which product line performs best in EMEA?”

You look at your utm_campaign values: spring_sale, webinar_demo, brand_awareness. There’s no way to filter by product or region, because neither was ever encoded. You can’t query what you never captured.

That question is the sound of the Flat approach hitting its ceiling.

The first five chapters gave you a complete working system, and the Flat approach from Chapter 3 (human-readable values drawn from an approved list) is the right start for almost everyone. From here the guide goes deeper. More channels, more people creating links, more dimensions to track: that’s when Flat starts to crack, and this chapter is the upgrade path. It settles three questions: which of the four structures fits your team, which enhancement layers keep any of them clean, and what to do when five UTM parameters stop being enough.

Inventory Your Dimensions Before You Pick a Structure

The upgrade instinct is to go shopping for a fancier structure. Resist it for one exercise.

First, inventory the dimensions your business actually needs to track. Structure without a dimension list is how teams end up with six-segment campaign names and no idea what half the segments are for.

Three steps:

1. Define the business objectives. What decisions will this data inform? Channel spend optimization, acquisition cost by product, messaging effectiveness, revenue attribution?
2. List every dimension you might analyze. Channels, sources, campaign types, products, dates, audiences, objectives, regions.
3. Then cut ruthlessly. Not everything worth tracking is worth tracking now. Keep the dimensions that directly inform decisions. The taxonomy can expand later.

Skip the exercise and you land in one of three traps: over-collection (too many dimensions crammed into limited UTM fields, producing unmanageable values), under-collection (the crucial dimension missing exactly when leadership asks about it), or misalignment (diligently collecting data that maps to no report and no strategic goal).

Key Data Points to Consider

Common dimensions beyond the basics:

• Business Unit / Product Line: e.g., electronics_division, software_product_a
• Target Audience Segment: e.g., new_customers, enterprise_leads, demographic_25-35
• Campaign Objective / Goal: e.g., brand_awareness, lead_generation, direct_sales
• Offer Type / Promotion Code: e.g., free_trial_offer, 20pct_discount
• Region / Market / Language: e.g., north_america, emea, lang_es
• Content Format / Creative Type: e.g., video_ad, blog_post, webinar_live
• Funnel Stage: e.g., tofu (Top of Funnel), mofu, bofu
• Date / Seasonality Identifiers: e.g., 2025_q1, holiday_promo_dec
• Internal Identifiers: Cost center, project code, team identifier

Map each dimension you keep to a UTM parameter (utm_campaign might concatenate region, product, and objective), or flag it as a candidate for the custom parameters at the end of this chapter.

Advanced Taxonomy Approaches

There are four fundamentally different ways to structure UTM parameter values. Chapter 3 covered the first one (Flat). Here are the other three, and how to pick.

1. Structured (Positional)

Predefined segments, fixed order, a delimiter between them. Each position means exactly one thing.

us-paid_social-facebook-summer_sale-awareness-2025_q2

Region

Medium

Platform

Campaign name

Objective

Quarter/Year

Note the two-delimiter convention in the example above: hyphens (-) separate segments from each other, while underscores (_) join words within a segment. paid_social is one segment (the medium); summer_sale is one segment (the campaign name). The distinction is what makes the value machine-parseable: split on hyphens and every segment comes out whole, still readable as a multi-word phrase. Use only hyphens (us-paid-social-facebook-summer-sale-awareness-q2-2025) and no program can tell where one segment ends and the next begins.

If you followed the starter taxonomy in Chapter 3, your values already use underscores (spring_sale, paid_social, brand_awareness, qr_code). Moving from Flat to Structured requires no value migration; every existing value is already a valid single segment. That’s the delimiter law from Chapter 3 paying off: no value carries a hyphen inside it, so a hyphen in a structured name means exactly one thing, and any value (the medium included) can ride inside utm_campaign or a composite parameter without corrupting the parse.

Structured embeds rich metadata directly in your analytics and supports regex filtering (e.g., ^us-.*-awareness). Now the flaw. Position is load-bearing. Someone skips a segment and every value after the gap shifts one position over, silently misinterpreted: nothing errors, the data is just wrong. That’s why unused positions need filler values like _na_, and why adding a new dimension is a breaking change to everything already collected. Structured is best for teams of 3–10 with a disciplined process, or a builder tool that makes skipping a field impossible.

How many segments? Three to five. Conventions with 6+ segments are harder to remember, harder to type, and harder to enforce; adoption drops and errors climb. If you genuinely need more than 5 dimensions, don’t build a longer string. Use Key-Value (only the relevant keys ride along) or Opaque ID (every dimension lives in a lookup table).

2. Key-Value (Self-Describing Pairs)

Each piece of data carries its own label. Self-documenting, position-independent.

utm_campaign = geo:us-obj:awareness-prd:enterprise-q:q2

This eliminates the biggest flaw of Structured. Order doesn’t matter. You include only the attributes that apply, so no _na_ fillers. geo:us is unambiguous with no position guide open in another tab. Adding a new dimension like aud:smb breaks nothing that already exists, and any key can be extracted with a regex. The trade-off: values this shape are tedious to type by hand (a builder tool stops being optional) and URLs run longer.

Key-Value is our recommendation for most growing teams. It hits the sweet spot of readability, extensibility, and machine-parseability. Best fit: teams of 10+ running 50+ campaigns per month across multiple regions or products.

3. Opaque ID (External Lookup)

The third approach is where this guide’s use of “UTM” as shorthand becomes most visible. With Opaque ID, the utm_campaign parameter (or, more commonly, a custom parameter like cid) carries a single meaningless identifier, and the taxonomy governance happens entirely in your backend system, not in the URL. The principles don’t change: structured dimensions, approved values, consistent naming. Only the location of the metadata changes.

All of it lives in an external lookup table.

utm_campaign = cid_8f3a2b1c

Lookup Table:

CID	Region	Objective	Product
cid_8f3a2b1c	north_america	competitor_displacement	platform_pro

(plus: quarter, budget_code, abm_tier, owner, etc.)

The appeal is real. Competitors learn nothing from your URLs. You can track unlimited dimensions. Metadata can be corrected without re-tagging a single URL. The price is real too: a database, a campaign management UI, and BI integration, all of which someone has to build and keep alive.

If we’re being honest, most teams don’t need Opaque ID. It’s technically elegant, but the operational overhead kills adoption.

Where it does pay its way: organizations with 30+ people creating campaigns, strong technical capabilities, and dedicated analytics engineering resources.

Comparing the Four Approaches

	Flat	Structured	Key-Value	Opaque ID
Example value	spring_sale	us-cpc-google-spring_sale-awareness-q2	geo:us-obj:awareness-prd:shoes-q:q2	cid_8f3a2b1c
Readable in reports?	Yes	Yes, with a guide	Yes, self-documenting	No: requires lookup
Position-dependent?	N/A	Yes: skipping a segment breaks everything	No: order doesn’t matter	N/A
Extensible?	Limited	Breaking change to add dimensions	Add new keys without breaking old data	Unlimited dimensions in lookup table
Requires tooling?	No	Recommended (builder prevents skipped fields)	Yes (manual typing is error-prone)	Yes (database, UI, BI integration)
Best for	1–2 people, <10 campaigns/mo	3–10 people, disciplined process	10–30 people, multi-region/product	30+ people with analytics engineering and automation
Key risk	Fragmentation without governance	Silent misinterpretation if a position is skipped	Longer URLs, harder to type	Infrastructure dependency

Our read of that table: Flat is the right answer for something like 80% of teams, and most of the rest want Key-Value. Structured looks tidy in the planning doc, and then someone skips a segment in week three. Opaque ID is for organizations that already employ analytics engineers, not organizations that hope to someday. If you’re staring at the table unsure which row you are, you’re a Flat team; the teams that need to upgrade already know it.

Upgrade When You Feel Pain, Not Before

Match the approach to your actual scale. Preemptive complexity is how taxonomies die young: start fancier than your team can sustain and you’ve traded fragmentation for abandonment.

How many people create UTM links?

• 1-2→Flat + Allowed Values (Chapter 3)
• 3-10→Do you need more than 5 dimensions?
  • No→Structured + Builder Tool
  • Yes→Key-Value + Dependency Validation
• 10+→Key-Value + Dependency Validation
  • 30+ with analytics engineering?→Opaque ID + Full Stack

Team Size	Recommended Combination
1-2 people, < 10 campaigns/month	Flat + Allowed Values list
3-10 people, 10-50 campaigns/month	Structured + Flat Source/Medium (with a builder tool)
10-30 people, 50+ campaigns/month	Key-Value + Dependency Validation (recommended for most)
30+ people, analytics engineering and automation	Opaque ID + full stack (database, campaign UI, BI integration)

Let the transition be evolutionary, driven by growing analytical needs and your organization’s real capacity to manage the added complexity. Never by ambition.

Enhancement Layers

Whichever core approach you choose, enhancement layers sit on top of it and do the enforcing.

Cascading Dropdowns (Dependency Validation) establish parent-child relationships between fields. Of all the governance mechanisms in this guide, this is the one that changes day-to-day data quality the most.

Here’s what it looks like in practice:

Without cascading dropdowns

utm_medium

• email

utm_source

• facebook

With cascading dropdowns

utm_medium

• email

utm_source

• newsletter
• hubspot
• mailchimp
• promotional_email

Select medium = email and the source dropdown narrows to the email-relevant options: newsletter, hubspot, mailchimp, promotional_email. Picking facebook as the source of an email campaign stops being a mistake anyone can make. The impossible combination is structurally prevented, by the interface, instead of by a rule someone has to remember.

That’s “governance at the point of creation” made tangible. You stop hoping people check the documentation. The wrong choice simply isn’t on the menu.

Cross-Field Validation goes a step further: rules about valid combinations across fields, beyond parent-child hierarchies. “If utm_medium is cpc, then utm_source must be one of google, bing, or yahoo.” That’s the step from a list of allowed values to a list of allowed combinations, and it catches errors that cascading dropdowns alone let through.

Conditional Rules change a field’s available options based on context, multiple conditions at once. “If Channel = display AND Region = EMEA, show the EMEA display formats picklist; if Channel = display AND Region = NA, show the NA display formats picklist.” One taxonomy serves different teams and regions, each seeing only the options relevant to their context, with nothing duplicated.

Post-Hoc Classification applies SQL or regex rules during analysis to normalize messy data after collection: every stray facebook, fb, and meta gets mapped to a single clean value. Keep it as a safety net. Never let it become the plan. Preventing a bad value at creation costs seconds; cleaning it up afterward is a recurring job that’s never quite finished.

None of these layers replaces the four core approaches; they stack on top. Structured plus cascading dropdowns. Key-Value plus cross-field validation, with post-hoc classification as the net underneath. Every layer you add narrows the path bad data can take into your system.

Custom Parameters: Beyond the Standard Five

Here the guide’s core reframing gets concrete: the taxonomy dimensions you defined in Chapter 1 are the real system, and the parameters that carry them are interchangeable. UTMs, custom cid parameters, ad platform campaign names, warehouse columns: different carriers, same classification. A team that starts from “what dimensions do we need?” ends up with a taxonomy that travels across all of them. A team that starts from “what should we put in utm_campaign?” ends up with a system shaped by parameter names instead of business needs.

When the five standard UTM parameters run out of room, organizations define custom query parameters.

Custom Campaign IDs (cid)

The classic example is cid (Campaign ID), most often used with Adobe Analytics as an all-in-one identifier. A cid like PROMO123-FALL-US gets parsed by backend classification rules into its parts (Promotion: PROMO123, Season: Fall, Region: US). The parse works for the same reason Chapter 3’s delimiter law allows no exceptions: hyphens are structure here, so a hyphen living inside any segment’s value would split it in two at classification time.

Reach for custom parameters when:

• The five UTM parameters don’t provide enough distinct fields for your tracking dimensions
• You need internal tracking dimensions that don’t belong in standard analytics reports
• A proprietary system requires a unique identifier that doesn’t map to UTMs
• You want a single consolidated ID in the URL, enriched with metadata on the backend

A structured cid approach keeps URLs clean while tracking more dimensions than the five standard UTMs, and it lets you correct metadata retroactively without altering historical click data. What you take on in return is governance: generating CIDs, maintaining lookup tables, and applying the classifications inside your analytics platform.

Third-Party Click Identifiers (gclid, fbclid, msclkid)

Major ad platforms automatically append their own click identifiers:

• gclid (Google Click Identifier): Auto-appended by Google Ads when auto-tagging is enabled. Essential for conversion tracking and for tying sessions to Google Ads campaigns in GA4; the cost data itself arrives through the Google Ads account link, not through Data Import.
• fbclid (Facebook Click Identifier): Auto-appended by Facebook to outbound links.
• msclkid (Microsoft Click ID): Auto-appended by Microsoft Advertising.

These coexist with manual UTM parameters. Configure tracking templates correctly to avoid conflicts where auto-tagging overwrites manual UTMs.

Watch for: Redirect chains stripping these identifiers, and fbclid causing page-level fragmentation in GA4 reports (strip it with GA4’s data redaction: Admin → Data streams → your web stream → Redact data).

utm_id: Google Analytics Campaign ID

The utm_id parameter is GA-specific: it populates GA4’s Campaign ID dimension. Its headline use is cost data import: upload non-Google campaign costs (spend, impressions, clicks) through GA’s Data Import feature, and GA4 joins them to your collected traffic on source, medium, and date. Campaign ID is an optional join key on top of those three, and Google recommends setting utm_id to the same IDs you upload.

Choose utm_id when integrating non-Google cost data into GA4. Choose custom cid when you need a flexible, cross-platform identifier. You can use both.

---

Action Item: Pull a report of your current utm_campaign values. Can you filter by objective, product, or region? If those are questions your leadership asks and the answer is no, you’ve found your ceiling. Start the move from Flat to Key-Value.