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

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

Their implementation and design are also considered to be quick and easy. In fact, it is not so — there are many points for consideration 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
• Users
  • Registered/Authenticated
  • Anonymous
    • Double opt-in?
• Subscriptions
  • Notify Me Buttons
    • Don’t Notify Me About This Product
  • Registry of Subscriptions
  • How Often and When to Stop
  • Handling Languages and Currencies
  • Handling Discontinued Products
  • Handling Multi-site Products
  • Handling Variant and Configurable Products
  • Duplicate Subscriptions
  • Canceling Subscriptions
• Notifications
  • Handling Product URLs and Categories
  • Handling Availability and Price Groups
  • Handling Multiple Subscriptions
  • Minimum Inventory and Price Drop Rules
  • Notification Intervals
• Service Suspend/Restore
• Integrating with Web Analytics
• Reporting
• Solution (diagrams)
  • Back in Stock Alerts
  • Price Drop Alerts

Overview

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

“Notify When Price Drops” is displayed (or active) only for the products available in stock. “Notify When In Stock” is displayed (or active) only for the products NOT available in stock.

When a product is back in stock or a product price decreases, a customer expects to get notified at the earliest. After the notification, the customer expects the product to be available within hours or a few days. For the price alerts, the customer expects that the product price will 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 doesn’t want to receive unwanted notifications. If such happens, a customer may want to cancel all further notifications and all subscriptions associated with the e-mail address of the customer. 

 

Users

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

Both types of users should be able to get subscribed to receive updates regarding an out-of-stock product or 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 were already registered in some way.

There are basically two subtypes of Authenticated users: 

• Authenticated users with an email on their stored profile and 
• Authenticated users without an e-mail on their stored profile. 

So, you need to have different behavior of the Notify Me buttons for these cases.

Additionally, there is soft-token and hard-token authentication. SAP Commerce supports cookie-based authentication, also called as “soft-token”, to distinguish it from the 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 the account-related functionality or proceed through checkout. In our case, it is required to get access to the customer’s e-mail address. For the users authenticated using the soft scheme, an e-mail is not available until the customer logs in with the login and password. 

It creates a challenge when a “Notify me” button is designed to be working 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 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 for the system. If not, a form should appear for collecting the e-mail address and other pieces of information such as name, last name, and user consent.

Technically, the registered user should accept terms and conditions with the first use of the alerting functionality or this checkbox should be added to the registration form. Probably, you need to request user consent with the first use of the new functionality or ask the 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 name of a customer 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 won’t have to be shown again? Should this information (stored in the session) be merged in some way with the user account after the user decided 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 (grayed)? 

In regards to 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 fields of the form? It might have become a big problem when some of the users having 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 received spam messages like this. 

Usually, there are two ways to reduce the risk of unwanted subscriptions: CAPTCHAs and e-mail confirmation (a 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, a user will have to confirm their e-mail address three times to activate all three subscriptions. Of course, it 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 which 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 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 the Don’t Notify Me for This Product won’t 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 the purpose. It is simply insecure. Technically, each subscription can have a hard-to-guess ID being assigned at the moment of subscription, and 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 productIDs so that the unsubscribe-me link could be properly rendered. The backend can’t provide the unsubscribe API for which these three pieces would be sufficient. If it were so, 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 to be overcomplicated for the purpose. If you feel that such security measures are excessive, you can go with the API receiving only an e-mail and productId as parameters. However, such approach would have made 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 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. Although, the expiration date should probably be set in a reasonable period, such as a few days, weeks, or months after the subscription date.

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

An alert can be sent if a difference between a baseline price and a new price exceeds some value (greater than 0). The minimum deviation is important for the case if 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, a customer subscribes to price drop alerts Product X ($100), which 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 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 only below the minimum price since the time of subscription.  

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

When to 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, months) and notify the customer regularly (frequency should be configured) each time the price drops from the value from the previous notification. 

 

Handling Languages and Currencies

The subscription should contain a current website language, currency, and the 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 cancelled. 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 to form a link in the e-mail 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 won’t take into account the subscription status from Website A since there 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 the list or search pages where an item doesn’t correspond to a single SKU but a group of SKUs, variants. Depending on the product model, implementing such buttons on the product pages can be also not 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 the price drop alerts, the latest price should be considered as a 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 doesn’t make much sense, because the subscription expires at the moment of notification automatically. However, the customer may be unhappy with receiving any notifications of the kind. There should be an option to cancel all notifications by following a link from the e-mail.  

For the registered users, the cancellation can be made in the My Account area. For anonymous users, it can be a link with a subscription id (hard-to-guess, of course). 

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

 

For Back-in-Stock notifications:

• Simplest: cancel all existing subscriptions associated with the e-mail. It doesn’t affect new subscriptions. 

 

For Price Drop Alers:

• Simplest: cancel (deactivate) all existing subscriptions 
• Deactivate the current subscription or all subscriptions
• Deactivate any subscriptions interactively in the My Account area

 

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 the category-aware URLs for the products. 

A product can be available in different categories (“Vacuum cleaners”, “New”, “Christmas Sale”), but a customer subscribes to one from the particular category (“Vacuum cleaners”). So, probably, if a product is available in several categories and accessible with different URLs, it is recommended to use an original URL in the notification. However, if the product was moved out from 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. The prices might differ for different users and locations. So the price drop should be calculated on a per-user or per-usergroup 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 it 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 10000 notifications “New iPhone 14 finally arrived!” when only three items actually arrived would be weird. It is likely that many customers will 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 is 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 the $5 product is actually a 20% drop. For the customer, a 20% drop for the new iPhone and for a $5 product have a 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 of the problem:

• It is not appreciated by your customers if you send tons of similar-looking e-mails and clog up their inboxes with notifications about different products.
• The notification service will be inefficient if it informs too many potential buyers (more than you have available products for sale).

Distributing the notification over time and adjusting the volume of notifications based on the 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 won’t 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 are not expired after the first notification. Alternatively, it is useful to have a configuration parameter that would determine how long to wait between batches of emails. With these 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

The administrators should be able to generate reports on 

• how many subscriptions were created, 
• how many notifications were sent
• notifications to website visits
• notifications to placed orders

What SAP Commerce Provides Out-of-the-box

Stock Notification Module is part of the China Accelerator. 

• It was developed a while ago and currently supports the JSP front-end only. 
• It supports only authenticated users (The user details  are retrieved from the user account, not from the pop-up form). 
• It supports two notification channels, e-mail and SMS.
• It doesn’t support minimum inventory settings
• For each product interest (or subscription) the code runs a separate TaskExecutor task. Upon fulfilling the conditions, the tasks send notifications. 
• It uses BusinessProcess functionality to orchestrate product back-in-stock notifications. There are three steps in it performed sequentially, “generateEmail”, “sendEmail”, and “removeSentEmail”. 
• It automatically includes the “reference products”, or products linked to a requested product as “SIMILAR”. The number of such products can be restricted. So, by default, the customer receives notifications not only the requested products but the products associated with them as similar products. 
• The messages are delivered via SiteMessageService. It creates a site message by given subject, link, body, message type, notification type and locale.

It is generally a basic implementation (but extendable), and due to its inefficiency for big volumes (traffic, product set, product interests), it might present problems. Also, involving similar products into 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).

Solution Design

Assumptions:

• price groups  (different prices for different users) are not supported
• availability groups (different availability in different locations or for different users) are not supported 

Back in Stock Alerts

Price Drop Alerts

 

Rauf Aliev

Solution Architect, Chief Software Engineer II
EPAM