Key takeaways
- Adobe Analytics can use UTM-style campaign logic, but teams must decide how those values should be captured, stored, and reported before campaign links go live.
- "cid" is a common Adobe campaign URL parameter, but Adobe does not require that exact name, so each organization must confirm which parameter feeds campaign reporting.
- The Adobe campaign variable, often seen as s.campaign in AppMeasurement, populates the Tracking Code dimension where campaign values appear in reporting.
- UTM-style values can be packed into one structured CID value and later classified into readable fields like source, medium, campaign, content, and term.
- UTM Smart Manager helps Adobe teams create governed campaign URL workflows so CID, UTM-style fields, naming rules, and classification logic stay consistent before values reach your Adobe Analytics reporting.
Table of contents
Campaign reporting breaks when marketers build links in one language and Adobe Analytics reports on them in another — and that is when teams stop trusting the numbers.
Most campaign teams already understand Google-style UTM parameters:
- utm_source
- utm_medium
- utm_campaign
- utm_content
- utm_term
Those labels are friendly because they tell you what each value means before you even open a report.
Adobe Analytics can support the same campaign-tracking logic, but it does not behave exactly like Google Analytics out of the box. In Adobe, the campaign value may come through a parameter like cid, get captured into the campaign variable, and show up in reporting as Tracking Code. From there, the value may need to be classified or mapped into other dimensions before marketers can read it the way they expect.
So the real question is not only:
“Can I use UTM parameters in Adobe Analytics?”
The better question is:
“How should my team translate familiar UTM campaign fields into Adobe’s CID, Tracking Code, and s.campaign model so reporting stays consistent?”
This article gives you the short, practical translation layer.
It explains what UTM parameters, CID, Tracking Code, and s.campaign mean in practice, why Adobe campaign URLs are not just Google UTM links copied into another tool, and why teams need one consistent campaign URL structure before agencies, vendors, or internal teams start creating links.
For the deeper implementation model, use the Complete Guide to Using Adobe Analytics UTM Parameters. That guide covers Classification Sets, separate eVars, Web SDK notes, validation, and legacy implementation support in more depth.
UTM parameters in Adobe Analytics: the short answer
Yes, Adobe Analytics can use UTM-style campaign logic.
No, that does not mean Adobe automatically treats UTM parameters exactly like Google Analytics does.
That is the important distinction.
In Google Analytics, UTM fields are the familiar campaign labels. A URL might look like this:
A marketer can look at that URL and immediately understand the campaign story:
source = facebook
medium = cpc
campaign = spring_sale
content = red_video
term = retargeting
Adobe can report on similar campaign information, but your team has to decide how that information enters Adobe.
That usually means choosing one of these models:
- Put the campaign values into one structured Tracking Code value, often through a parameter like cid, and classify that value later.
- Map separate UTM-style parameters into separate eVars.
- Support an inherited legacy setup that already uses AppMeasurement, getQueryParam, or older classification workflows.
This article focuses on the first translation: how UTM-style campaign logic becomes understandable in Adobe through CID, Tracking Code, and s.campaign.
The Complete Guide covers the full decision tree. This article keeps the first mental model clear.
How CID, Tracking Code, and s.campaign relate
The confusion starts because people use these terms like they are interchangeable.
They are not.
Here is the practical translation.
UTM parameters
UTM parameters are the marketer-facing campaign fields many teams know from Google Analytics.
They describe campaign context:
- where traffic came from
- what channel or medium drove it
- which campaign it belonged to
- which creative, message, audience, or term was involved
UTM language is familiar because it is visible. You can read it in the URL.
CID
cid is commonly used as an Adobe campaign URL parameter.
But Adobe does not require every organization to use cid.
That means your team might use:
cid=
Or:
ccid=
Or:
pcid=
Or a custom parameter your Adobe team already mapped.
The name matters less than the consistency.
If your organization uses cid, the goal is not to make the URL look clever. The goal is to pass a clean campaign value into Adobe so reporting can be trusted.
Adobe s.campaign / campaign variable
In Adobe Analytics implementation language, the campaign value is commonly associated with the campaign variable.
In AppMeasurement, that often appears as:
s.campaign
Or, in plain English:
Your campaign URL sends a value.
Adobe captures that value.
That captured value becomes the campaign tracking value Adobe can report on.
Tracking Code
Tracking Code is the Adobe reporting dimension where the campaign value appears.
So if a campaign URL contains:
?cid=facebook:cpc:spring_sale:red_video
and your Adobe implementation captures cid into the campaign variable, then the Tracking Code dimension can show:
facebook:cpc:spring_sale:red_video
That raw value is not yet a friendly UTM report.
It is the captured campaign code.
To make it more readable, Adobe teams often use classifications or another reporting model to split that value into fields like source, medium, campaign, content, and term.
A simple Adobe CID URL example
Let’s make this concrete.
A Google-style campaign URL might look like this:
An Adobe CID-style URL might instead look like this:
https://example.com/?cid=facebook:cpc:spring_sale:red_video:retargeting
That one cid value is carrying familiar campaign ideas in a different structure:
| Piece of the CID value | UTM-style meaning |
|---|---|
| source | |
| cpc | medium |
| spring_sale | campaign |
| red_video | content / creative |
| retargeting | term / audience |
That is the bridge.
Adobe is not rejecting UTM logic. Adobe is asking your team to decide how that logic should be captured and reported.
A governed Adobe CID builder makes this easier to see because marketers can use familiar fields while the workflow outputs the Adobe campaign structure your organization has agreed to use. The public Adobe builder, for example, generates a cid= structure and explains that some teams use ccid, pcid, or another parameter mapped to Adobe Tracking Code.
That is why a builder can be useful as a training example even before a team decides how far to customize the workflow.
It shows the hidden structure.
See the Adobe CID workflow in practice
The example above shows how UTM-style campaign logic can become one structured Adobe CID value. This video shows the next step: how a team can turn that structure into a governed Adobe campaign URL builder with approved fields, SmartLists, dependencies, and bulk link creation before values reach Adobe Analytics.
Watch this walkthrough to see how CID, Tracking Code, and campaign URL governance move from concept into an actual builder workflow for marketers, agencies, and Marketing Ops teams.
Why Adobe campaign URLs are not just Google UTM links
This is where teams get into trouble.
Someone says:
“We already know UTMs. Let’s just use the Google UTM builder.”
That can work only if Adobe has been configured to read those values correctly.
If your Adobe setup expects one structured cid value and your agency sends separate utm_source, utm_medium, and utm_campaign values that nobody maps into Adobe, your reports may not show what the team expects.
If your Adobe setup maps separate UTM-style values into eVars, then visible UTM parameters may be exactly the right model.
Both can be valid.
The problem is guessing.
Do not start by arguing about whether cid is better than UTM.
Start by asking:
- Which campaign parameter does Adobe collect today?
- Does it populate Tracking Code?
- Are values stored as one structured code or separate report fields?
- How are source, medium, campaign, content, and term made readable?
- Who controls the naming rules before links go live?
That is where campaign reporting starts getting cleaner.
The real problem for implementing Adobe UTM parameters: consistent campaign URL governance
The technical question matters.
But the operational question matters more.
A perfect Adobe setup still breaks when every team creates campaign links differently.
- One team uses: facebook
- Your marketing agency uses: Facebook
- A new employee uses: fb
- And you use: meta_paid_social
Now your reporting problem is not Adobe. Your reporting problem is upstream chaos.
That is the problem Marketing Ops ends up policing unless the workflow prevents bad values at creation time.
The same issue happens with campaign names, ad names, date formats, owners, objectives, and creative labels. Adobe can only report on the values it receives. If the values are messy at creation time, the reporting cleanup happens later, usually when everyone is already in a meeting arguing about the numbers.
That is why this topic is bigger than “Which parameter should we use?”
The real workflow is:
- Define the campaign fields your team needs.
- Decide whether Adobe should receive one structured Tracking Code value or separate values.
- Keep the field order and naming rules consistent.
- Make teams and agencies create links inside those rules.
- Validate that the values arrive in Adobe correctly.
- Classify or report on those values in a way humans can understand.
UTM Smart Manager sits in that upstream workflow: it helps teams create Adobe campaign URLs through governed forms, approved values, and rules before those values reach Adobe reporting.
That is the useful product connection here.
Not “use a builder because builders are nice.”
Use a governed workflow because Adobe campaign data is only as trustworthy as the values teams put into it.
When to use The Complete Guide to Using Adobe Analytics UTM Parameters
Use this article when you need the short translation:
- What is a UTM parameter?
- What is cid?
- What is Tracking Code?
- What is s.campaign?
- Why does Adobe campaign tracking feel different from Google Analytics campaign tracking?
Use the Complete Guide when you need the full implementation model.
That includes:
- structured Tracking Code
- Classification Sets
- separate eVars
- Web SDK notes
- Analysis Workspace validation
- legacy AppMeasurement support
- inherited implementation troubleshooting
This article is the front door.
The Complete Guide is the deeper map.
If you are still deciding which model your organization should use, we recommend you first read The Complete Guide to Using Adobe Analytics UTM Parameters before changing your implementation.
If you already understand the model and just want to see a structured Adobe campaign code in action, try the free Adobe builder.
Legacy implementation support for inherited Adobe setups
Many Adobe Analytics teams are not starting from a clean, modern setup. They inherited something and it could be your responsibility to now take over this setup. Your Adobe setup may include:
- AppMeasurement
- s.campaign
- s.Util.getQueryParam(“cid”)
- the older getQueryParam plug-in
- regex
- Classification Rule Builder
- manual classification uploads
- a campaign parameter nobody wants to touch because it “mostly works”
That is normal.
It does not mean the setup is useless.
It means you need to understand it before you change it.
Understanding AppMeasurement and s.Util.getQueryParam(“cid”)
In older or custom AppMeasurement implementations, a common pattern is:
s.campaign = s.Util.getQueryParam(“cid”);
That means Adobe looks at the landing-page URL, finds the value after cid=, and assigns it to the campaign variable.
Adobe’s documentation still shows this pattern as an example for collecting a cid query string parameter into s.campaign.
So if you see this in an older setup, do not panic.
Just document what it does.
Understanding the older getQueryParam plug-in
Some inherited implementations use Adobe’s older getQueryParam plug-in.
That plug-in can still appear in older Adobe Analytics implementations, especially where teams needed more complex query-string parsing. But it should not be treated as the obvious starting point for new work when simpler implementation paths are available.
Plain English:
If it exists in your inherited setup, understand it. But do not assume it is the best starting point for new work.
Understanding how to use Regex and Classification Rule Builder for Adobe UTM links
In older Adobe Analytics setups, teams often used Classification Rule Builder and regular expressions to split one structured Tracking Code into readable reporting fields.
For example, a value like:
facebook:cpc:spring_sale:red_video:retargeting
could be parsed into:
source
medium
campaign
content
term
A legacy regex pattern might look like:
^(.+):(.+):(.+):(.+):(.+)$
That kind of rule can work when every campaign code follows the same structure, but it becomes fragile when teams change delimiters, skip fields, or create campaign links outside the approved process.
For newer or refreshed setups, use The Complete Guide to Using Adobe Analytics UTM Parameters for the deeper Classification Sets and implementation model. This article keeps the key point simple: structured Adobe campaign values only become useful when the team defines the format, captures it correctly, and governs the values before reporting breaks.
What to document before changing anything
Before changing an inherited Adobe campaign tracking setup, document:
- the current query parameter
- whether the team uses cid, ccid, pcid, UTM parameters, or something custom
- whether the value lands in Tracking Code or separate eVars
- the delimiter, if the code is structured
- the field order
- the classification logic
- where reports are currently read
- which teams and agencies create campaign links
This is not busywork. It is necessary and will save you and your team a lot of headaches later on. Plus, and equally important, this is how you avoid breaking the one thing that still works.
Final takeaway
Adobe campaign tracking is not hard because marketers fail to understand campaign logic.
Marketers already understand campaign logic.
They know source, medium, campaign, content, and term.
Adobe feels harder because it makes the organization define how that logic is captured, stored, split, and governed.
That is the whole game.
Find the current campaign pattern. Decide whether your team should use one structured Tracking Code value or another model. Make the structure explicit. Govern values at creation time, before links go live. Validate that Adobe receives the values correctly. Then report on campaign performance without turning every dashboard review into a cleanup meeting.
If you want the complete implementation path, read the Complete Guide to Using Adobe Analytics UTM Parameters.
If you want a hands-on example first, use the free Adobe CID builder to see how a governed Adobe campaign code can be structured before it reaches Adobe Analytics.