A note from 2026: This article was published in 2022. SAP Commerce Cloud has moved beyond the 1905-era APIs and accelerator patterns referenced here; accelerator/JSP storefronts and the China Accelerator stock notification module should be treated as legacy, while SAP Composable Storefront and Backoffice-based implementations are now standard starting points.

Taking advantage of back-in-stock notifications, customers are informed that a product they were recently interested in has become available again. Alternatively, a customer may want to subscribe to product price updates and be notified when the price drops.

As a result, customers are more likely to return to make a purchase. These two features are often considered must-haves for almost any marketplace solution.

Their implementation and design are also considered quick and easy. In fact, this is not so—there are many considerations that are easy to miss in the design phase. In this article, I focus on the potential pitfalls and best practices in implementing “Back-in-stock notifications” and “Price drop alerts”.

Overview

There are “Notify When in Stock” and “Notify When Price Drops” buttons that appear on product pages and optionally on list and search pages for sold-out products. Clicking these buttons subscribes a customer to product stock or price updates.

“Notify When Price Drops” is displayed, or active, only for products available in stock. “Notify When In Stock” is displayed, or active, only for products not available in stock.

When a product is back in stock or a product price decreases, a customer expects to be notified as soon as possible. After the notification, the customer expects the product to be available within hours or a few days. For price alerts, the customer expects the product price to remain as advertised.

A customer can subscribe to be alerted about the price drop of a product they are interested in. When the price of the product drops, the shopper receives an automated notification informing them about the change.

Alerts are sent only when the product price decreases for the first time or when a product gets back in stock.

A customer does not want to receive unwanted notifications. If that happens, the customer may want to cancel all further notifications and all subscriptions associated with their e-mail address.

Users

Any large e-store has at least two types of users: authenticated and anonymous, or unauthenticated/public. Users of both types can browse the catalog and often place orders.

Both types of users should be able to subscribe to receive updates regarding an out-of-stock product or a price drop. There are, however, essential differences beyond the UI.

Registered/Authenticated Users

A registered user is one who created an account; an authenticated user is one who has successfully logged in with the credentials associated with the account. Authentication is obviously possible only for users who have already registered in some way.

There are basically two subtypes of authenticated users:

So, you need different behavior for the Notify Me buttons in these cases.

Additionally, there is soft-token and hard-token authentication. SAP Commerce supports cookie-based authentication, also called “soft-token”, to distinguish it from hard-token authentication based on the password. A customer authenticated with the soft token needs to provide a password and log in fully to access account-related functionality or proceed through checkout. In our case, it is required to access the customer’s e-mail address. For users authenticated using the soft scheme, an e-mail is not available until the customer logs in with the login and password.

This creates a challenge when a “Notify me” button is designed to work without a page reload. The system should handle soft-token and hard-token authentication and redirect the customer to the login form if necessary, as well as redirect the customer back from the login form to the original page.

The use of social networks to authenticate on websites has become increasingly popular. Social networks may not provide users’ email addresses required for the alerts, even after successful authentication. Clicking a “Notify” button creates a subscription silently only if all information is available to the system. If not, a form should appear for collecting the e-mail address and other pieces of information, such as first name, last name, and user consent.

Technically, the registered user should accept terms and conditions on the first use of the alerting functionality, or this checkbox should be added to the registration form. You probably need to request user consent on the first use of the new functionality or ask users for consent after the first login.

Anonymous Users

There are some challenges associated with supporting anonymous users. Of course, you need to ask for consent, e-mail address, and a customer name to create a subscription because all this information cannot be pulled from the profile, since there is no profile attached to the session.

However, after the first form submission, some information can be stored in the session, at least temporarily, to avoid filling out the form again and again for all further uses of Notify Me. Should the subscription be saved in the session so that a subscription form does not have to be shown again? Should this information, stored in the session, be merged in some way with the user account after the user decides to authenticate? Although this is probably a minor edge case, it is useful to know that such situations exist and how they will be handled.

Will the buttons change their look from “Notify me...” to “Unsubscribe” in this case for the products from the subscription list? Or at least become inactive, or grayed out?

