The Complete Guide to Using Adobe Analytics UTM Parameters

Key takeaways

• Adobe Analytics can support UTM-style campaign tracking, but your team must first decide whether campaign data should live in one Tracking Code value, separate eVars, or a legacy inherited setup.
• The structured Tracking Code model usually captures one value through a parameter like cid and uses Classification Sets to split that value into readable fields such as source, medium, campaign, content, term, and even date.
• The separate eVars model keeps familiar UTM-style parameters in the URL and maps each value into its own Adobe eVar for reporting.
• Legacy Adobe implementations may still rely on AppMeasurement, getQueryParam, s.campaign, and older classification workflows, so teams should document what exists before changing anything.
• UTM Smart Manager helps turn the Adobe tracking model into a governed campaign URL workflow so teams can standardize values before they reach Tracking Code, eVars, Classification Sets, or Analysis Workspace.

Table of contents

How to make Adobe campaign tracking feel a lot more familiar

If you already know Google Analytics UTMs, Adobe Analytics can feel like someone took a perfectly normal system, hid half the labels, renamed the other half, and then asked you to “just configure the implementation.”

Very cool. Very calming.

Here’s the good news: the underlying marketing problem is not actually different.

You still want to know:

• where traffic came from,
• what campaign drove it,
• which ad or message showed up,
• and whether any of that did something useful after the click.

The real issue is not that Adobe cannot do this. It can. The issue is that Adobe does not hand marketers the same familiar out-of-the-box campaign language Google does. Adobe expects your team to decide how campaign tracking should be structured, captured, and reported. Adobe’s own campaign-tracking workflow starts with establishing a tracking code generation process, then adding that code to URLs, then adjusting the implementation, and finally viewing the data in Analysis Workspace. That order matters. It tells you something important: if your campaign inputs are messy, your reporting will be messy with a fancier interface.

This guide is for marketers, marketing ops teams, analytics managers, and Adobe admins who all have the same practical question:

How do we make Adobe speak enough “UTM” that normal humans can use it without creating reporting chaos?

That means this article will do five things:

• help you figure out what your Adobe setup already is
• show you the current best path to make Adobe campaign reporting understandable
• explain how to use a real Adobe CID builder example to make Classification Sets easier to understand
• explain the separate eVars model like a real operating model, not a footnote
• keep the legacy implementation at the bottom for teams who inherited older setups and still need to support them

If you are specifically looking for the older AppMeasurement + getQueryParam + legacy Classification Rule Builder approach, skip to the Legacy implementation section near the end. Adobe now says Classification Sets are the primary way to classify data, and the legacy classification methods are being deprecated, so I would not start a new implementation there unless you are supporting an inherited setup.

Start with the part marketers actually care about

Let’s not begin with s.campaign, marketing.trackingCode, or a sentence that sounds like it was written by a committee of APIs.

Let’s begin with the familiar thing.

In Google Analytics land, a tagged URL might look like this:

https://example.com/?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale&utm_content=red_video&utm_term=retargeting

That is comforting because the labels are visible. Each piece tells you what it is.

Adobe often works differently.

A lot of Adobe teams capture one campaign value into the campaign variable , which populates the Tracking Code dimension. A common query-string parameter for that is cid, but Adobe is clear that the parameter depends on your organization’s setup, not on a universal Adobe rule. Adobe also documents two valid ways to handle UTM-style campaign data: send all the UTM pieces into one Tracking Code value and classify them later, or send the pieces into separate eVars.

So the familiar Google question:

“Where do I see source, medium, and campaign?”

turns into the Adobe question:

“Where is the campaign value being captured, and how is my team storing or splitting it back into readable reports?”

That is the bridge.

Not: “Adobe is mysterious.”
Not: “UTMs are wrong.”
Not: “Marketers need to learn twelve new nouns before lunch.”

Just this:

Google gives you campaign labels out in the open. Adobe gives you a container and asks your team to define the rules.

Once you understand that, the rest gets much less threatening.

Google-to-Adobe bridge table

Here is the simplest phrasebook I know.

What marketers already know	What Adobe calls it	What it really means
utm_source, utm_medium, utm_campaign, etc. in the URL	query-string parameters	the raw campaign values riding on the link
one value captured in Adobe’s campaign field	campaign / s.campaign	the variable Adobe uses for tracking codes
the report that shows that raw captured value	Tracking Code	the reporting dimension populated by campaign
one structured campaign code split back into readable fields	Classification Sets	the modern Adobe way to unpack one code into multiple reporting columns
separate fields stored one by one	eVars	the alternative path if you want source, medium, campaign, content, and term stored separately

The table above is based on Adobe’s current campaign documentation , eVar documentation, and Classifications overview . Adobe says the campaign variable is dedicated to tracking codes, populates the Tracking Code dimension, acts like an eVar in the current product, and is commonly populated from a query string. Adobe also says Classification Sets are now the primary classification interface.

Before you build anything, figure out what your Adobe team already did

This is the part most marketers skip because they are trying to be helpful and move fast.

Do not skip it.

