“Change is the law of life and those who look only to the past or present are certain to miss the future.” — John F. Kennedy

It seems to be human nature to keep doing what we know, even if we understand there is a better way to solve a vexing problem. There have been a handful of customers who told me over the last several months that Context Data is not for them and they want to stick with what they know. (Don’t know what Context Data is? See this link). Despite this tendency and in harmony with what President Kennedy said above, we don’t want Adobe’s Mobile Analytics customers to miss the future. As such, the most recent release of the Mobile App 4.x SDK only supports Context Data for analytics data collection. Although you may get a bit teary-eyed bidding farewell to expounding on the differences of eVars and props to your developers, we’re sure you’ll eventually get over it. To help make you more comfortable in this Context Data-only world of mobile, this blog post provides valuable Context Data best practices and a multi-report suite tagging trick.

Before continuing, if you are one of Adobe’s customers who isn’t quite ready to make the jump to Context Data within your mobile app analytics, you still have options. The older 3.x SDK supports explicitly set variables (i.e. props, eVars, and events) as well as Context Data and may be utilized while you prepare to migrate to Context Data.

What does it look like?
Even those who understand Context Data is essentially arbitrarily naming a data collection variable, still may not know what Context Data looks like within a request. Let’s review examples of what Context Data looks like within a URL, Bloodhound, and Charles.

Context Data within a URL
Context Data Example - URL

Note: “c.” and “.c” denote the beginning and end of Context Data elements in an XML-like structure.

Context Data within Bloodhound
Context Data Example - Bloodhound
Context Data within Charles
Context Data Example - Charles
What’s mine, what’s yours?
In the examples above you may note the “my.” and “.my” and the “a.” and “.a”. These are “namespaces” used as a best practice to prevent variable name collision. While, the “a” prefix is reserved by Adobe for their specific variables, you’re welcome and encouraged to use any other prefix for your variables.

What’s in a good name?
When naming your Context Data variables, use names that are clear while concise. Although CamelCase is not required, it can be helpful in making variables more readable when examining output. Here are a few examples: my.loginStatus, my.shareType, my.shareAction. However, be aware that the Processing Rule UI will force all Context Data variable names to lowercase.

You may also group Context Data variables by creating secondary prefixes, such as “media.” Examples of this would be: my.media.title, my.media.creator, my.media.genre.

As a word of caution, don’t use Context Data variable names such “prop3” or “eVar6” even if those variables are where the Context Data variables may eventually be mapped using Processing Rules. It can cause a lot confusion during validation when analytsts and developers alike can’t figure out why their prop3 report is not populating within Adobe Analytics despite “seeing it” within the output of the app. Furthermore, this destroys the intent of abstraction between the type of data stored within a variable and where it ultimately lives within Adobe Analytics reporting.

Note: Windows tablets have a 2048 character limit on the submitted URL request that is sent to our data collection servers. Given this limitation, shorter Contex Data variable names may be required.

What about the 50-processing-rule limit?
Some Adobe Analytics customers have nearly tapped-out all 75 eVars, 75 props and 100 events for a given report suite. If each of those variables were unique and needed to be mapped, the customer would need 250 Context Data variables. In the past, some customers have created one processing rule for each Context Data variable mapping (e.g. my.ShareType -> eVar4). Since there currently is a limit of 50 processing rules per report suite, 200 variables would remain unmapped in the example above. Thankfully, there’s a much simpler approach, which is fortunate as I can’t think of anyone who would want to manage 250 distinct Processing Rules. The recommended best practice for variable mapping is to simply map multiple ContextData variables within one Processing Rule. Going back to the example above, a single Processing Rule could be utilized to map all 250 variables.

processing_rule_1
What’s the effect on eVars?
If you’re wondering if all the ContextData variable mappings found in a given Processing Rule need to be defined within a request, they do not. This is especially important to call out with respect to eVars, for two reasons: 1) An empty Context Data variable that maps to an eVar won’t “unset” its value if it was previously defined for a given visit (assuming the particular eVar has an expiration longer than a page view). 2) An empty Context Data variable that maps to an eVar won’t create “None” values that appear within that particular eVar report.

