Expand my Community achievements bar.

Help shape the future of AI assistance by participating in this quick card sorting activity. Your input will help create a more effective system that better serves your needs and those of your colleagues.

Tutorial Discussion: Migrate Target from at.js to Web SDK tutorial

Avatar

Employee Advisor

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.

23 Replies

Avatar

Level 2

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?

Avatar

Employee Advisor

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. 



Avatar

Level 2

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?

Avatar

Employee Advisor

I see so you would have:

 

  • Web SDK powering Analytics and Target
  • AppMeasurement powering Analytics 

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.

Avatar

Level 2

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);
}
})();

Avatar

Employee Advisor

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

 

 

Avatar

Level 2

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

 

  1. {events: [{,…}], query: {identity: {fetch: ["ECID"]}},…}
    1. events: [{,…}]
      1. 0: {,…}
        1. data: {__adobe: {target: "Data definition specified does not exist on the page"}}
          1. __adobe: {target: "Data definition specified does not exist on the page"}
            1. target: "Data definition specified does not exist on the page"

Avatar

Employee Advisor

Can you tell me which page and exercise of the tutorial you are on?

Avatar

Level 1

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

 

https://experienceleague.adobe.com/docs/platform-learn/migrate-target-to-websdk/debugging.html?lang=...

Avatar

Level 1

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. 

Avatar

Level 2

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

Avatar

Level 2

@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

Avatar

Employee Advisor

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?

Avatar

Level 2

Two calls- We have a page top (AEP Web SDK, sendEvent) rule and a page bottom (Core, Custom Code, sendEvent) rule.

 

Tom

Avatar

Employee Advisor

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.

 

https://experienceleague.adobe.com/en/docs/platform-learn/implement-web-sdk/applications-setup/setup...

Avatar

Level 2

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. 

Avatar

Employee Advisor

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.

Avatar

Employee

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

Avatar

Level 2

I am currently integrating Adobe Target with WebSDK to implement a personalization experiment and have made the following progress:

  1. WebSDK and Target Extension Setup: Successfully configured WebSDK with the Adobe Target Extension.
  2. Catalog Upload: Uploaded a catalog in Adobe Target using a CSV feed containing product data, including thumbnails, categories, and other relevant details.
  3. Recommendation Models: Built custom and in-built recommendation models to deliver personalized recommendations, specifically a "Recommended for you" feature based on the current item.
  4. Activity Creation and Testing: Created an activity and successfully tested it in a lower environment.

However, we are encountering several challenges where I would appreciate some guidance:

  1. Catalog Corruption: When events are triggered from WebSDK, the catalog is being corrupted. Fields such as thumbnail, name, and value contain empty values, and only the SKU is passed.
  2. Recommendation Rendering Issues: Due to the above catalog issues, the recommendation design displays broken names, links, and images after catalog is corrupted.
  3. Event in WebSDK: With the current WebSDK setup, display events (screenshot attached) are being triggered on the PDP page along with pageViews and productViews. No custom entity attributes are being passed at all but some how catalog gets this and sets it empty, except sku.

I am seeking advice on how to prevent the catalog from being updated with empty values, as I have been unable to locate documentation addressing this issue. Any insights on how to optimize this setup for a production environment would be highly valuable.

For reference, I have consulted the following documentation resources:

Thank you in advance for your assistance.

Avatar

Employee Advisor

I just wanted to let you know I see your message, but I haven't heard other reports of this happening. I see in your screenshots you are using custom scopes. Be aware that you cannot set different params on custom scopes made in the same call. All scopes will include the same params.

Are you sure there is no issues with your feed? Are you able to see some records from your feed that are intact? Are you sure you have escaped the fields in your field that need to be escaped? https://experienceleague.adobe.com/en/docs/target/using/recommendations/entities/feeds