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