We are running into issues where a JSON is undefined in a subsequent page by design.
Suppose a data layer in an SPA:
Page 1: digitalData.abc returns "label X"
Page 2: digitalData.abc returns undefined
The data element (DE) that maps to it would:
Page 1: DE returns "label X" !
Page 2: DE returns "label X"
What's the best way, if it's possible, to make the DE return undefined in page 2?
I tried converting the DE to custom code (below). Doesn't work.
if(digitalData.abc == undefined){
return undefined;
}
else {
return digitalData.abc;
}
Any advice?
Solved! Go to Solution.
I've been told this change is actually going into production tomorrow!
Since you are using a SPA framework, the duration of the data element likely isn't getting reset even when you've set it to "page view".
You'll likely need to either reset the value of the data element after firing the beacon, or you'll need to apply the logic to conditionally set the data element before each beacon.
It looks like you've attempted the later in the code you've provided. Can you tell me what about that code doesn't work? For example, does the first value set always persist to the second beacon?
Alternatively, could you provide a URL where we could test?
Cheers,
Jantzen
Views
Replies
Total Likes
Thanks for replying Jantzen. Unfortunately our test servers are in an internal environment.
I am not sure why the code doesn't work. To test it, I called _satellite.setVar('DE abc') first in a page where digitalData.abc has a value. I then navigated to a page where digitalData.abc is not populated and called _satellite.setVar('DE abc'). The return result was still the value of digitalData.abc. I then navigated to another page where digitalData.abc has a different value (say value B), called _satellite.setVar('DE abc'), then called _satellite.getVar('DE abc') and received Value B.
'DE abc' is configured via the code above.
What is the recommended practice when it comes to data elements in SPA? Am thinking of explicitly clearing all DEs in our page load rule, but that introduces a point of failure because all future DEs will have to be explicitly cleared. Another concern is the potential extra CPU time as opposed to just assigning variables directly to the data layer via code. That's unfortunate because we really want to use Launch's set variables UI to keep things clean and non-coder friendly.
Views
Replies
Total Likes
After speaking with one of our engineers about this, I found out the following:
Launch is designed to always retrieve a data element's value from its source every time the data element is used. If the value it retrieves is null or undefined, only then will it fall back to the "stored" value.
I believe this explains the behavior your seeing. I'm still working to see if there is a way to disable the fall back behavior or another work around that might help you accomplish what you are seeking.
Views
Replies
Total Likes
just fix up your JavaScript a bit
if(typeof digitalData.abc === 'undefined' ){ // note:undefined is now a string value for the conditional
return undefined;
}
else {
return digitalData.abc;
}
Views
Replies
Total Likes
aseelund, tried but still doesn't work.
Views
Replies
Total Likes
After speaking with our team, there is not a way to disable the fall back to the stored value. We've created a feature request for this change but I don't have an ETA on when it might be available.
I'm sure what you're asking could be accomplished via some custom javascript, but there isn't anything built into the UI to accomplish you're looking for as of today.
Views
Replies
Total Likes
Thanks Jantzen. Not a big deal since we can just assign digitalData directly to props/evars. Thanks again.
I've been told this change is actually going into production tomorrow!
That's awesome, thanks!
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies