Adobe Target

markusb54298925 · 2/3/21

Description -

We have a SPA (single page application/asynchronous) webshop, where Launch is loaded only once on the first page. With the debugger I can see, that Target parameters set with "add params to page load request" are still there when going to next page (which is a asynchronous load). e.g. parameters for a product (detail page) are send again on next page even when it is another page type. This could break things.

Why is this feature important to you -
As I said in description, Target parameters set on one page are send on the next page even if this does not make sense. The option "don't send if empty value" does not work.

How would you like the feature to work -
The Target extension v1 and v2 should get a "clear variables" Option/Rule just as the Analytics extension have. Or the option "don't send if empty value" has to check if the Launch parameter has changed.

Current Behavior -

Tremendous parameters are send with Target v2 on our SPA. Adobe support told me to put it here in ideas. Please vote for it if have or plan to get a Single Page Application with Target.

josejr19 · 2/3/21

@markusb54298925 If the issue is that as the user navigates between routes/views on the SPA, then I would recommend that you implement a custom js event that is fired as the user switches routes/views. In Launch you would listen for this custom event, then reseting the parameters, then firing Target. Right now I am assuming your issue is because targetPageParams is not being reset by a normal page load when switching view/routes in the SPA.

markusb54298925 · 2/3/21

@josejr19 : we do all have that (SPA changes browser history with new URL, so you can always load any URL at any time as entry page).

"then resetting the parameters" is just not working with Target/launch extension, because it seems that parameters are stored internally. Because Launch/Target extension is not loaded every time (just as you wohl have a full page load for each URL, this is cascading.

It is the same with Analytics: If you do not use "clearVars" and send Analytics pixel in an SPA context all eVars/props will be sent again (which might be ok in some scenarios). But Analytics offers that "clearVars" method which is missing in Target.

josejr19 · 2/3/21

@markusb54298925 What are you doing to try to clear the values or change them? While I get there is nothing out of the box, you can just reset targetPageParams by overwriting it, this object always gets picked up when you call Target global mbox or custom mbox.

Here is how I have set it up real quickly to show what I mean.

1. In Launch, I have a rule that is fired off a custom event, I am calling it "targetReset".

Screen Shot 2021-02-03 at 10.02.12 AM.png

2. For the same Launch rule, I have two items for thee Action section.

Screen Shot 2021-02-03 at 9.57.35 AM.png

3. Lets look at Reset Params... I am overwriting the targetPageParams function. I also have it set to execute globally. The main focus here are lines 23-27, the other logic is something I needed for my environment. This is it for Launch.

Screen Shot 2021-02-03 at 9.59.38 AM.png

4. Lets test it out... In the screenshot below I first call targetPageParams to see what the object has, notice that A: 1 and B: 2, then I create my js event and fire it... Then I call targetPageParams to see what the object has, notice that A: 5 and B: 6 now.

Screen Shot 2021-02-03 at 9.56.27 AM.png

5. And just to make sure the right data was actually set to Target, here are the payloads for each call.

Screen Shot 2021-02-03 at 10.00.55 AM.png

Screen Shot 2021-02-03 at 10.01.05 AM.png

Hopefully this helps.

markusb54298925 · 2/3/21

@josejr19 : interesting approach... but that would need a complete Launch redesign on my side, because I do not use the "targetPageParams":

So I've just entered (after page loading)

function targetPageParams(){ return {}; }

in the console and go to the next page, all my parameters are still there. It seems that there is a difference in using the "targetPageParams" function or the dedicated launch extension...

josejr19 · 2/3/21

@markusb54298925 Makes sense why you would be concerned making the switch. I decided to take a look at using the OOB option and I am getting the same end results as using targetPageParams. I inspected the Launch module for setting the page params and verified that it is working as intended as well. Below is a screenshot of my AEP debugger where I have three mboxes fired and in each the "c" value is changed in each call. I am wondering, are you able to confirm that you are using "Add Params to Page Load Request" which uses the"addPageLoadParams" module and and not "Add Params to All Requests" which uses the "addParams" module? They are treated different by Launch at execution. Look directly at the action and see what configuration you are using, the labels might be misleading if you are looking at the rule versus the individual action.

Screen Shot 2021-02-03 at 11.17.59 AM.png

markusb54298925 · 2/4/21

@josejr19 : Thank you very much for your effort! But it is really complex on our side, because of Target Premium and Recommendations. I really would have a lot of work to rewrite and to be honest I really would expect that an enterprise tool should be aware of those issues and therefore there should be a solution inside Launch (just as the "clearVariables" for Analytics).

If you don't mind, come in and visit "www.fressnapf.de". If you would also register in the shop (pet profiles etc) and surf a bit around with the debugger you might see the complexity.

josejr19 · 2/4/21

@markusb54298925 I was able to investigate this better after I got the URL. What I observed is that when I go to a product page I get the entity values along with other parameters. Then when I go back or to another page without the same parameters, that the adobe target still has these persisting parameter values. So if that is the issue I have a solid understanding now of what is going on.

I then thought through some possible options. I tested these both by using developer tools to intercept the Launch script on your site with a local one, when I say below I created a rule, I mean I coded it in the cloned Launch script on my local.

Option1 - Create a separate rule and have it execute only on pages where pageData.page.pageType == product, I called in AT - Product page. Updated the existing rule(non-product page) to execute only when pageData.page.pageType != product. I observed on product pages the correct rule(product page) executing with the expected Target parameters. I then navigated away from a product page to a category page. The non-product page Adobe Target rule fired, and still the parameters from the product page persisted and were sent in. This is a gap/defect in my mind.

Option 2 - I cleared the launch script I had before and started with a fresh copy of the current one. I updated the current condition that looks for a bot detection flag and added additional if else statement. I am referencing it below. As you can see I am using targetPageParams to set the product entity data when on a product pageType, and when not I clear this information and start fresh. The other parameters are still being set via the out of the box Launch option. This is what I originally recommended and while it works well, I believe I better understand now why this would be more work for the team because we don't always have these values so you would have to create logic to check for different page types possibly.

if(pageData.page.pageType == "product"){
    _satellite.logger.log('AT: Product Page');
    targetPageParams = function() { 
        return { 
            "entity.id" : _satellite.getVar('productIdCurrent'),
            "entity.name": _satellite.getVar('target_pname'),
            "entity.brand": _satellite.getVar('target_pbrand'),
            "entity.catLevel1": _satellite.getVar('productCat1'),
            "entity.catLevel2": _satellite.getVar('productCat2'),
            "entity.catLevel3": _satellite.getVar('productCat3')
        }; 
      };  
  return true;
}
targetPageParams = function() { 
    return {
    }; 
  };  
return true;
}

