Best Practice on Capturing Campaign tags

Avatar

Avatar

shiniga

Avatar

shiniga

shiniga

12-04-2018

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

View Entire Topic

Avatar

Avatar

joshd7227840

MVP

Avatar

joshd7227840

MVP

joshd7227840
MVP

30-04-2018

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.