Using both Analytics Extension and AEP Web SDK together

[hs_vk]

Hi,

I have a theory that I would like to understand if its right before actually trying it out

My website has Analytics Extension implemented which uses an old datalayer  say digitalData object & sends data to old report suites

Plan is to add a new datalayer say dData object to the website & use Web SDK to send data to new report suite.

But I need to do a transition where for a specific period, I am looking to have Analytics extension in the tags property sending data to old report suites, while I implement Web SDK & create new data elements & rules for it to send data from new datalayer to new report suites through Edge Network.

As I don't want to switch off the old implementation abruptly & only have a new implementation running on the site.

Is that even possible? Can one tag property have 2 of these extensions (Analytics Ext & Web SDK Ext) that send data to completely different report suites?

To enable below flows -

Tag Property A-> digitalData (old datalayer) -> AA Ext ->Report Suite A

Tag Property A-> dData (new datalayer) -> Web SDK Ext ->Report Suite B

Will this lead to inflated server calls?

Later on I need to disable AA extension & its rules & data elements so it doesn't affect the performance of the website & to reduce server calls by having data being sent to only one report suite

What are some possible conflicts that I need to be mindful of? If above theory cannot be implemented, what could be some alternate workarounds?

[Haran_Huang]

You can use Analytics Extension and AEP Web SDK at the same time, of course, this will cause your server call to double.

[leocwlau]

Hi @hs_vk ,

For sure you can do that and it is very logical if you have lots of tracking to be migrated for a large site. Moreover, you also need to plan for the cutover of individual tracking from the old datalayer to the new datalayer, as it will double your server call as you suspected and mentioned by @Haran_Huang .

So at the end of migration, there should be nothing being pushed into the old datalayer and you are safe to remove any Launch elements related to the old datalayer.

[hs_vk]

Thanks both.

Agree with the inflated server calls & cutover planning.

However are there any conflicts that need to be managed or planned for and will the above configuration work with both Mobile & Web SDK?

For example: the Analytics extension needs a separate extension for ECID service whereas when implementing Web SDK its recommended to remove the extension & migrate the ECID service.

In that case, when we're having both AA extension & Web SDK in the same launch property - do we keep the ECID extension or not? How would that work with both solutions? (keep in mind data from both extensions is being sent to different report suites)

Also are there any other similar conflicts to be managed?

[leocwlau · Accepted solution]

For the ECID extension in particular, there will be no conflict with WebSDK and you still need it for the AA extension until you finished migration. Just to make sure you have the default enabled selection for the "Migrate ECID from VisitorAPI to the web SDK" so you can maintain the same ECID to identify the unique visitor properly.

[ishanchopra]

Hi @leocwlau, Thank you for providing the response.

However, as per my use-case I wanted to check is there a way we can bypass the additional server call to old report suite that has older datalayer implemented and only data should be sent to new report suite where the new datalayer implemented to avoid inflating the server calls.

[leocwlau]

Nothing comes automatically, assuming you have different sets of rules in the same Launch property for WebSDK and AA extension, you need to disable rules sending data to the old report suite using AA extension to stop inflated server calls and cost.