“Variables”

Here’s a topic that has likely prompted the odd head scratch: “variables” in Adobe Analytics.

From the point of view of a marketer, there are two different types of variables, and Adam Greco did a great job describing them: Traffic Variables, Conversion Variables – Part I and Conversion Variables – Part II. There’s also something called “Success Events”, again aptly explained by Adam Greco: Conversion (Success Events)

If you’re a developer and you’ve read through those articles, my hunch is you’re now totally confused, because these “variables” do not work like a variable in – say – C, Java or even Javascript.

In fact, all they are is attributes of the “s object”. They are reserved spaces in that object. We put data into those spaces, and the Analytics client-side Javascript code reads that data and builds an HTTP GET request.

And that’s it.

No scope, no persistence, no type-checking.

The “variables” in Adobe Analytics are very simple “drop off points” where we put data so it can be sent into the collection servers and processed.

Example

Let’s run through an example. Take the following code on a sample page:

	s.pageName="Blog:Variables";
	s.prop1="blog";             // section
	s.prop2="en";               // english
	s.prop5="article";          // page type
	s.events="event1,event2";
               // custom page views event, blog views event
	s.eVar5="article";          // page type

When you send off the tracking data (remember: call s.t()), the Javascript library takes all the data and builds an HTTP GET request that it’ll ask the browser to send.

The data above will end up looking something like this in that URL:

	...&pageName=Blog%3AVariables&c1=blog&c2=en&c5=article \\
	&events=event1,event2&v5=article...

All the JS library is doing is take the data you wrote into the different attributes of the “s object”, read it, and put it into the URL for the tracking beacon.

Hm…

Right. So what if you need proper variables? What if you want to store data and re-use it on another page? Adobe Analytics doesn’t do that. At least not like you usually would do it.

I’m sure you know the answer: cookies, HTML5 storage, Flash LSOs and similar technologies can be used client-side, or you can use server-side storage, usually session-based, if your CMS can do that.

For the client-side approach, we can now circle back to the plugins we mentioned before. Some of those are built for the very purpose of storing data and retrieving it when needed.

Good examples are: s.getVisitNum, s.getPreviousValue or s.crossVisitParticipation. They all use cookies and are used to tie together things that happened in previous visits or on previous pages.

Cookies & Privacy

A little note on privacy: Adobe suggests that you be open about what data you store, both locally and remotely. If you are using cookies to store data, tell your visitors! Most people don’t mind if they’re told (see Facebook), but they do mind if they aren’t.

Adobe Consulting will not help you use Flash LSOs to store data, for the same reason.

People know how to get rid of cookies and more and more people get what they can and cannot do. But Flash LSOs, sometimes suggested as a “more sticky” alternative because they are not as easy to delete and work across browsers, are still a bit spooky to most people, which is why you should steer clear.

Results

What happens to the data we send into Adobe Analytics?

Back to the top and the two types of “variables”: traffic and conversion.

For traffic variables (“propXY”), the data can be found in one of the “Custom Traffic” Reports, as line items on the left hand side.

[Screenshot]

Traffic Report

The metrics that your marketer can use with this data are: Page Views, Visits, Unique Visitors, and a couple others depending on setup.

The system will count a Page View for a specific item of data (say the “en” we sent in prop2 in the example above) every time you send it in with an s.t() call. It will also calculate Visits and Unique Visitors metrics based on who it thinks the visitor is. We’ll get back to that at some point.

Reports based on conversion variables (“eVarXY” & events) can be found in the “Custom Conversion” Reports. The data in the eVars will become line items on the left, and the events can be used as metrics.

[Screenshot]

Conversion Report

Now when will a value in an eVarXY be counted for a specific event?

That depends on a couple of settings, but in general, an eVar is like a stamp that you can apply to a visitor’s forehead, and the event is counted to whatever the stamp on the forehead says at the time the event happens.

Yes, it is more complicated than that, and we will get to that later as well.