The first step is not “open Adobe and configure some rules.”
The first step is: find your current campaign pattern.

Adobe’s own campaign-tracking workflow says it is important to reference your organization’s solution design document and keep a consistent system in place for tracking codes. Adobe’s eVar docs make the same point from the other side: if your organization has a solution design document, most dimensions specific to your business end up as eVars, and those eVars need to be configured in report suite settings before you use them.

Ask your Adobe admin these seven questions

If you want campaign tracking in Adobe to feel less intimidating, ask these questions first:

1. Which query-string parameter feeds Adobe Tracking Code?
Is it cid, ccid, pcid, or something else entirely?

2. Are we putting everything into one Tracking Code value, or are we mapping campaign pieces into separate eVars?
Adobe supports both campaign tracking approaches. One uses more setup in classifications. The other uses more eVars.

3. What delimiter are we using, if we are using a structured Tracking Code?
Colon :, pipe |, underscore _, hyphen -, or something else?

4. What is the exact field order if we are using one structured code?
For example:
source:medium:objective:campaign_name:adset_name:ad_name:date

5. If we are using separate eVars, which eVar numbers hold which values?
For example:

• eVar11 = Source
• eVar12 = Medium
• eVar13 = Campaign
• eVar14 = Content / Adset
• eVar15 = Term / Ad Name

That exact numbering is just an example. The real question is whether your team has a documented map. Adobe lets eVars be used however your organization wants, and the friendly name in the report suite is what appears in reporting.

6. What are the expiration and allocation settings on those eVars?
This matters because eVars persist until they expire, and Adobe lets admins control expiration and allocation in Conversion Variables. If those settings are inconsistent or poorly chosen, your campaign reporting can behave in surprising ways.

7. Are we already using Classification Sets?
If not, is the team still on a legacy classification workflow that needs to be migrated? Adobe now calls Classification Sets the primary classification experience.

If nobody can answer those questions, here is how to power your way through it

You can still learn a lot without full admin access:

