Custom Payload from Mobile for SDK implementation through Edge for Analytics. | Community
Skip to main content
B
BertBru
Level 2
August 4, 2025
Solved

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

  • August 4, 2025
  • 1 reply
  • 735 views

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!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by John_Man

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

 

 

1 reply

John_Man
Community Advisor
John_ManCommunity AdvisorAccepted solution
Community Advisor
August 5, 2025

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

 

 

    B
    BertBruAuthor
    Level 2
    August 5, 2025

    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
    Community Advisor
    John_ManCommunity Advisor
    Community Advisor
    August 5, 2025

    @bertbru 

     

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

    Terms & ConditionsAccessibility statement

    Loading footer...