WebSDK and data send to AEP Schema | Community
Skip to main content
chrisludwig87
chrisludwig87
Level 2
November 18, 2024
Question

WebSDK and data send to AEP Schema

  • November 18, 2024
  • 2 replies
  • 1853 views

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?

    2 replies

    chrisludwig87
    chrisludwig87Author
    Level 2
    November 18, 2024

    /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
      SSampsa
      Level 4
      November 19, 2024

      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
        chrisludwig87Author
        Level 2
        November 20, 2024

        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?

          chrisludwig87
          chrisludwig87Author
          Level 2
          November 27, 2024

          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
            SSampsa
            Level 4
            November 27, 2024

            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.

              Terms & ConditionsAccessibility statement

              Loading footer...