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

[Meghan_Powers]

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!

[yuhuisg · Accepted solution]

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]

Great idea, thanks, we will check!

[Meghan_Powers]

Hello!  We checked into this and determined that we are setting ECID in both SDK and non-SDK pages and that they are the same ECID as a customer moves across those pages or lands on them.  Given that, do you think anything about ECID's would be the cause of the Internal URL issue we're still seeing when we migrate over a page into SDK?  Or do you think it's something else?

Open to any suggestions anyone has!

[yuhuisg]

IIRC I too experienced a jump in Internal URLs when migrating to Web SDK. I never really figured out why that was the case. But it eventually "sorted itself out" after a month or 2.

[Meghan_Powers]

Thanks for the reply - based on the graph I just pulled, it looks like it's come down from its initial crazy spike right after launching SDK, but still not back down to pre-SDK volumes yet (and it's been 9 months)...