eventGroupingEnabled - web sdk activity map

[Franc_G]

hi all, based on the adobe documentation clickCollection.eventGroupingEnabled is a boolean that determines if the library waits until the next page to send link tracking data (clickCollection | Adobe Data Collection). Have tried setting it to "true" and the event bundling does not work. The existing appMeasurement set up does the trick - activity map is being surfaced on the next pageload. Want to have the exact set up in the web sdk. Would appreciate if anyone could help. Thanks  

[bjoern__koth]

Hi @Franc_G 

yeah, it does not seem to work for me either. I actually have a call tomorrow 11:30am CEST with Adobe support about this

Send me a DM if you want to hop on the call.

Björn

[bjoern__koth · Accepted solution]

Hi @Franc_G 

little update on this one. So, I looked at the alloy.js code which has a function hasPageName that internally called in onBeforeEvent and expects xdm.web.webPageDetails.name to be set to detect page views. Also mentions that ideally, the event type should be "web.webpagedetails.pageViews" (which is commented and not in use).

Both is a little problematic in my opinion since these days, you are not obliged to set these values to have a working analytics solution if you use WebSDK UX to set data variables instead of going for an XDM schema.

Long story, it still does not work for me though

Sent it to support, maybe they have an idea. But maybe worth checking if you can make it work on your end

[Franc_G]

@bjoern__koth  a bit of a tricky one. I will raise a ticket with Adobe - this is what our customer support has suggested.  

In the current setup (without event grouping), the activity map is not amazing. It will results in an enormous amount of extra requests. Any nav link, toolbar, tab will result in an additional server request.  Adobe needs to sort this out. I can see a lot of clients being unhappy once they see the server request quota limits being breached.

Putting this on hold for now.

[bjoern__koth]

I mean it should not be rocket science. You can persist the data yourself in the WebSDK's "Edit filter click properties callback code" and can abort the execution with "return false" if needed.

try {
    // persist the data in sessionStorage
    const payload = {
        link: encodeURIComponent(content.linkName),
        page: encodeURIComponent(content.pageName),
        region: encodeURIComponent(content.linkRegion),
        pageIDType: content.pageName ? 1 : 0,
    };
    sessionStorage.setItem("prev_activityMap", JSON.stringify(payload));

    // abort execution
    return false;

} catch (error) {
    _satellite.logger.error(">>> ActivityMap - filterClickDetails error", error);
}

And from there on, in the page view, we will have to pull it out and set it on the data.__adobe.analytics.contextData.a.activityMap object

In my case, I use an "Update variable" WebSDK action's custom code block.

// try to read previous ActivityMap item from sessionStorage
try {
    let prev_activityMap = JSON.parse(sessionStorage.getItem("prev_activityMap"));

    if (Object.keys(prev_activityMap).length > 0) {
        content.__adobe.analytics.contextData = content.__adobe.analytics.contextData || {};
        content.__adobe.analytics.contextData.a = content.__adobe.analytics.contextData.a || {};
        content.__adobe.analytics.contextData.a.activitymap = content.__adobe.analytics.contextData.a.activitymap || {};

        // iterate over sessionStorage item and fill activitymap context data
        for (const [key, value] of Object.entries(prev_activityMap)) {
            content.__adobe.analytics.contextData.a.activitymap[key] = decodeURIComponent(value);
        }

        // remove sessionStorage item
        sessionStorage.removeItem("prev_activityMap");
        _satellite.logger.debug(">>> ActivityMap applied", content.__adobe.analytics.contextData.a.activitymap);
    }
} catch (error) {
    _satellite.logger.error(">>> ActivityMap - filterClickDetails error", error);
}

This seems to work on my end at least but again, should work out of the box.

Also, I do not really like that you can only capture that one event.

So, maybe a hybrid approach could be best. Meaning, we can check if the clicked link URL is actually navigating away on another page and if not, still trigger the activitymap right away to not lose interactions without page navigation?

[Franc_G]

@bjoern__koth  thanks for the above - definitely a valid back up option. I have raised a ticket with adobe customer support and their engineers are looking into it. Would really prefer for this to work out of the box, but its good to have a back up option

Weirdly enough, on my end, out of the box solution works on SPAs, but it does not work on non-SPA pages. But then again, I am using a different TMS (Ensighten and not Launch). 

[bjoern__koth]

Interesting, but could Ensighten have an older version of the WebSDK where it still works,

