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

It seems to be human nature to keep doing what we know, even if we under­stand there is a bet­ter way to solve a vex­ing prob­lem. There have been a hand­ful of cus­tomers who told me over the last sev­eral months that Con­text Data is not for them and they want to stick with what they know. (Don’t know what Con­text Data is? See this link). Despite this ten­dency and in har­mony with what Pres­i­dent Kennedy said above, we don’t want Adobe’s Mobile Ana­lyt­ics cus­tomers to miss the future. As such, the most recent release of the Mobile App 4.x SDK only sup­ports Con­text Data for ana­lyt­ics data col­lec­tion. Although you may get a bit teary-eyed bid­ding farewell to expound­ing on the dif­fer­ences of eVars and props to your devel­op­ers, we’re sure you’ll even­tu­ally get over it. To help make you more com­fort­able in this Con­text Data-only world of mobile, this blog post pro­vides valu­able Con­text Data best prac­tices and a multi-report suite tag­ging trick.

Before con­tin­u­ing, if you are one of Adobe’s cus­tomers who isn’t quite ready to make the jump to Con­text Data within your mobile app ana­lyt­ics, you still have options. The older 3.x SDK sup­ports explic­itly set vari­ables (i.e. props, eVars, and events) as well as Con­text Data and may be uti­lized while you pre­pare to migrate to Con­text Data.

What does it look like?
Even those who under­stand Con­text Data is essen­tially arbi­trar­ily nam­ing a data col­lec­tion vari­able, still may not know what Con­text Data looks like within a request. Let’s review exam­ples of what Con­text Data looks like within a URL, Blood­hound, and Charles.

Con­text Data within a URL
Context Data Example - URL

Note: “c.” and “.c” denote the begin­ning and end of Con­text Data ele­ments in an XML-like structure.

Con­text Data within Blood­hound
Context Data Example - Bloodhound
Con­text Data within Charles
Context Data Example - Charles
What’s mine, what’s yours?
In the exam­ples above you may note the “my.” and “.my” and the “a.” and “.a”. These are “name­spaces” used as a best prac­tice to pre­vent vari­able name col­li­sion. While, the “a” pre­fix is reserved by Adobe for their spe­cific vari­ables, you’re wel­come and encour­aged to use any other pre­fix for your variables.

What’s in a good name?
When nam­ing your Con­text Data vari­ables, use names that are clear while con­cise. Although Camel­Case is not required, it can be help­ful in mak­ing vari­ables more read­able when exam­in­ing out­put. Here are a few exam­ples: my.loginStatus, my.shareType, my.shareAction. How­ever, be aware that the Pro­cess­ing Rule UI will force all Con­text Data vari­able names to lowercase.

You may also group Con­text Data vari­ables by cre­at­ing sec­ondary pre­fixes, such as “media.” Exam­ples of this would be: my.media.title, my.media.creator, my.media.genre.

As a word of cau­tion, don’t use Con­text Data vari­able names such “prop3” or “eVar6” even if those vari­ables are where the Con­text Data vari­ables may even­tu­ally be mapped using Pro­cess­ing Rules. It can cause a lot con­fu­sion dur­ing val­i­da­tion when ana­lyt­sts and devel­op­ers alike can’t fig­ure out why their prop3 report is not pop­u­lat­ing within Adobe Ana­lyt­ics despite “see­ing it” within the out­put of the app. Fur­ther­more, this destroys the intent of abstrac­tion between the type of data stored within a vari­able and where it ulti­mately lives within Adobe Ana­lyt­ics reporting.

Note: Win­dows tablets have a 2048 char­ac­ter limit on the sub­mit­ted URL request that is sent to our data col­lec­tion servers. Given this lim­i­ta­tion, shorter Con­tex Data vari­able names may be required.

What about the 50-processing-rule limit?
Some Adobe Ana­lyt­ics cus­tomers have nearly tapped-out all 75 eVars, 75 props and 100 events for a given report suite. If each of those vari­ables were unique and needed to be mapped, the cus­tomer would need 250 Con­text Data vari­ables. In the past, some cus­tomers have cre­ated one pro­cess­ing rule for each Con­text Data vari­able map­ping (e.g. my.ShareType -> eVar4). Since there cur­rently is a limit of 50 pro­cess­ing rules per report suite, 200 vari­ables would remain unmapped in the exam­ple above. Thank­fully, there’s a much sim­pler approach, which is for­tu­nate as I can’t think of any­one who would want to man­age 250 dis­tinct Pro­cess­ing Rules. The rec­om­mended best prac­tice for vari­able map­ping is to sim­ply map mul­ti­ple Con­text­Data vari­ables within one Pro­cess­ing Rule. Going back to the exam­ple above, a sin­gle Pro­cess­ing Rule could be uti­lized to map all 250 variables.

processing_rule_1
What’s the effect on eVars?
If you’re won­der­ing if all the Con­text­Data vari­able map­pings found in a given Pro­cess­ing Rule need to be defined within a request, they do not. This is espe­cially impor­tant to call out with respect to eVars, for two rea­sons: 1) An empty Con­text Data vari­able that maps to an eVar won’t “unset” its value if it was pre­vi­ously defined for a given visit (assum­ing the par­tic­u­lar eVar has an expi­ra­tion longer than a page view). 2) An empty Con­text Data vari­able that maps to an eVar won’t cre­ate “None” val­ues that appear within that par­tic­u­lar eVar report.

