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
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Migrating legacy AAM to WEBSDK with launch

Avatar

Level 1

What is impact of migrating legacy AAM to WEBSDK with launch on existing Data? What changes we need to do in terms of traits and signals in AAM?

1 Accepted Solution

Avatar

Correct answer by
Employee

The biggest impact to traits is that you have to change the expression criteria to match Web SDK data. I'm going to assume you're currently using Server-side forwarding from Analytics. The big change with Web SDK is that the data goes from Edge directly to AAM without going through Analytics first. As such, your trait expressions will go from looking for props, evars, and events to XDM values. Typically, we would add OR criteria to your existing trait expressions so that if you have pages still using SSF, the traits will still work with Web SDK or SSF data. 

 

I'm not sure how urgent the move is, but there are plans for making the transition/migration from SSF to Web SDK for AAM easier so that you don't have to manually update X number of traits. If you can wait a few quarters, you may find a much faster migration path. I can't commit to timelines on a post like this or even if these initial plans are going to pan out. We just know how big a move it is, and we are planning to make it easier than it is now. 

View solution in original post

2 Replies

Avatar

Correct answer by
Employee

The biggest impact to traits is that you have to change the expression criteria to match Web SDK data. I'm going to assume you're currently using Server-side forwarding from Analytics. The big change with Web SDK is that the data goes from Edge directly to AAM without going through Analytics first. As such, your trait expressions will go from looking for props, evars, and events to XDM values. Typically, we would add OR criteria to your existing trait expressions so that if you have pages still using SSF, the traits will still work with Web SDK or SSF data. 

 

I'm not sure how urgent the move is, but there are plans for making the transition/migration from SSF to Web SDK for AAM easier so that you don't have to manually update X number of traits. If you can wait a few quarters, you may find a much faster migration path. I can't commit to timelines on a post like this or even if these initial plans are going to pan out. We just know how big a move it is, and we are planning to make it easier than it is now. 

Avatar

Level 1

@dhwoolsey We have enabled datastream for audience manager,Can you please help us to understand below questions.

1.What is ideal way to check signals in AAM after migrating to websdk?  

2.While trying to create multiple traits, we are getting error for integration code redundancy.

3.How much time it will take to collect data in AAM after enabling data stream?

4.We need to create new data source for websdk after websdk implementation or we can use the existing one

Avatar

Employee

1. Depending on the amount of data you pass in, the Signal search tool (https://experienceleague.adobe.com/docs/audience-manager/user-guide/features/data-explorer/signals-s...) would be an excellent place to start. Just note it is sampled, so you may not see everything you pass in. That said, if you filter for anything with web.webPageDetails, you would probably find something. If you haven't seen this tutorial yet, I highly recommend it: https://experienceleague.adobe.com/docs/platform-learn/implement-web-sdk/overview.html?lang=en. If you expand the Applications Setup and Audience manager section, you'll see details on how to create a trait for Web SDK data. 

2. You can't use the same integration code for multiple traits, so if you're cloning traits, you'd need to adjust the integration code for each trait. Having said that, I'm not sure why you'd need an integration code for traits like this anyway, so depending on your scenario, I'd question the need even to have an integration code.

3. It's real-time, but like all AAM reports, you won't see the results until the next day when the UI reports update. If you have a cookie-based destination that you use for validation, then that would show the immediate results as well. That said, remember that there's at least an hour wait for settings in the UI to be pushed to the edge. I recommend waiting 4 hours to be sure. 

4. Either. It really depends on how your AAM instance is organized per your business needs. I'd be hard-pressed to offer a hard and fast rule with only this community post as my background of your implementation. By and large, though, data sources are usually classified as things like websites, mobile apps, or onboarded data. How the data is passed (Analytics or Web SDK) is less important.  then where the data comes from. So unless you have a compelling reason to switch data sources (again, my background is limited), I'd think you'd just want to keep the same one.