Catalog promotions

[Arminek]

👋 Hello, Sylius community,

In the core team, we were discussing how to tackle catalog promotions. I would like to share our perspective on this topic with you, but before we jump into the proposition, let’s build a shared understanding of the problem.

Here is the story:

As a store owner, I want to make a discount for all products within a taxon by 50% starting 2021-03-21 and ending 2021-12-12

Okay, so let’s break down this case into few problems and possible solutions

1. How to store configuration about this type of promotion?
   • New entity “CatalogPromotion” with a new rule and action engine.
   • Modify the current promotion system and add different types of promotions.
   • …
2. How to correlate product (variant) with the discount source?
   • Add relation with “CatalogPromotions” on the product variant.
   • …
3. How to apply discounts on the product catalog in a given period? & How to deal with a 500k+ product catalog?
   • Add some sort of price matrix.
   • Background process
     • Cron job every x time check if there is any catalog promotion to be applied and change catalog prices
     • Process manager with event-driven architecture. (Base on Symfony messenger: default implementation will be sync but using transport configuration you can switch to an async background process.)

This example story is straightforward, and of course, there are more complex cases, but let’s focus on this.

We would be very grateful if you could share any thoughts about this topic. Cheers!

Relates to:

• Promotions: Catalog price rules · Issue #7977 · Sylius/Sylius · GitHub
• Promotions at product level should be visible on frontend - Catalog Promotions · Issue #9851 · Sylius/Sylius
• URBANARA/UrbanaraCatalogPromotionPlugin
• Setono/SyliusCatalogPromotionPlugin: Create catalog promotions in your Sylius store. Allows you to easily setup rules to change prices on all your products
  • Exemplary live usage of this plugin: https://www.2trendy.dk/
• Locastic/SyliusCatalogPromotionPlugin: Sylius plugin for promoting products prices based on catalog logic.
• Snake-Tn/SyliusCatalogPromotionPlugin: Sylius plugin for catalog promotion
• BitBagCommerce/SyliusCatalogPlugin: BitBag SyliusCatalogPlugin Allows for displaying catalog with products - calculated dynamically with rules.
• Customize sales in Sylius-based eCommerce - Sylius Catalog Plugin
• Setono/SyliusCalloutPlugin: Adds callouts / badges to your products

[loevgaard]

This would be wonderful to have in the Sylius core. I would love to help everything I can.

So first of all your use case is too simple to actually outline the 'real' difficulties with catalog promotions: Here is a more complex use case:

As a store owner I want to make a discount of 50% for all products in taxon x for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59 (possibly even handling timezones on channels)

What are your internal thoughts on this? Is this something you want to handle in the first version of this feature?

I have a few ideas on how I wanted to tackle this in my own plugin, but I think it would be great if we handled it in the core if you're up for it :)

[loevgaard]

And I just want to clarify why I would like to discuss this more complex use case: With your use case it would be sufficient to update the channel pricings (which is what I do in Setonos plugin), but with this more complex use case prices should be output dynamically.

[CoderMaggie]

Everything besides timezones we are considering within the first version of this feature :) 💪🏼

[Prometee]

If we want to keep the actual promotion behaviour and just add a new capability :
I would like to propose to add a display section to the actual promotion form, allowing to choose how the promo will be displayed (PromotionDisplayType?).
Example :

• "Catalog promo (public)"
• "Catalog promo (restricted with rules)"
• "Cart displayed (eg: 'Hey ! Add X more to get the promo')".

Or we can imagine a dedicated page in the admin allowing to choose what will be inside this PromotionDisplayType

• "Catalog promo (public)" simply choose what promos will be displayed
• "Catalog promo (restricted with rules)" choose what promos will be displayed and rules to apply
• "Cart displayed" choose what promos will be displayed and rules rules to apply

The rest is an extensive use of the OrderProcessor cached for each product and variant.

I never used promotions from other products than Sylius so maybe there is better ideas than this one.

[CoderMaggie]