Regarding anonymous users, the next big question is whether they have to confirm their e-mail by clicking the link in the confirmation email.

Should you implement something to prevent bots from entering data into the form fields? It might become a big problem when some users who have nothing to do with your website receive a branded e-mail saying that they have subscribed to something. It may give the impression that your marketing department is using this mechanism to promote the brand and invite users to visit the website. I believe many of you have received spam messages like this.

Usually, there are two ways to reduce the risk of unwanted subscriptions: CAPTCHAs and e-mail confirmation, or double opt-in.

A CAPTCHA protects your website from harmful bots, but it is a bad design choice, and you will get fewer users who use your notification service as a result.

Double opt-in?

An email confirmation is used to verify whether a user’s email address is legitimate. The subscriber receives a confirmation email that includes a link for activating the subscription.

However, this approach increases the number of steps a user must take to subscribe. If you don’t save the user status in the website session, you have to send confirmation e-mails for each subscription happening within the same session. In other words, if a user subscribed to three products, they will have to confirm their e-mail address three times to activate all three subscriptions. Of course, this is also a bad design choice. To simplify the user experience, storing confirmation status in the session is important. However, ask yourself if this process differs from normal registration. As a result of such complexity, the system becomes error-prone and unnecessarily complex, redundant processes are introduced, and new challenges are created.

Subscriptions

Notify Me Buttons

A “Notify Me When In Stock” button should be available only for out-of-stock items that are not marked as “discontinued” and for products having no subscriptions for the current user.

When it comes to discontinued products, it is better to suggest substitutes than to allow the customer to create a subscription that will never work.

“Don’t Notify Me About This Product” button

For authenticated users, it is trivial to implement such a button. Since the user is authenticated, the website trusts all calls coming from the frontend and having the token. For anonymous users, things are not so straightforward.

Using the website anonymously makes it difficult to determine whether a user has subscribed to a product or not. For such users, Notify Me When In Stock will be displayed even if the subscription for the product and the user exists, and Don’t Notify Me for This Product will not be displayed.

The reason is related to the parameters for such unsubscribe or get-the-subscription-status calls. Storing only e-mail, name, and consent in the session is not sufficient for this purpose. It is simply insecure. Technically, each subscription can have a hard-to-guess ID assigned at the moment of subscription, which would be a great candidate for the parameter for the unsubscribe and get-the-subscription-status APIs. It means that the session on the front end should contain a list of complex IDs associated with product IDs so that the unsubscribe-me link can be properly rendered. The backend cannot provide an unsubscribe API for which these three pieces would be sufficient. If it did, it would be possible to send unsubscribe requests for e-mails not belonging to the current user.

Alternatively, you can send a confirmation e-mail to a user who created a subscription that was attempted to be revoked. This approach adds complexity too.

So the solution with storing a list of complexID-productId in the session still exists, but this solution seems overcomplicated for this purpose. If you feel that such security measures are excessive, you can go with an API receiving only an e-mail and productId as parameters. However, such an approach would make your system less secure.

Registry of Subscriptions

Internally, it would be helpful to know whether the customer has been notified about the restocking of a product or if their subscription has expired. It is useful not only for stats, but also for planning marketing activities and predicting sales. In addition to that, it aids in troubleshooting and gives a good indication of how efficient the service is.

It might be helpful to provide a list of active subscriptions under the My Account section for registered users. It would make the subscription process more transparent.

Is it necessary for anonymous users to see all subscriptions associated with their e-mail addresses through the link in the e-mail they receive? It may seem like overkill to me, but customer support and administrators should have this kind of capability for supporting customers.

How Often and When to Stop

As soon as the first notification is sent, back-in-stock subscriptions expire. However, the expiration date should probably be set to a reasonable period, such as a few days, weeks, or months after the subscription date.

While things are relatively easy for back-in-stock notifications, Price Drop Alerts present a more complex case and a bunch of edge cases to handle.

An alert can be sent if the difference between a baseline price and a new price exceeds some value greater than 0. The minimum deviation is important in cases where the price comes from the automatic pricing service and can slightly fluctuate around some value.

