Overview:

The Retroactive Badge Issuance enables organizations to acknowledge and reward customers for their past transactions or actions and allows the issuing of expired badges.
Example:
Suppose a brand introduces a new loyalty badge called "Gold Shopper." The badge is awarded to customers who have made a total purchase of $500 between Oct 1 - Oct 30th.

Without Retroactive Badge Issuance, a customer who reached the $500 threshold before the badge was introduced would not receive the "Gold Shopper" badge.

With Retroactive Badge Issuance, the Retroactive Badge Issuance feature allows the platform to identify customers who met the $500 threshold even before the badge was introduced.
Customers who made qualifying purchases in the past say six months ago, would retroactively receive the "Gold Shopper" badge, acknowledging their loyalty.

Key concepts:

• Event Date vs. Issual Date - Retroactive badges are based on the event date (when the customer action happened), ensuring accurate recognition. The issuance date (when the badge is awarded) triggers additional rewards or perks triggered by awarding the badge.
• Issuance expiry: Badges expire based on the current date/processing date, not the event date.
• Timezone: Retroactive badge issuances consider the timezone configured at the organisational level.
• Restrictions:
  • Fixed Windows badge constraint - If selected, restrictions will be checked based on the event date if fixed Windows restrictions are chosen for the badge.
  • Rolling windows badge constraint - Restrictions based on rolling windows are not handled in retro enrolment.

Handling upcoming, live and expired badges

Configuring retroactive badge issuance window

You can define the period that needs to be considered for the customer's past actions.

To define, perform the following:

1. Navigate to Intouch > Organisation settings > Billing.
2. Define the below configurations:
   • CONF_CLIENT_RETRO_MAX_ALLOWED_AGE_DAYS: This parameter determines the maximum allowed age (in days) for retroactive transactions. For example, if the value is set to 30 days, customers can claim badges for transactions that occurred within the last 30 days from the registration date.
   • CONF_CLIENT_RETRO_DELAY_SINCE_REGISTRATION_HOURS: This parameter introduces a buffer time or delay (in hours) since customer registration before they can claim retroactive badges.

For more information on Retro transactions, refer to the Retro transaction documentation.

Note: If the badge metadata such as the end date of the badge changes, the time until which the badge can be issued retroactively will also change based on the retro configs defined at an org level. For example, if the configured retro days are 30 and the badge expiry date is extended for 10 days, the retroactive days will be calculated from this new expiry date.

Example

Consider a badge with the following characteristics:

• Active period: October 1st to 15th
• Type: Enrol&Issue (requires both enrolment and issuance)
• Enrolment expiry: 2 days after enrolment
• Badge issuance expiry: 2 days after issuance
• Current date: October 20th
• enrolEventDate: October 10th
• Retro days configured to 30 days

Refer to the APIs below:

Enroll customers in badges

Issue badge to the customer