Event Grouping Link Tracking - Session Storage Still Sending Network Calls on Link Click

[liamevans11]

Hello,

I am testing our the new Beta feature in the Adobe Experience Platform Web SDK extension for event grouping of link clicks where the network call gets sent to Adobe on the next page view. Please see settings in extension below.

I have ticked this box but when I review this change, I am still getting requests for link clicks immediately and I cannot see any link click data in the page view request on the next page.

I cannot find any guides online that explain how the data should look when this setting is configured but I don't think it is working correctly in my case.

Does anyone know how this should look or has anyone experienced a similar issue with event grouping?

Many thanks

Liam

[bjoern__koth · Accepted solution]

Hi Liam,

yeah it is indeed still beta and I have also been in contact with them.

What do you see if you type "sessionStorage" in your console after clicking a link?

Also, sometimes my changes to extension configs don't get properly saved to the library (at least that is my impression)

To make sure that is not the case, can you go into one of these two custom code blocks and just add a newline at the end?

Then save and publish again.

Also be aware that the XDM eventType must be the standard "Web Webpagedetails Page Views" and any other event types will not pull the sessionStorage in.

I have a test setup which works fine.

No requests in the debugger

and on the following page, the Activity Map is tracked

[liamevans11]

Hi Bjoern,

Thank you for your swift and detailed response, it is much appreciated. I have followed the steps you've outlined above and I can see that my sessionStorage contains the link click details.

However, even though the link click details are held within Session Storage, the request still immediately gets sent. 

What specific values should I be looking for on the next page where the link details are meant to be sent? It is the activity map that indicates they have been sent or should there be data in the XDM object on the pageView request relating to the link click?

Thanks

Liam

[bjoern__koth]

Hi @liamevans11 

here's my test page: https://bkoth.ch/

I actually created it for the exact same purpose, since I was also struggling to make the event grouping work.

after clicking the link, the page will reload and you will see an entry in the network tab which is the page view of the following page

the request payload will contain data.__adobe.analytics.contextData.a.activitymap... which is your clicked link from the page before (see page is "/" from the home page)

Hope that makes it clearer

[bjoern__koth]

For completeness, here's my setup from AEP to Launch.

AEP Schema

Launch Setup

1. Data Elements

Note: in my setup I am using the approach to set analytics attributes all through the data.__adobe.analytics object and not via an XDM schema.

Page Info - Pathname

Will be used as analytics "pageName"

Captures the current pathname after the domain (or take whatever you need for your own pageName)

Web SDK Data

Web SDK Variable Data element

Used to set AppMeasurement-style analytics props/eVars/events. In here I will set all payload I want to send to AA.

Web SDK XDM page view

This data element is likely redundant, but explicitly I set the pageViews value to 1 and the page name through the "name" attribute.

UPDATE: no IT IS NOT!

I just tried to ditch the XDM information in my Web SDK sendEvent call, and the activity map data did not get transported.

!!! Setting both the "name" and "pageViews" value to 1 seem to be mandatory !!!

A little special that you can initialize all analytics data in the data.__adobe object, including the pageName, but in the end you still must set the web.webPageDetails.name and .pageViews.value

Rule - Test Web SDK Call

Handles the page view calls. Before that, set the analytics variables

Set pageName

In the sendEvent, choose "Web Webpagedetails Page Views" as Type.

And that's it. Boy that was easy, wasn't it?!?

[Franc_G]

@bjoern__koth Re: "Also be aware that the XDM eventType must be the standard "Web Webpagedetails Page Views" and any other event types will not pull the sessionStorage in."

That's not great as we will need separate events for pageLoads and everything else. Essentially, we will be replicating the "old" appMeasurement set up.  I thought the idea was to turn everything into an event (regardless whether it is s.t() or s.tl()).

[liamevans11]

Thank you for the detail @bjoern__koth, it's been really useful. One additional question, I am using the Adobe Analytics Experience Event in the XDM schema to map data to Adobe Analytics props/eVars/Events, would I need to utilise the data._adobe.analytics object method in order for the link event grouping to work correctly? I'm not sure where the data exists in the XDM schema approach in the interact request.

[bjoern__koth]

Hi @liamevans11 
no, using the Adobe Analytics Experience Event schema does not change anything.

I prefer the data.__adobe.analytics approach since it resembles the "old world" approach of AppMeasurement where you set everything on the "s" instance name of the library. Many times, existing code (if used) can be implemented easier in the data approach.

And (between you and me...) I think the XDM schema approach is extremely bloated unless you have data elements for everything you want to set (unless your data layer contains everything already preprocessed and no data cleanup or transformation has to be done.

From experience, when you have a setup that uses many props/evars/events, at some point this does not really scale well in Launch anymore.
Meaning, the build time will increase substantially.

I did use the same XDM schema in the beginning of AEP (before the data approach got supported better), writing one huge piece of code that replicated the whole _experience.analytics object, trying to replicate the extremely overengineered schema structures in this fieldgroup.

Example: initialize a list prop (snippet from the actual monster code I wrote back then), just have a look at this...

// ...
// _experience.analytics.customDimensions.lists.list1.list
customDimensions: {
    lists: {
        list1: {
            list: [
            	{value: "hello"},
            	{value: "world"},
            	{value: "bla"},
            	{value: "blub"}
            ]
        }
    },
},

// ...

as compared to (part of a "update variable" code where I have

/*
// initialized earlier
content.__adobe = content.__adobe || { };
content.__adobe.analytics = content.__adobe.analytics || { };
let s = content.__adobe.analytics;
*/

s.list1 = "hello,world,bla,blub";

So yeah, I don't do this (to myself) anymore and rather have a flat object structure to set my props/eVars/events on.

I mean, I do get the historic background:

• back then, there was no automatic mapping between AEP request data and AA props/eVars, which obviously was a huge issue for everyone (especially since you could not easily look at your network request and see what was send)
• so, Adobe had to come up with some kind of helper
• to stick with the XDM schema approach, the new fieldgroup was introduced, adding automatic mapping features in the background
• it had to become a monster schema to cater for the 1000 events, 250 eVars, etc.
• the fact that you could use that prefixed data.__adobe namespace to send in this information in an unstructured/untyped way went mostly unnoticed
• guess at some point people at Adobe also realized that their XDM approach wasn't the smoothest

Sorry for the rant, just trying to keep people from doing the same mistakes I have done xD

Just keep in mind that using strictly this data approach will not work with the event grouping (as described in a comment earlier).
Additionall, you must set the correct XDM event type and webpagedetails payload to make it work.

[liamevans11]

@bjoern__koth Absolutely, I can see your reasoning. I am currently new to AEP so I have been testing out all approaches. I've tested the event grouping using the XDM schema on my dummy website and can see the data appearing in the events[0].data.__adobe.analytics.contextData.a.activitymap object so your explanations and responses have been really useful. 

Thank you again for your guidance!