Let’s look at exam­ples for each of these of two cases. For the first case, let’s refer to the map­ping of my.shareType -> eVar4. Within a report suite eVar4 has an expi­ra­tion of “visit.” Fur­ther­more, eVar4 was just set to a value of “Twit­ter.” Then a sub­se­quent request comes in where my.shareType was not included within the request. Within this sce­nario eVar4 will still have a value of “Twitter.”

For the sec­ond case, let’s assume these three map­pings occur within one Pro­cess­ing Rule: my.shareType -> eVar4, my.loginStatus -> prop5, my.menuLocation -> eVar6. Let’s say my.shareType is not set, but the other two Con­text Data vari­able are set within a spe­cific request. The result would be prop5 and eVar6 hav­ing defined val­ues, and eVar4 would be left out. The rea­son I call this out is some fear that eVar 4 would still be included and mapped to noth­ing and cause a “None” to appear within the eVar4 report. This will not hap­pen (although “None” may appear within Adobe Ana­lyt­ics for other unre­lated reasons).

How about map­ping Con­text Data for Events?
Astute read­ers will note I haven’t used any context-data-to-event map­pings to this point. There is an added nuance with events when it comes to per­form­ing mul­ti­ple Con­text Data map­pings within a sin­gle Pro­cess­ing Rule. Tra­di­tion­ally Con­text Data events have taken on the fol­low­ing name-value struc­ture: my.someAction = some­Ac­tion, or my.someAction = true. There is noth­ing wrong with this struc­ture per se. The only chal­lenge is this struc­ture inher­ently requires one Pro­cess­ing Rule per map­ping, since it requires a log­i­cal oper­a­tor to check to see if the vari­able name (e.g. my.someAction) is set. So if there are 100 Con­text Data events that need to be mapped, this will be a prob­lem with the 50-processing-rule-limit per report suite, as dis­cussed pre­vi­ously. To get around this prob­lem and allow mul­ti­ple Con­text Data events to be mapped within a sin­gle pro­cess­ing rule, we need to set the Con­text Data event value dif­fer­ently. Instead of set­ting its value to some string, set it’s value to “1″ (equiv­a­lent to a counter event) or a higher numeric value (equiv­a­lent to an incrim­i­na­tor event). So for exam­ple, my.someAction=“1” or my.someAction=“5”. Here’s the updated Pro­cess­ing Rule that now includes the map­ping of my.someAction -> event2.

processing_rule_2

What about Pro­cess­ing Rules for Life­Cy­cle met­rics?
As was shown ear­lier, there are sev­eral Con­text Data vari­ables that have an “a” pre­fix. For the Mobile App SDKs, these are the Life­Cy­cle met­rics that are mea­sured auto­mat­i­cally by the mobile library. When it comes to Pro­cess­ing Rules, what dif­fer­en­ti­ates these Adobe Con­text Data vari­ables from the vari­ables you define is that you don’t need to worry about cre­at­ing and man­ag­ing rules for these spe­cial vari­ables. All you need to do is click the but­ton shown below (Adobe Ana­lyt­ics > Admin (“Star”) > Admin Tools > Report Suites > Edit Set­tings > Mobile Man­age­ment > Mobile Appli­ca­tion Report­ing). Behind the scenes these par­tic­u­lar Con­text Data vari­ables are mapped for you. Fur­ther­more, these map­ping 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 intro­duc­tion, you can do some pow­er­ful things by lever­ag­ing Con­text Data that you could not do with explic­itly set vari­ables. One of these comes into play with multi-report suite tag­ging. Tra­di­tion­ally, when send­ing the same requests to mul­ti­ple report suites, it was a pre­req­ui­site that vari­ables were in align­ment across the report suites that were included. For exam­ple, eVar8 and event10 need to be used for the same pur­pose in a pri­mary and global report suite. With Con­text Data this is no longer a prob­lem. Since Pro­cess­ing Rules live and oper­ate within a spe­cific report suite, dif­fer­ent map­pings can occur across report suites. To illus­trate, we could have my.loginStatus -> prop6 within the pri­mary report suite and have my.loginStatus -> eVar12 within the global report suite.

You can also exclude Con­text Data vari­ables that may not be rel­e­vant within a given report suite if there are data ele­ments that are not required at the global report suite level. Past approaches have been to “hide” these vari­ables within the global report suite menu struc­ture so as to pre­vent con­fu­sion. Using Con­text Data you sim­ply don’t map the data ele­ments within the global report suite that aren’t rel­e­vant. For exam­ple, my.menuLocation is quite impor­tant within the pri­mary report suite, but is use­less to include at the global report suite level. Within the Pro­cess­ing Rules of the global report suite, sim­ply don’t map my.menuLocation.

Con­clu­sion
With the Mobile App 4.x SDK, Con­text Data is the one and only way of doing data col­lec­tion. With the tips and tricks dis­cussed in this blog post, you should be on a solid foot­ing in get­ting the most bang-for-the-buck out of your Pro­cess­ing Rules. Fur­ther­more, mak­ing the change to Con­text Data will assure you won’t miss upcom­ing Adobe Mobile capa­bil­i­ties that lie within the future.

 

0 comments