CODEWITHSUNDEEP
adobe-analytics
user2810905
user2810905

Reputation: 11

Omniture: Creating Specific Context Variables

Was wondering if anyone out there can help.......

My company works in the travel industry and one of the product we provide is the function of buying a flight and hotel together.

One of the advantages of this is that sometimes a visitor can save on a hotel if they buy the package together.

What I want to be able to track is the following:

The hotel which has the saving on it (accomodation code); the saving that they will make; the price of the package that they will pay.

I am new to implementing but have been told by a colleague that I can use a context variable.

Would anyone be able to tell me how I should write this please?

Kind Regards

Yaser

Upvotes: 1

Views: 1297

Answers (1)

CrayonViolent
CrayonViolent

Reputation: 32532

Here is the document entry for Context Data Variables

For example, in the custom code section of the on-page code, within s_doPlugins or via some wrapper function that ultimately makes a s.t() or s.tl() call, you would have:

s.contextData['package.code'] = "accommodation code";
s.contextData['package.savings'] = "savings";
s.contextData['package.price'] = "price";

Then in the interface you can go to processing rules and map them to whatever props or eVars you want.

Having said that...processing rules are pretty basic at the moment, and to be honest, it's not really worth it IMO. Firstly, you have to get certified (take an exam and pass) to even access processing rules. It's not that big a deal, but it's IMO a pointless hoop to jump through (tip: if you are going to go ahead and take this step, be sure to study up on more than just processing rules. Despite the fact that the exam/certification is supposed to be about processing rules, there are several questions that have little to nothing to do with them)

2nd, context data doesn't show up in reports by themselves. You must assign the values to actual props/eVars/events through processing rules (or get ClientCare to use them in a vista rule, which is significantly more powerful than a processing rule, but costs lots of money)

3rd, the processing rules are pretty basic. Seriously, you're limited to just simple stuff like straight duping, concatenating values, etc.

4th, processing rules are limited in setting events, and won't let you set the products string. IOW, You can set a basic (counter) event, but not a numeric or currency event (an event with a custom value associated with it). Reason I mention this is because those price and savings values might be good as a numeric or currency event for calculated metrics. Well since you can't set an event as such via processing rules, you'd have to set the events in your page code anyways.

The only real benefit here is if you're simply looking to dupe them into a prop/eVar and that prop/eVar varies from report suite to report suite (which FYI, most people try to keep them consistent across report suites anyways, and people rarely repurpose them).

So if you are already being consistent across multiple report suites (or only have like 1 report suite in the first place), since you're already having to put some code on the site, there's no real incentive to just pop the values in the first place.

I guess the overall point here is that since the overall goal is to get the values into actual props, eVars and possibly events, and processing rules fail on a lot of levels, there's no compelling reason not to just pop them in the first place.

Upvotes: 3

Related Questions