My Recommendation -

I think option 2 is a possible option still in the interim while Adobe can prioritize a new feature. It might require some work right now but it can close the gap with your current issue which is impacting the recommendation engines understanding of what is actually being viewed and conversion. I would follow up with client care, post this issue as well in the the AEP - Launch community room and I would also open an issue in the github project for Launch, it looks like it is monitored, link below.

https://github.com/AdobeDocs/launch.en

Hope this helps!

markusb54298925 · 2/5/21

@josejr19 : Thank you very much! I've thought of "Option 2" already as you gave the hints in your previous comments.

Also we had a Target Audit presentation today (with Adobe Pro Services) where I pointed out this issue.

I have to test it within the next weeks, because of some other projects. I'll let you know (here in the comments) as soon as I have news on this topic.

josejr19 · 2/5/21

@markusb54298925 ok sounds good, let me know if you run into any issues. Best of luck!

markusb54298925 · 2/9/21

@josejr19 : as always when it is urgent, I've adjusted our Target rule from using the "Launch Target Rules" to simply custom code the last two days.

We have tested it and therefore it is live now: Because I've setup all the parameters regarding the pagetype, the setup for "targetPageParams" function was quite easy.

Now we have the "behavior" as it were a "regular website" and we are able to send only those parameters that make sense in terms of page context.

So thank you very much again for supporting!

Adobe Target

Reset page parameters (Launch, SPA website)

Learn

Documentation

Community

Support

Resources

Adobe account

Adobe