Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

remove prop/evar[n] mapping requirement

Avatar

Avatar
Boost 3
Level 2
lisensee0
Level 2

Likes

4 likes

Total Posts

2 posts

Correct Reply

0 solutions
Top badges earned
Boost 3
Boost 1
View profile

Avatar
Boost 3
Level 2
lisensee0
Level 2

Likes

4 likes

Total Posts

2 posts

Correct Reply

0 solutions
Top badges earned
Boost 3
Boost 1
View profile
lisensee0
Level 2

18-10-2016

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

5 Comments

Avatar

Avatar
Employee
BretGundy
Employee

Likes

0 likes

Total Posts

99 posts

Correct Reply

0 solutions
View profile

Avatar
Employee
BretGundy
Employee

Likes

0 likes

Total Posts

99 posts

Correct Reply

0 solutions
View profile
BretGundy
Employee

19-10-2016

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. 

Avatar

Avatar
Coach
Employee
ericmatisoff
Employee

Likes

151 likes

Total Posts

275 posts

Correct Reply

77 solutions
Top badges earned
Coach
Contributor
Shape 10
Shape 1
Ignite 5
View profile

Avatar
Coach
Employee
ericmatisoff
Employee

Likes

151 likes

Total Posts

275 posts

Correct Reply

77 solutions
Top badges earned
Coach
Contributor
Shape 10
Shape 1
Ignite 5
View profile
ericmatisoff
Employee

19-10-2016

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.

Avatar

Avatar
Contributor
MVP
joshd7227840
MVP

Likes

275 likes

Total Posts

241 posts

Correct Reply

70 solutions
Top badges earned
Contributor
Give Back 10
Give Back 5
Give Back 3
Give Back
View profile

Avatar
Contributor
MVP
joshd7227840
MVP

Likes

275 likes

Total Posts

241 posts

Correct Reply

70 solutions
Top badges earned
Contributor
Give Back 10
Give Back 5
Give Back 3
Give Back
View profile
joshd7227840
MVP

20-10-2016

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.  

Avatar

Avatar
Contributor
MVP
joshd7227840
MVP

Likes

275 likes

Total Posts

241 posts

Correct Reply

70 solutions
Top badges earned
Contributor
Give Back 10
Give Back 5
Give Back 3
Give Back
View profile

Avatar
Contributor
MVP
joshd7227840
MVP

Likes

275 likes

Total Posts

241 posts

Correct Reply

70 solutions
Top badges earned
Contributor
Give Back 10
Give Back 5
Give Back 3
Give Back
View profile
joshd7227840
MVP

21-10-2016

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. 

Avatar

Avatar
Validate 1000
Community Manager
jantzen_belliston-Adobe
Community Manager

Likes

337 likes

Total Posts

2,286 posts

Correct Reply

815 solutions
Top badges earned
Validate 1000
Springboard
Validate 500
Validate 250
Validate 100
View profile

Avatar
Validate 1000
Community Manager
jantzen_belliston-Adobe
Community Manager

Likes

337 likes

Total Posts

2,286 posts

Correct Reply

815 solutions
Top badges earned
Validate 1000
Springboard
Validate 500
Validate 250
Validate 100
View profile
jantzen_belliston-Adobe
Community Manager

27-10-2020

 
Status changed to: Archived