Promo Management

[3ch023]

I want to present a concept for running promotions in Milo.
Any feedback/ideas are welcomed. Since promotion is a big topic there will be some other discussions to follow, with this one I want the community to agree on a general approach. The stuff below was already presented to GWP and now pending technical approval.

Use-case

GWP needs to run promotions on the pages during specific periods, e.g. Black Friday. Different blocks need to be replaced with the promotion variation of it, sometimes new blocks need to be injected into the page.
Team that prepares promo content, should not touch the base content of the page (because often it's different teams).

Suggested Solution

Please see the example below and this Wiki with a detailed description.

Example

For example, GWP needs to author a Black Friday promo on the Indesign page marquee.

• first, GWP creates a Black Friday promo document. It will hold all promo blocks for Black Friday, for all affected pages. The Promo document holds the info about the dates of the promotion. PROMO Document
• GWP opens the base Indesign document, previews it, and copies the hlx.page link to the Promo document. All following Blocks until the next Page link will be applied to Indesign.
• GWP copies the marquee block from the base document to the Black Friday promo one and does the required content changes
• Promo document is getting Previewed, Published, and Indexed
• Index xlsx contains the info about each promotion off and on dates and scope (all affected pages)
• Replacement of the base block with promo block is done not in the user browser, but on the edge worker (hlx.live cloudflare layer). When the page is requested the first time, JS code in the worker will request an index with all promos, check if any of the promos should apply, and replace the content. This way we can cache promotion for all users and avoid any additional performance cost.
• Sidekick plugin can be implemented to preview promo before they are active (similar to the 'instant' parameter in dexter)

[chrischrischris]

I think that we should integrate this into the milo personalization framework. It is done client-side but for simple swapping of blocks there is nearly no performance degradation.

Take a look at https://wiki.corp.adobe.com/pages/viewpage.action?pageId=2925220944 to see how it is authored.

We'd need to add on/off ability. The target team also has the ability to swap content and they have on/off already implemented, but I'm not sure you'd want to have to go through target.

[npeltier]

I agree it deserves a try for sake of simplicity of implementation.

Two concerns though:

1. even if I didn’t see the authoring side yet, initial requirement is single document edited by another team holding all variations of all the pages for a given promo. Rights / document management here is pretty unusual as that team does not generally have any rights on base documents, and I wouldn't be surprised we'd have to add some changes.
2. Sorry for being picky but promotion is not personalization. We serve same amended pages for 100% users for a given period of time. Edge work makes it just nitpicking, but let's keep it in mind for any other issue this approach brings

[npeltier]

cc @chrischrischris @3ch023 writing here what has been discussed offline.

authoring

looks like above authoring concern is almost irrelevant. Moreover personalization as stated Mariia is bringing lots of cool features we hadn't tackled yet or even thought about (preview with context switches, entitlement based personalization, adding of new content with no need of a given placeholder, and probably more). Big missing feature had already been identified and is being discussed separately in #1048

CSS Selector block matching might make it, especially if as hoped accessibility/analytics related tagging bring e.g. product name attributes (and make cards selector as simple as #photoshop) we could consider later if needed some mapping or something, but let's try hard way first :p.

One thing that has been asked though is to have some kind of overview of all on going changes that runs for one given promotion, as today internal communication is one promotion document listing page URLs, with each update listed. Obviously we don't want for ease of authoring bilateral linking (page pointing to manifest, some other documenting pointing to page), so we'll probably need some indexing of a given "moment" (see #1048), especially if we have it in pages metadata

rendering

we agreed with @chrischrischris that caching could be considered premature optimization for now. Let's try everything on the client, especially considering some personalized promotion will be needed at some point. Let's keep in mind to double check though as most important pages will have 4/5 promotions authored and we must not loose too much because of this

while thinking about #1048 another thing to double check is how confidential a future "moment" is, if we have moments authored in another place, we can still publish the dates at last moment though

[npeltier]

back to options proposed by @chrischrischris in #1048, there are several options on where moment is authored

• in the document's metadata, making usage of a given manifest optional or not (which binds us to use one manifest per page, promotion, and locale),
• as a column which could allow us to have one manifest per page and locale (warning though on parallel editing/publishing of promos)

[3ch023]

(moving my comment from #1048 here)
Before commenting on the scheduling options I wanted to ask if we agree that we have 1 manifest per page for each promotion.
Something like:
For the base 'Indesign' and 'Photoshop' pages we have:

/milo/de/de/products/indesign.docx
/milo/de/de/products/photoshop.docx
BlackFriday promo:

/milo/de/de/promotions/blackfriday/indesign-manifest.xlsx
/milo/de/de/promotions/blackfriday/photoshop-manifest.xlsx
/milo/de/de/promotions/blackfriday/fragments/indesign-marquee.docx
/milo/de/de/promotions/blackfriday/fragments/photoshop-marquee.docx
BackToSchool promo:

/milo/de/de/promotions/backtoschool/indesign-manifest.xlsx
/milo/de/de/promotions/backtoschool/photoshop-manifest.xlsx
/milo/de/de/promotions/backtoschool/fragments/indesign-text2.docx
/milo/de/de/promotions/backtoschool/fragments/photoshop-merchpods.docx

[3ch023]

(and moving a second comment from #1048 )
following an offline discussion with @npeltier, instead of using 'moment' feature, we could bulk publish of a folder for promotion scheduling.
We would need a bulk-publish document, where we specify a date range and folder path.
This feature doesn't have to be MEP-specific (actually I need to see if Milo/Franklin don't have it already).
To schedule Black Friday, GWP would then need to go to bulk-publish.xlsx document and add something like this:
start | end | folder
2023-11-23 | 2023-11-25 | /milo/promotions/blackfriday

There would be a cron job checking this file hourly or daily. If the start time has passed, the job will publish the folder. If the end time has passed, the job will unpublish the folder. On the client side, we don't have a time range check. Until the manifest is not published it won't be used. As soon as it was published it will start to apply to the page.

• of this option is that we don't need to expose the promo dates on the client side (which is an uncleared security concern for now)
• no need to have an additional client-side request to fetch 'moment date ranges'.

• is that on hlx.page blackfriday manifest will be on before the actual dates, that could be confusing to GWP. unless they will be ok to use the per-manifest-preview feature.
• no idea yet how to implement that cron job

In this case, we don't need to implement/specify a moment (blackfriday:) in the personalization metadata.

@chrischrischris @npeltier wdyt? if it makes some sense, I could investigate how this bulk publish could be implemented. If not, I could start working on option 3.

[sukamat]

Floodgate is another option for handling page level personalization. Alternate content for large releases (like MAX) are handled using Floodgate. The on/off will depend on the date range Floodgate will be enabled for. You can get some high level context in section 3.1.1.
https://wiki.corp.adobe.com/display/WP4/Milo+Floodgate+Solution#MiloFloodgateSolution-CDNEdgeWorker

If there is no connection to Floodgate based releases, what @chrischrischris proposed might be a good place to integrate promo handling.

[npeltier]

Problem with floodgate approach is that you need to maintain content in variation tree for the whole duration of the promotion preparation which can take long