@Jennifer_Dungan mentioned that her approach suddenly stopped working. 

[bjoern__koth]

Hi @Franc_G 

got feedback from support. So, as it seems, this event grouping feature only works if you set the "web.webPageDetails.name" in your page views.

Meaning, if you have a lean Analytics setup that does not care about XDM and only uses Web SDK Variable data (data.__adobe), and leave out a dummy XDM that has this value set, this won't work.

This would be the bare minimum of information to send as a page view.

And in the payload, it will contain the activity map data of the previously clicked link.

Looking at this, I wonder if this will even be able to store more than a single activity map click.
data.__adobe.analyitics.contextData.a.activitymap are exclusively objects.

Not a single array in there that could actually capture more than one click to be executed on the next page.

I don't see myself using the feature soon should this not be possible

[Franc_G]

@bjoern__koth  I have got the same reply from adobe engineer. My key findings:

1. web.webPageDetails.name needs to be populated on the subsequent page load in order for the event grouping to work. I have started to populate this property on all events.

2. Anchor tags will be triggered as stand alone events (any link with href="javascript:void(0) attribute). ie clicking on some sort of nav (without triggering another pageload) will result in stand alone call. It works with all internal links.

3. Re: "...Looking at this, I wonder if this will even be able to store more than a single activity map click.". Don't think so. We just get the value populated on the subsequent page load. There is a single value within the "activitymap" obj.

[bjoern__koth]

Hi @Franc_G 

there are many parallel threads about this topic at this point.
I documented a working solution here

Also, interestingly, all of a sudden also the button clicks seem to be captured and tracked on the following page

https://bkoth.ch/

[Franc_G]

@bjoern__koth  qq - you are setting an empty object as a fallback in the custom code. Below is the example. 

content.__adobe.analytics.contextData =
        content.__adobe.analytics.contextData || {};

I normally set an empty string "", which prevents variable(s) from being populated. Just trying to understand why you use the {}. Thanks

[bjoern__koth]

Hi @Franc_G 

the data structure will be further nested so, if you want to make sure this structure is available before setting it, I would highly recommend to generate it as needed.

content.__adobe.analytics.contextData.a.activitymap

 I mean, technically you would have to create the whole structure to make sure you're not running into errors should it not be present.

So, technically this should be done

// make content.__adobe.analytics.contextData is available before setting anyhing on it
content.__adobe = content.__adobe || {};
content.__adobe.analytics = content.__adobe.analytics || {};
content.__adobe.analytics.contextData = content.__adobe.analytics.contextData || {};

Let's say my approach above was a little quick 'n' dirty to showcase that it would be possible.

Ideally, Adobe should fix their activity map context data to be able to transport more than one clicked element.

But I don't see this coming any time soon. Support will keep me updated if they hear anything from the developers

[Franc_G]

@bjoern__koth Okay, makes sense. You just want to make sure that obj property exists and setting it to an empty obj if its not. Thought about something completely different, but thanks for explaining. 

[bjoern__koth]

Hi @Franc_G 

had the session with support, they will look into the issue. According to the agent, he would also assume that the sessionStorage value is picked up upon and request on the next page.
He will investigate with the WebSDK team and come back to me next week.

Cheers

[Franc_G]

Thanks for the update, much appreciated.

[Franc_G]

@bjoern__koth  I have a problem with the eventGroupingEnabled set up. The very first request is adobe target's 

eventType: "decisioning.propositionFetch", which unfortunately needs to have the web.webPageDetails.name set (otherwise, we can't run AT experiments on specific pages). The unfortunately bit is that this call type (eventType: "decisioning.propositionFetch") is being dropped by adobe.

Have been in touch with Adobe and here is their suggestion: 

 "...either avoid using eventGrouping for clicks, or utilize the event callback and manage it with custom code". I am a bit surprised about the whole thing - it seems like WebSDK set up by definition didn't expect to have the AT working in parallel. Custom code in the callback is only option I have at the moment 🤷‍ 

[bjoern__koth]

what?! So, even without the page view event type, it is being pulled in? That definitely sounds like a bug to me!

So, Adobe's suggestion is that you write your own code that stores the Activity Map in your own custom sessionStorage and to pick it up in the callback, checking whether the event name is a page view?

I mean seriously, I am considering writing a blog now with all these bugs and custom code how to circumvent these issues.