For now, this is all you need to know about “variables” in Adobe Analytics.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , ,
Posted in Page Code, Principles
48 comments on ““Variables”
  1. […] how in the article on variables we talked about how data is transported into Adobe […]

    Like

  2. […] data is assigned to “variables” in Javascript. Those “variables” are then sent off to the collection servers. […]

    Like

  3. […] that everybody can use designations just the way they see fit. We saw that in the article on “variables” in SiteCatalyst, and today we show another example: Data […]

    Like

  4. […] which we haven’t mentioned yet. In a nutshell, they “replace” the usual Analytics “variables”. Context Data variables are more like a hash map and they should make it easier for developers to […]

    Like

  5. […] “variables” for tracking purchases. Let’s take the example from our post about basic tracking and amend it […]

    Like

  6. […] submit when s.tl() is called. This is different from tracking pages! When you track with s.t(), all “variables” are being sent. With s.tl(), none of them are per default. You have to explicitly tell the system […]

    Like

  7. […] They draft a “Solution Design Reference” or a “Tech Spec” that contains a list of “variables” […]

    Like

  8. […] can no longer just include a <script> block on your page that sets the various “variables” or otherwise accesses the s object, because the object might not yet exist, or you might be too […]

    Like

  9. […] file that are not working very well in parallel to old versions, like for example if you reassign a “variable” or an […]

    Like

  10. […] for the results page to load. Then look at the tracking using your favourite debugger. Check the “variables” that are being […]

    Like

  11. […] changing of events for the fun of it. No reassigning of eVars. Once you use a “variable” for something, you’re tied […]

    Like

  12. […] The possible elements that you can use cover pretty much everything available in Adobe Analytics, including all “propXX” and “eVarYY” custom “variables“. […]

    Like

  13. […] system will read all the “variables”, then answer with a HTTP Status 302 and tell the browser to go to the URL you […]

    Like

  14. […] the article on basic tracking, you have to do three things: a) load the s_code.js file, b) assign “variables”, c) send it all off using the s.t() […]

    Like

  15. […] it into the s.campaign variable (and treat it like any other campaign), or we might use a separate conversion variable. Your friendly marketer should […]

    Like

  16. […] The library offers a new method called s.clearVars(), which removes existing values for most of the “variables”. […]

    Like

  17. […] the call to s_gi() is meant to instantiate the “s object” which will a) carry the “variables” and b) define the s.tl() method used to trigger the tracking […]

    Like

  18. […] here’s the issue: because the UK and US sites do not use the same “variables” for the same data, the global report suite has mixed data in some reports. Not nice, not pretty, […]

    Like

  19. […] Each report suite has settings that are independent of all other report suites. Some of the things your friendly marketer sees in the interface are attached to the report suite, for example “Bookmarks”, “Schedules” or even the menu structure and semantics of the different “variables”. […]

    Like

  20. […] were sending in a prop and an eVar along with an event as payload on a custom link. The numbers for that custom link were […]

    Like

  21. […] last year, while discussing Context Data with a web developer (which in turn led to me explaining “variables” in Adobe Analytics in general), I realised that while there is a lot of really helpful content out […]

    Like

  22. […] idea is that instead of aligning “variables” across all report suites, you switch to using Context Data & Processing Rules on those that are […]

    Like

  23. […] data is assigned to “variables” in Javascript. Those “variables” are then sent off to the collection servers. The collection […]

    Like

  24. […] the post about “Variables” I neglected to mention one important characteristic of Adobe Analytics: with each Report Suite, you […]

    Like

  25. […] assign values to “Variables” for basic […]

    Like

  26. […] (of course, it’s a cookie!) and the system picks it up and records it along the rest of the “variables” you […]

    Like

  27. […] that you just use the new Visitor object to set the new s.visitor “variable”, like […]

    Like

  28. […] the top menu, you can add “Variables” and metrics (Please tell me your app has an actual purpose! If it does: good. Make sure you add […]

    Like

  29. […] assign values to “Variables”, or rather into a HashMap of Context Data, because the Mobile SDKs v4.x+ do not support old-style […]

    Like

  30. […] how I did not once talk about specific “variables” or Processing Rules at all! You essentially get a lot of very tailored and therefore useful stuff […]

    Like

  31. […] the web page. As both marketers and implementers become more knowledgeable, they’ll add more information to those image […]

    Like

  32. […] a row somewhere in the Data Feed that contains “DE” in the column that represents that “variable”. The same is true for all values you are sending, with a notable exception: Context Data is NOT […]

    Like

  33. […] those of you who still put data into “variables”: you will need to find out which variable or variables to use! It is highly likely that your […]

    Like

  34. […] about “variables”? Essentially having twice as many sounds good, […]

    Like

  35. […] think I have mentioned eVars often enough by now for you to know what they are and what we use them for. (Let me know if not, […]

    Like

  36. […] the number at the start of a visit), and providing the current number so we can track it into a “variable” of our […]

    Like

  37. […] Based Rules, like all rules, allow you to set Adobe Analytics “variables”. You can use Data Elements for that, for example. This is great with a Data Layer, but I think I […]

    Like

  38. […] Simo mapped things that happen on his blog to the ecommerce capabilities of Google Analytics. That should be even easier with Adobe Analytics, given that we have a bunch of Success Events and flexible eVars. […]

    Like

  39. […] the resulting “variable”, I can make a New/Repeat report using Classifications. Just classify “1” as […]

    Like

  40. […] they hit a button? Did they swipe down far enough? Those are good questions, and you should use an eVar to make that […]

    Like

  41. […] 20 – 25 are where your tracking code goes. You can set props, eVars and events here, then you must call s.t() or […]

    Like

  42. […] topic: I know that I am setting a “variable” or event somewhere — say event2. How can I find out which rule is doing […]

    Like

  43. […] fire actual tracking requests, your PLRs are still being executed, meaning they’ll set “variables” quite […]

    Like

  44. […] easy to understand, right? But you still have to put Javascript code into it to assign “variables“, and you have to think of adding those “variables” to s.linkTrackVars and […]

    Like

  45. […] into pages (much better!), setting s.products was no different from setting any other “variable“. We would just write some code that determined what to put into it. Some code that would […]

    Like

  46. […] our case (using Adobe Analytics), we would send a Success Event plus an eVar carrying the name of the page. This would later allow us to see two things for every page: how […]

    Like

  47. […] long time back, I used to write on this blog about “variables”, and I always put that in quotes, because you really shouldn’t see something like s.eVar47 as […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: