Seeking Expert Insights: WebSDK Migration Strategy (Schema, FPID, Media Analytics, App vs. Web)

[nitesh__anwani]

Hello Experts,

I am working on initiating the migration of our AppMeasurement implementation to the WebSDK for Web and (AEP Solution specific SDK to the AEP Edge SDK for App) products in my company.

Our product is a content site where the editorial team publishes news and educational articles. Registered users consume this content across both web and app platforms. Additionally, we operate multiple affiliate sites with similar offerings but targeting different user groups geographically.

Current (Legacy) Implementation 

• We do not track Adobe Analytics variables (eVars or props) directly. Instead, we always use context variables across web, app, and affiliate applications.

• This approach allows developers and QA teams to easily interpret the named context variables during implementation and testing.

• It also gives data architects full control over managing the mapping of context variables to the appropriate Adobe Analytics variables.

• The same set of context variables is tracked across both web and app, differentiated only by a prefix to simplify rule handling.

• The current implementation is same for web and app

Planned Migration to WebSDK

We plan to migrate from AppMeasurement to WebSDK to leverage the following benefits:

• Edge Network

• First-Party ID (FPID) support

• Alignment with Adobe’s long-term data collection strategy

• Lighter and faster libraries

• A single network call for Adobe applications (though in our case, this was already true with AppMeasurement because we only use the Adobe Analytics)

Currently, Adobe Analytics is the only Adobe application we use. There are no immediate plans for CJA or AEP applications, though RT-CDP Connections may be considered in the future for real time event forwarding.

Schema Design Approaches Considered

I explored different approaches for schema design:

1. XDM Object

• Custom Schema: Design a fully custom schema to standardize data collection based on requirements (not limited to Analytics). This is recommended if we plan to expand into AEP applications (e.g., CJA). XDM fields can be mapped to Adobe Analytics variables in the DataStream using "Data prep for data collection". In my view, this acts somewhat like processing rules, although not technically the same.

• Custom Schema + AdobeAnalyticsExperienceEventTemplate: This acts as a wrapper, where the Analytics-specific fields (eVars, props, etc.) are included alongside other data required for AEP.

2. Data Object

• Replicates the AppMeasurement approach by tracking analytics variables directly under data.__adobe.analytics.*.

• This offers an easier migration path with minimal effort while gaining Edge Network and FPID capabilities.

In all three solutions, complete XDM payload is sent to the DataStream is mapped to Analytics variables, with unmapped fields still available as context variables.

My view: For our case, a custom XDM schema without any specific field group related to the analytics variables aligns best with our current practice of using context variables exclusively. The Data Object approach doesn’t feel as clean given our setup, and the AdobeAnalyticsExperienceEventTemplate doesn’t align with our existing implementation.

Question: Is there anything specific I should consider while finalizing the schema design approach?

 

Media Analytics Considerations

I reviewed the documentation for Implementing Media Collection using Edge Network. My understanding is:

• The schema must include the Media Collection Details field group with required fields.

• The Media Analytics service must be enabled under the DataStream.

Question: Are there any recommendations or best practices I should follow for Media Analytics while designing the schema?

FPID Implementation

Currently:

• We do first party domain based tracking using CNAME.

• ECIDs from the demdex domain are also in use.

• For non-Safari users (with third-party cookies enabled), cross-domain tracking is possible with demdex ECID cookie, allowing two different domains in the same report suite to share the same ECID.

With FPID:

• FPID is seeded in ECID generation on the Edge Network, ensuring a longer cookie lifespan by returning the same ECID for users with the same FPID.

• This improves visitor persistence on the same site but sacrifices cross-domain tracking.

Question: Can you confirm if my understanding here is correct?

App WebView Considerations

Today, we pass the ECID into WebViews using appendVisitorInfoForURL.

Once we migrate the web to FPID-based tracking:

• For new users coming from the app into a WebView, will the ECID passed in the URL still be used?

• Or will a new ECID be generated on the webpage using the server-seeded FPID?

Question 2: Are there any specific considerations or best practices we need to apply for App WebViews in this migration?

Mobile App Considerations

Currently:

• We use the same context variables in apps as on the web, with different prefixes and separate processing rules. Conceptually, the approach is consistent.

For migration:

• Moving app context variables into an XDM schema would be a heavy lift for the app team.

• A quick alternative could be to wrap the existing context variables in the Data Object and continue using them as context variables. This would provide parity with web and still leverage Edge Network capabilities.

Question: Is it ideal to maintain the same schema structure across app and web, or is it acceptable to use the Data Object approach for apps as a quicker workaround?

Apologies for the long post, but I wanted to provide full context to get the most accurate insights.
I would highly appreciate any recommendations, best practices, or experiences you can share regarding schema design, Media Analytics, FPID, or app vs. web implementation strategies.

Thanks,

Nitesh

[Jennifer_Dungan]

Hi,

You outlined a lot of great points here.

I will say, we haven't moved to WebSDK ourselves, but we are in the process of moving our mobile app to the newer AEP SDK using Data Streams, and like you, we predominantly use Context Variables on our apps.

We also have no intention at this time to move to CJA... and just like you, it would have been a large undertaking to change our entire mobile strategy to send values into the XDM... one additional factor that we have to deal with is the fact that we don't enforce app upgrades, meaning that I have to ensure full backwards compatibility to older versions of the app still running the old ACP SDK.

Given those challenges, we made the decision to use the Data Object, and maintain our Context Variable mapping using Processing Rules. This seemed like the best solution to prevent re-coding the entire app implementation from scratch and potentially breaking tracking.

In your own implementation, are you using the same Context Variables for Web and App? Also, in your current setup, are you taking the content variables as is, or do you have concatenation rules that need to be factored into consideration?

Since I haven't used the XDM Stream per se, I know that you should be able to map a custom key to your Analytics, what I don't know is if you can concatenate values from multiple keys into a single dimension using logic.

Basically, I can't tell you what is best (as I don't know your implementation, or complexities that might factor in), but these are the types of things I would want to consider and test before making a decision on the approach...

Such as, if the context variables are the same between app and web, maintaining those rules might be easier to ensure consistency in the tracking... if you do choose to keep context variables on your app to ensure your developers don't have to re-write the implementation.

If there are other complications, I would be tempted to set up a completely separate testing suite, and play with the Data Stream mapping, making sure that your isolated tests are working as intended and with all needed logic. This will also give you a sense of future efforts for future tracking needs, to make sure that you are comfortable with what is required.

As for the App to Web passing the ECID, you would still need this... WebSDK will still read the ECID from the query string to maintain user identification:

https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/identity/id-sharing

Good Luck!

[nitesh__anwani]

Hi @Jennifer_Dungan ,

Thank you for your response.

You raised an excellent point about backward compatibility for users who continue using older versions of the app.

We also avoid forcing updates, as doing so can lead to user drop-off.

Currently in legacy implementation, I maintain two separate sets of variables and rules to process data for the app and the web.

For example:

• Web: context variables web.user_id and web.user_age

• App: context variables app.user_id and app.user_age

These are mapped to analytics variables through separate rules.

From a technical perspective, I could implement a custom schema on the web and, once the implementation is on all page of the sites, switch to a new set of rules to process context variables from the XDM-based schema—allowing me to eventually retire the older rules.

For the app, however, I need to design the data object so that it acts as a wrapper for the existing context variables. This way, the same rules would work for both users on older app versions and those on newer ones.

If I adopt an XDM-based custom schema for the app (similar to the web), I would need to maintain two sets of rules, since data would be collected from both older and newer versions of the app.

Considering all of this, it seems that creating a data object for the app is the quicker win. This approach allows us to leverage Edge-based capabilities without the significant effort required to completely rewrite the app implementation.

Thanks,

 Nitesh