WebSDK and data send to AEP Schema

[chrisludwig87]

Hi everyone,

In my current setup, I've split AA and AT into two different data collection rules. I want AT to load on the library loaded event and AA with the data layer push event. Both use the "send data" event with a guided event: AA with data collection and AT with "personalization request."

so, if I add the XDM object and/or data object to my AT rule, it seems like the schema is receiving a call with counting a page view +1 and all the web page details as those are defined in the "update variables"-event in my AA rule. I'm wondering if I'm messing up my data in the CDP because the desired AT rule tells the schema, that a page view has happened? I'm not sure about best practices here. Should I leave it blank, or build a separate data element or update/empty the variables before? How are you folks doing that?

[chrisludwig87]

/edit: Adding some insights for clarification.

If I have only one active send event which is a guided event for request personalization and I perform a page load on my test website, I can still see an edge log in the AEC-Debugger with an upstream event to AA. Shouldn't this be stopped, or is it still streamed due to the data stream configuration as a result of any send event?

[SSampsa]

Hey. In this case I think you have the right idea and by populating data that is used by Analytics to identify page calls, the data is counted towards page views, regardless of its type. This seems a bit backward, but it is what it is.

The best method is to use a different data object for Target and Analytics respectively, so that Analytics specific data is not passed to Edge when only Target should be called. There could be a common base object and then separate parts used for each individual product that add to it.

[chrisludwig87]

Thanks for your reply. Regarding your last sentence, would you agree that adding an AT-specific are in the schema would make sense.

I'm finding it difficult to understand. Looking at the documentation it says all XDM parameters sent to Edge are transferred to AT automatically if you've added AT to the Datastream. But that's not what happens. If I'm going to create an audience in AT with custom parameters, I can only see the web parameters like "web.webPageDetails.XYZ".

I assumed that every parameter sent by a send event with an XDM object would be immediately forwarded to AT by the data stream. That's not happening for my click interaction parameters. I receive them in AA, but the params are unavailable in AT.

Any idea? Am I missing something?

[SSampsa]

This link could help you find out the missing details in data mapping for Target's parameters: Send parameters - Migrate Target from at.js 2.x to Web SDK | Adobe Target 

While it is true that all XDM is passed to each destination (with the exception of items under data-object), it does not mean they are mapped correctly (which one would assume when statements like "will be automatically sent to all destinations" are used).

Some common elements, such as the webPageDetails ones are mapped directly and partially product information from the Commerce field group, since they replace some of the separate data structures used by AA and Target, but for parameters there are different ways the system behaves as the link I shared shows.

[chrisludwig87]

Thanks for providing your thoughts. Maybe I didn't get you 100%, but I was looking at the migration docs too and they're explicitly saying "All Target mbox parameters must be passed as part of the xdm object and conform to a schema using the XDM ExperienceEvent class. Mbox parameters cannot be passed as part of the data object."

To me, this means if I have a send event in place, that consists of the event type "web.webinteraction.linkClicks" and has a custom parameter anywhere in the schema (in my case it's "web.webInteraction.name"), this path should appear in the dropdown for custom parameters when building an audience in AT. Funny enough, all the objects below the path webPageDetails for which I passed values are available. I'm confused...

[SSampsa]

I see, my mistake in taking "parameters" as universally instead of literally Target-parameters. These parameters, as you said, are part of the XDM data structure and Target gets them automatically. As shown in the migration document, it does not cover profile, user and some other parts of Target data, but that is not relevant to this case.

As things are currently, you would be sending data along this sample to Edge:
xdm/components/datatypes/webinfo.example.2.json at master · adobe/xdm

From this data you are able to see the webPageDetails data, but not data under webInteraction object, so you're able to use page names, but not "link" names in Target. The former data object contents shows up regardless of data coming from pageview or interaction event, the latter does not show up at all.

Is this a relatively accurate description of what is happening?

[chrisludwig87]

Yes it is.

I'm using data collection to manage the send events, but it's in the same direction. I have a click event on my website, updating the variables with Data Collection for the XDM, and then adding a send event for both AA and AT together. Technically it seems to work because I can see those parameters in the debugger for the server-side forwarding and mapping of AA. I can also see all these parameter values in the AEP call within the appropriate keys in the schema. But still only the page details in the dropdown for custom parameters in AT.

[chrisludwig87]

One more thing, that surprises me.

I currently have 2 rules in my Tags setup. Both create a send event (guided) for personalization only, w/o XDM or data object. The only difference here is, that rule 1 fires at page top "Library Loaded" and rule 2 is triggered by a custom event "linkClick" (DL push from the page).

It's meant to have no differences in communication with the servers, but there are.

The first difference is, that rule 2 is missing all that personalization stuff. Why?

Rule1:

[{"xdm":{"eventType":"decisioning.propositionFetch","web":{"webPageDetails":{"URL":"https://aep.verrodata.com/"},"webReferrer":{"URL":""}},"device":{"screenHeight":1440,"screenWidth":2560,"screenOrientation":"landscape"},"environment":{"type":"browser","browserDetails":{"viewportWidth":2038,"viewportHeight":1184}},"placeContext":{"localTimezoneOffset":-60,"localTime":"2024-11-27T08:37:33.221+01:00"},"timestamp":"2024-11-27T07:37:33.221Z","implementationDetails":{"name":"https://ns.adobe.com/experience/alloy/reactor","version":"2.24.0+2.27.0","environment":"browser"}},"query":{"personalization":{"schemas":["https://ns.adobe.com/personalization/default-content-item","https://ns.adobe.com/personalization/html-content-item","https://ns.adobe.com/personalization/json-content-item","https://ns.adobe.com/personalization/redirect-item","https://ns.adobe.com/personalization/ruleset-item","https://ns.adobe.com/personalization/message/in-app","https://ns.adobe.com/personalization/message/content-card","https://ns.adobe.com/personalization/dom-action"],"decisionScopes":["__view__"],"surfaces":["web://aep.verrodata.com/"]}}}]

Rule 2:

[{"xdm":{"eventType":"decisioning.propositionFetch","web":{"webPageDetails":{"URL":"https://aep.verrodata.com/"},"webReferrer":{"URL":""}},"device":{"screenHeight":1440,"screenWidth":2560,"screenOrientation":"landscape"},"environment":{"type":"browser","browserDetails":{"viewportWidth":2038,"viewportHeight":1184}},"placeContext":{"localTimezoneOffset":-60,"localTime":"2024-11-27T08:37:43.638+01:00"},"timestamp":"2024-11-27T07:37:43.638Z","implementationDetails":{"name":"https://ns.adobe.com/experience/alloy/reactor","version":"2.24.0+2.27.0","environment":"browser"}}}]

Second difference I can see while debugging (Edge Transactions) is, that the response from rule 2 (server-side) has something like "not-enabled" in the URL. Why?

Rule1:

Rule 2:

[SSampsa]

I can't say off the bat why would the second, identical call not include the actual query for Target, but that is very much why the second call in debugger is not working the same, as the parts of request defining the action to Target is missing and will not have Target capability working as intended.