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. One of the solutions we would like to share with you is the rolling expiration of points.

The main purpose of this article is to explain the methodology of counting the rolling 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 ways of expiring accumulated points in loyalty programs: batch and rolling. Both methods require a bit different configuration, starting from the main balance math expression down to specific analytics and expiration process. You can find a more detailed batch expiration description here.

An important part of the process is to create specific assumptions:

  • Each event with points received has its own configurable expiration time, common for each event type.
  • There is no limitation in the types of events collecting points.
  • 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.

Configuration and detailed description

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. 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

3. 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).

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

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 C (including this day’s points, so in our case, everything until 6 months ago) is equal to or lower than the number of points spent/lost (expression from point B), 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.

a. 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)

b. Result of the expression from point F 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:

Obviously, such an event may trigger some communication flow to the customer. We may 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.