• pull a few live campaign URLs from email, paid ads, or social posts
• check whether they use cid=, ccid=, or another parameter
• look at the value after the equals sign
• see whether it is a short opaque code, or a structured value with a delimiter
• check whether the URL instead uses visible Google-style parameters such as utm_source=, utm_medium=, and utm_campaign=
• in Analysis Workspace, drag Tracking Code into a project and inspect the raw values if you have access
• if the raw values look like facebook:cpc:spring_sale:red_video, your team is probably using a structured code that can be split into readable pieces
• if the raw values look like EM989027 or some short ID, your team may be using classifications or lookup logic to enrich that code later
• if the campaign URLs still use separate UTM query parameters and your Workspace reports show dimensions with friendly names like “UTM Source” or “Campaign Medium,” your team may be mapping those separate parameters into eVars rather than relying on one structured Tracking Code
• if you have access to Experience Platform Debugger or Assurance, inspect the Analytics variables being sent. In a modern implementation, you may see values landing in data.__adobe.analytics.campaign for Tracking Code or data.__adobe.analytics.eVarX fields for separate eVars. Adobe’s Web SDK setup guide (https://experienceleague.adobe.com/en/docs/platform-learn/implement-web-sdk/applications-setup/setup-analytics) explicitly recommends validation with Debugger and Assurance.

That small detective step saves a shocking amount of confusion.

Quick shortcut: how to tell which model you are probably using

If you see this	You are probably using
?cid=facebook:cpc:spring_sale:red_video	one structured Tracking Code value
?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale... and Adobe reports with “UTM Source” or similar	separate eVars
a short code like ?cid=EM989027	Tracking Code with later enrichment through classifications or lookup logic

That shortcut is not a replacement for the solution design document. It is just the fastest way for a marketer to avoid wandering into the wrong implementation conversation. Adobe’s own docs support the underlying logic here: the query-string parameter is organization-specific, Tracking Code can hold a single value, and UTM query strings can either be concatenated into Tracking Code or sent to separate eVars.

A simple working example: using the free Adobe CID builder as your training wheels

Now let’s make this practical.

The free Adobe CID builder (with screenshot below) is actually a very good teaching example because it makes the hidden structure visible.

Want to see the Adobe CID builder example in action?

The screenshot above shows the structure. The walkthrough shows how that structure becomes a governed workflow: starting from a template, updating fields and styling, adding SmartLists and dependencies, supporting bulk link creation, and keeping campaign values consistent before they reach Adobe Analytics.

The form uses a familiar set of marketer-facing fields:

• Source
• Medium
• Objective
• Campaign Name

And it outputs a single campaign parameter using this pattern:

LandingPageURL?cid=source:medium:objective:campaign_name with a few additional fields added in the video example to demonstrate how you can take tracking even further.

That is helpful because it teaches the marketer two things at once:

• Adobe can absolutely support UTM-like campaign logic
• Adobe often wants that logic expressed in one structured code rather than five separate default parameters

So instead of thinking:

“Adobe does not understand UTMs”

the marketer can think:

“Adobe needs a structured campaign value, and we decide how to break it back into readable reports.”

That is a much healthier mental model.

A sample CID value

Let’s say your builder produces this:

https://utmsmartmanager.com/?cid=facebook:cpc:aw:spring_sale:retargeting:red_video:202604

A marketer looking at that can already understand the story:

• facebook = source
• cpc = medium
• aw = objective
• spring_sale = campaign
• retargeting = adset
• red_video = ad
• 202604 = date

That is exactly why this example is useful in the article. It turns Adobe’s unfamiliar campaign setup into a structured version of something marketers already understand.

Now the rest of the job is simply:

• capture that cid value into Adobe
• tell Adobe how to split it back into readable fields
• validate it
• report on it without chaos

That is the article’s real job.

A gentle next step

If you want to see the structure with your own hands first, start with the free Adobe CID builder. It is the public Adobe-first example and the fastest way to understand how an Adobe campaign code can be structured in a governed way.

If you are looking for how that same Adobe-first approach should work across your organization so your reporting stays clean, go to the Adobe Analytics solution page. That page is there to help Adobe teams see what a governed Adobe campaign URL system looks like in Adobe terms, with the implementation trust and workflow clarity that Adobe users actually need.

And if you want to duplicate the template, style it to your brand guidelines, add or edit the fields, control the dropdowns and dependencies, and govern how the workflow operates across your organization, that is where Campaign URL Studio comes in. Campaign URL Studio is the enterprise form builder layer that lets your team turn the Adobe-first example into a governed campaign URL system built to fit your requirements.

Two ways Adobe can “speak UTM”

Adobe’s own campaign-tracking docs say there are two valid ways to handle UTM-style campaign data.

Model A: one structured Tracking Code + Classification Sets

What the URL usually looks like

https://example.com/?cid=facebook:cpc:aw:spring_sale:retargeting:red_video:202604

What Adobe stores

One value in the campaign variable / Tracking Code dimension.

How reporting becomes readable

Classification Sets split that one value into Source, Medium, Campaign Name, Ad Name, and so on.

Why teams choose it

• one campaign spine
• fewer extra eVars
• a clean way to enforce structure
• very useful when you already think in CID or campaign IDs

What the tradeoff is

• more classification setup
• a steeper learning curve if your team is new to Adobe

Model B: separate UTM-style query parameters + separate eVars

What the URL usually looks like

https://example.com/?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale&utm_content=red_video&utm_term=retargeting

What Adobe stores

Each parameter is mapped into its own eVar.

How reporting becomes readable

The eVars themselves are the readable fields, assuming they were named and configured properly.

Why teams choose it

• simpler mental model for marketers
• URLs stay very legible
• implementation can be easier overall

What the tradeoff is

• uses extra eVars
• requires a clean variable map and clear eVar settings
• if your team is sloppy with naming, you still get chaos, just in separate columns

Adobe’s docs explicitly say that if your organization collects UTM query strings, you can either send them all into Tracking Code as concatenated values and classify them later, or send each UTM query string into a separate eVar. Adobe says the second option is more simple to implement overall, but it requires extra eVars.

The current best path: how to make Adobe feel familiar without pretending it is Google

Let’s start with the modern path first.

Step 1: Decide your reporting model before anyone touches code

Here is the practical version:

• If your team already thinks in CID and wants one clean campaign spine, use one structured Tracking Code and split it with Classification Sets.
• If your team wants separate report-ready UTM-style fields directly in Adobe, use separate eVars.
• If your organization already has a working CID model, do not throw it away just because UTMs feel more familiar.
• If your organization already has a working UTM discipline but Adobe reporting feels alien, you can still use the same field logic — you just need to decide whether Adobe will receive it as one structured code or as separate variables.

For the next few sections, I’m going to use the structured Tracking Code + Classification Sets path because that is the cleanest way to explain how Adobe can “speak UTM” to marketers without making the article feel like a developer manual.

Step 2: Capture the campaign value the modern Adobe way

Adobe’s current campaign docs and Web SDK setup guide are pretty clear here:

• the campaign variable maps to marketing.trackingCode in XDM
• or to data.__adobe.analytics.campaign in the data object
• Adobe’s Web SDK guide says setting Analytics variables in the data object is the recommended way to set eVars, props, and events
• Adobe says the campaign variable populates the Tracking Code dimension
• and the campaign value max is 255 bytes; longer values are truncated

If you’re thinking, WTF! That is a lot of Adobe words! I’m with you. So let me translate.

What marketers need to hear

If your campaign URLs look like this:

?cid=facebook:cpc:aw:spring_sale:retargeting:red_video:202604

your Adobe admin’s job is to make sure Adobe captures that value into the campaign / Tracking Code field.

That’s it.

Not “deploy a galaxy-brain measurement framework.”
Not “model a perfect ontological taxonomy.”
Just: make sure the value after cid= lands in Tracking Code.

What admins need to check

If you are on a current implementation path:

• confirm which URL parameter you are using
• confirm it gets written into campaign
• if you are using Web SDK, use the data object
• if you are using the Adobe Analytics extension, set Campaign in the rule or global variables
• if you are on older AppMeasurement or extension custom code, s.Util.getQueryParam("cid") is still a valid simple way to retrieve the value from the URL

A very important side note: Adobe’s older getQueryParam plug-in still exists, but Adobe says it is provided by Adobe Consulting as a courtesy, and for simple needs recommends Web SDK URL parameter features, the Adobe Analytics extension, or Util.getQueryParam() instead. Translation: fine for inherited or more complex cases, but do not treat it like the obvious modern default.

So the modern implementation message in plain English is:

Capture the campaign value cleanly first. Then classify it.

That order matters.

Step 3: Turn one Adobe Tracking Code into familiar UTM-style reports with Classification Sets

This is where the article needs to hold the user’s hand a little.

Because this is the part where marketers often hear “Classification Sets” and think:

“Terrific, another noun.”

So let’s make it less scary.

Classification Sets explained like a marketer

Imagine you took all your familiar UTM columns and squished them into one structured campaign string so Adobe could capture them in one place.

Classification Sets are the part where you unpack that string back into readable reporting columns.

That is all they are.

Adobe defines a classification as metadata tied to a variable value, and says Classification Sets are the primary components to classify data in a single simplified interface. The Classification Sets overview says they combine the older settings, importer, and rules into one interface, and the newer backend reduced processing time from 72 hours to 24 hours.

So if your raw Tracking Code looks like this:

facebook:cpc:aw:spring_sale:retargeting:red_video:202604

your Classification Set can unpack it into:

• Source = facebook
• Medium = cpc
• Objective = aw
• Campaign Name = spring_sale
• Adset Name = retargeting
• Ad Name = red_video
• Date = 202604

Now Adobe starts to feel a lot more like the UTM world marketers already know.

How to set up Classification Sets with your Adobe CID builder example

If you are using your free builder’s colon-delimited format, the process becomes much easier to explain.

First, create the classification schema

Inside Classification Sets, create a set on the Tracking Code dimension and add the fields you want reported.

For your builder example, those could be:

• Source
• Medium
• Objective
• Campaign Name
• Adset Name
• Ad Name
• Date

If your team prefers UTM vocabulary, you could also label those fields closer to the Google mental model:

• utm_source
• utm_medium
• utm_campaign
• utm_content
• utm_term

The names matter less than the consistency.

Adobe’s Classification Sets overview explains that each set defines subscriptions, a schema, and one or more rules to support those classifications.

Second, choose the least dramatic rule type possible

Adobe’s Classification Sets rules support several function types, including Split and Regular expression.

If your code format is predictable, use Split first.

Adobe’s rules docs say the Split function splits the key dimension value based on a token into one or more classifications. For your builder example, that token can simply be :.

So for your builder, the easy explanation is:

• key dimension = Tracking Code
• token = :
• output fields = Source, Medium, Objective, Campaign Name, Adset Name, Ad Name, Date

That is a much friendlier teaching path than leading with regex.

When should you use regex instead?

Use Regular expression when the pattern is less consistent, when some positions are optional, or when the formatting is more complicated than a clean delimiter split.

Adobe’s rules docs explicitly show Regular expression as a supported rule type that can assign multiple classifications using match groups like $1, $2, and $3. The same page uses an example regular expression of ^(.+)\:(.+)\:FY(.+)$ for three classifications.

But here is the practical rule of thumb:

If Split can do the job, let Split do the job.
Regex is useful. It is also the fastest way to make normal marketers feel like they accidentally wandered into a haunted house.

Third, test the rule set with real sample keys

Adobe’s Classification Sets rules workflow lets you paste sample keys and test the rule set before activating it. The rules page specifically calls out sample keys, remembering sample keys, and Test rule set.

For your builder example, a good sample key would be:

facebook:cpc:aw:spring_sale:retargeting:red_video:202604

If the test results map each value into the correct field, you are in good shape.

If not, congratulations: you found the problem before it ruined a dashboard.

Also important: Adobe’s rules docs say the last rule determines the classification value when multiple rules affect the same classification. That is the sort of tiny detail that becomes a very large detail once numbers start looking suspicious.

Step 4: Validate like you mean it

Please do not stop at “the setup looks right.”

Adobe’s Web SDK setup guide explicitly includes validation using Debugger and Assurance, and that is exactly the right instinct. You want to confirm not just that a rule exists, but that the campaign value is actually being captured and passed the way you expect.

What to validate

At minimum, check these four things:

1. The URL contains the parameter you expect
For example: cid=... or ccid=...

2. Adobe receives the value in Tracking Code
If the builder generated facebook:cpc:aw:spring_sale:retargeting:red_video:202604, Adobe should receive that exact value in the raw campaign field.

3. Classification values unpack correctly
Source should not end up in Medium. Date should not end up pretending it is a campaign name.

4. The value is not too long
Remember Adobe’s campaign value max is 255 bytes. If your structured string gets too long, Adobe truncates it. That is a quiet little disaster if you do not catch it early.

Where to view the result

Adobe’s campaign-tracking workflow doc keeps the reporting part refreshingly simple:

• create a Workspace project
• drag the Tracking Code dimension onto the canvas
• add metrics like Visits or Orders
• then use the classification fields once they are available

That is the right starting point.

Not a twenty-tab dashboard.
Not a seven-panel attribution debate.
Just: “Did the campaign value arrive, and can we read it?”

A gentle next step

If the idea of one structured campaign code already feels clearer, try the free Adobe CID builder first. If you want the broader Adobe trust path, go to Adobe Analytics. If you need the governed workflow that sits behind consistent link creation, move into Campaign URL Studio.

Step 5: What if your team uses separate eVars instead of one CID-style string?

This is not wrong. It is just a different path.

Adobe explicitly documents that if your organization collects UTM query strings, you can send each UTM string into a separate eVar. Adobe says this is generally simpler to implement, but it requires extra eVars. Adobe also documents that eVars are custom variables, must be configured in report suite settings before use, and by default they persist beyond the hit until they expire.

That means if your Adobe admin says:

“We don’t want one structured cid value. We want source, medium, campaign, content, and term stored separately,”

that is a legitimate model.

How would a marketer know this is the setup?

Usually, one or more of these clues show up:

• your campaign URLs still use visible utm_source=, utm_medium=, utm_campaign=, and similar parameters
• your Workspace reports have individual dimensions with friendly names like “UTM Source,” “Campaign Medium,” or “Campaign Name”
• your admin tells you those report dimensions are backed by eVars
• in the report suite’s Conversion Variables settings , those eVars have friendly names that match campaign components
• in Debugger or Assurance, you see Analytics variables like eVar11, eVar12, and eVar13 getting populated instead of one main Tracking Code value carrying the whole structure

How will the URL look if separate eVars are being used?

Usually, it will look more like the Google world marketers already know:

https://utmsmartmanager.com/?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale&utm_content=red_video&utm_term=retargeting

Adobe’s campaign-tracking workflow specifically says that organizations using Google Analytics in addition to Adobe might already have a UTM tracking-code model established, and that if your organization collects UTM query strings you can send each UTM query string into a separate eVar.

In other words, the URL itself does not need to become weird for Adobe to use it. The weirdness, if there is any, is usually in the implementation layer and not in the URL.

What if the marketer is asked to help set it up?

If you are asked to help set up the eVars model, your job is not to become a JavaScript monk overnight. As a marketer who had to learn the ins and outs of adobe analytics because the previous admins left the company, I will say what you’re thinking: WTF! Your job is to help define the business logic clearly enough that the admin or developer can implement it without guessing.

So, here is the cleanest way to do that.

Part 1: Define the campaign schema in plain English

Decide which fields matter.

For a simple UTM-like model, that could be:

• Source
• Medium
• Campaign
• Content
• Term

For a more Adobe-ops-friendly model, it could be:

• Source
• Medium
• Objective
• Campaign Name
• Adset Name
• Ad Name
• Date

This is exactly where adobe-cid-builder.com is useful even if you do not plan to use the public builder output directly. It gives marketers a visible field framework, naming structure, and validation model they can agree on before any implementation work begins.

Part 2: Decide what each field maps to in Adobe

Create a simple variable map such as:

• eVar11 = Source
• eVar12 = Medium
• eVar13 = Campaign Name
• eVar14 = Content / Adset
• eVar15 = Term / Ad Name
• eVar16 = Objective
• eVar17 = Date

Again, the numbers are examples. Adobe supports up to 250 eVars if your contract allows it, and each one must be configured in report suite settings before use.

Part 3: Name those eVars properly in the report suite

Adobe’s Conversion Variables settings let admins give each eVar a friendly name, choose allocation, and choose expiration. That means the marketer should not settle for “eVar11” if what they really need in reporting is “UTM Source” or “Campaign Medium.” The friendly name is what appears in reporting. Adobe also warns that eVar settings like allocation and expiration affect how credit is assigned to success events, and changing those settings on an already-used eVar can create reporting confusion.

Part 4: Decide the URL pattern

For the eVars model, the easiest and most marketer-friendly choice is usually to keep separate UTM-style parameters in the URL:

https://example.com/?utm_source=facebook&utm_medium=cpc&utm_campaign=spring_sale&utm_content=red_video&utm_term=retargeting

That way, the URL remains legible, the marketing team recognizes the fields instantly, and the implementation layer simply maps each query parameter to the correct eVar.

Part 5: Implement the mapping

In a current Web SDK implementation, Adobe documents that eVars can be set in the data object using fields like data.__adobe.analytics.eVar1 through eVar250, or in the matching XDM eVar paths. In the Adobe Analytics extension, eVars can be set in global variables or under rules. In AppMeasurement custom code, an eVar can be set directly as s.eVar1 = "Example custom value";.

So if your team is collecting utm_source, utm_medium, and utm_campaign, the implementation layer simply needs to retrieve those URL values and assign them to the chosen eVars.

That is the part the admin or developer configures.

Your job as the marketer or marketing ops lead is to make the field map explicit so the implementation is boring.

Boring is good.

Part 6: Validate in Debugger, Assurance, and Workspace

Once that mapping is live:

• confirm the URL contains the parameters you expect
• confirm the correct eVars are populated
• confirm the eVars have the friendly names you expect in reporting
• confirm the values persist and allocate credit the way you intended based on the eVar settings
• confirm your campaign reports now show readable fields instead of mystery meat values

Adobe’s Conversion Variables guide makes the allocation and expiration point especially important: eVars can be Most Recent, Original Value, or Linear, and they can expire by page view, visit, time period, event, or never. That means two technically “working” eVar setups can still tell very different attribution stories if those settings were not chosen deliberately.

Separate-eVars implementation checklist

If you want the shortest checklist for a marketer helping an admin, use this:

• define the campaign fields in plain English
• decide the friendly reporting names
• decide the query-string names in the URL
• decide the eVar map
• decide the expiration and allocation settings
• confirm the URLs will stay legible
• validate in Debugger / Assurance
• verify the finished dimensions in Workspace

So where does the Adobe CID builder fit if the setup is separate eVars?

It still helps in three ways:

1. It teaches the team a governed naming structure
Even if you eventually map the pieces separately, marketers still need a common format, common naming, common defaults, lowercase rules, and a shared idea of what belongs in each field.

2. It gives you a visible planning model
Many Adobe implementations fail not because the code is impossible, but because nobody agreed what “campaign,” “adset,” or “objective” should mean before implementation started.

3. It becomes the bridge into a custom Adobe-first workflow
The public builder outputs one structured cid value. That is ideal for the structured Tracking Code model. For a true separate-eVars production model, the next step is usually to personalize the form so it outputs separate parameters or otherwise aligns to the implementation your Adobe team chose. In practice, that means the builder still does its job as the public Adobe-first example, the Adobe Analytics solution page still shows how the Adobe version of the workflow should operate, and Campaign URL Studio is the product layer that lets your team customize and govern that workflow behind the scenes.

So no, the point of this article is not “use UTMs instead of CID” or “use CID instead of UTMs.”

The point is:

Adobe campaign tracking becomes useful when marketers can translate familiar campaign logic into a structured Adobe setup without guessing.

That should be the running theme through the whole article.

A gentle next step

If you are still in planning mode, use the free Adobe CID builder as the easiest shared example of field logic, naming, and validation.

If you want to understand how an Adobe-first governed campaign URL system should work across teams, agencies, and reporting, go to Adobe Analytics. That page exists so Adobe users can identify with a solution designed around Adobe campaign tracking realities, not a generic campaign URL explanation.

And if your team is ready to personalize that workflow, govern the rules, reuse standards, and build the same kind of governed system for Adobe or Google, that is when Campaign URL Studio becomes the right workflow layer. It gives your team the control to turn an Adobe-first example into a governed system that can scale across your organization.

The newer advanced path: Customer Journey Analytics and derived fields

This is not the first stop for most readers, but it is worth mentioning because Adobe’s newer reporting world has expanded.

Adobe now documents how to ingest Analytics classifications data into Experience Platform and use those classification fields in Customer Journey Analytics . Adobe also documents Derived Fields , which allow rule-based transformations at report time. That includes things like parsing query-string values and even deduplicating Tracking Code in certain scenarios.

Why that matters

If your organization is already using CJA, you have newer options beyond the old “capture one string and live forever in the legacy rule builder” model.

Adobe’s Derived Fields docs include:

• a URL Parse use case that extracts the value of a cid query-string parameter from the Page URL
• and a Deduplicate function that can be used for cleanup logic at report time

This does not mean every marketer should stop what they are doing and rebuild campaign reporting in CJA tomorrow.

A sane way to phrase it is:

• Core Adobe Analytics team? Start with clean Tracking Code capture and Classification Sets.
• Advanced Platform / CJA team? You now have additional report-time options through classifications in Platform and Derived Fields.

That is enough for the main article. No need to drag every reader into a side quest.

A quick reality check: why this is still hard for marketers

Because the hard part is not really the rule.

It is the translation.

Marketers are used to seeing campaign logic in plain sight, right out of the box:

• source
• medium
• campaign
• content
• term

Adobe asks teams to decide:

• which parameter collects campaign data
• how the value is structured
• how it gets captured
• how it gets split back into meaningful reports
• whether it should live in Tracking Code, separate eVars, or both
• how long the values should persist
• and where the rules live

That is why this topic keeps attracting attention. It is not because marketers enjoy reading about rule interfaces. It is because they are trying to turn an unfamiliar Adobe setup into something that feels as legible as UTMs. Adobe’s own docs reinforce this from multiple angles: campaign tracking starts with a defined generation process, eVars persist and need allocation / expiration decisions, and Classification Sets now carry much of the reporting logic that older teams once spread across several interfaces.

Legacy implementation: for teams that inherited older Adobe setups

Now, while Adobe’s newer updates do make life easier for many teams, a lot of organizations still inherited some version of the older Adobe campaign-tracking stack.

That usually means some mix of:

• AppMeasurement
• s.Util.getQueryParam() or the older getQueryParam plug-in
• s.campaign
• legacy Classification Rule Builder
• manual classification uploads or lookup-table style enrichment

That setup still exists in the wild. It is not imaginary. It is not rare. And if that is your reality, the goal is not to panic. The goal is to understand how it works well enough to stabilize it, document it, and then make smart decisions about what to keep and what to modernize.

The reason this old path mattered so much is actually pretty simple.

Google Analytics made marketers comfortable with visible campaign fields like source, medium, campaign, content, and term. Adobe did not hand marketers that same out-of-the-box structure. Instead, Adobe gave teams a campaign variable and asked them to decide how campaign tracking should be captured and reported. That flexibility is powerful. It is also exactly why so many older Adobe implementations ended up depending on a custom query parameter, a structured Tracking Code, and a classification workflow to turn that one code back into readable reports.

So if you inherited an older Adobe implementation, here is the plain-English version of what was usually going on.

What the legacy path usually looks like

First, the team chooses a query-string parameter such as cid, ccid, or something custom.

Second, that value gets captured into s.campaign.

Third, the value inside s.campaign is either:

• a short campaign ID such as EM989027 that gets enriched later with classification data

or

• a longer, structured value such as source:medium:campaign:content:term:owner that Adobe can later split into readable dimensions

Fourth, the reporting team uses classifications to turn that one Tracking Code value into something marketers can actually read.

That is the basic idea. Not elegant. Not impossible. Just older.

Step 1: Capture the query-string parameter into s.campaign

In many older Adobe implementations, the first job was simply to pull a campaign value out of the landing-page URL and place it into the campaign variable.

For simple AppMeasurement usage, Adobe still documents the familiar pattern:

s.campaign = s.Util.getQueryParam("cid");

If your team used cid, that meant Adobe would look at the landing-page URL, grab the value after cid=, and store that value in the campaign variable. If your team used ccid, pcid, or another parameter instead, the logic was the same. Only the parameter name changed.

This is why older Adobe URLs often looked like this:

www.example.com/?cid=abc123

or like this:

www.example.com/?cid=facebook:cpc:spring_sale:red_video:retargeting:john_smith

In both cases, Adobe was still capturing one value. The difference was simply whether that value was short and opaque or already structured.

A note on the older getQueryParam plug-in

A lot of legacy Adobe implementations also used the older getQueryParam plug-in instead of the simpler Util.getQueryParam() method.

That plug-in still exists in Adobe’s docs, and Adobe says it can be useful for more complex query-string parsing. But Adobe also says it is provided by Adobe Consulting as a courtesy and recommends simpler alternatives such as Web SDK URL parameter features, the Adobe Analytics extension, or Util.getQueryParam() for simple needs.

So if you inherit this older plug-in, do not assume it is wrong. Just do not treat it like the best starting point for new work.

Step 2: Decide what kind of value is living inside Tracking Code

This part matters more than people think.

In older Adobe implementations, there were usually two broad patterns:

Pattern A: short campaign IDs

Example:

cid=EM989027

In this pattern, the Tracking Code by itself is not especially readable. The real meaning gets added later through classifications, uploaded lookup tables, or other enrichment logic.

Pattern B: structured campaign strings

Example:

cid=facebook:cpc:spring_sale:red_video:retargeting:john_smith

In this pattern, the Tracking Code itself already contains multiple campaign components packed into one value. The later job is to split that value into readable reporting dimensions.

This second pattern is exactly why older Adobe campaign-tracking articles talked so much about “getting Adobe to follow UTM logic.” Teams were trying to take the campaign language marketers already understood and compress it into one structured Adobe Tracking Code.

A common legacy example might look like this:

source:medium:campaign:content:term:owner

or:

channel:tactic:campaign:creative:audience:date

The exact field order varied by organization. The important part was consistency. If the order changed every time someone built a link, the classifications became useless and the reports turned into cleanup work.

Step 3: Turn one Tracking Code into readable marketing dimensions

Once Adobe was collecting the Tracking Code, the next job was to make it readable.

This is where classifications came in.

Older Adobe teams often created classifications such as:

• Source
• Medium
• Campaign Name
• Content
• Term
• Campaign Owner
• Channel
• Creative
• Audience
• Date

And then they used one of two methods to populate those classifications.

Option 1: manual upload or lookup-table style enrichment

This was the more manual path.

A team would export the Tracking Code values, build a classification file or template, fill in the metadata that belonged to each code, and upload it back into Adobe.

This worked. It was also exactly as fragile and annoying as it sounds.

It was most common when teams used short codes like EM989027 and needed Adobe to look up the meaning later.

Option 2: Classification Rule Builder

This was the more automated legacy path.

Instead of uploading metadata every time, the team would create rules that told Adobe how to parse or classify the Tracking Code automatically. This was especially useful when the Tracking Code followed a stable structure with a consistent delimiter.

For example, if your Tracking Code looked like this:

facebook:cpc:spring_sale:red_video:retargeting:john_smith

then a legacy rule-builder setup could split that value into six reporting fields based on the colon separator.

That is why so many older Adobe implementations ended up using regular expressions. The regex was not the goal. The goal was simply to turn one structured code into readable columns without manual uploads every week.

A legacy regex example for six parts might look like this:

^(.+)\:(.+)\:(.+)\:(.+)\:(.+)\:(.+)$

Then the classifications would be mapped like this:

• $1 = Source
• $2 = Medium
• $3 = Campaign Name
• $4 = Content / Creative
• $5 = Term / Audience
• $6 = Campaign Owner

If you are reading that and thinking, “This is exactly why marketers hate this topic,” you are not wrong.

The upside is that when the structure was stable, the rule builder could keep campaign reports surprisingly clean. The downside was that as soon as the structure drifted, the rules broke, the classifications fragmented, and everyone suddenly became very interested in who had been building links “the wrong way.”

A more useful way to think about the old rule-builder path

Do not think of the old Classification Rule Builder as “the magic Adobe thing.”

Think of it as a translator.

Your marketers spoke in campaign logic:

• source
• medium
• campaign
• content
• term
• owner

Adobe stored one Tracking Code.

The rule builder was the translator that took one structured code and broke it back into the language marketers expected to see in reporting.

That is why the old path was so popular. It was not elegant, but it helped Adobe speak enough “UTM” for marketers to make sense of their campaigns.

What changed

The main thing that changed is not the core idea of campaign tracking. The main thing that changed is the tooling around classifications.

Adobe now says Classification Sets are the primary classification experience.

Adobe’s legacy classification pages also carry deprecation warnings for the older importer and rule-builder paths. So if you inherit the old setup, the smartest move is not to keep expanding it forever. The smartest move is to understand it, support it if you must, document it carefully, and then make a plan to migrate the reporting logic into Classification Sets.

That does not mean your current implementation is instantly broken.

It means you should stop treating the legacy path as the future.

So if you inherited the old path, the smart move is:

• support it if you must
• document it carefully
• keep the field order and delimiter explicit
• reduce improvisation from teams and agencies
• and make a plan to move the classification logic into Classification Sets

A practitioner note

This is not just Adobe saying “please use the shiny new thing.”

Updated practitioner tutorials are moving the same direction as well. For example, the BCS UTM-to-campaign-ID walkthrough still teaches the UTM-to-campaign-ID concept, but its updated versions put much more emphasis on clear schema design, rule testing, and validation once the data lands in Adobe.

That is a useful signal.

The practical conversation has shifted from:

“just throw regex at it”

to:

“make the structure explicit, test it, and stop letting the input drift.”

That is a much healthier place to be.

What to do if this is your reality today

If your team is still on a legacy Adobe setup, here is the practical move:

• First, document the current parameter name, delimiter, field order, and rule logic.
• Second, figure out whether you are using short opaque IDs or structured Tracking Code strings.
• Third, confirm how the existing classifications are being populated — manual upload, rule builder, or a mix of both.
• Fourth, test a few real campaign URLs and verify that the resulting Adobe reports still match the intended structure.
• Fifth, decide whether you need to keep stabilizing the legacy path for now or start moving the classification logic into Classification Sets.

The goal is not to become nostalgic about the old implementation.

The goal is to stop being surprised by it.

And once you are no longer surprised by it, you can finally decide what deserves to stay and what deserves to be retired.

Final takeaway

If you remember only one thing from this article, remember this:

Adobe campaign tracking is not hard because marketers do not understand campaign logic. It is hard because Adobe makes teams define how that logic is captured and reported.

The winning move is not memorizing more Adobe nouns.

The winning move is:

• find your current campaign pattern
• make the structure explicit
• decide whether you want one structured Tracking Code or separate eVars
• capture it cleanly
• turn it into readable report fields
• validate it
• and govern it before the reporting mess starts

That is how Adobe starts to feel less like an unfamiliar measurement cave and more like a campaign system normal marketers can actually use.

Try the free Adobe CID builder if you want a hands-on example of structured campaign logic as a starting point. It is the public Adobe-first starting point and the fastest way to see how a governed Adobe campaign code can be structured.

If you like the control and rules the form has in place, you can click on “Personalize this form” to duplicate the template, style it to your brand guidelines, and then add or edit the fields, dropdowns, and dependencies to make the workflow align with your Adobe requirements. That is where Campaign URL Studio comes in. It gives your team the governed workflow layer needed to turn a public Adobe example into a reusable system built for your organization.

If you are not quite ready to implement a governance system with your own Adobe campaign URL forms, go to the Adobe Analytics solution page to learn how an Adobe-first campaign URL system can work across your organization. Think of that page as the Adobe-first expression of the governed workflow, built so Adobe users can recognize themselves in the solution before they need to think about the broader workflow layer behind it.

And when you want campaign metadata to keep going past the URL and into creative accountability because you want to know which creative performed best using the same clean campaign parameters tied to the workflow, you should look into Assets Studio.

Now it’s your turn. Have you come across any other ways to improve the UTM Building and tracking for Adobe Analytics?