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.
There are two basic approaches to loyalty points cancellation:
In this article, we will present the first one - Rolling cancellation.
The main advantages of this method as following:
It also comes with some challenges, especially when you call yourself a modern digital company. The main challenges is:
Let’s have a look how we can configuration rolling cancellation with Synerise.
In our case, there will be 3 types of events:
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:
We create lifetime aggregates for all three events as in this example for points.loyalty.
As the next step, we create an expression summing up all points that are lost/spent.
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).
We build an optional expression summing the same types of aggregates that may look like the example presented below.
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.
We also need a formula that will tell how many points should be expired (as some of them may have been used on rewards).
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, in our case, everything until 6 months ago) is equal to or lower than the number of points spent/lost from point B (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.
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.
Thanks to that automation will be run only when necessary.
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:
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.
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.