Best Practice on Capturing Campaign tags

[shiniga]

Hi,

I need to know if it would be okay to assign the campaign parameters that have been tagged in the URL such as source and medium into evars and props, instead of using SAINT file to add the extra details. s.campaign is set to capture the campaign id alone. The rest are being captured in evars and props. Would this be considered okay? Thoughts on this would be very helpful.

Thanks,

Shiniga

[mac28]

Hi,

I don't think so it's a good practice to classify 'source & medium' into evars & props, instead you can use classification & then create classification rules to send those campaign values (see below). Under Admin-report suites-Conversion-Conversion classification, use it to apply text classifications & then create rules in classification rule builder.

Thanks!

[shiniga]

Thank you for your answer Madhur. I understand classification is the ideal way to do this, and I have worked on it in the past. I am evaluating the Adobe implementation for a client, and currently they are passing campaign tags into props and evars. I am trying to understand the drawbacks of this method and if it is urgent that classification be used for campaign tracking.

Also, if we are using classification, we do have to update the campaign details manually for each campaign, using SAINT files, right?

[Gigazelle]

You can use the classification rule build to properly classify them if there's a pattern to them. SAINT is really only used for one-off classification uploads; I find myself using it less and less frequently.

I also would recommend using classifications to get this data. You might face discrepancies if you use an eVar - if you do opt to go this route, make sure the eVar has the exact same settings as your campaign variable. (allocation, expiration, etc).

[josh_donley · Accepted solution]

My 2 cents..

Classifying the campaign variable

• Pro - You don't have to burn any other variables. Maybe you have a ton of unused variables today, but you never know how your implementation will evolve/grow down the line.
• Pro - Classifications are retroactive. This is one of the biggest pros for classifications. Typos happen all the time. Format / value requirements change all the time. Once a key (base/raw value) is recorded, it's there forever unless you want to pay Adobe a lot of money to scrub it. But the classification reports based off the key can be changed, simply by uploading a new table (or updating a classification rule).
• Pro - Classifications can be changed. This is similar to previous point about being retroactive, but is worth separately pointing out that the classification columns themselves can be changed. Today you may have 4 classification columns. Tomorrow you may throw another 3 into the mix. A month from now you may toss them all out for a new set of 5.  And you can do this simply by updating the classification config, pull and reclassify historical keys.
• Con - There is a lag in processing time for classifications (generally about 24h, but I have seen it take upwards of a week sometimes). Generally not a big deal for longer term reports, but can become a problem if you are trying to maintain shorter term reporting needs.
• Con - Creating a process for classifying the raw keys may be a bit of a lift.  Maybe your keys follow a very defined pattern with only  handful of possible values, and you can setup a CRB with a few rules and call it a day. This is best case scenario. In my experience, this is not the average, realistic scenario.  There's only so much CRBs can actually do, and more often than not I hit the limitation wall and they do not become a viable option. Which means, instead, I setup a recurring data warehouse report to export the keys (along with any other data, depending on requirements) to be ftp'd to a server. And then, I setup a server-side script to process the files and generate classifications based on requirements, which then sends the classifications back to Adobe. I have setup hundreds of scripts such as these over the years, starting from before CRB was even an option, but even pretty regularly now, because of CRB limitations.  And depending on your classification needs, there's a good chance you will have to do similar (unless you like regularly doing it manually!)

Using separate variables for classifications

• Pro - If your site already exposes the classified data in real-time during page load, it will almost certainly be easier to push that data to variables at that point, instead of creating a server-side process to classify the data separately.  But how useful this actually is, depends on that data. As mentioned in the other list - if we're talking a handful of set values, then there is little to no benefit from this.
• Pro - No lag in classifications showing up in reports (other than normal data collection lag, same as the campaign variable)
• Con - Increases http request lengths.  If you are using marketing cloud id service and app measurement, this isn't *that* big a deal.
• Con - You burn extra variables.
• Con - Values pushed to the variables are not retroactive. Notice a typo? Format requirements change? Some bug introduced that causes the value to get messed up, or not pop at all? Little to nothing you can really do anything about that, and any kind of workaround/bandaid you come up with will almost certainly involve adding classifications to the variable.
• Con - Changing classifications can quickly become a mess. Throwing a new classifications into the mix means burning another variable(s), and you cannot retroactively classify against historical data.  And when you get into having to change your classification columns in general? It's effectively the same as previous point, only you're deliberately bringing on the pain.

Summary: IMO, in general, going the classification route is usually always the clear winner.  But the separate eVar route *may* come out ahead, depending on your exact circumstances, requirements, and resources.