As Sylius is becoming rather API-first lately, then I cannot promise we will add this functionality to Sylius, but I have also been thinking about it.

Regarding the catalog promotions, I have proposed two fields: label and description.

The label is meant to be displayed on/around/near the product's main image - but I am not considering any display method yet, for headless Sylius shops this leaves unlimited options of the display, and the model could be extended with configurable display types. For core Sylius I'd go with one, overridable display type (+docs).

The description is designed to be an explanation text, where the Admin could elaborate on how long will the promo be on etc.

[loevgaard]

Based on the answer from @CoderMaggie here are a few opinions:

• I don't think we should mix catalog promos and order promos. My fear is that this will end up with a bad developer experience and bad/difficult user experiences. A platform like Magento also separate these two features into what they call 'cart price rules' and 'catalog price rules'

• When you want to handle the use case I wrote above I believe a relation to a catalog promotion entity is a good move.

• How to handle hundreds of thousands of products? What we do in the callout plugin (which you also referenced) is that we relate products to callouts before they are active and then we filter active callouts in the frontend (in our case using a twig filter). Here is an example so it's easier to understand: I want to discount all products on black friday and I have 1,000,000 products. Depending on your server setup this could take minutes or maybe even hours to do (hopefully not :D), but if I made this catalog promotion a week ahead then we had a week to add this promo to all products and then when black friday appears (i.e. a date threshold is met) a filter would loop through all related promos and 'activate' the ones where all checks pass (other checks could be customer group, channel, loyalty points or anything else).

With this setup there is still an obstacle: How do we know or how do we decide when to update/assign catalog promotions? If we did it every time a catalog promotions was created it could easily be that it would run 10 times in a row (because the administrator updated/created 10 promos). And what about product changes? The rules would most like be affected by taxon or product changes, so should we also run it each time a product changes? What we do in the catalog promotion plugin is to check updatedAt timestamps on affected entities and then we run the 'assignment process' if these entities were changes since the last run. I am not a big fan of this approach, but it works.

[nikkuexe]

A platform like Magento also separate these two features into what they call 'cart price rules' and 'catalog price rules'

As someone who has come from the Magento platform, I can say that this method works well. It's a logical separation of promotions that occur within the cart (mostly coupons), and promotions that are shown directly on the product page.

[wlwwt]

another three cases

As a store owner I want to make a discount of 100€ for a special combination of products in my cart for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59

As a store owner I want to make a discount of 50% for all products in taxon x except selected products for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59

As a store owner I want to discount a flexible amount of a selected product for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59 => buy 4 get one free

[loevgaard]

As a store owner I want to make a discount of 100€ for a special combination of products in my cart for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59

This is not a catalog promotion and can be done already in Sylius

As a store owner I want to make a discount of 50% for all products in taxon x except selected products for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59

This doesn't change the implementation, this is just another rule

As a store owner I want to discount a flexible amount of a selected product for customers in group b2b starting 2021-08-01 00:00:00 and ending 2021-08-07 23:59:59 => buy 4 get one free

This is also an order promotion, not a catalog promotion and can be done already

[Arminek]

Thank you all very much for your feedback. We are currently considering event-driven architecture to apply catalog promotions, which will be based on Symfony messenger with doctrine transport layer in the standard implementation. We believe that this kind of approach will be the most flexible for our community to replace/extend/change.

Let me explain how it could work:

As a store owner, I want to discount 50% for all products in taxon swords starting tomorrow, and it will take 5 days.

Let's break it down into few problems as we did in the previous example:

Storing catalog promotion configuration

A new entity with all information about rules & actions that will take on the product catalog.
In this case, it will be:

startAt: tomorrow
endAt: tomorrow + 5 days
rule: products in taxon "swords"
action: 50% discount

Triggering change on the product catalog

The default implementation will be based on delayed messages (This can also be an effortless cron job that will run every 10 minutes. Delayed messages will reduce the number of triggers to check if now is the time to apply promotion).

