Activity Map - Can I add more context to the click tracking?

[bjoern__koth]

The activity map is great to understand what's happening on the page without separate setup for many interactive elements.

Unfortunately, the extension is still broken (due Chrome updates, and yes I know there is a workaround), but the information is still usable in the Workspace.

Now, it seems that these are the values that an actitivity map click may transport

• clickedElement: The DOM element that was clicked
• pageName: The page name when the click happened
• linkName: The name of the clicked link
• linkRegion: The region of the clicked link
• linkType: The type of link (typically exit, download, or other)
• linkUrl: The destination URL of the clicked link

But, there is a lot of context missing to fully understand where this click happened. Hence, it would be awesome if I could add information that is present in any other tracking call with the ActivityMap click.

So, is it actually possible to enrich this with additional context data payload like for instance parts of the data layer (which I then obviously have to map via processing rules)?

Has anyone ever tried this out and has an opinion on this?

UPDATE:

The Web SDK's "on before event callback" seems to give me some possibility to modify the XDM before sending.

// Modify content.xdm or content.data as necessary. There is no need to wrap the
// code in a function or return a value. For example:
// content.xdm.web.webPageDetails.name = "Checkout";

let activityMap = content?.data?.__adobe?.analytics?.contextData?.a?.activitymap;
if (activityMap) {
    // enrich with additional information
    activityMap.foo = "bar";
}

_satellite.logger.debug(`>>> on before event send: ${JSON.stringify(content,null,2)}`);

UPDATE 2:
I updated my "on before event send" callback now to pull additional information from data element to enrich the context with what I need to better understand and segment interaction by let's say language and page country. And it works fine!

let activityMap = content?.data?.__adobe?.analytics?.contextData?.a?.activitymap;
if (activityMap) {
    // enrich with pageName and pageURL if not present
    content.data.__adobe.analytics.eVar4 = _satellite.getVar("Page Country", event);
    content.data.__adobe.analytics.eVar5 = _satellite.getVar("Page Language", event);
}

Now what? This question is kind of answered, just if anyone could give their two cents on this as well, and I can sleep better at night.

Obviously, the Activity Map was built for one specific purpose: an overlay on the browser (which currently / has not been working for a while now).
So, adding more context will obviously not be made visible in that extension. But should that keep us from hacking it?

@Jennifer_Dungan, @MandyGeorge, @Krishna_Musku 

[Krishna_Musku]

Hello @bjoern__koth,

The New Activity Map v3 was released this month. Which fixes the chrome update issue.

https://chromewebstore.google.com/detail/activity-map-v3/bknaiihbekigjeginplhehfiekeeodme

This is my discussion post about the new activity map extension

https://experienceleaguecommunities.adobe.com/t5/adobe-analytics-discussions/activity-map-v3-extensi...

[Jennifer_Dungan]

@bjoern__koth to be honest, I haven't used the extension for years... now, I haven't done anything with the XDM Stream, but one thing I had done in our previous site (and would like to re-create in some fashion a similar update), was to use Session Storage variables when some elements were clicked, storing additional context about the click. I would pass the info on the next call. I should also mention that we replicate our Activity Map data into some custom dimensions (one so that we could get it in our Data Lake, which way back when Activity Map was not included in Raw Data Feeds, and so that we could replicate the Activity Map behaviour into our Mobile Apps, storing both Web and App data into our custom dimensions)

In our case, we had some editorial configurable content blocks, so we passed some additional info. The whole block was the region, but the sub-blocks would pass a sub-block name and position, and then every link inside each sub block would pass the link position. For less complex blocks (no sub-blocks) I would just pass a link position..

This was really helpful for understanding how deep into our containers users were looking (particularly when it came to carousel type blocks).

So I wasn't explicitly adding to "Activity Map", but it was used in conjunction with Activity Map data....

[bjoern__koth]

Hi @Jennifer_Dungan 

that's what I was looking for.

How/where did you reuse this information? Via AppMeasurement's do_plugins?

I spoke to support about Web SDK's new event grouping functionality which acts very similar to what you have described above.

Currently, it only persists one single / the last click and will not persist multiple activity map clicks that happend on the previous page before navigation happened.

So, one could potentially use your approach to store contextual data in sessionStorage and enrich the call on the next page (assuming you have dedicated props/eVars for this). Should at some point the event grouping store multiple clicks, it will surely get more complicated again to enrich the right call with the right information.

Bottom line, there is no official support for additional information, correct?

[Jennifer_Dungan · Accepted solution]

Yeah, I've not seen any official support... 

I built my tracking into my Rules... I would check if the session storage had values, set them into my variables, then I would clear the session storage so that it wouldn't accidentally get picked up again... 

On Click Rule - set session storage  (just for setting these values, but no actual tracking)

On Page View:

- Check for Session Storage Values

- If they exist, set my variables (inside the custom code of my set variables action)

- Clear Session Storage

- Send the beacon

So basically, through custom code I would set, use and then clear the values so they didn't persist. Activity Map doesn't generally persist (it's really designed to track the click that brought you to the current page, or the click on the element with tracking).. and while I had a few mismatches (due to some odd behaviour with AM when users would refresh or use their back buttons, which I would love to try and address), it worked, and I would address some of those issues if I were to do it again (learning from the past issues)

[bjoern__koth]

Thanks for your insights, @Jennifer_Dungan @and @Krishna_Musku 

will close this one as "we kinda know it can be hacked if needed"

[Jennifer_Dungan]

Haha yeah, this is totally a "hack as needed" solution, lol