Hi,
We are migrating from CIDs to UTM Parameters potentially, how do we attribute this in an eVar or does adobe have something out of the box to capture the UTM fields that Google Analytics is used to?
There are probably other ways to do it, but I've done this using processing rules.
I actually have three different UTM values to capture. So, I set up three evars with the settings I need and then used the processing rules to fill in the appropriate values. I overwrite the value of "evar" with QSP, and then I put the utm type in that small box on the right.
The evar settings you just set up like normal evars with whatever attribution and expiry you need.
Hi @MandyGeorge,
So your evars actually aren't set at all until the processing rule happens for the UTMs? What about if a user goes to different pages after they land and their url says the query UTM parameters in them? How do you get the QSP overwrite to the evar to persist to the visit? Maybe I'm not thinking about this correctly. The eVars can't be captured in the page/link calls themselves when looking at a debugger or the network/console?
Views
Replies
Total Likes
The implementation I'm working with is majorly out of date, and we're working on updating it. The hard part is that everything is currently hard coded onto the site, so when I need to add new tracking that can't wait for the devs, I have to get creative, and processing rules are really good for that.
Hahah we've all been there! Processing Rules is a perfect workaround in that situation.
Views
Replies
Total Likes
We also use UTMs, though my implementation is a bit more complex than @MandyGeorge
First, we make use of all 5 standard UTMs (source, medium, campaign, term and content), as well as two more custom UTMs (email and campaign_id - the first is not an email address, it's a user guid for our newsletter email users, and honestly I don't really know why we have campaign_id... but someone is using it as an additional field to their campaign code)
Now, for my tracking, like Mandy, I have an eVar reserved for each UTM, set to Visit level attribution. However, I also have code in Launch that grabs each UTM, and strings it together in an easy to regex pattern to pass into my s.campaign variable (which is the Tracking Code or eVar0 dimension)
Edit: I should add, I set my eVars and campaign code all in Launch, not in processing rules.
For me, I decided to use a shortform keyword pair and delimiter pattern (us=source|um=medium|up=campaign|ut=term|uc=content|ue=email|ui=campaign_id)... so that while this as a whole will have 1 week attribution (and can be passed to my marketing channel details as a whole), both Tracking Code and Marketing Channel Details have classification rules that can break these into pieces (keeping them in line with the appropriate attribution, rather than mixing with my Visit level eVars)
I look at the UTM params directly in my Paid Search detection, as well as in my Marketing Channel Rules to properly identify my incoming traffic.
Agree with @MandyGeorge
what I typically do is merge the UTM params together into the Analytics campaign value, so you can use them as Tracking Code dimension.
Key there is to use a unique separator that is not used in any of the UTM param values, such as ":_:" or similar.
Also, when filling the s.campaign dimension, make sure to always have the same number of values set, even if a campaign does not use UTM param xy.
This could be your data element for the aggregated s.campaign value.
[UPDATE] added @Jennifer_Dungan 's input in Option B when no fixed positions are needed anymore and a prefix is used instead
@Jennifer_Dungan Option A is great if you want to export data to Excel
// Option A: fixed positions
const searchParams = new URLSearchParams(window.location.search);
const utmParams = ["utm_source", "utm_medium", "utm_campaign", "utm_content", "utm_term"];
const utmValues = utmParams.map(param => searchParams.get(param) || "");
// if there is at least one value set, return the concatenated string of all parameters
if (utmValues.some(param => param)) {
// source:_:medium:_:campaign:_:content:_:term
const delimiter = ":_:";
console.log(utmValues.join(delimiter));
}
// ------------------------------------------------------------
// Option B: prefixing each parameter with its name and ditch not set params
const searchParams = new URLSearchParams(window.location.search);
const utmParams = {
us: searchParams.get("utm_source"),
um: searchParams.get("utm_medium"),
ucmp: searchParams.get("utm_campaign"),
ucnt: searchParams.get("utm_content"),
ut: searchParams.get("utm_term")
};
// generate pipe separated string of all parameters with name and values, excluding empty values
console.log(Object.entries(utmParams)
.filter(([key, value]) => value)
.map(([key, value]) => `${key}:${value}`)
.join("|")
);
This way, the structure with the delimiter dictates which values were set when you are looking at the Tracking Code dimension.
At the same time, I would strongly recommend capturing the individual UTM params in separate eVars with the same expiration as your Tracking Code dimension.
Views
Replies
Total Likes
Yes, if you are just using a delimiter, you need to keep the same relative position number of elements... if you are using a "key value" like me, you can just send what you have:
Example:
?utm_source=exL&utm_medium=forum&utm_campaign=advisor
With just a delimiter like : you would need to reserve space for term and content with an _ or "na" like:
exL:forum:advisor:_:_
OR
exL:forum:advisor:na:na
But if you are using value pairs, you don't need to:
us=exL|um=forum|up=advisor
OR
us=exL|um=forum|up=advisor|uc=other-value
with prefixes / value pairs, I can use a simple regex like:
(us=)([-_a-zA-Z0-9]*)
To get my source... and with the us= in front of the value, its easy to read without maintaining all the "non-values"... (then I can extract group 2 $2 to get the value without the prefix into my classification)
But both are perfectly acceptable solutions, it all comes down to what you need and how you want to style your tracking codes.
@bjoern__koth with the ability to split your tracking codes with regex rules, why would you use the same attribution on your eVars as Tracking Code? I explicitly make mine different.. Tracking Code at the default 1 week and my eVars at visit. If I need the "Tracking Code" attribution, I will just use my classification from Tracking Codes?
Also, as you can see @skatofiabah there are many ways to do something. You can use a combination of what we do, or track your own path.
Ah, fair enough with the excel point, I don't think I've ever had to do that... but makes sense.
I opted for a solution that people didn't have to remember the order (I have enough trouble getting them to put the correct values per UTM.... )
Views
Replies
Total Likes
Views
Likes
Replies