Profile Scripts Behave Differently in WebSDK

[MktgCloudUser]

Hello,

We are switching to WebSDK and notice many of our Target campaigns which use Profile Scripts do not behave as previously did under at.js.  Take for example this script we use for abandoned cart;

if (mbox.param('pageURL').indexOf('/user/checkout.html') > -1 ) {
return true;
} else if (mbox.param('pageURL').indexOf('thank-you.html') > -1) {
return false;
}

In the WebSDK, the "true" value is returned only when the visitor is on the checkout.html page; False is returned on any other page which means the profile script value isn't being saved.

Is this a known issue or is there some sort of workaround?

[alexbishop]

There is an article here that explains a bit around profile script compatibility between at.js & Web SDK.

But essentially that mbox.param('pageURL') approach won't work with Web SDK, you would need to change it to page.url instead. e.g.

if (page.url).indexOf('/user/checkout.html') > -1 ) {
return true;
} else if (page.url).indexOf('thank-you.html') > -1) {
return false;
}

[MktgCloudUser]

Thanks, still doesn't work across pages; the Profile Script value is only returned on the page in which it was set.  Here's how anyone can test it.

1. Create a monitoring campaign that doesn't do anything but push a console log.  This is so we can see the response tokens (which the profile script is a part) even if we don't qualify for the "real" campaign.
2. Create a new activity that does a simple JavaScript alert('in campaign") if you qualify for the activity.
3. Ensure "Migrate Target from at.js to Web SDK" is checked in Launch.

What happens is the alert only fires on the checkout page when it should fire on every single page except for thank-you.html.  If you look at the Response Tokens, it shows there's no weRetailCheckout flag on any page except for checkout.

As you can see, the Profile Script is not being persisted across pages.  This same profile script works just fine under at.js.

Potential Bigger Issue

The Target Profile ID seems to be changing every page - see the section highlighted in Blue.  Could be the Profile Scripts are working just fine but something between the WebSDK and Target is causing the Profile ID to change - which means the script can't "find" the current user.

Is anyone else seeing this?

[alexbishop]

If the tntId isn't persisting then it's certainly a broader implementation issue, not an issue with profile scripts per se. I can also see that the marketingCloudVisitorId is different in the screenshot. Is the checkout page on a different sub-domain/domain vs the other pages?

[MktgCloudUser · Accepted solution]

Yes, domains are the same; it was getting a new ECID on every page.

I think I found the issue, using a cname in the WebSDK in Launch is is causing it to get a new ECID each page.  When I reverted back to the default edge.adobedc.net domain, the ECID stopped changing page-to-page and the Profile script returned the value correctly.

To validate, created a brand new Launch property with nothing but the WebSDK and a single Rule to output the Response Tokens to the console.  All other settings being the same, entering our cname generates a new ECID every page, the default domain doesn't.

Note: the one thing that is different is my website is a AEM instance running on localhost.  So the "bug" may be limited to localhost pages, pages without a SSL certificate (the cname is under SSL) or CORS related to the browser running against localhost.

Net, this works correctly under AT.JS (the cname part) - with WebSDK, Activities based on Profile Data failed due to the WebSDK incorrectly generating a new ECID every page in certain instances (localhost pages appearing to be one of them).

[alexbishop]

Glad that you found the root cause - it makes sense that a CNAME implementation wouldn't work on localhost without SSL

[MktgCloudUser]

But the same cname works just fine with at.js. 

But the new ECID every page load seems like a WebSDK bug - using a cname shouldn't cause a new one every page.

[alexbishop]

I agree but I'd suggest raising this with Customer Care because it's not a known issue where Web SDK+CNAME causes this problem