Taxonomy Types
Flat, Structured, Key-Value and Opaque ID: what each packs into one slot, what it takes to read it back, what each survives, and what each asks of your team.
On this page
Your reports are clean. Then your boss asks: “Which campaign sold the most sneakers in Europe?”
You look at your campaign values. Maybe they carry the product, the way Stride’s carry runners. None of them carries a region, because nobody ever wrote one down. There’s no Europe to pull out.
The usual next thought is that you need a fancier naming structure, and that a team your size should be on one. Teams that act on it climb to structures they can’t keep clean, or stay with names nobody can split, and both choices are made for the wrong reason.
A fancier structure isn’t better data. It’s a different deal with whatever reads your names back, and the size of your team was never part of the deal.
Every structure is a promise to its parser
Chapter 2 gave you five slots, and Chapter 3 put three facts into one of them: spring_sale-runners-2025_03 carries the initiative, the product and the launch month in the campaign slot. Packing is the easy half. The other half is getting them back out, so a report can group by product or filter by month.
Something has to split the value back into its parts and read each part for what it is. In a spreadsheet it’s one formula: split the campaign column on the hyphen, and spring_sale-runners-2025_03 becomes three columns (initiative, product, month), ready to filter. In a data warehouse, where all your data lands, it’s one line of a query. In a report it’s a filter that matches the middle piece. Chapter 3 showed what makes a split possible: hyphens between segments, underscores inside one, which is why summer-sale-shoes fell apart and summer_sale-shoes didn’t. That step is parsing.
Whatever does it is your parser, and every structure is a promise to it.
Now try the opposite:
spring_
Everything is in there, and none of it can come back out. No separator says where the campaign ends and the platform begins. Nothing can parse it.
A structure is the agreement about how values get packed so they can be parsed. There are four.
Four ways to pack a slot
Flat. One dimension per value: spring_sale, facebook, paid_social. Nothing to parse, which is its strength and its limit. Sources and mediums stay Flat in almost every taxonomy, because each of those slots carries one fact (a source may add one detail segment, like partner-acme). The moment a slot needs to carry two, Flat has nowhere to put the second.
Structured. Segments in a fixed order, joined by hyphens. It’s built by concatenation: you take the values for each field and join them in order. Stride’s campaign pattern is Structured already:
stride.com/
utm_campaign, one segment per hyphen
- spring_
sale initiative - runnersproduct
- 2025_
03 launch month
Position carries the meaning: the second piece is the product because it’s second. Choosing which segments go in, and in what order, is part of the deal:
- As few segments as your reports need.
us-carries five (region, initiative, product, objective, quarter), and some teams run ten. Each one adds a choice on every link, a position that can slip, and length against the ad platforms’ name limits (Chapter 6). Long names hold up when a builder asks for each segment separately (a dropdown for region, another for product) and joins them in order, so nobody types the whole name (Chapter 9). Typed by hand, a long name is where segments get skipped or swapped.summer_sale- shoes- awareness- 2025_q2 - Every segment on every name. When a dimension doesn’t apply, give it a value that says so (
na), or keep its empty place between two hyphens.nais easier to read and to filter on; an empty place keeps the name shorter and is easier to miss. Either way the gap stays open: close it up, andus-without its region readssummer_sale- shoes- awareness- 2025_q2 summer_saleas the region. - Never source or medium: their own slots already carry them.
- Put the segment you filter by most first.
Key-Value. Each segment labels itself with a key and a colon:
stride.com/
utm_campaign, one segment per hyphen
- init:spring_
sale initiative - prd:runnersproduct
- launch:2025_
03 launch month
The order no longer matters, and a name only carries the keys it needs. The colon has one job in this book, and this is it. The cost shows up at the other end: every tool that reads these names needs someone who can split the pairs and look each value up by its key.
Opaque ID. The link carries one meaningless identifier, cid_4d71e09a, and every dimension lives in a lookup table on your side, the same two-column idea as Chapter 1’s lookup, grown into a table:
| ID | Initiative | Product | Launch |
|---|---|---|---|
cid_4d71e09a | spring_sale | runners | 2025_03 |
In the Introduction’s terms, the link carries a pointer to the letter instead of the letter. The pointer buys two things a name can’t. Fix a wrong value in the table and every click that ever carried the ID is corrected, with no link retagged. And the table holds as many columns as you like.
The day the region arrives
Now put the four to the same test. Suppose Stride had written its letter three ways from day one:
| Structure | Stride’s spring sale |
|---|---|
| Structured | spring_sale-runners-2025_03 |
| Key-Value | init:spring_ |
| Opaque ID | cid_4d71e09a, with the row above |
Then Stride starts selling in Europe, and every name needs a region, in front, where it’s filtered most. New names get one. Before you open the answer: what does a parser built for the new names read from the names already recorded, in each structure?
Show what happensHide it
| Structure | New names | An older name, read by the new parser |
|---|---|---|
| Structured | us-spring_sale-runners-2025_03 (the spring sale, had it been written the new way) | region spring_sale, initiative runners, product 2025_03, launch empty |
| Key-Value | gain a geo:us pair | everything it had, with no region |
| Opaque ID | rows gain a region column | the table fills in the region; no link changes |
Structured pays at the parser: every older name now reads one segment off, because position was the meaning. Key-Value pays nothing for the old names, which simply have no region. Opaque ID pays in the table: someone fills in the region for every older ID. That doesn’t contradict Chapter 1’s rule that nothing can be added to clicks already made: the clicks are exactly what they were; only the row behind the ID is new.
And the Structured cost comes from where the region went:
- Region last: older names parse with the region empty.
- Region first, where it’s filtered most: every older value shifts.
There’s a second catch in the Structured row. After the change, the parser sees two kinds of names, three segments and four, and it has to be told which is which. Running both formats side by side until the old ones fade is its own piece of work, and Chapter 10 is where it gets done.
Every structure can take the change. Each one pays for it in a different place.
Choose by capability, not headcount
Each structure sends its bill to your team: what it can build, and what it can keep running.
- FlatNo parsingone dimension per value
- Structuredthe common defaultA spreadsheet splitsplit on the hyphen; a non-technical team can do it
- Key-ValueA key-aware parsersome technical skill, in every tool that reads the names
- Opaque IDA warehouse and a processone source of truth, every system joined to the table, a table kept complete
Opaque ID’s rung deserves spelling out, because it asks the most. Every report has to rebuild its dimensions by joining the ID to the table, so it needs three things:
- One source of truth. All your data lands in one place first, usually a data warehouse: the one copy everyone reads from.
- Every system integrated. Analytics, the CRM, the lead forms and the ad platforms all have to join to it.
- A table kept complete before any link ships, because an ID with no row is a click with no meaning.
So when a team has to pick, the default runs in one direction:
- Concatenation. A good choice, and the most common one.
- Key-Value, next. For names that must survive new dimensions, once something can read keys.
- Opaque ID, last. Only when you know every system it will affect and can join each one to the table.
Most teams don’t need Opaque ID. It’s elegant, and the operational overhead kills adoption.
Size isn’t the test either way. A large company can run on concatenation, and most likely needs it. A small one shouldn’t take on Opaque ID, however tidy it looks.
The four side by side
| Flat | Structured | Key-Value | Opaque ID | |
|---|---|---|---|---|
| What one slot carries | one dimension | several, in a fixed order | several, each labelled | an ID; the dimensions live in a table |
| Reading it back | nothing to parse | a split on the hyphen | a parser that reads keys | a join to the lookup table |
| A segment added or skipped | no room to add one | shifts every value after it | nothing breaks | add a column; nothing to skip |
| What it asks | nothing | a split on the hyphen | technical skill in every tool | a source of truth, integrations, a process |
Read the bottom row first. The top three describe your names; the last describes your team, and it’s the row that decides.
Both teams chose by the same test. Stride’s names only need to survive a second region it can see coming; the home goods brand needed three dimensions at once, more on the way, and analysts who could read keys. Neither chose by counting people.
Your situation
Read your structure off three questions:
- How often do your dimensions change? Rarely, and concatenation holds. Often, and Key-Value is the one where nothing breaks.
- What parses your names today? A person or a spreadsheet split: concatenation. A query that reads keys: Key-Value is open to you.
- Can your team keep a lookup table complete, with every system joined to one source of truth? Yes: Opaque ID is on the table. Not yet: it isn’t.
What changes
| The decision | When structure is a status symbol | When structure is a parsing deal |
|---|---|---|
| Which structure | the most advanced one | the one your names must survive and your parsers can read |
| What decides it | how many people make links | technical and process capability, and what each choice costs to run |
| Adding a dimension | a new segment wherever it fits | a new segment shifts every older value after it, so decide where it goes and put the most-filtered first, or use keys |
| Opaque ID | flexibility, so why not | only when every system it touches is known and can join to the table |
Where the rule lives
Every structure meets its real test when someone types a name. Its rules sit in one of two places:
Beside the path
Written in a planning doc, the structure is a rule people remember segment by segment, and one skipped segment shifts everything after it.
Inside the path
Built into the builder, each segment is its own field, and a skipped one can’t ship.
Check yourself
A campaign is typed by hand under the pattern as spring_sale-2025_03, with the product skipped. What does a parser read?
Show answerHide answer
Initiative spring_sale, product 2025_03, and an empty launch month. Every value after the gap shifts one place, because position carries the meaning.
A 200-person team's only parser is a spreadsheet that splits on hyphens. Key-Value, Opaque ID or concatenation?
Show answerHide answer
Concatenation: it’s what they can parse. Size isn’t the test. Key-Value only once something can read keys, and Opaque ID only once every system joins to one table.
A colleague proposes Opaque ID because it's the most flexible, and your data lives in an analytics tool and a CRM that don't share a warehouse. What do you weigh?
Show answerHide answer
What it asks: one source of truth, every system joined to the table, and a process that keeps the table complete before any link ships. Without those, concatenation or Key-Value will serve you better.
In one line
Pick a structure by what your names must survive and what can parse them, never by headcount: concatenation first, Key-Value next, Opaque ID only when every system it touches is known.
Before the next chapter
Write down what parses your campaign names today (a person, a spreadsheet, a warehouse query) and one change it couldn't survive. That's the limit of your structure.