Classifications Overview

Everything you have built so far has done its work on the way in. Processing Rules reach into a hit and rewrite a value before it is stored. VISTA Rules do the same thing further upstream and with fewer restraints. Marketing Channels read the arrival signals on a hit and stamp a channel onto it as almost the last act before storage. Different tools, different points in the pipeline, but one shared habit: each of them shapes the data while it is still moving, and then steps aside.

Classifications break that habit completely. They never touch the hit. Nothing about collection changes, no new code ships, no developer is involved, and the stored data is exactly what it was before. And yet the reports come out different. Understanding how that is possible is the whole of this section, and it starts with a limitation you have been living with since the foundations of this curriculum, without necessarily noticing it.

The one-way street

Adobe Analytics can report on one thing and one thing only: what arrived in a server call. Whichever collection method you chose, AppMeasurement, the Web SDK, a mobile SDK, or a server-side call, every value that ends up in a report had to ride in on a hit. There is no other door.

Sit with the consequence for a second. Can you connect an outside database to Adobe Analytics and have it show up in your reports? Can you open a report suite and type a value in by hand? Not really. And that is not a defect. The tool was built for a specific job, which is to observe how people behave on your site or app and then hand that behavior back to you in a form you can act on. It watches, it records, it reports. It was never designed to be a general-purpose data store.

Which is fine, right up until the day it is not.

The club

Picture a community club with a proper online presence, a website and an app. Members can book the community hall, reserve a badminton or gym slot, arrange a party, send out invitations, and receive notifications. It is not a public site. It exists for members, so every member logs in with their credentials before doing any of it.

Somewhere else entirely, the club runs a CRM. That system knows a great deal about each member: name, address, age, gender, occupation, membership tier, when the subscription started, when it expires, and the entire history of fee payments.

Now watch what Adobe Analytics captures when a member logs in. A User ID. That is all. The eVar carrying it holds something like M-10482, and nothing about the human behind that string comes with it.

A month passes. You open the report. One hundred members visited, they booked halls and slots, they opened notifications. The report is honest and it is useful. It is also strangely flat, because every question worth asking dies on the first breath. How many men booked gym slots this month? How many members under twenty-five took up badminton? How many senior members reserved the community hall, and on which days? Nobody can answer, and the frustrating part is that nothing is actually missing. The behavior is in Adobe Analytics. The attributes are in the CRM. Both datasets are complete, both are correct, and neither can say anything interesting on its own.

The data is not lost. It is in the wrong building.

What a classification actually is

A classification is a lookup table. That is the entire idea, and every other property of the feature falls out of it.

You give Adobe a file. The first column holds a value that Adobe Analytics already collected, and that column is called the key. Every column after it holds an attribute that Adobe Analytics never collected and never could have: Age Band, Gender, Membership Tier, Join Year. Adobe stores that table off to one side, and from then on, whenever you ask for a report, it matches the raw value against the key and hands back the attributes you supplied.

Notice what the club never had to do. No developer wrote a line of code. No new server call fires. No eVar was spent. The member's age was never pushed into the browser, which is fortunate, because pushing a member's age and gender into a public web page would be a poor idea for reasons that have nothing to do with analytics. The CRM stayed exactly where it was. All that changed is that Adobe now holds a small table saying, in effect, when you see M-10482, this is who that is.

Classifications work this way on most custom dimensions. Props, eVars, tracking code, product ID. A single dimension can carry many classification columns at once, and a Product ID can be classified by name, color, size, category, and margin all at the same time, each one becoming its own reportable dimension.

Two things follow immediately, and one of them is a warning

The first is the property that makes practitioners fall in love with this feature. Because the lookup happens when you run the report, and not when the data was collected, classifications are retroactive. Upload the club's member file this afternoon, and every hit from every month in your history that carried a User ID becomes readable through Age Band and Membership Tier immediately. Not the hits from tomorrow onward. All of them, going back. The report will look as though you had been collecting age and gender all along, and in a sense you had been, because you had the key.

The second thing that follows is the sentence that saves people from months of disappointment, and it is worth reading twice.

Reflections, not values

It is worth being precise about where classification data actually lives, because the common mental picture is wrong in a way that causes real confusion later.

The attributes do not go into the eVar. The eVar still holds M-10482, unchanged, exactly as it was collected. What Adobe creates instead is a set of classification dimensions that hang off the parent variable. In Analysis Workspace they look and behave like ordinary dimensions, and you can drag Membership Tier into a table beside Bookings and it will simply work. But they hold no values of their own. They resolve the parent's value at the moment you ask.

Which means classification dimensions behave exactly as their parent behaves, and they do so without inheriting anything, because there is nothing to inherit. They are the parent, wearing a different name. If the User ID lives in an eVar set to expire after thirty days, that key persists across thirty days of hits, so its classifications appear on those same hits. If the User ID lives in a prop, which does not persist at all, the classifications appear only on the hits where the prop was actually set, and the member's post-login browsing carries them while the pre-login browsing does not. You never configure this. It is not a setting. It is simply what happens when a shadow follows the thing casting it.

Which is really the honest way to think about the whole feature. You look up at a bright night and call it moonlight, and you are not wrong in any way that matters. But the moon has no light. It never did. What you are seeing is the sun, reflected, and everyone knows this and nobody says it, because nobody stands in a garden at night announcing that the sunlight is unusually well reflected this evening. They say the moonlight is beautiful and they go inside. Classification dimensions are moonlight. Full, useful, worth building reports on, and entirely borrowed.