During the creation of the catalog promotion, we will delay a message. In this case, it will be 24h.

Start of the promo:
(catalogPromotionApplied) -> (...) -> (channelPriceChanged) -> (catalogPromotionAssigned)

End of the promo:
(catalogPromotionEnded) -> (...) -> (channelPriceChanged) -> (catalogPromotionAssigned)

... -> here will be a place to implement messaging optimization algorithms. Like for example, in the case of big catalogs, some chunking mechanism.

Regarding customer groups, it is a different type of problem. I am going to open a new discussion about this topic soon, so stay tuned.

[loevgaard]

Hi, @Arminek

Just to clarify your idea. Do you want to force the usage of a doctrine transport to use a database table to hold delayed messages and then have a consumer reading from that table/queue?

[Arminek]

@loevgaard We are aiming for September. This is a forecast tho 😄

[loevgaard]

We are considering using doctrine transport by default. It does not mean that we want to force using it

Do all Messenger transports support delayed messages?

[stloyd]

We are considering using doctrine transport by default. It does not mean that we want to force using it

Do all Messenger transports support delayed messages?

Yes, it's handled by stamps: https://symfony.com/doc/current/messenger.html#envelopes-stamps to be more accurate by DelayStamp.

[loevgaard]

@stloyd: Weird that I haven't noticed that. That's a great feature :D Thank you for enlightening me :)

[Arminek]

I am not sure how it will work with InMemoryTransport. For sure, we are going to use it in test env to do not handle time in our test suite 💃

[Arminek]

@loevgaard We have started the first sprint about catalog promotions 🎉

[loevgaard]

Cool! Thanks for updating. I appreciate that 😊

[Arminek]

🖖 Hello,

We have finished two sprints so far 🎉 .
Demo

Features that we have covered:

• As an Admin, I want to create a catalog promotion with a rule and action
• As an Admin, I want to disable/enable a catalog promotion
• As an Admin, I want catalog promotions to be reapplied on variant once the product variant's data changes
• As an Admin, I want Catalog Promotions to be reapplied on a correct set of variants after editing them
• As a Customer, I want to see products'/variants' discounted in the catalog
• As a Customer, I want to add a product with discounted catalog price to my cart

Our next goals:

• As an Admin, I want to specify a taxon based catalog promotion rule
• As an Admin, I want to create a Catalog Promotion with a start and end date 🔥
• As a Customer, I want to sort products by their discounted prices

If you want to help us deliver the best quality you can contribute by testing what we did so far 💃

[loevgaard]

Thanks for the update, @Arminek! Is the 'scope' somewhat equivalent to the rules in promotions?

[Arminek]

@loevgaard What do you mean by equivalent to the rules in promotions? Are you referring to the existing cart promotion engine?

[loevgaard]

Yes, the existing cart promo engine. I.e. the scope is a set of rules to match variants?

[Arminek]

Some of them will be quite similar to the existing promotion engine. But definitely not all of them.

[loevgaard]

Yes, of course. Thank you :)

[Arminek]

🖖 Hello,

Features that we have covered:

• As an Admin, I want to create a Catalog Promotion with a start and end date 🔥
• As an Admin, I want to specify a taxon based catalog promotion rule

Our next goals:

• As an Admin, I want to prioritize catalog promotions
• As an Admin, I want to edit the start and end date of a catalog promotion
• As a Customer, I want to sort products by their discounted prices
• As an Admin, I want to specify a minimum price of a product
• As an Admin, I want to specify a product based catalog promotion scope
• As an Admin, I want to mark a Catalog Promotion as exclusive

Demo
Concept
How to add a custom catalog promotion scope?

I would like to start testing it for big product catalogs. Do you have any SQL to share with a huge amount of products & variants (500k variants)? cc @loevgaard @stloyd @Prometee @Roshyo @vvasiloi

[vvasiloi]

From a recent experience I can say that the performance in this case does not depend on the number of products and variants, but on the amount of promotions and their related resources (like taxons).