AA extension to Web SDK extension - testing issue | Community
Skip to main content
M
mmasonWD
Level 3
March 7, 2025
Solved

AA extension to Web SDK extension - testing issue

  • March 7, 2025
  • 1 reply
  • 1096 views

We are in the process of switching from the AA extension to the Web SDK extension. The Web SDK extension was created as a new tag (for testing purposes). The issue we are facing is migrating this tag with Web SDK, into our Production instance. Testing has been verified and validated in Staging, but what we had hoped to do was include the new tag along with our old AA extension tag in Production for a certain time frame. The reason for this is to cross reference the two tag's analytics to make sure everything is actually identical with live data. But I have read that duplicate adobe tagging is not possible. Is this true? 

 

If this is not possible, are there any suggestions on final migration to Production, before all web sdk extension changes are made to the old tag? This is entirely new to our team, and while we understand the importance of testing and validation in Stage, it's hard to get an exact representation of the data in a Staging instance versus Production, for Analytics purposes.  

Best answer by Jennifer_Dungan

@jennifer_dungan ,
Can you please describe the solution you talked about today on Champs office hours call here?


Absolutely,

 

Adobe does support multi-suite (different profile) tracking... I did this way back in the days before Launch was even a thing... we had to have different AppMeasurement (or was it s_code at the time) files, that made an alternate s object... so one suite used the standard "s" object, and the second suite used the alternate "s2" object. This was done on a white label site where we needed to track our data the way we needed, and the company who was using the white label needed their data their way.

 

I know that Launch does have a way to set this up with two traditional AppMeasurement tracking... but your situation should be easier....

 

Since you are using AppMeasurement and WebSDK, two fundamentally different code bases, there shouldn't be interference.. WebSDK doesn't use the s object.

 

Now, to start, you obviously don't want to send the data to the same suite... if the intention is start with a completely fresh suite, and forgo your history, then setting up a new suite is fine... or maybe you want to keep your history... so you have two immediate options:

  • use an alternate suite for WebSDK until you feel confident to make the full switch and keep AppMeasurement as it is (making the full switch later)
  • Or you switch your main suite to WebSDK, and keep AppMeasurement as a temp backup

 

Whichever way you choose, you should be able to configure this in Launch (and make sure you have an easy rollback if you are switching your AppMeasurement)

 

The next consideration is the increased server calls, as you will be doubling them for the duration of this setup... make sure that your projected server calls can take the extra load, and for how long... or that you accept the risk of overage charges at the end of your contract.

 

So, while I haven't done this, I do know that AppMeasurement and WebSDK are very different code bases... so they shouldn't conflict. For each trigger, you should be able to add an additional WebSDK action to send data via WebSDK (or you can create all new rules with the same triggers, but this seems like a lot of extra effort depending on the number of rules you have... and making sure you duplicate every rule... )

 

If you need to ensure the same ECID is used, then you will probably have to use idMigrationEnabled.. this is more for transitioning parts of sites, but the same principal applies... make sure the ECID is set as a client side cookie so that both implementations can stitch on the same ID.

 

https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/configure/idmigrationenabled?lang=en

 

 

This will of course require a lot of testing in Dev, QA or Staging, to make sure that everything is working as expected... but that should be more related to your setup then to the two code bases themselves.

1 reply

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
March 8, 2025

Well I would not say it's impossible. You could configure a test report suite (clone the current prod one) in your datastream and send the data side by side.

 

What I am not 100% sure about is how cookies will be handled. In theory I would say it's ok.

 

but better have a look at some more docs on this about possible pitfalls.

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-platform-blogs/ecid-migration-with-aep-web-sdk/ba-p/423234

 

Cheers from Switzerland!
    M
    mmasonWDAuthor
    Level 3
    March 11, 2025

    Thanks for the responses. I had also performed just about all of Meghan Powers recommendations prior as well. Can you see any downsides or definite no's to my potential migration solution:

     

    We have our main tag configured in Launch - "Main Site" tag. The report suite points to main.site.prod.

    I configured a brand new tag for Web SDK extension testing and configuration - "Web SDK test" tag. The report suite points to test.site.prod.

     

    Originally I had thought I would need to create the Web SDK test tag, then migrate and move all new rule configurations to the 

    Main Site tag. But now I am wondering if I can just use this new Web SDK test tag as my main tag, and just change the datastream from test.site.prod to the main.site.prod?

     

    I hope this makes sense. Can you foresee any major issues with taking this route?

     

    M
    mmasonWDAuthor
    Level 3
    March 12, 2025

    Absolutely,

     

    Adobe does support multi-suite (different profile) tracking... I did this way back in the days before Launch was even a thing... we had to have different AppMeasurement (or was it s_code at the time) files, that made an alternate s object... so one suite used the standard "s" object, and the second suite used the alternate "s2" object. This was done on a white label site where we needed to track our data the way we needed, and the company who was using the white label needed their data their way.

     

    I know that Launch does have a way to set this up with two traditional AppMeasurement tracking... but your situation should be easier....

     

    Since you are using AppMeasurement and WebSDK, two fundamentally different code bases, there shouldn't be interference.. WebSDK doesn't use the s object.

     

    Now, to start, you obviously don't want to send the data to the same suite... if the intention is start with a completely fresh suite, and forgo your history, then setting up a new suite is fine... or maybe you want to keep your history... so you have two immediate options:

    • use an alternate suite for WebSDK until you feel confident to make the full switch and keep AppMeasurement as it is (making the full switch later)
    • Or you switch your main suite to WebSDK, and keep AppMeasurement as a temp backup

     

    Whichever way you choose, you should be able to configure this in Launch (and make sure you have an easy rollback if you are switching your AppMeasurement)

     

    The next consideration is the increased server calls, as you will be doubling them for the duration of this setup... make sure that your projected server calls can take the extra load, and for how long... or that you accept the risk of overage charges at the end of your contract.

     

    So, while I haven't done this, I do know that AppMeasurement and WebSDK are very different code bases... so they shouldn't conflict. For each trigger, you should be able to add an additional WebSDK action to send data via WebSDK (or you can create all new rules with the same triggers, but this seems like a lot of extra effort depending on the number of rules you have... and making sure you duplicate every rule... )

     

    If you need to ensure the same ECID is used, then you will probably have to use idMigrationEnabled.. this is more for transitioning parts of sites, but the same principal applies... make sure the ECID is set as a client side cookie so that both implementations can stitch on the same ID.

     

    https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/configure/idmigrationenabled?lang=en

     

     

    This will of course require a lot of testing in Dev, QA or Staging, to make sure that everything is working as expected... but that should be more related to your setup then to the two code bases themselves.


    Thank you for the explanation here. I was under the impression from some of the documentation that I initially read, that you couldn't or shouldn't have the AA extension and Wed SDK extension published and active at the same time. 

     

    I had already configured a new tag and report suite for testing of this extension. So now I just need to install the web sdk extension in our current tag and migrate the accommodated changes over. 

      Terms & ConditionsAccessibility statement

      Loading footer...