Augment event data with Target experiment

[pitchmuc]

Expected Behaviour

The expected behavior would be to have the Target experiment data would be added to the event sent on the page.

Actual Behaviour

At the moment, when sending the first event, we received the response from Target, the experiment is then applied to the page.
In order to track these experiments, we need to send an event again.

That results in additional rows ingested in the data lake.

That new event needs to be accounted for and has several implications:

• If we want to have the context of that experiment, we need to send the page information again. That is no problem for tracking but double the number of times the page information is counted.
• that can be accounted by sending one as pageView and the other as events but that is not true. In reality, the Target experiment has been seen on the same page, so page view and target experiment should be linked.
• In CJA, the filtering can be applied on Person, Session and Hit based, you can see the problem when applying any of these contexts for filtering. In any way, it will always return incorrect data in the reporting.

Actual reporting setup (A4T)

As a reference, I can provide what I know on how Adobe Analytics solves that issue with A4T.
At the moment of the request, the data are augmented with an id.
That ID is then classified (a lookup is applied on it in AEP terms) and allows to have Target experiments attach to the page views.
That solves the latency issue, as you do not need to wait for Target response to augment the data, you just need to make sure that Target has this ID as well.

Event Merge ID option & implication

This seems something that could be applied by the Event Merge ID but not sure how and not sure which team takes care of the merge.
If merge only applies in CJA (possible option) -> Query Service is still impacted.
Event Merge ID would probably have other use-cases than just Target, so risky to build around that use-case alone.

Pure Target ID for merge

Another way is to have a "Target Merge ID" attached somewhere in the schema via augmentation in Konductor.
Then be able to feed a record type schema via AEP Web SDK to later classify that value in CJA or AEP.
That would allow the use-case to be matched in AEP & CJA.

Consideration for Target Merge ID

if a unique "Target merge ID" is created by send event, that can create a very large lookup dataset.
There may be a way to deduplicate the "Target Merge ID" per experiment.