Manage the expiration of points in your loyalty program with Synerise

In every loyalty program where the accumulated points may expire at some point, we face the challenge of properly managing this area. The main purpose of this article is to explain the methodology of counting the expiration of loyalty points in Synerise and define the configuration with a step-by-step manual showing the pros and cons of such a solution.

Main assumptions

There are two basic approaches to loyalty point cancellation:

  1. Rolling cancellation setting up an expiration date for each loyalty point earning event.
  2. Regular batch cancellation for the entire database (mostly once a year) with specific business conditions.

In this article, we will present the first one - Rolling cancellation.

Advantages

The main advantages of this method are as follows:

  • quick change to the calculation of points,
  • flexible configuration.

Challenges

It also comes with some challenges, especially when you call yourself a modern digital company. The main challenges are:

  • First, each event with points received has its own configurable expiration time, common for each event type.
  • You need to specify and implement rules of cancellation – which points for which activities and in what timeframe should be considered in the process and which shall not.
  • Promotion deactivation is not possible (it needs to be automatically redeemed after activation – points once used may only be returned by manual intervention).
  • Points expire daily at the same time of the day.
  • Events adding and reducing points will be stored for lifetime.
  • The last thing is to inform the customer of the reduction in the points balance by an alert with information about special offers for which the lef points can be spent.

Configuration and detailed description

Let’s have a look at how we can configure rolling cancellation with Synerise.

In our case, there will be 3 types of events:

  • points.loyalty for adding points,
  • points.expire for deleting expired points,
  • and client.activatePromotion deleting points used on rewards.

We also assume that points.loyalty are 6 months due. For day-to-day precision, we will need to convert 6 months to 182 days to use in configurations. To meet all assumptions mentioned, we have to prepare a list of needed elements, described below:

1.  Aggregates summing points per event type

Create three separate aggregates summing all three types of events (points.loyalty,‍points.expire and client.activatePromotion), as in this example below for the points.loyalty event.

Figure 1. The configuration of an aggregate summing all points.loyalty events in a customer’s lifetime

2. Aggregate summing up all points that are to potentially expire on a specific day

Create an additional aggregate. The time frame is set to 20 years so we can count all historical events (20 years is a safe beginning as we cannot set infinity) up until the day we analyze points that are to potentially expire in 6 months  (in this case, changed to 182 days).

Figure 2. The configuration of an aggregate summing all points.loyalty historical events up to the date points are to expire

3. Expression summing up aggregates with all lost points (both expired and redeemed)

As the next step, create an expression summing up all spent/lost points. This expression consists of two aggregates: one counting the points used for promotions and the other one counting expired points. (aggregates summing up points.expire and client.activatePromotion events created in the first step).

Obraz zawierający tekstOpis wygenerowany automatycznie
Figure 3. The configuration of an expression summing up aggregates with all lost points (both redeemed and expired)

4. Expressions summing up points-collection aggregates into a single element (optional, for a clearer view and easier management if needed)

Build an optional expression summing the same types of aggregates that may look like the example presented below.It consists of the sum of three elements – points for registration, points earned from transactions, and points for upcharging events.

Obraz zawierający tekstOpis wygenerowany automatycznie
Figure 4. The configuration of an expression summing up aggregates with all collected points

5. Expression calculating current point balance

Create a current point balance expression based on our aggregates (and optional expressions if applicable). Subtract points lost (both redemeed and expired) from all points gathered with a simple formula presented below.

Obraz zawierający tekstOpis wygenerowany automatycznie
Figure 5. The configuration of an expression calculating the current point balance

6. Expression calculating points to expire

Create a formula that will tell how many points should be counted as expired (as some of them may have been used on rewards).

Obraz zawierający tekstOpis wygenerowany automatycznie
Figure 6. The configuration of an expression calculating points to expire

This expression is based on the condition that if the number of points gathered before the day of points expiration and the expression summing up aggregates with all lost points—including this day’s points, in our case, everything until 6 months ago (expression from step 3) is equal to or lower than the number of points spent/lost (expression from step 3), then we assume all gained points were redeemed. We have nothing to expire - the expression returns 0.  

If not, we subtract points redeemed/expired from points gathered and return the result that equals the number of points to expire.

7. Segment of users that have points to expire

Next, create a segment of users that will be the audience for a daily automation. The decision will be based on two conditions.

  • 6 months ago, they had any number of the events that may be potentially expired (simplified to one event points.loyalty in our case, others may be added with OR),
  • The result of the expression from step 6 is more than 0.

Thanks to that the automation will be run only when necessary.

Figure 7. The configuration of a segmentation of users who have points to expire

8. Automation workflow coordinating the whole process

Lastly, create a simple automation that runs daily, ideally a few seconds (5-10) after midnight.

Figure 8. The configuration of the automation for expiring points

What is more, the event block in this process should be built as follows:

Note that the uuid of expression from step 6lets us dynamically generate events with points number personalized for each user.

The result of such action will be such an event:

9. Optional create personalized campaign

We can also create a special early communication, serving as an alert for expiring points, to run in advance. For example, we could send a campaign that notifies users about their expiring points and highlights special offers where they can redeem them. This could be a great opportunity to boost the number of transactions and positively impact the level of points spent.

Summary

The article discusses a process designed for situations where each event involving received points has its own configurable expiration time, consistent with the event type. A key benefit of this setup is the ability to continuously monitor and communicate with customers about their point balance, as it is updated daily. Providing gradual updates about point reductions encourages more active participation in the loyalty program. This approach is more motivating than notifying users about point expiration just once a year, which can be discouraging.