triggerView() function call sending notifications with old parameters after calling getOffers() and applyOffers()

[rickyRodriguez2]

Hello,

Have been struggling with this issue for a few days now and can't seem to get it to work. Here is the problem:

Our website is a SPA - we implement Target through Adobe Launch. I'm trying to set up some activities for cross sells on certain pages. I.e. Target will be used to offer enrollment for certain programs on given page. A user's eligibility for a program can be determined by a local storage value that we send as a custom parameter to target.

When Target initially loads we get the value of this local storage parameter and send it in a page load request. In testing we found a defect where Target was making an offer for a program on the cross sell page even though the user had already enrolled in that program earlier in the session. When the user enrolled earlier in the session the local storage object was updated but it appears as if the latest version of that custom parameter did not make it to Target.

Upon further investigation I found that the 'notifications' being sent by the triggerView() call in Target seemed to be sending an old version of the eligibility parameter.

Below is a layout of the Custom Code setup I am using in Launch in order to call Target for these offers and trigger the view. The launch rule is kicked off by a custom JS event from the application:

1. Get the local storage parameter containing program eligibility

2. Calls adobe.target.getOffers() API, passing the local storage parameter as a custom param

3. Calls adobe.target.applyOffers() API with response from #2 above

4. Calls triggerView() passing the view name of the cross sell page

When I inspect the network tab I can see that the getOffers() call is sucessfully sending the newest parameter and in return I get a prefetch with the views as expected. HOWEVER when I call triggerView() it sends a payload with notifications and that payload has old parameters.

It appears to me that the issue is that getOffers() applyOffers() is not updating the cache and so when I call triggerView() it is sending the older parameters. Any guidance or insight would be super helpful, thanks!

[rickyRodriguez2]

Just in case it helps any others - I have found a workaround / solution to this. Though still seems like it could be a sort of bug.

In Target I only had audiences for when user qualified for an offer. It appears that when you call getOffers() it will only update the prefetch cache if the user QUALIFIES, not if they are DISQUALIFIED. So what was happening is that the user had qualified initially in the session, but when they enrolled and should have been disqualified, the getOffers() call did not update the cache for that particular view.

So what I did to work around this was add an 'All Visitors' audience to my activity, this means that a user that didn't qualify for the actual offer would at least always qualify for All Visitors. In All Visitors I put a simple console log modification that end users should not really ever see. After this update the triggerView() call successfully passed the notification with right parameters. 

[lukep68653732]

Have been struggling with this issue too since moving to at.js v2. Would be good to get some guidance on this.

As you have said, using this method I can only qualify new offers. When using views on an SPA once an offer has been qualified there doesn't seem to be any way to disqualify it.

[Ryan_Roberts_ · Accepted solution]

Hi @rickyRodriguez2,

If I'm following you correctly, you've got a SPA and over the course of a session a visitor might "unqualify" for an offer on a later view of the SPA and you'd like to see that Target no longer shows them the offer they previously had. And you are making the pageload request but also some getOffers() in addition to a triggerView().

Does your getOffers() request, after they've unqualified include prefetch with the updated parameters in it? Here's an example getOffers() in help.

One thing to keep in mind, the triggerView() request will potentially include parameters on it, but they are NOT used for decisioning/qualification by Target. Decisioning on  experiences/offers a visitors sees ONLY happens on a request with a prefetch or an execute in the request body - so normally the pageload or getOffers() requests. Consequently, if a visitor's attributes change from one view to another view in a SPA you need to call a getOffers() with the prefetch including those updated parameters to update the prefetched offers in cache to reflect the new information - assuming it could change the experience they see.

Hope that helps!

[lukep68653732]

Hi @Ryan_Roberts_,

I'm not the original poster, but the setup I have is exactly as per your post and I still face this issue. I have the page load request initially, but because the site is SPA I'm using the below approach for the following page changes. The code is based on the examples in the URL you linked.

adobe.target.getOffers({
    request: {
        prefetch: {
            views: [{
                parameters: parameters
            }]
        }
    }
}).then(function(response){ 
    adobe.target.applyOffers({ 
        response: response 
    });
}).then(function(){ 
    adobe.target.triggerView(viewName);
});

The issue is, say that I have an activity with an audience that requires a parameter to be "true", that has a modification on a certain view. Once I have set it to "true" using getOffers/applyOffers I get the modification being delivered every time you hit that view. Even after the parameter has been set to "false" using the above approach it will always still fire.

This is problematic because say I have an SPA site with a product page, where a productName parameter is set and I'm using that in audiences. If the user navigates to multiple product pages I could end up with a situation where they've qualified for multiple product audiences with no way to remove them if I just want to show one product experience at a time.

If I could get some clarification on this that would be great as I've been trying to find workarounds for this issue for a few years at this point.

[rickyRodriguez2]

Hi all - this is exactly right, same scenario for myself. 

I'll try and illustrate the issue a little further below:

User loads in to the site and a getOffers()/applyOffers() call is made. In this call we get a prefetch response with the views a user qualifies for. For sake of example let's say the user qualified for offers on 2 possible views. So the prefetch in the response contains content for each applicable view. 

"prefetch":{

"views":[

{"name": "view1", .......},

{"name": "view2", .......}

]}

Now let's say that the user goes through the site and does some actions that DISQUALIFIES them for "view2". When they get to the page where "view2" is triggered another getOffers()/applyOffers() call is made, as well as a triggerView() call. The prefetch response from getOffers() now looks something like this:

"prefetch":{

"views":[

{"name": "view1", .......}

]}

With the response above it appears like the cache should be updated to ONLY contain "view1" now. However, the issue is that when I call triggerView() it actually sends prefetch content and parameters from when the user originally qualified for "view2". My theory here is that since "view2" qualified originally, it remains in the cache, even if subsequent getOffers()/applyOffers() calls DO NOT include "view2".

The workaround in my scenario was to add an All Visitors audience to "view2". When I did this the prefetch response will now ALWAYS contain "view2" in its list of views. Since the modification for 'All Visitors' audience in my scenario just writes a simple console log the user doesn't actually get an offer. In other words: I had to disqualify the user by making them qualify for 'All Visitors'.

[Ryan_Roberts_]

Hi @rickyRodriguez2 and @lukep68653732,

Yes, in this is case your implementation seems good, what you are describing is an activity setup issue. I presume you are using an XT activity. Once someone qualifies for an experience in an XT activity they stay in that experience (even if they would no longer qualify for it) unless they qualify for another XT experience. So, adding a default experience for the "disqualified" users would correct that. Ricky's "all visitors" work around does a similar thing.

-R