Personalised content and Real Time Context

[kptdobe]

https://github.com/adobe/express-website-issues/issues/158 is the first time we see the need for conditional content: the popup must be shown when returning/web app visitors click on the individual plan for m2m (audience).

In Helix terms, the popup is a block and the block would be shown only if the surfer is currently part of the audience, which is determined by Adobe Audience Manager (AAM).

The requirements are:

• a block can be associated with an audience
• an author should be able to easily create the block and changed the associated audience
• when page loads, audiences are loaded from AAM and block is shown only if the audience associated matches one of them
• a non obvious mandatory requirement: integrate the show / no show of the block into the tracking of the page. Without good tracking / measurement and a capability to determine if a content "test" is successful, having personalised content would be useless.
• when previewing the page, an author would be able to "simulate" if the audience is currently matching or not in order to preview the page with and without the popup. "Personalize" Button for Adobe Audience Manager helix-sidekick#64

Specifications:

The first idea to explore to associate a block with an audience is to allow any block to have a first row like:

Block Name
Audience	audienceID_XYZ
Block content	...

The "audience row" would be extracted before block handling logic which means the block code would receive the same dom as before. This gives an easy way for authors to edit the block - audience relationship. An "audience" picker could even be built to even make it smoother.

Then we'll need some logic that would bridge the audiences from AAM and some global object containing the current context of the surfer (the Real Time Context (RTC :)) and providing a way to determine which block must be shown / loaded or not.

cc @davidnuescheler @trieloff @rofe

[trieloff]

An "audience" picker could even be built to even make it smoother.

The idea is that adobe/helix-sidekick#64 would work as an audience picker when invoked from within Word or Google Docs:

Edit

The same dropdown will be shown, but without an option to clear or set the audience, instead clicking an audience name will copy the audience ID so that it can be used in the first column of the personalization block's table

[trieloff]

Then we'll need some logic that would bridge the audiences from AAM and some global object containing the current context of the surfer (the Real Time Context (RTC :)

That would be the window.hlx.audience and window.addEventListener('helix-audiencechanged', (evt) => console.log(evt.detail); outlined in adobe/helix-sidekick#64 (comment)

[trieloff]

The "audience row" would be extracted before block handling logic which means the block code would receive the same dom as before
[…] and providing a way to determine which block must be shown / loaded or not.

Wouldn't it be better to encapsulate the entire logic of calling Audience Manager and showing/hiding rows (using display: none) in the "Personalization Block" component? For one, we won't have an additional global state and second-order dependencies like (only load the AAM integration when the personalization block is on the page). On the other hand, this will make toggling audiences with adobe/helix-sidekick#64 easier, as you only have to flip the display: none/block style.

[kptdobe]

If you do a "Personalisation Block" (I made a prototype, that's the first I have done :) ), you will need to put the other blocks inside - or make a "Personalisation Block flavour" for all your blocks that you want to have personalised.

[kptdobe]

window.addEventListener('helix-audiencechanged', (evt) => console.log(evt.detail);

I know by experience that this is the start point of an event mess: everybody listens and everybody fire events on each change. The time for all 3rd party dependencies to be loaded (AAM, Target...), you changed the page content a gazillion of time.
I am not saying we should not do it like this but we should try different approaches before defining the technical solution.

[trieloff]

Given that we have only one personalization use case so far, I'd be fine with having one single personalizable block over the more general solution.

[kptdobe]

The reason we design it event base (I built the feature 2 times already that way...) is because we start by the simulation: you want to update the page on each change. I "hope" that if we start by the content loading sequence, we can avoid it and not over-engineer it.

[kptdobe]

Given that we have only one personalization use case so far, I'd be fine with having one single personalizable block over the more general solution.

That's definitively a fair point ;)