adobe / target-nodejs-sdk-samples

Adobe Target Node.js SDK Samples & Demos
Apache License 2.0
18 stars 43 forks source link

Not prefetching views #25

Open tinavanschelt opened 3 years ago

tinavanschelt commented 3 years ago

Hi,

We’re using the next-server-side-rendering-demo for a pretty large project and this is the first server-side integration within the company. If we use the targetClient.getOffers() call as it is in the demo, the request is not prefetching any views - this is the response we receive:

AT: Response received {
  "status": 200,
  "requestId": "xxx",
  "id": {
    "tntId": "xxx"
  },
  "client": "xxx",
  "edgeHost": "mboxedge35.tt.omtrdc.net",
  "prefetch": {} // empty
}

If we replace the prefetchViewsRequest variable with an older mbox call



execute: {
  mboxes: [
    {
      address: {
        url: requestURL,
      },
      name: mboxName,
    },
  ],
}

the request does return the experiments for that mbox. We've checked the config numerous times and are calling the right properties, etc. We do have A/B tests configured based on URL location, but I suspect this might have to do with how we configure our A/B tests in the AT dashboard, is there anything specific that we need to do to get the experiments to show up when we prefetch views?

Then, what would the best approach be for handling action execution once the views have been fetched? Ideally, we would like to avoid having to hardcode anything into our codebase and handle everything within the dashboard. So if, for example, we wanted to change a button color, we don’t want to have to update the code to handle a flag of sorts, we want that action to fire automatically - is that possible?

Thank you.

XDex commented 3 years ago

@tinavanschelt Thank you for reaching out! Please provide some more context, so we could better understand the issue you're running into:

  1. Do you have any live A/B activites with views currently running? Note, that activities for SPA sites using Target views are distinct from mbox-based ones created in Form VEC UI (legacy "AT dashboard UI"), and should be authored separately in the Visual VEC UI (the "AT dashboard UI" for SPAs), having provisioned at.js 2.x and implemented adobe.target.triggerView() calls in the page beforehand, refer to Target docs for more info
  2. If the answer to the previous question is yes, could you please confirm that besides page URL targeting, there are no other audience constraints present for these activities, which would require passing any additional params in getOffers calls for example?
  3. Please add a trace token to the page URL and attach the trace response returned in getOffers call, see docs

So if, for example, we wanted to change a button color, we don’t want to have to update the code to handle a flag of sorts, we want that action to fire automatically - is that possible?

Yes, that's totally possible and with views it works similarly to mboxes, once you define the views in your SPA by marking them with adobe.target.triggerView(viewName) calls, you can reference those views in any activities created in the Target SPA VEC UI. With server-side rendering and view prefetch on the server-side you can deliver all the prefetched view offer content on first page load and at.js will apply those offers when views are triggered. Note that if you're not using at.js to apply any prefetched offers, you'll need to implement sendNotifications() calls either on the server-side or client-side depending on your use-case (so that prefetched content is counted and reflected properly in Target reports)

tinavanschelt commented 3 years ago

I appreciate the quick response @XDex. We do have a live A/B test configured in the Visual VEC UI, specifically for testing purposes. I’ve checked and there’s no other audience constraints, but looking at the docs I suspect we might have to take another look at how the test is configured. I’m off today, but will take a look tomorrow morning and get back to you ASAP. Thank you.

tinavanschelt commented 3 years ago

Hi @XDex,


I can confirm that we do have live A/B activities running. We’re testing things out by changing the colour of a button, I’ve updated the tests using the VEC. When I enable Target Console Logging in the debugger views register as expected, but instead of changing the background colour of the button - there’s a quick re-render of the page (almost like the call is client-side) and then it just hides the button complete. Unless I do a hard refresh, then the browser prefetches the view and renders the A/B test as expected, but only in Firefox and only when Target Console Logging is activated in the debugger.

We are using at.js and are using adobe.target.triggerView() on all views. In the Target dashboard the Decisioning Method of the test is auto assigned as “On-Device”.



For Target Trace, I have tried with both Chrome and Firefox (fresh token added to the URL, logged into the Adobe Account) and with Chrome I get an ERROR{{errorRetrievingTargetAccessData}} response (as mentioned, I am logged in) and with Firefox (which did work a couple of weeks ago) the tab has completely disappeared. This makes debugging challenging. 

We’ve made some progress since last week, and I’m confident that the views are configured correctly now, but we



Any pointers would be very much appreciated.

XDex commented 3 years ago

@tinavanschelt Thank you for providing additional details. It looks like the issues you're running into are mostly with at.js rendering and not delivery via the Node.JS SDK. From your description it sounds like there may be some kind of race between at.js rendering on triggerView() and some React app or other web component rendering or updating the container DOM elements. Would it be possible for you to share a test URL where the issue is reproducible, so we could troubleshoot it further? cc: @jasonwaters

tinavanschelt commented 3 years ago

Hi @XDex, I have a sent the staging url to you via email. Thanks.