Profile Scripts Behave Differently in WebSDK | Community
Skip to main content
MktgCloudUser
MktgCloudUser
Level 4
October 23, 2023
Solved

Profile Scripts Behave Differently in WebSDK

  • October 23, 2023
  • 1 reply
  • 1636 views

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?

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 MktgCloudUser

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?


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).

1 reply

alexbishop
Adobe Employee
alexbishopAdobe Employee
Adobe Employee
October 26, 2023

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
MktgCloudUserAuthor
Level 4
October 28, 2023

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
Adobe Employee
alexbishopAdobe Employee
Adobe Employee
October 30, 2023

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?

Terms & ConditionsAccessibility statement

Loading footer...