If the price continues to drop, should the customer be kept informed? Yes. Price baselines should be recalculated after the first notification so that the next comparison occurs against updated prices. The recalculation logic should take into account the first baseline.

For example, if a customer subscribes to price drop alerts for Product X ($100), whose price drops to $90 the next day, then increases to $110 a day later, and then drops to $105 one more day later, you should not inform the customer about the drop from $110 to $105 because $105 is greater than $100, which was the price at the time of subscription. However, the first drop from $100 to $90 should trigger a notification.

We need to consider whether we should notify customers if the price drops from $105 to $95 in the above example. Technically, it is a drop below the initial value. Technically, it is a sufficient condition to send a notification. But the last e-mail the customer received showed $90, which is less than the price from the notification the customer may receive today, which is $95. As an option, you can inform the customer only about drops below the minimum price since the time of subscription.

How often should such price drop alerts be sent? It should be configurable to keep the e-mail traffic under control.

When should you stop notifying users of price changes? The simplest case is making the subscription expire right after the price drop alert is sent—so, it is going to be a one-time price drop alert. The next level of complexity is to set some expiration time, in days, weeks, or months, and notify the customer regularly, with a configured frequency, each time the price drops from the value from the previous notification.

Handling Languages and Currencies

The subscription should contain the current website language, currency, and URL of the product page to present the information and the link to the product page in the e-mail.

Handling Discontinued Products

If it is known that the requested product will not be available at all, it will allow us to estimate the demand and suggest appropriate substitutes.

If a product is marked as discontinued and it is known that the stock will never become positive, such subscriptions should be automatically canceled. If possible, all subscribers should be notified about the substitutes.

Handling Multi-site Products

In SAP Commerce, a product can be used on different websites. How should a link in the e-mail be formed then? The SAP Commerce OOTB implementation stores this information in the subscription, which is called “interests” there. There are, however, some challenges associated with using this functionality for anonymous users. The sessions on Website A and Website B are different, since the sessions are different for different domains. Visiting the product page on Website B will not take into account the subscription status from Website A, since A and B have no shared session.

Handling Variant and Configurable Products

Variant and configurable products have complex availability and pricing rules depending on user input. The button should be displayed for a product with all these parameters defined. It will make it difficult to add this product to list or search pages where an item does not correspond to a single SKU but to a group of SKUs, or variants. Depending on the product model, implementing such buttons on product pages may also be non-trivial.

Handling Duplicate Subscriptions

An unauthenticated user may not be able to be identified as a subscriber if the information is not present in the current session. For such users, Notify Me When In Stock or Notify Me If Price Drops will be displayed even if the subscription for the product and the user exists. The system should update the subscription once a form with an e-mail address is submitted and display a message saying that the subscription was found and updated.

As a result, the system should not create duplicate subscriptions for the same e-mail address and product combination. For price drop alerts, the latest price should be considered the baseline.

Canceling subscriptions

The user should be able to cancel all regular notifications coming to their e-mail.

For back-in-stock notifications, per-product cancellation does not make much sense, because the subscription expires automatically at the moment of notification. However, the customer may be unhappy with receiving any notifications of this kind. There should be an option to cancel all notifications by following a link from the e-mail.

For registered users, the cancellation can be made in the My Account area. For anonymous users, it can be a link with a subscription ID, which should be hard to guess, of course.

There are several levels of complexity in how it can be implemented:

For Back-in-Stock notifications:

For Price Drop Alerts:

This functionality should be provided to Customer Support Agents as well.

Notifications

Handling Product URLs and Categories

Whenever a product is moved from one category to another, the URL of the product page should remain the same. It can be done by introducing category-aware URLs for products.

A product can be available in different categories, such as “Vacuum cleaners”, “New”, and “Christmas Sale”, but a customer subscribes to one from a particular category, such as “Vacuum cleaners”. So, probably, if a product is available in several categories and accessible with different URLs, it is recommended to use the original URL in the notification. However, if the product was moved out of that category, the customer should not see a 404 error. Instead, the customer should be redirected to the new category of the product.

