Web SDK implementation - separating the Adobe Target and Analytics calls

[Franc_G]

hi all, I want to dispatch a call to the Adobe Target with all the relevant parameters (at the moment I am only interested in pageName, but would like to expand to entity.id etc.) as soon as alloy library is ready (window.alloy is ready). 

I have tried the following:

1. to set up a separate tag with the "eventType": "decisioning.propositionDisplay" and add pageName as xdm.web.webPageDetails.name - doesn't work!
2. to set up a separate tag with the "eventType": "decisioning.propositionDisplay" and add pageName to the data obj - doesn't work either!

It seems like its not possible to separate AT and analytics calls at the moment. My main concern is that at some point (when we add more variables and some "extra" dependencies pop up) the analytics calls will become too heavy and will impact the AT performance. Please a advise. 

[bjoern__koth]

Hi @Franc_G 

I think we had this before in the blog?

The WebSDK extension has a new feature called "Guided Events" which essentially is removes certain fields from the XDM that caused e.g., unwanted page views to fire when web.webPageDetails.name was set. So, that field can be set but will be removed from the call.

In your case, are you sure sending "data" on the same level as "xdm" does not work? This more or less the equivalent of context data in Adobe Analytics. A free form data object that should be accessible also from target. Target also has a dedicated section inside of "data" called "__adobe.target" where you can pass in target-relevant information for recommendations etc.

{
    xdm: {
      // ...  
    },
    data: {
        // reserved for Adobe products
        "__adobe": {
            "target": {
                "entity.name": products[0].name,
            }
        },
        // some other free form data
        pageName: "fooBar"
    }
}

Maybe this documentation helps: https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/personalization/adobe-target/... 

[Franc_G]

@bjoern__koth apologies for the lack of context - we are not using Launch, we are using Ensighten TMS. So, I will need to implement "Guided event(s)" manually. I just noticed that I was using the wrong event type

eventType: "decisioning.propositionDisplay"

instead of

eventType: "decisioning.propositionFetch"

Will do more testing. 

[Franc_G]

@bjoern__koth my set up works fine with the 

eventType: "decisioning.propositionFetch"

type of events. No duplicate pageviews observed. Putting attributes into the data obj doesn't work for AT.

[WestonNorwood]

@Franc_G and @bjoern__koth , thank you for your comments here and on the "Web SDK Part 4: Avoiding Banana Peels (and other things that can trip you up!)" blog post! 
We are facing similar issues as we migrate our Target implementation to the Web SDK; specifically, our legacy implementation includes getOffer() and getOffers() calls from multiple teams at our org, so we created a wrapper to transform these into alloy calls. 

Initially, this dramatically increased page view events, but your note about specifying the event type was helpful in resolving that. (Thank you!) The remaining issue we are facing is that in Assurance, we can see that all of these calls still have an analytics hit associated with them. The "Banana Peel" blog post, indicates this is unavoidable, and I'm wondering if you have found a way around this side effect, or if you can confirm these "analytics hits" have counted towards your analytics hit allowance. Thanks for your insight!

[bjoern__koth]

Well, so I think this is what the new "guided events" should solve i.e., they should remove certain fields from the request payload to make sure analytics is not interpreting them. Which fields exactly are affected I honestly cannot say.

But maybe this is interesting: https://experienceleague.adobe.com/en/docs/analytics/implementation/aep-edge/overview

Only question is if Target will actually still like it / work if you drop all of this web-related data.

[Franc_G]

@WestonNorwood the server call limit (and the impact) is an interesting question. Don't have a valuable insight on this front unfortunately (our set up is not in prod yet), but my gut feeling suggests that the impact will be substantial. Something, what needs to be discussed with adobe directly perhaps ?

Don't have any workarounds atm apart from the one suggested by @bjoern__koth.