remove prop/evar[n] mapping requirement

[#1]

In mobile services contextData is passed in a Key/Value pair, it seems rather "old-school" to then require an admin user to go in and remap the key again to a different system level key.  Understandably this is done to provide cross compatibility with SC/Adobe Analytics, but by default you could have a contextData key to Friendly Name mapping for AMS and Workspace, and then optionally use props/evars for components that would need to be used in SC. If a contextData key is not mapped to a Friendly Name then it is not processed otherwise the import processing just needs to locate the contextData key rather than an additional mapping.

This would remove the limits on props and evars, and lighten the implementation effort.

Thanks.

-Lee

[#2]

Thanks for submitting this, Lee. We're discussing ways to remove the prop/eVar mapping requirement, but there are a few technical steps we need to take to get there. Lightening the implementation effort is the key driver for those discussions. 

[#3]

I'm interested in hearing more about your thoughts here Lee.

Is this what you're thinking?

Key/Value pairs are passed directly into your report verbatim. No settings are applied to them for allocation/expiration, everything is hit-based.

Let me know if I missed something.

[#4]

I think this would be a good thing to move to.  But the problem is props and eVars have separate configurations/behaviors. For example props can be configured as list props or have pathing enabled on them, but are hit scope only.  Whereas eVars have different scopes and attributation models you can apply to them.  

So it's not as easy as just pushing the contextData directly to reports with the same effect. At a minimum, you'd have to specify all those things - which you do already (configuring the prop/eVar) and then you map the contextData variable to it.  Point is, *at best*, pushing contextData variables directly to reports and yet allowing them to be as robust as props/eVars isn't really going to change LoE of configuration. Maybe a minor one where it's all in one config interface, which more convenient, sure, but doesn't actually bring anything more/less to the table in terms of functionality.

Having said all that - I would LOVE to at a minimum see a core "contextData" report, similar to the Actions report, where it shows all of the user defined contextData variables, as well. The reports would just be hit scoped, no allocation, expiration, nothing. Basically a "raw hit" report.  Well okay, maybe bake in some correlation since all props are correlated with each other now and under the hood it'd probably be easiest to just treat it like a prop w/ no additional configuration. 

This would largely help with QA efforts, especially when taking over a new implementation. But also with ongoing implementation to help ensure the raw data is coming in vs. maybe some misconfiguration w/ the mapping or prop/eVar settings they are mapped to. Or being able to tell when something suddenly stops tracking.  I can't tell you how many times I've had to QA something that stopped tracking, only to find out it's because someVar was changed to some_var by some dev who didn't think it mattered.  

[#5]

I don't know the backend setup but I think maybe one way to approach it would be to have a single contextData report where under the hood it's basically a prop, and then the keys/values would be handled similar to saint classifications. Since there a one to many relationship with key/values, the values would be similar to subclassifications.

So the master key (the "Key" column of saint classifications) would always be the same, then they contextData variable names would be a regular classification column, and then the value would be subclassification of the variable names.

Key  Name      Name^Value
*    fooname1  foovalue1
*    fooname1  foovalue2
*    barname2  barvalue1
*    barname2  barvalue2
*    barname3  barvalue3

So then there would be a single contextData report similar to Actions report where all the variables are listed ("Name") and you could break them down by their values ("Name^Value"). 

Well I don't know how feasible that actually is on the backend, what is already there to use, but at face value I think that's where I'd start, anyways.  But the overall principle is to be able to see a list of contextData variable names being pushed to Adobe, and their values.