Improved click collection with ActivityMap and event grouping support

[liljenback]

Description

The Web SDK now includes more granular click collection settings.

alloy("configure", {
  clickCollectionEnabled: true,
  clickCollection: {
    internalLinkEnabled: true,
    downloadLinkEnabled: true,
    externalLinkEnabled: true,
    sessionStorageEnabled: true,
    eventGroupingEnabled: true
  }
}

Click collection for specific link elements (download, external, and internal) can now be controlled independently from within the clickCollection namespace. In addition a user can enable sessionStorageEnabled and eventGroupingEnabled to capture and store internal link element click events which are grouped with the subsequent page view event.

The Web SDK will now include ActivityMap specific data within the DATA container. This data becomes available for reporting in Adobe Analytics and with the ActivityMap browser extension.

Related Issue

AN-329919

Motivation and Context

• Not all clickable elements were correctly captured in the alloy library.
• Too many requests were sent for internal link click events. Now a user can limit the number of outbound requests for internal link click events by bundling them with the next page view event.
• There's a need to have better control of what link types that are captured.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change which does not add functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.

[jonsnyder]

Love all the tests! This is a well thought out PR.

Overall, we need to discuss how we determine which request is a "Page View" and therefore should include the previous page link clicks. For the top and bottom changes I made, we made it explicit by adding the option "includeRenderedPropositions".

[jonsnyder]

We haven't yet dropped support for IE11, although I think it is planned for this year. I don't think IE11 supports property accessors.

[liljenback]

Looks like we're using it in a few other locations such as the createTaskQueue.js.

[jonsnyder]

What if you wanted to run AppMeasurement and Web SDK side by side to ensure they were collecting all the data?

[liljenback]

AppMeasurement ignores the event that has been "tagged" with s_fe because it is the previously captured and cancelled event that was then re-fired. What happened was that Alloy ended up picking up the original event and this event as well causing two link click event getting sent. It might be that this design in AppMeasurement no longer is required (with the beacon API being available etc.). This addition makes it so that alloy is not affected by the "additional " event.

[liljenback]

That said, depending on the browser prioritization or execution logic for the capturing click handlers this could potentially cause race conditions where we end up losing the event. Perhaps a better solution would be to introduce some sort of rate limiting instead.

[jonsnyder]

Is this the same logic that Analytics uses?

[liljenback]

Outside a lot of small details (like not looking at XDM) AppMeasurement operates the same way. AppMeasurement is limited to two types of requests, a page tracking event (track) and a link tracking event (tl). When a click doesn't qualify as a link click, the properties that we capture are just stored and submitted on a future call (for internal link clicks) which will need to be a page view if that data is to be kept. This is because a qualifying link click will erase and replace previously stored data. In the Web SDK we could argue that we should augment any future event with the data that we've captured previously but then we start to deviate further from how AppMeasurement manages click data (which might get reflected in reporting). However, this is something we might want to test in future releases given that the Web SDK is significantly more flexible in the type of events that can be submitted.

[ninaceban]

This looks great Martin 👍

However, there's a crucial use case that requires our attention. Specifically, when a user clicks on a link that qualifies as both a click collection element and a Personalization metric, we must ensure that this event is not cancelled. This is because it contains the Personalization conversion and/or A4T token, which is also shared with Analytics.

This can be identified by examining the event payload. The payload of a Personalization metric event would have the XDM structured as follows:

{
    "eventType": "decisioning.propositionInteract",
    "_experience": {
        "decisioning": {
            "propositions": [
                {
                    "id": "test",
                    "scope": "test",
                    "scopeDetails": {...}
                }
            ]
        }
    }
}

[liljenback]

This looks great Martin 👍

However, there's a crucial use case that requires our attention. Specifically, when a user clicks on a link that qualifies as both a click collection element and a Personalization metric, we must ensure that this event is not cancelled. This is because it contains the Personalization conversion and/or A4T token, which is also shared with Analytics.

This can be identified by examining the event payload. The payload of a Personalization metric event would have the XDM structured as follows:

{
    "eventType": "decisioning.propositionInteract",
    "_experience": {
        "decisioning": {
            "propositions": [
                {
                    "id": "test",
                    "scope": "test",
                    "scopeDetails": {...}
                }
            ]
        }
    }
}

Let's add a functional test for this. I believe it might work as it's currently setup. If the event is augmented by the Personalization module it will not be empty and get submitted.