Designing the Key

Open the classification interface in Adobe Analytics and go looking for the screen where you design the key.

There is not one. There never was. You can create a set, define a schema, upload a file, write a rule, and at no point does Adobe ask you what the key should be. By the time you arrive at that interface the key already exists, and has existed for months. Somebody chose it. Maybe a marketer inventing a campaign code convention. Maybe a developer deciding what to push into an eVar. Maybe nobody chose it at all, and the key is simply whatever the system happened to emit.

Which is a strange thing to sit with. The most important decision in this entire module gets made outside the tool that depends on it, long before anyone is thinking about classifications, and usually by people who have never heard the word.

The key is not a setting

The phrase "designing the key" invites the wrong mental picture, so it is worth clearing up straight away.

The key is not a field you fill in anywhere. The key is the raw dimension value itself. Classify a tracking code, and the key is whatever string arrived in that tracking code. Classify an eVar holding a User ID, and the key is that User ID, exactly as the login page pushed it. No translation layer, no configuration, nowhere to step in. Whatever was collected is the key, and the classification either finds it or it does not.

So designing the key is not an analytics task you perform in an analytics screen. It is a decision about what gets collected in the first place. It belongs in the same conversation as the rest of your variable planning, the one you have with marketing and with the developer, written down during variable planning long before a single classification exists.

Remember what Classifications Overview established. Classifications shape data at report time, not at collection time. That is what makes them retroactive and what makes them free of code. But it also means they have nothing of their own to hold on to. They grip the collected value, and only the collected value. The key is the one thing a classification can reach, which makes it the whole load-bearing structure.

Five things make a key good. Here they are before the detail, so you know the shape of the walk.

One: the key has to be there

Start with the rule that sounds too obvious to bother stating, then watch how often it gets broken.

A classification resolves a key on a hit. No key on the hit, nothing to resolve, and that dimension item goes into Unspecified. No error. No warning. Just a quiet line in the report absorbing everything the classification could not reach.

So the real question is never "will the key be collected." It is "on which hits will the key actually be present," and the answer depends entirely on where you put it.

Put the club's User ID in a prop and it lives only on the hits where the code explicitly set it. Realistically that means the login page and nothing else. Every classification hanging off it will describe the login page and go silent everywhere else. Run a report of Membership Tier against Hall Bookings and you get almost nothing, correctly, because the booking page never carried a User ID.

Put that same User ID in an eVar with a thirty-day expiration and it persists. The member's whole month of activity now carries the key, and the classifications travel with it everywhere they go. Same data, same file, completely different report.

You configured none of that in the classification screen. You configured it back when you decided which variable holds the key and how long it lives, which is a decision you made back in Variables, and it has just come due.

Two: the key has to mean one thing, forever

This is the rule that gets broken most expensively, and it turns the best property of classifications into the most dangerous one. Slow down here.

Retroactivity is not a one-time gift. It is a permanent, living relationship between the lookup table and every hit in your history. Change the table today and history changes today. Load a file with the same key in it twice, and the second row simply wins. There is no versioning. There is no effective date. One current value per key, and it applies to all of time.

Now picture what happens when a key gets reused.

Member M-10482 is a sixty-four year old Gold member who booked the community hall every month for two years. She leaves. Eighteen months later the membership system, which recycles IDs, hands M-10482 to a twenty-three year old new joiner. The CRM export runs on schedule that night. The file uploads cleanly. No error appears anywhere.

And two years of hall bookings by a senior Gold member have just become two years of hall bookings by a twenty-three year old.

So before you accept any value as a key, go and ask the system that generates it one question. Can this value ever refer to something else later? Not "will it," but "can it." If the answer is yes, either fix it at the source and make the identifier permanent, or classify something else instead.

That question quietly indicts a whole family of tempting keys. A campaign code reused next year because it worked well last year. A product SKU retired and later reissued for something different. An order number that resets each fiscal year. Every one of them looks fine on the day you upload it. Every one of them is a slow rewrite of your own history.

Three: the key has to be readable by a machine

The first two rules are about correctness. This one is about leverage, and it separates a key that merely works from a key that pays for itself.

