Use this thread to ask any questions related to the Migrate Target from at.js 2.x to Platform Web SDK tutorial on Experience League. Experts are monitoring this thread to ensure your questions are answered.
Views
Replies
Total Likes
HI @dwright
We have planned to GO Live with WebSDK but also keep AppMeasurement.js active for 3 weeks after WebSDK go Live. The idea was to study if WebSDK and AppMeasurement.js collect the exact same data in 2 separate Analytics reportsuites. And later the plan was to remove appmeasurement.js when we are confident.
But I am aware that AppMeasurement for Analytics & WebSDK for Target will create issues. Its mentioned in this Adobe Article https://experienceleague.adobe.com/docs/platform-learn/migrate-target-to-websdk/plan-migration.html?...
"A mixed implementation of Platform Web SDK for Target and AppMeasurement for Analytics on a particular page is not supported. However, a mixed implementation across different pages is supported, for example Platform Web SDK on page A, and at.js with AppMeasurement on page B."
Does that stop us from going Live? Do we have to disable AppMeasurement before WebSDK GO Live? AppMeasurement and WebSDK set up works fine on our PreLive but the question is will it impact analytics data ingestion, AEP data ingestion or Target activities/operations in Live?
Views
Replies
Total Likes
Hi @Amrish_Popat ,
Thanks for kicking off this discussion!
It sounds like you are planning on running both Web SDK and AppMeasurement.js simultaneously for a period of time so you can compare the two Analytics implementations side by side. That is outside the scope of this Target migration tutorial, but there are other migration materials we are working on which I am very close to. We have other customers using this approach to help ensure a smooth migration of their Analytics implementation, and I think it's a really good idea. It will result in extra Analytics hits, but you can limit this by simply shutting off the Web SDK sendEvents when you have the amount of data you want.
When it comes to migrating Analytics to Web SDK now and Target later, it hasn't been extensively tested. You can do what you want, but Adobe wouldn't be able to help you if you run into issues, hence "not supported". If you use Analytics data for your Target reporting (A4T) this will definitely break. I can tell you from my personal experience as the implementer of Adobe Target on the Experience League docs and tutorials, we are using Web SDK for Analytics and at.js for Adobe Target and I have not experienced any issues. I am not using A4T. Also, the Web SDK Analytics implementation was already in place before Target was implemented, which is slightly different from your scenario.
"Does that stop us from going Live?" You can do what you want, but you will be limited in your support from Adobe if you encounter issues.
"Do we have to disable AppMeasurement before WebSDK GO Live?" There are other customers who have used this approach, so I think you should be fine with this, especially since this is for a limited time and you are using separate report suites.
"Will it impact AEP data ingestion?" You should be careful if you are currently using the Analytics source connector to ingest data from your AppMeasurement report suite into Platform. If you have two Analytics implementations feeding into Platform and compromising your data integrity.
"Will it impact Target activities/operations in Live" It will definitely, impact A4T. The rest, I can't tell you for sure. Again, this is "unsupported" territory.
Views
Replies
Total Likes
Hi @dwright
Thanks a ton for the quick response. Further to this, I wanted to clarify that we would ideally want to keep appmeasurement and websdk for Analytics but only Websdk for target and reading the migration of planning page; it tells me that appmeasurement for analytics and websdk for target won’t work, which isn’t exactly what we want
so just confirming that if websdk is for both AA and AT, and Appmeasurement for a time being parallely won’t impact target activities and A4T?
Views
Replies
Total Likes
I see so you would have:
After the 3 weeks, would the goal be to then remove AppMeasurement?
As far as A4T, I would expect that for any new Target activities set up after both Analytics and Target are both on Web SDK would work, but I would be concerned about Target activities that were set up before the migration. For example, you have two Analytics report suites. I am assuming that the activities were setup using the report suite populated by AppMeasurement. And now you are introducing a new report suite with Web SDK. The reporting would break. I would suggest that you build new versions of the Target activities for the Web SDK implementation.
Views
Replies
Total Likes
Hi @dwright
Yes the plan is to get rid of appmeasurement on the pages in scope from the tag management system after 3 weeks.
On your suggestion about Target activities, would it work if we pointed them to the new report suite(one for WebSDK) on the go live date?
Also another things that not clear to me is about the customizations on the at.js. Do they have to shared with Client care so they can update the WebSDK with the same/like-to-like customizations and send an updated alloy.js to us?
PS: Some of the customizations are as below:
INIT
defaultContentHiddenStyle: "visibility: hidden;",
defaultContentVisibleStyle: "visibility: visible;",
bodyHiddenStyle: "body {opacity: 0 !important}",
bodyHidingEnabled: !1,
deviceIdLifetime: 632448e5,
sessionIdLifetime: 186e4,
selectorsPollingTimeout: 5e3,
visitorApiTimeout: 2e3,
overrideMboxEdgeServer: !0,
overrideMboxEdgeServerTimeout: 186e4,
optoutEnabled: !1,
optinEnabled: !1,
secureOnly: !0,
supplementalDataIdParamTimeout: 30,
authoringScriptUrl: "//cdn.tt.omtrdc.net/cdn/target-vec.js",
urlSizeLimit: 2048,
endpoint: "/rest/v1/delivery",
pageLoadEnabled: "true" === String("true"),
viewsEnabled: !0,
analyticsLogging: "server_side",
serverState: {},
decisioningMethod: "server-side",
legacyBrowserSupport: !1,
allowHighEntropyClientHints: !1
Token event listeners
// Add the adobe target response token event listener
document.addEventListener(adobe.target.event.REQUEST_SUCCEEDED, getEventData);
Funtion to deal with Decibel insights
function getEventData(e) {
// Check to verify all necessary information is present for the integration
if (e.detail && e.detail.responseTokens) {
// Store the token and mbox data
tokens = e.detail.responseTokens;
// Send the response data when Decibel is fully initialized
if (window.hasOwnProperty('decibelInsight')) {
decibelInsight('ready', sendAdobeEvent);
} else {
window['_da_ready'] = sendAdobeEvent;
}
}
// Remove the Adobe listener
document.removeEventListener(adobe.target.event.REQUEST_SUCCEEDED, getEventData);
}
// Send the ATDecibelTokens custom event when decibelInsight is ready
function sendAdobeEvent() {
var adobe_event = new CustomEvent("ATDecibelTokens", {
detail: {
tokens: tokens
}
});
document.dispatchEvent(adobe_event);
}
})();
Views
Replies
Total Likes
"On your suggestion about Target activities, would it work if we pointed them to the new report suite(one for WebSDK) on the go live date? "
No, the reporting would be broken and you would lose continuity for any active tests. So for any activities where the reporting is essential (like test activities), either call a winner or make a copy and restart the test after the migration. For activities where the reporting is less essential (like experience targeting) you might be okay just changing the report suite. If not, make a copy and use the new activity.
"Also another things that not clear to me is about the customizations on the at.js. Do they have to shared with Client care so they can update the WebSDK with the same/like-to-like customizations and send an updated alloy.js to us?"
Client care doesn't make these customizations, this is up to the customer and any consultants they work with. Most of these library settings are covered in these two pages of the tutorial:
https://experienceleague.adobe.com/docs/platform-learn/migrate-target-to-websdk/detailed-comparison....
https://experienceleague.adobe.com/docs/platform-learn/migrate-target-to-websdk/replace-library.html...
You will need to update your DecibelInsights integration for Web SDK. The "Send Event Complete" event might be useful if you are using tags/Launch. If not, this documentation might be helpful: https://experienceleague.adobe.com/docs/experience-platform/edge/fundamentals/tracking-events.html?l...
Views
Replies
Total Likes
Hi @dwright
We implemented the WebSDK on our lower environment but the interact calls get a 207 response instead of 200 and I see the below in the alloy interact logs. hoping you have a quick help for me here
Views
Replies
Total Likes
Can you tell me which page and exercise of the tutorial you are on?
Views
Replies
Total Likes
Hi @dwright
I am at the end of the tutorial trying to debugging why a copy of at.js activity throws above error when trying to make it work on WebSDK
Views
Replies
Total Likes
Just to close the loop @dwright
The issue was due to Target call fired without the data which we tried to fetch from the data layer. The Data layer wasnt ready with the data when the WebSDK call was fired. We then hard coded the data and Target started behaving normally.
HI @dwright ,
we are migrating at.js to websdk, one of the things we utilize mostly is form base component with global scope and utilize js to update content , as per adobe form based compone with scope as _view_ should render automatically with the checkbox as part of your load rule. but this is working for VEC and not for form based any suggestion .
r
Views
Replies
Total Likes
@dwright We migrated our main web property to Web SDK in June '23, and observed an immediate and drastic drop (-87% May vs July; full month pre-sdk vs full month post-sdk) in ootb AA bounces, and increase (+151%) in ootb AA page views. We do have ongoing Adobe Support engagement on this. How do we better limit calls from impacting basic ootb hit-based metrics?
Note- Visits stayed relatively flat (+3% for full month prior to Web SDK go live vs full month after).
Thanks.
Tom
Views
Replies
Total Likes
Hi Tom,
How are you implemented? Do you have a single call per page load that is used for both Target and Analytics? Or do you have two calls per page load, with one at the top used for personalization and one at the bottom for analytics?
Views
Replies
Total Likes
Two calls- We have a page top (AEP Web SDK, sendEvent) rule and a page bottom (Core, Custom Code, sendEvent) rule.
Tom
Views
Replies
Total Likes
Hi Tom,
If this was implemented in June 2023, this would have been before our "guided events" approach to two call implementations come out. Can you adjust your top-of-page and bottom-of-page calls to use it? The first call needs to use the "Request personalization" option and the second call needs to use the "Collect analytics" option.
Views
Replies
Total Likes
Hi @dwright
Had a question related to how can we address A4T reporting while migration. are there any known issues or caveats and will this have any business impact. I did check on the idMigrationEnabled property which will help read the AMCV cookie set by previous adobe experience cloud implementations. Do the customers need to take care of anything else.
Views
Replies
Total Likes
Hi @tarun_jamana8469 ,
Good question. Be sure to check the migration checkbox for Target too, so that the mbox cookie details will transition.
I haven't heard of any specific issues with migrating activities with A4T. Are you going to use a two call or single call implementation of Web SDK? The A4T mechanism is a little different between those options, which is good to be aware of.
Views
Replies
Total Likes
The single call or a two call implementation is not yet finalized with the customer. Can you please help me understand how the A4T differs between these mechanisms
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Like
Replies
Views
Like
Replies