Web SDK - Internal URL's and query string param testing in workspace | Community
Skip to main content
Meghan_Powers
Community Advisor and Adobe Champion
Meghan_PowersCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
January 24, 2023
Solved

Web SDK - Internal URL's and query string param testing in workspace

  • January 24, 2023
  • 1 reply
  • 1912 views

has anyone else implemented the SDK?
If so, two questions:
We are implementing it microsite by microsite (for example, there are 10 microsites on carmax.com).  After each implementation, we see a big jump in 'Internal URL's' just to that microsite that went live in the SDK.   Adobe has confirmed all our Marketing Channel settings are correct and say that the increase in Internal URL's is because the other microsites on carmax.com are NOT in SDK yet.  Has anyone else experience the same problem and are there any workarounds?
Often when we do QA, we not only check that variables and events are showing up in debugger/dev tools, but also add a query string parameter to our dev environement and then check events in workspace against that query string param (like carmax.com?adcode=Meghantest.  Our issue is that method works fine on pages NOT in the SDK, but once a page is IN the SDK, that method is no longer reliable and we don't see our adcodes showing up in workspace with our events.  Has anyone else experience the same problem and are there any workarounds?

Thanks for any help!

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 yuhuisg

Adobe relies on the Experience Cloud ID Service (ECID) to identify visitors. Do you still have ECID running in your migrated websites?

If you use a straightforward Web SDK implementation, then the ECID is generated by Adobe server-side, and used by Web SDK with all tracking. In your case, that means when the same user Tom goes from microsite A (legacy implementation) to microsite B (Web SDK), he will have one ECID at microsite A and another ECID at microsite B, even though he's really the same person!

Keeping ECID in your migrated websites ensures that the ECID continues to be generated client-side, and Web SDK will use that client-side ECID to identify a visitor, i.e. Tom will still have the same ECID in both microsites A and B.

1 reply

yuhuisg
Community Advisor
yuhuisgCommunity AdvisorAccepted solution
Community Advisor
January 26, 2023

Adobe relies on the Experience Cloud ID Service (ECID) to identify visitors. Do you still have ECID running in your migrated websites?

If you use a straightforward Web SDK implementation, then the ECID is generated by Adobe server-side, and used by Web SDK with all tracking. In your case, that means when the same user Tom goes from microsite A (legacy implementation) to microsite B (Web SDK), he will have one ECID at microsite A and another ECID at microsite B, even though he's really the same person!

Keeping ECID in your migrated websites ensures that the ECID continues to be generated client-side, and Web SDK will use that client-side ECID to identify a visitor, i.e. Tom will still have the same ECID in both microsites A and B.

    Meghan_Powers
    Community Advisor and Adobe Champion
    Meghan_PowersCommunity Advisor and Adobe ChampionAuthor
    Community Advisor and Adobe Champion
    January 26, 2023

    Great idea, thanks, we will check!

     

    Terms & ConditionsAccessibility statement

    Loading footer...