Let’s look at examples for each of these of two cases. For the first case, let’s refer to the mapping of my.shareType -> eVar4. Within a report suite eVar4 has an expiration of “visit.” Furthermore, eVar4 was just set to a value of “Twitter.” Then a subsequent request comes in where my.shareType was not included within the request. Within this scenario eVar4 will still have a value of “Twitter.”

For the second case, let’s assume these three mappings occur within one Processing Rule: my.shareType -> eVar4, my.loginStatus -> prop5, my.menuLocation -> eVar6. Let’s say my.shareType is not set, but the other two Context Data variable are set within a specific request. The result would be prop5 and eVar6 having defined values, and eVar4 would be left out. The reason I call this out is some fear that eVar 4 would still be included and mapped to nothing and cause a “None” to appear within the eVar4 report. This will not happen (although “None” may appear within Adobe Analytics for other unrelated reasons).

How about mapping Context Data for Events?
Astute readers will note I haven’t used any context-data-to-event mappings to this point. There is an added nuance with events when it comes to performing multiple Context Data mappings within a single Processing Rule. Traditionally Context Data events have taken on the following name-value structure: my.someAction = someAction, or my.someAction = true. There is nothing wrong with this structure per se. The only challenge is this structure inherently requires one Processing Rule per mapping, since it requires a logical operator to check to see if the variable name (e.g. my.someAction) is set. So if there are 100 Context Data events that need to be mapped, this will be a problem with the 50-processing-rule-limit per report suite, as discussed previously. To get around this problem and allow multiple Context Data events to be mapped within a single processing rule, we need to set the Context Data event value differently. Instead of setting its value to some string, set it’s value to “1″ (equivalent to a counter event) or a higher numeric value (equivalent to an incriminator event). So for example, my.someAction=“1” or my.someAction=“5”. Here’s the updated Processing Rule that now includes the mapping of my.someAction -> event2.

processing_rule_2

What about Processing Rules for LifeCycle metrics?
As was shown earlier, there are several Context Data variables that have an “a” prefix. For the Mobile App SDKs, these are the LifeCycle metrics that are measured automatically by the mobile library. When it comes to Processing Rules, what differentiates these Adobe Context Data variables from the variables you define is that you don’t need to worry about creating and managing rules for these special variables. All you need to do is click the button shown below (Adobe Analytics > Admin (“Star”) > Admin Tools > Report Suites > Edit Settings > Mobile Management > Mobile Application Reporting). Behind the scenes these particular Context Data variables are mapped for you. Furthermore, these mapping won’t count against your 50-processing-rules-per-report-suite limit.

enable_lifecycle

Where’s the multi-report suite trick?
As promised in the introduction, you can do some powerful things by leveraging Context Data that you could not do with explicitly set variables. One of these comes into play with multi-report suite tagging. Traditionally, when sending the same requests to multiple report suites, it was a prerequisite that variables were in alignment across the report suites that were included. For example, eVar8 and event10 need to be used for the same purpose in a primary and global report suite. With Context Data this is no longer a problem. Since Processing Rules live and operate within a specific report suite, different mappings can occur across report suites. To illustrate, we could have my.loginStatus -> prop6 within the primary report suite and have my.loginStatus -> eVar12 within the global report suite.

You can also exclude Context Data variables that may not be relevant within a given report suite if there are data elements that are not required at the global report suite level. Past approaches have been to “hide” these variables within the global report suite menu structure so as to prevent confusion. Using Context Data you simply don’t map the data elements within the global report suite that aren’t relevant. For example, my.menuLocation is quite important within the primary report suite, but is useless to include at the global report suite level. Within the Processing Rules of the global report suite, simply don’t map my.menuLocation.

Conclusion
With the Mobile App 4.x SDK, Context Data is the one and only way of doing data collection. With the tips and tricks discussed in this blog post, you should be on a solid footing in getting the most bang-for-the-buck out of your Processing Rules. Furthermore, making the change to Context Data will assure you won’t miss upcoming Adobe Mobile capabilities that lie within the future.

 

0 comments