Classifications Overview introduced the rule builder, which reads the key you already have, matches it against a pattern, and fills classification columns without any file at all. Whether that is even possible has nothing to do with the rule builder. It was settled months earlier, by whoever wrote the campaign code convention.

Look at two tracking codes for the same email campaign.

The second key is not just nicer to look at. It has a structure, and structure is the thing a regular expression can grip.

Regular expressions work best on codes that use delimiters. Not codes of a fixed width, not codes you slice by character position, but codes with a separator between the parts. The reason is practical. Position-based parsing breaks the first time a campaign name runs one character long. Delimiter-based parsing does not care how long the parts are, only that something sits between them.

So the delimiter matters more than it looks. It has to be a character that can never appear inside any of the values it separates. An underscore is safe, because campaign names rarely contain one. A hyphen is riskier, because win-back is a perfectly natural thing for a marketer to type, and the moment they do, your rule quietly produces a Campaign of win and a Country of back.

Four: the key has to survive the boring constraints

None of this is exciting. All of it breaks real uploads, and the failures tend to arrive weeks after the key convention was agreed, when changing it has become expensive.

Read that zero row twice, because nobody believes it until it happens to them. A store with a product whose SKU is genuinely 0, or a campaign code that a system emits as 000 when it has nothing better to say, will fail to classify and will never tell you why.

Five: the key has to be countable

The last rule decides whether the whole approach is even viable, and it comes down to scale.

Performance rests almost entirely on one number: how many unique values the key will ever hold. Variables carrying enormous numbers of unique values deserve real caution, and the caution grows when several of them are combined into a single classification set.

So the question to ask of any candidate key is not "can this be classified." It is "how many distinct values will this key ever carry." A tracking code convention producing a few thousand campaigns a year is comfortable. A product catalog of two hundred thousand SKUs is a normal, working classification. A User ID for a club with three thousand members is entirely fine. A User ID for a retailer with forty million customers is not, and pushing it there gives you something slow, fragile, and eventually unusable, without ever producing an error that says so.

That ceiling is not a reason to avoid classifications. It is a reason to find out, at design time, roughly how many unique values your key will carry. The source system can tell you in an afternoon, and almost nobody thinks to ask.

The fork this all leads to

Now the architectural decision Classifications Overview promised, and one you will make again and again for the rest of your career.

The campaign above needs five attributes reportable. There are two entirely legitimate ways to get them, and choosing well is exactly the kind of judgment that separates an architect from someone following a tutorial.

Neither column wins. They answer different questions.

If the attribute is needed in real time, or has to reach a downstream data lake through the raw feed, give it its own variable and pay the slot. If it is descriptive, likely to grow, and read by humans in reports rather than by machines in pipelines, build it into a structured key and classify it. Usually the retroactive row is what decides it, because being able to add a sixth attribute two years from now and have it apply to every hit you have ever collected is something separate variables cannot offer at any price.

Which means somebody has to write it down

Look back over those five rules and notice what they share. Not one of them can be fixed later.

A recycled key cannot be un-recycled. A key that was never collected cannot be collected retroactively. A tracking code convention without delimiters cannot be given delimiters after ten thousand campaigns have already used it. Classifications heal almost everything downstream of the key, and nothing at all upstream of it.

Which is why the key convention becomes a document, in exactly the way the channel list has in Marketing Channels, and for exactly the same reason. It encodes a decision nobody can take back.

Hand that to a marketer and it looks like bureaucracy. It is not. It is the only thing standing between a business and the discovery, two years and forty thousand campaigns later, that all of its campaign reporting has to be rebuilt by hand because nobody ever decided what the code should look like.

Where the key goes next

Every rule here pointed the same way. The key has to be present where it matters, mean one thing forever, carry structure a machine can read, survive a short list of unglamorous limits, and stay countable.

Get that right and the rest of this module is largely mechanical. The key is the hard part, and it is the part decided furthest from the classification screen.

With a key worth classifying, the next question is where the classifications will actually live. That is Classification Sets, the container that holds the schema, the subscriptions, and everything you are about to put into it.