Handling Availability and Price Groups

Product availability might be conditional by nature. Some products might be available for some users and not available for other users—based on their location or status. When a user sees a product as unavailable, and a Notify me button there, it might not mean that the product is unavailable for any user.

There might be a similar case with prices. Prices might differ for different users and locations. So the price drop should be calculated on a per-user or per-user-group basis.

As many small aspects of the requirements and constraints affect the solution, supporting different prices and availability groups is actually a big challenge.

Handling multiple subscriptions

If a user is subscribed to several products and more than one product gets back in stock, the simplest approach is sending one e-mail per product. Normally users don’t subscribe to many products for stock updates, but this might not be the case for price drop alerts.

It might be helpful to group the price updates and send them as a single e-mail.

Minimum Inventory and Price Drop Rules

Minimum Inventory refers to the number of items that must be restocked before you notify subscribers. When an item is in high demand, you might receive hundreds of subscription requests. Having one item restocked does not mean you should email everyone about it. Yes, sending 10,000 notifications saying “New iPhone 14 finally arrived!” when only three items actually arrived would be weird. It is likely that many customers would be dissatisfied.

To alert people that the item is back in stock, you might have a threshold at which you consider the volume significant.

A similar situation exists with Price Drop Alerts. A notification such as “iPhone price dropped! One dollar off” would seem ridiculous. It would therefore be useful to configure a certain drop, percentage, or absolute value. Also, take into account that different price ranges may need different approaches. $1 off for a $5 product is actually a 20% drop. For the customer, a 20% drop for the new iPhone and a 20% drop for a $5 product have different value.

Notification intervals

If you send separate e-mails per product, sending a bunch of e-mails in one go might be a bad idea. There are actually two sides to the problem:

Distributing the notification over time and adjusting the volume of notifications based on sales and stock changes is the solution.

For example, you can specify the maximum number of subscriptions a product can have, sorted by the age of the subscriptions, and the interval between sending the next batch of emails. By distributing e-mail alerts over time, you can avoid receiving more orders than you can fulfill.

If a product is restocked and the number of users to be notified is set to 10, the system should inform the first 10 users subscribed to that product first. The system should wait for a few minutes, let’s say 5 minutes, so that these 10 users can come and buy. The notifications will be sent in batches of 10 with a 5-minute interval between each batch until a certain threshold is reached. Additional emails will not be sent until the waiting period has ended if additional items are restocked during the waiting period. Following the waiting period, we will determine the number of items in stock for this item and inform the subscribers accordingly.

In order to avoid clogging up the user’s inbox, grouping the notifications together into fewer e-mails would be a great solution. It is especially important for price drop alerts when a user may have dozens of subscriptions that do not expire after the first notification. Alternatively, it is useful to have a configuration parameter that determines how long to wait between batches of emails. With this setting, some alerts may come with some delay.

Service Suspend/Restore

Customer Support or administrators should be able to temporarily suspend the service if any issues are identified. Of course, the technical support team should be able to restore the service when the issues are resolved.

This means removing all Notify Me buttons from pages if the service is suspended, and also stopping the notification service.

Suspend/restore is often considered optional and unimportant until issues arise.

Integrating with Web Analytics

The web analytics system should be immediately informed of a user clicking on the notification link and configured to generate reports on conversion to engaged users or orders from notified users.

Reporting

Administrators should be able to generate reports on:

What SAP Commerce Provides Out-of-the-box

Stock Notification Module is part of the China Accelerator.

It is generally a basic implementation, but extendable, and due to its inefficiency for big volumes, such as traffic, product set, and product interests, it might present problems. Also, involving similar products in the notifications is questionable.

However, the module can be taken as a reference for the full-scale solution.

Price drop alerts are not implemented in SAP Commerce OOTB.

SAP Commerce stock notification module screenshot

Solution Design

Assumptions:

Back in Stock Alerts

Back-in-stock alert solution design diagram

Price Drop Alerts

Price drop alert solution design diagram

Rauf Aliev

Solution Architect, Chief Software Engineer II
EPAM