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 proper management of this area. The main purpose of this article is to explain the methodology of counting the expiration of loyalty points in Synerise, explain the configuration with a step-by-step manual and show the pros and cons of such solution.

Main assumptions

There are two basic approaches to loyalty points cancellation:

  1. Rolling cancellation setting up 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 as following:

  • quick change to the calculation of points,
  • configuration is flexibility.

Challenges

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

  • First of all, 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 lifetime.
  • The last thing is inform the customer of a reduction in the points balance by the alert with the information about special offers for which we can spend points that left.

Configuration and detailed description

Let’s have a look how we can configuration 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 into 182 days and use this in configurations. To meet all assumptions listed before, we have to prepare a list of needed elements which will be described below:

1.  Aggregates summing points per event type (both adding and consuming points).

We create lifetime aggregates for all three events as in this example for points.loyalty.

2. Additional aggregate counting all points that are potentially expiring on a specific day.

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

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

As the next step, we create an expression summing up all points that are lost/spent.

Obraz zawierający tekstOpis wygenerowany automatycznie

This expression consists of two aggregates: one counting the points used for promotions and the sum of expired points.

4. Expressions summing aggregates into single elements (optional, for a clearer view and easier management if needed).

We build an optional expression summing the same types of aggregates that may look like the example presented below.

Obraz zawierający tekstOpis wygenerowany automatycznie

It consists of the sum of three elements – points for registration, points earned from transactions, and points for upcharging events.

5. Expression calculating current points balance.

We have to also create a current points balance expression based on our aggregates (and optional expressions if applicable). We need to subtract points lost from points gathered with a simple formula presented below.

Obraz zawierający tekstOpis wygenerowany automatycznie

6. Expression calculating points to expire.

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

Obraz zawierający tekstOpis wygenerowany automatycznie

This expression is based on a condition that if a number of points gathered until expiring points day comes – expression from point 2 (including this day’s points, in our case, everything until 6 months ago) is equal to or lower than the number of points spent/lost from point 3 (expression ), then we assume all gained points were redeemed and we have nothing to expire (expression returns 0). If not, we subtract points redeemed/expired from points gathered and return the result which equals the number of points to expire.

7. Segment of users that have points to expire.

Now we need to create a segment of users, for whom we will run this daily automation. The decision will be made based on two conditions.

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

Thanks to that automation will be run only when necessary.

8. Automation workflow coordinating the whole process.

Last, but not least, we create simple automation run daily, preferably at least a few seconds (5-10) after midnight.

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

Note that this expression from point 6. uuid lets us generate events with points number dynamically and personalized for each user.

The result of such action will be such an event:

9. Optional create personalized campaign

We can also create special early communication working as an alert about expiring points run beforehand. For example, we can send a campaign which alerts users about expiring points and special offers for which we can spend those points. It might be a great opportunity to boost the number of transactions and have an influence on the spending points level.

Summary

The article discusses process dedicated for situations where every event with received points should have its own configurable expiration time, consistent for each event type. A significant simplification from this configuration is the ability to constantly monitor and communicate to customers about their point balance, given that this number is updated daily. Gradual information about the decrease in loyalty program points encourages active participation. This approach is more motivating than providing information about point expiration just once a year, which can be demotivating for users.