overwriteCrossDomainMCIDAndAID in Web SDK

[Hey_John]

Hi,

In the past with AppMeasuremnt and ID Service, we can config this overwriteCrossDomainMCIDAndAID option to support app-to-web visitor persistence. But it seems this option is no linger in Web SDK?

Or in Web SDK, the adobe_mc value from the app always overwrite the cookie in the web?

Thanks, John

[fhusain]

In WebSDK, it is done using appendIdentityToUrl. Here's the reference for the same - https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/appendidentitytourl

[Hey_John]

Hi @fhusain ,

Thanks for your reply. We have no issue to create the adobe_mc and the URL. My question is on the "overwriteCrossDomainMCIDAndAID" config, when using AppMeasurement, this is a configurable parameter to control whether the adobe_mc ECID value will overwrite the web site's existing ECID. And it's default value is "false".

Now we are using WebSDK, would like to know if this config parameter is still valid and where to set it?

Thanks,

John

[fhusain]

Hey @Hey_John, I doubt this parameter is still valid in the case of WebSDK, but I'll see what I can find.

[fhusain]

@Hey_John It seems WebSDK doesn't support this function.

One way to do this: If you want to use the identity from the URL, you have to delete the identity cookie manually before the send event call.

The AEP Web SDK extracts the ECID and puts it in the identitymap. It can also be used to overwrite existing ECID or konductor cookies - but if there is already an identity cookie, it takes precedence. So you might need to manually remove the existing cookie before overwriting it. The solution will be a custom one in the case of WebSDK for this functionality.

[Hey_John]

Hi @fhusain 

Thanks again for your prompt reply.

Manually deleting as existing cookie as it takes precedence seems a bit complex, as it's just a config in the past with AppMeasurement.

Anyway, I just tested it in a simple web page with Web SDK, and manually put the adobe_mc parameter in the address bar, I found that the ECID in the existing cookie actually can be over written. Looks like the behavior is to over write existing cookie in Web SDK.

Thanks,

John