Custom Payload from Mobile for SDK implementation through Edge for Analytics.

[BertBru]

Hello,

I am writing requirements for our mobile dev team and would like to gauge how much flexibility we have with mobile payload vs schema, especially since we're using a datastream.

So far, if the xdm structure from the payload doesn't match our schema, nothing shows up in Analytics reporting, even when mapped in the datastream. I am beginning to wonder what the datastream mapping is for if the payload needs to match the schema.

Example of datastream mapping that works (shows up in reporting)

• _experience.analytics.customDimensions.props.prop36
  
  • mapped to
  • _experience.analytics.customDimensions.props.prop36

Example of datastream mapping that doesnt work (doesnt show up in reporting)

• programDetails.degreeLevel
  • mapped to
  • _experience.analytics.customDimensions.props.prop33

I hope my question makes sense!

[John_Man · Accepted solution]

Hi @BertBru 

For your first example that shows up in reporting, is there any reason why you need to map the same field (_experience.analytics.customDimensions.props.prop36) to itself?

Anyway, for AEP Mobile SDK, we tried the following approach using sendEvent() and both works fine,

1) populate the XDM structure in app side and send it to Edge, no extra config/mapping needed.

2) use your usual context data style, and do mapping in Data Stream

Actually there's a 3rd approach, and it's useful if you are upgrading your app and want to keep the leagcy trackAction/State API calls, by using the Edge Bridge extension. In this way, you still need processing rules to handle the context data like before.

Hope it helps,

Thanks,

John

[BertBru]

Hi John, 

Yes this helps a lot.

You asked:

"For your first example that shows up in reporting, is there any reason why you need to map the same field (_experience.analytics.customDimensions.props.prop36) to itself?"

I was surprised I had to map it. it doesn't work unless I do. This might be because I didnt send the proper web.interaction or webpagedetails information below. Maybe the data got dropped. Im gathering information to send another test event soon. Maybe for the next round, mapping won't be needed for this

With that being said, I will refine our code requirement to test your option 1 again.

Option 2 is intriguing!

I think it's what we're looking for. How is it structured? and where does it live in the xdm structure? Could it be anything custom or does it need to be something specific like: _experience.analytics.contextData

or simply

_contextData?

Does it relate to this field?

Is this the sort of mapping you're referring to?

_experience.analytics.contextData.customValue 

• mapped to
• _experience.analytics.customDimensions.props.prop36

The 3rd approach

Is nice but we're implementing from scratch and arent using track action and track state. We can go this route if the above fails but prefer to use Edge in case we end up using more than just Adobe Analytics

[John_Man]

@BertBru 

For Option 2, I think you can just place the context data in the top level of your payload.

[BertBru]

ok. i will try that!