[mep] moment based experience

[npeltier]

as a follow up for https://github.com/orgs/adobecom/discussions/993, we discussed offline and agreed we could try to go with OOTB mep with some more features first.
One of them is what we've called on/off from our aeminds or scheduling. Thinking twice, start & end dates for a given personalized experience would be something cumbersome to add in each and every manifest, and to update, and to maintain consistent.

Idea would be to have some place where we define "moments" like blackfriday, where we set start and end date.
Then a moment column in mep manifest would refer to that moment key in a human fashion.
Resolution on browser would be current date being including in [start,end] interval

wdyt? cc @chrischrischris

[chrischrischris]

One thing to determine is do we want to be able to toggle on/off on a per-line basis in the manifest or would we want to do it at a manifest level. I think we also should have the ability to do "moments" and to enter datetime range directly.

Options are:

1. New column in the manifest where a moment column is added and controls each line
2. New "moment" command that applies to the entire manifest.
3. Ability to specify the moment in metadata. Currently the personalization key takes a list of manifests. We could add the ability to enter a manifest prefixed with a moment: personalization | blackfriday:path/to/manifest. This allows the controlling to happen via metadata.xls so nothing has to be updated manually on pages or manifests.

We may also want to offer a combination of the above. I could see for blackfriday knowing that a specific manifest will only ever apply for those dates.

[3ch023]

Hi @chrischrischris could you give more details on option 2 pls, I am not sure I understand what is the 'command' and how it can be applied to the manifest.

So far option 3 looks the best to me, even though it means an additional request for the moment start and end date (if I understand the idea correctly)

[npeltier]

with promotions in mind, for mapping of moments & dates, for sake of confidentiality, @honstar raised an interesting idea i think @3ch023 alluded to too: just having a file live that says which moment we are in (e.g. ['blackfriday', '2023', 'Q4']). On a private space this can be attached to dates, some scheduled publication of content could be made based on this, and then we don't have to even think about exposing that content anymore

[rgclayton]

We may also want to offer a combination of the above. I could see for blackfriday knowing that a specific manifest will only ever apply for those dates.

I'm not sure I fully understand option #2 either.

It sounds like options #1 and #3 would cover the current use cases.

I'm assuming #3 option would override anything set by #1 in the event both options are used?

[3ch023]

yes, I think #3 should have higher priority over #1.
I am not even sure if we need implementing #1 right away, might be that #3 is enough to cover the requirements.

[vgoodric]

My first inclination is to say that this is an excellent use of Target. Target is fully integrated into MEP and has scheduling features. Additionally, you can create and QA a new personalization experience before the activity is even set up. This would allow authors to keep working while waiting for T&O assistance. But perhaps there's a reason Target is not suitable for your needs. If so, I need more details to understand the situation.

But I worry the solutions discussed so far are all more clunky than using Target. Additionally, anything that involves information in the manifest will require the manifest to be downloaded to the user's computer and checked. But if Target is the shutoff mechanism, it will simply stop sending the data once the activity is over.

[npeltier]

Are you talking about on/off only or the whole promotion use case discussed in #993 ?
Problem is that we'll be using this for all our most important pages (plans, products, ...), all the time. I've been bought to use personalization for promotion use case even if for now 100% of users at a given moment will get same content. I'm also ok to try for now on client directly. Now adding additional blocking call makes me tensed a bit more. Do we know how many LH points would be lost by using target for doing this (rather simple) task ?

[vgoodric]

enabling Target adds is like an 8 point hit to the LH score. But that's true if Target is enabled for the page, regardless of whether or not any activities are served. So if the pages have Target enabled for possible testing, it doesn't slow you down any further to have personalization served through Target.

[3ch023]

Opt. 1 - 'Flags'

Following the call we had, here is a brief description of what the suggested 'Flags' feature could look like and open points:

Inspired by the option 3 from @chrischrischris , Flag name is prepended to the manifest path specified in metadata:
blackfriday | path/to/manifest-blackfriday.json, bts | path/to/manifest-bts.json
Flags can enable a MEP manifest:

• by toggle (ON/OFF)
• by moment (specified datetime range)

Flags will use Franklin's Scheduling feature to pre-publish content in advance(some defined delay before). Content needs to be pre-published, but not shown to the user till the moment time starts. This is required to make sure there is no delay when Moment time is on.

Flags could be specified in (To be decided):

• metadata
• or a dedicated file (performance concern, we can cancel this option)
• hardcoded in code (I still see it as an option since code change in Milo is a quick operation)
• other (pls suggest)

Mep flags would fulfill both promotion and feature flags use cases

[3ch023]

Flags sample page
Sharepoint with content

[3ch023]

Opt. 2 - 'OOTB Franklin Scheduled Publish'

After spending some time thinking about how to avoid client-side datetime check, I have a second option to suggest:

1. Each promotion is scheduled by manifest. Promo Fragments can be pre-published in advance, at any time. The Promo Manifest is not published until the promo goes live.
2. As soon as the Promo Manifest is Published the promotion content will be shown to users (+- Akamai TTL).
3. As soon as the Promo Manifest is unpublished, Promo content won't be shown to users (+- Akamai TTL).
4. Publishing/Unpublishing of Promo Manifest will be scheduled using Franklin's Scheduling feature

Decrease amount of Manifests

If we go with this approach we need to decrease the number of promo manifests. It will not be rational to have 1 manifest per page, per locale, per promotion.
The suggestion to GWP is to have 1 manifest per locale per promotion, having changes for all pages in it.
Please check an example of the manifest, using the page filters column, and confirm if that will work for you.
For 'blackfriday' we would have 1 manifest in US (for all pages), 1 in DE and so on.

Overview of changes

GWP needs a way to preview what changes will be made to the page. If we rely on OOTB Frankling Scheduling, we need to teach MEP to read the schedule file and only show 'active at a time' manifests.

Pros/Cons

pros:

• no custom implementation, simplicity
• promo start&end time is never exposed to the user, and security concerns addressed
• no need to modify global metadata in order to schedule a promo - less risk of mistakes

cons:

• Promo will depend on publishing to work. If there is a delay in publishing - there is a delay in promo starting. If publishing is broken - promo won't start until publishing is fixed.
• 'specific time' scheduling is not yet implemented, we need to wait for Franklin team (we can use yearly cron expr till then)
• for each promo, we still have promo X [number_of_locales] amount of manifests, each of those will be a line in the schedule document, making it a long list if there are 5-10 promo/campaigns in progress. (500 lines?) but we might find a better way to deal with it. (e.g. putting all locales blackfriday manifests in one folder and publishing whole folder?)