Augment event data with Target experiment

Open
  • Is something wrong?
#748 0 comments 1 reaction 1 assignee View on GitHub

Maintainers usually reply within 1 day

@vivasd is already working on this.

Since Aug 10, 2021.

Assessment

This issue has not been assessed yet.

Description

Adobe Target Alloy
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.

Dominant language
JavaScript
Stars
104
Forks
63
Avg merge
1d 22h
Merged PRs (30d)
23

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from adobe/alloy

All issues in adobe/alloy

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.