One practical consequence follows from all this, and it catches teams by surprise. Classification values do not appear in data feeds. The feed carries the hit, and the hit carries the key, but the classification lives in a lookup table that the feed does not export. If a downstream data lake needs Membership Tier, it has to be joined there from the same source file you gave Adobe. Data Warehouse is a different story and does carry classified values, but the raw hit-level feed does not.

The contradiction, and how it resolves

By now a definition has been quietly forming: a classification is an Adobe Analytics feature that lets you upload offline data against a key such as a User ID or a tracking code, so that reporting can show richer attributes than the raw value ever carried. That definition is good. It is also incomplete, and if you have been reading carefully something in it should feel loose.

Because there is a second way to fill those same classification columns, and it involves no offline data at all.

It is called the Classification Rule Builder, and it works on data you already have. It reads the keys sitting in your report suite, matches them against a pattern, and populates the classification columns automatically. Suppose your campaign tracking codes are built to a structure, something like eml_2026_07_winback_in. A human can read that. A rule can too. Set up the patterns once, and the raw code splits itself into Channel of Email, Year of 2026, Month of July, Campaign of Winback, and Country of India, each one a real reportable dimension, and none of it uploaded from anywhere. It has always been in the data. It just needed to be read.

So which is it? Offline data import, or pattern reader? Both, and the apparent contradiction dissolves the moment you look at what the two paths have in common. They fill the same classification columns. One fills them from a file you supply, because the information exists only outside Adobe. The other fills them from a pattern, because the information was already inside the key and merely needed unpacking. The columns do not know or care which one wrote to them, and the report cannot tell the difference.

What the attributes attach to

An architect earns the title by knowing where a tool ends, and one boundary is worth saying plainly while the club example is still fresh, because it is the one that trips up experienced people.

Attaching CRM attributes to a User ID eVar is a legitimate thing to do, and it is exactly what the club is doing. But Adobe also ships a feature built specifically for person-level enterprise data, called Customer Attributes, and it does not behave the same way. A classification attaches attributes to the key value, so those attributes exist only where the key was actually set, which means everything a member did before logging in falls under Unspecified. Customer Attributes ties the data to the visitor profile instead, through the Experience Cloud ID, so it reaches backward and covers behavior from before the person ever identified themselves.

Same CSV file. Same gender column. Materially different numbers in the report. Neither one is broken, and neither one is lying. They are answering slightly different questions, and knowing which question you are actually asking is your job, not the tool's.

A workable rule of thumb: classifications describe things, such as a campaign, a product, a page, an article, a promotion. Attributes that belong to a person, and that should follow that person across everything they ever did, belong to Customer Attributes. The club sits comfortably on the classification side of that line, and most implementations will too.

SAINT, Classifications, and Classification Sets

This feature is old, and its history explains a lot about why the interface looks the way it does.

In the Omniture SiteCatalyst era it was called SAINT, short for SiteCatalyst Attribute Importing and Naming Tool. The acronym is a stretch, and it was surely meant to be, though it earns a certain forgiveness given how many everyday business problems the thing quietly solves. You will still hear practitioners say SAINT today, decades on, and you will still see the word in old documentation and older colleagues.

Adobe eventually renamed it to plain Classifications. Nothing about the mechanics changed. The key, the columns, the lookup, the retroactivity, all identical. Only the name went.

Then Adobe rebuilt the experience properly as Classification Sets. Where the older system spread the work across three separate interfaces, a set brings all of it into one place: the dimensions being classified, the schema of columns, the imports, the jobs, and the rules. Processing time came down from seventy-two hours to twenty-four. A single set can subscribe multiple report suites and multiple dimensions at once, so a product classification built once can serve every report suite that has a product SKU, instead of being replicated by hand into each one.

The direction of travel is the part that matters, and it is not ambiguous. Adobe is consolidating on Classification Sets, and the legacy interfaces are being retired on a published schedule. The two legacy paths do not retire together, which is worth knowing before you plan any migration, because the file importer and the rule builder have separate deadlines several months apart. A team that hears "classifications are being retired" and treats it as one event will move the wrong things first and prepare for the wrong date.

The instruction that outlives any particular date is simple, and it does not change regardless of which system your organization is currently sitting on. Build new work in Classification Sets. The window for moving the old work deliberately has now closed, so anything still running on the legacy importer is a migration to schedule rather than a decision to weigh. And when you read older blog posts, forum threads, or internal documentation, check the date before you trust the interface it describes, because this particular corner of Adobe Analytics has been moving.

Everything hinges on one thing

Step back and look at what has actually been claimed here. A classification is a lookup table. It is retroactive because it resolves at report time. It cannot invent what was never collected. It fills the same columns whether a file writes them or a rule does. And the dimensions it produces are reflections of a parent variable, carrying no values of their own.

Every single one of those properties depends on the same thing, and it is the thing almost nobody plans for. The key. The raw value the classification is built on top of. Get the key right and this entire feature is a quiet, powerful, almost free extension of your implementation. Get the key wrong and no amount of clever rule-building or careful uploading will save the report, because there will be nothing solid underneath to look anything up against.

Which is why Designing the Key comes before any discussion of sets, files, or rules. The key is not a detail you tidy up later. It is the decision the rest of this module rests on.