Skip to main content

Cheetah Loyalty Release Notes

  • Updated

Detailed information about the latest releases of Cheetah Loyalty.

 

Loyalty Version 22.3.0 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 22.3.0

Features

New Order Return Program API Allows Offer Clawback on Product Returns

Background

Retail brands with longer return policies can run into the scenario where a customer returns a product they purchased, but in the meantime the points earned from the purchase have been used to redeem a reward. This incurs extra cost for the loyalty program due to the system not fully offsetting point accrual when products are returned, and because the issued reward offer is not rescinded.

Solution

To mitigate the additional program cost this scenario can incur, Cheetah has introduced a new Order Return Program API to evaluate and execute returns that can:

  • Evaluate the returned items to assess the points to be removed from the member’s balance based on the value accrued from the original purchase.
  • Provide the current point balance of the customer, in response to the Evaluate request and if the point balance is insufficient to fully absorb the return, the API will return a list of available offers that were generated from rewards that are available to be canceled.

With this additional insight, if the member’s point balance is sufficient to absorb the return, eCommerce or Point of Sale systems can proceed with the return as-is by submitting an Execute request.  However if the point balance is insufficient to fully absorb the return, then the eCommerce or POS system can specify one or more available reward offers to be canceled in the request, causing points to be returned to the member’s account. Thereby appropriate points can be offset corresponding to value of the return, reducing the cost and liability of any extraneously issued rewards.

POS API Enforces Offer Location Eligibility

Background

Provide capability for brands that want to limit Offer access and redemption to certain locations, and the ability to execute the appropriate business rules.

Solution

Brands that submit orders to Cheetah via the POS API can now configure Offer Location Eligibility parameter and accordingly the POS API will allow or restrict offers from being returned in the Assign Member request, depending on whether the order location is permitted to access and redeem the offer.

Like Segment Eligibility allows marketers to target Offers to certain groups of members, Location Eligibility controls which locations can access and redeem an offer.  When an offer has no Location Eligibility configured (neither Included nor Excluded Locations are specified) then the offer is available in all locations. When an offer is configured with Included Locations, only those locations can access the offer, and when an offer is configured with Excluded Locations, then only non-excluded locations can access the offer.

Search Members Program API Supports Configurable Set of Returned Member Attributes

Background

Enhance search members functionality to retrieve additional member attributes.

Solution

The Search Members Program API has been enhanced to allow the API request to specify additional member attributes to be included in the response. The attributes can be standard or custom attributes.

The new input parameter to specify additional member attributes to include in the response is member_attributes[] and examples of correct usage include:

URL Parameters

curl --location -g --request GET '{{base_url}}/program/api/members?term={{search_term}}&member_attributes[]=mailing_country&member_attributes[]=mailing_street&member_attributes[]=mailing_state_custom' \

--header 'Accept: application/vnd.stellar-v1+json' \

--header 'Content-Type: application/json' \

--header 'Authorization: Bearer {{token}}'

Form Parameters

curl --location --request GET '{{base_url}}/program/api/members' \

--header 'Accept: application/vnd.stellar-v1+json' \

--header 'Content-Type: application/json' \

--header 'Authorization: Bearer {{token}}' \

--form 'term="{{search_term}}"' \

--form 'member_attributes[]="mailing_country_custom"' \

--form 'member_attributes[]="mailing_street_custom"' \

--form 'member_attributes[]="mailing_state_custom"'

 

When specified, the API will return the default set of attribute values and any additional attributes specified in the member_attributes[] input parameter.

New Permission Settings for CSR Screen Independent from Other Member Screens

Background

Before this release, programs that wanted to provision access to the CSR > People screen couldn’t do that without also providing access to other screens under the Member tab including the legacy People screen (Member list and detail pages).

Solution

This release separates the CSR > People screen from other Member screens through the updated Members resource available in Admin > Role >Permissions tab, so that it now controls access to the CSR > People screen.  A new Members (Legacy) resource has been introduced that allows access to the legacy People screen (Member list and detail pages).

To provision access to only the CSR > People screen, program administrators can create a new role or update an existing role by including only the Members resource. 

Consolidation of Tier Expiration Settings

Background

Prior to this release, the Tier Expiration Settings were managed from multiple places in the admin console.

Solution

This release consolidates tier settings under the Tier Scheme level, so for brands that have one tier scheme, this will be managed under the default or single active scheme. When multiple Tier Schemes are defined in the program, each can support its own expiration settings.

Tier_Scheme.png

Tier-related program settings that were removed in this release and consolidated under the Tier Scheme Settings include:

  • Allow member tier downgrade
  • Tier expiration description
  • Expiration Metric
  • Expiration Value

Tier Rule Settings under Rules > Settings > Tier Rule Settings have been similarly removed and consolidated into the Tier Settings.

Fixes

Fixed Local Store Marketing (LSM) to Allow Local Store Admins to Manage Segments

A fix has been made to allow LSM to expose the Segment screen to local store admins allowing them to view and manage Segments when the program has Business Units defined. This corrects a previous issue where the system didn’t properly reconcile LSM and Business Unit access control handling, causing the functionality on the Segment screen to behave incorrectly for local store admin users.

With this fix, local store admin users will have access to segment records tagged with the same store, the local store admin has access to.  Additionally, segment results will be filtered to only include members with the same Place Integration Id member attribute value, matching the store the local store admin user has access to.

Note that if a program doesn’t track a member’s Place Integration Id value (typically used when having members select a favorite store at signup), then the system will not filter the segment results to only return members with the same store as the local store admin user.

Fixed Integration with Sabre to Pull Customer Web Services Description Language (WSDL) file from New Hosting Location

Updated the Cheetah-Sabre integration to pull the Sabre Customer WSDL definition from a new hosting location.  This corrects an issue that was causing member sync between Cheetah and Sabre to fail.

Fixed Inconsistent Return Codes When Submitting Retro Claim Requests

Retro Claim return codes were not consistent when the program was using Receipt and Credit Card based retro claim schemes.  The system will now return the same code in both cases.

Fixed a Content Token Rendering Issue When Using Content Source Token Type

This fix corrects a bug that caused the system to incorrectly return the default token value instead of the value from the content source.

Fixed a Campaign Offer Targeting Issue Related to Incorrect Default Rule Score Values

Previously, campaign targeting rules would default the score to integer values (1) which caused the rules to be evaluated incorrectly, requiring manual intervention to correct.  The system now defaults the score to a decimal value (1.0) that allows the score to be correctly evaluated without changes.

Fixed a Point Expiration Issue that Incorrectly Handled Canceled Redemptions

The system did not compute points to expire correctly when the member activity history included a canceled redemption. This fix allows the system to recognize and handle this case correctly and offset any expirable points from canceled redemptions.

Fixed a Get Place Program API Issue That Didn’t Retrieve Place Records by Integration Id

The Get Place Program API didn’t correctly find matching place records when the request specified an integration id input parameter.  This fix corrected the issue and now places can be retrieved by integration id.

Fixed Push Message Validation that Incorrectly Required a Member to have an Email Specified

Previously, the system would require members targeted with Push Messages to have an email address specified, and the fix removed this incorrect validation so email is no longer mandatorily required for members who are targeted with push messages.

Fixed Handling of Gift Card Debits when Offer Lock is Disabled

Previously, when submitting a POS API request where the lock parameter was set to false, meaning no locking of Offers and other discounting objects like Gift Cards are used, the system would incorrectly reserve value on the Gift Card as it does when lock is enabled. The fix prevents a Gift Card debit from reserving a value if Offer lock is disabled.

Fixed the OLO API to Return HTTP 400 When Responding with an Error

The OLO API did not previously differentiate between successful and failed processing, returning HTTP 200 for all responses. With this fix, when a request results in an error, Cheetah will return the HTTP 4xx response code together with the body of the response.

 

Loyalty Version 22.2.0 Release Notes

Features

Mobile Wallet Enhancement

Background

Members can view their earned offers (e.g. a $25 subtotal discount) via our Mobile Wallet solution. To redeem the offers both online and in store whilst reducing fraud, some brands require the use of a Certificate Code and a security PIN. Therefore we need to store both of these details and the Mobile Wallet needs to be able to display them.

Solution

Certificate codes and PIN data attributes can now be imported through batch feeds, into Offer Responses* and exposed as a Content Source so they can be displayed in a Mobile Wallet and other channels.

There will be an online help update to follow.

 

Daily process to Update Offer Responses

Background

There are some scenarios where brands have a requirement to update the Offer Response*, for example if the offer expires, or if it is redeemed. These updates would need to be done on a regular schedule to keep offer responses up to date.

Where a brand needs to update Offer Responses, they export the Offer Responses, update the records as required and then import the updated data. 

This enables the Offer Responses status to remain in sync with systems external to Cheetah such as POS or Ecommerce systems.

Solution

A new field “Response ID” has been added to the mappable fields in the Offer Response records to enable correct updates to the records. This can be set to a daily schedule.

There will be an online help update to follow.

 

* Offer Responses are created when Certificate Codes are distributed to Members (to link the code to the Member), or when a Member redeems an offer.  The Offer Response contains the details and metadata of the Offer, its current status, and expiration (if it has one).  

 

Enable Manual Approval of Receipts

Background

When a paper receipt is scanned to provide a proof of purchase in order to, for example, award points to a Loyalty member, the system will use automated scanning to read the receipt, or OCR (Optical Character Recognition). 

However, where there is no system in place for OCR the brand needs an option for the CSR (Customer Service Representative) to create the receipt manually in the system.

Solution

A new program setting is provided so the brand can choose to Skip OCR and manually create a receipt. 

There will be an online help update to follow in the Program Settings Section here

 

Multi language Translations Tab

The multi language feature is currently in preview mode and can be activated in customer staging environments upon request.

Background

A key requirement for multi language support is to enable the marketer to add, review and amend member facing text. 

A Translations Tab within Challenges, Offers and Rewards has been added. This tab displays all the configured languages for the program, including all member facing text that has been added or spaces where member facing text can be added if required.

All member facing text needs to be exported including the necessary spaces so that translations can be added offline and then imported.

This includes multi question challenges where the number of questions to be displayed, reviewed and amended, exported and imported, dependent on user input.

Solution

A Translations Tab within multi question Challenges now renders according to the question configured by the marketer, and the export file structure is driven by the questions configured by the marketer.

There will be an online help update to follow.

 

Multi Language Default Locale

The multi language feature is currently in preview mode and can be activated in customer staging environments upon request.

Background

Where a brand starts using the multi language features for Offers, Rewards and Challenges, the default locale will be automatically set to US English (en-US), however, if the required default locale or language is different, then the admin user needs to be able to retain existing text that is not US English as the default language or local.

Solution

When the admin user changes the default locale from en-US to for example “da” for Danish, then all existing member facing text will be labeled as Danish and will be present in the default locale space.

Online help for configuring locales is here

 

Improved Testing for Different Punch Card Types

Background

When testing different types of punch card, good test data is required to perform effective tests before launch. Currently a single set of test data for all punch card types is locally stored by an admin user which means that the user has to manually enter the correct values for the punch card type in question each time they conduct a test.

Solution

The admin user can now create and update a standard set of punch card data for each punch card type using the Categories feature in Loyalty, which is already used to define punch card types.

The system will automatically access the correct test data based on the category selected during the punch card configuration. 

The user can then view and edit the standard test data and the changes will be stored locally. This test data is then automatically available to future configurations of the same punch card type and again the user can view and edit it as required.

The user will also have the facility to restore the standard test data, overwriting the locally stored data.

There will be an online help update to follow.

 

Improved Data for Punch Card Reporting

Background

More data can give better insights on campaign effectiveness and assist with troubleshooting.

Solution

Additional data points for punch cards have been added for reporting purposes:

List of offers / promotions, number of transactions, number of punches, first and last transaction in 24 hour window (helpful for troubleshooting).

 

Reserving Gift Card Debit for Orders

Background

Gift Cards can store reward metrics such as points or monetary value which can be used against orders and purchases. Often an order is placed ahead of the purchase being completed. A common scenario would be where an online order is made on a restaurant website for food to be collected later. Another scenario might be where goods are pre-ordered due to a release date of new stock in the future.

In some markets, rewards stored on gift cards as a monetary value can be used “pre-tax” to help pay for purchases and reduce the overall total.

The challenge here is that money or points required for orders to be completed later should not be available for use on other orders or purchases as this could lead to a negative balance and potential abuse from consumers “gaming” the system.

Consumers may wish to use the entire monetary value or number of points available, or they may prefer to specify the exact amount to use towards an order and purchase.

Solution

In the same way that credit cards operate where the credit amount is reserved to cover the purchase amount that will be banked later, the monetary amount or points required for orders can now be reserved on Gift cards which will be debited later when the purchase is completed. These reserved amounts can also be voided where an order is canceled.

To achieve this, integration is required with e-commerce / online ordering systems and Point of Sale systems (POS).  A number of enhancements to the Loyalty APIs have been made to facilitate these integrations with robust and supportable solutions.

The API documentation will be updated under Technical Documentation here (password required for access).

 

POS Enhancements to Enable choice to Lock Offers to a Member

Background

POS APIs support multiple different functions, such as fetching member offers or rewards, so that the sales assistant or server can advise the member what is available and so that they can be used at the POS. 

Currently when offers and rewards are fetched by the POS they are locked to the member until the order is complete.. However, sometimes the requirement is simply to advise the member of the offers and rewards available at the POS but not to lock them into using them for that order.

Solution

It’s now possible to specify that the offers or rewards fetched to the POS will not be locked to the member, if they are only required for information purposes. 

The API documentation will be updated under Technical Documentation here (password required for access).

 

Order Rules Enhancements

Background

Earn rules are used to define how various activities such as purchases or visits are processed and how they will earn points or other metrics. These can be complicated to configure and require technical knowledge or Groovy scripting language.

Order rules are different to earn rules in that they determine the number of points that would be accrued or earned from orders submitted through a POS API, based on the configured order rules. From that determination an “SL” value is created and included on the purchase activity for the order, and that SL value is applied to calculate the accrual or points earned. 

The challenge is to provide self service capabilities for non technical marketers to  manage their accrual rules including more complex rules and to understand the breakdown of how a member earned their points so that campaign effectiveness can be better understood and for where adjustments are required to specific elements of a total number of points accrued for a transaction.

Solution

Order Rules can now be configured through a simple user interface without the need for any scripting language. 

The configuration includes more eligibility criteria for bonus rules such as location, minimum qualifying quantities or amounts, minimum order amounts, plus look up tables can be used to determine included and excluded items, plus additional multiplying factors. 

Order rules will now specify the breakdown of points that are calculated against an order i.e. base points plus points from all the different bonuses. This allows marketers to track effectiveness of rules and promotions; they can also charge back or reconcile as required, or determine points attributed to partner promotions etc.

This development provides a powerful self service tool for marketers to configure their earn rules, track effectiveness of those rules and accurately calculate any manual adjustments required.

There will be an online help update to follow.

 

Offer Placements available via API

Background

A Placement is a reusable, named location where Offers (or other content objects such as Rewards and Challenges) can be displayed, such as a web carousel or a particular section of an email message.

These features are currently available via the Loyalty application, however, external applications also need to use the placement functionality.

Solution

Offer placements have now been added to the Program API, so external systems can now get the necessary access to  configure placements.

The Program API documentation has been updated here (password required for access).

 

Notable Fixes 

  • Fixed an issue where images were not displaying correctly in the Content Editor
  • Fixed an issue where Punchcards were showing as completed where there were insufficient punches
  • Fixed an issue where discounts for free items were not applied correctly
  • Fixed an issue where changes to Offers were not saving correctly
  • Fixed an issue with error notifications in Mobile Wallet
  • Fixed an issue with merged accounts where a deleted metric was showing an error
  • Fixed an issue where the time value in the Program Setting “Metric expiration program date” was not saving
  • Fixed an issue to enable a forced import for airline member profiles

 

Loyalty Version 22.1.1 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 22.1.1 

Features

Configure Delete Member API Behavior

Background

Currently the system will delete the member record and all related responses in MySQL when the Delete Member API is invoked.

Solution

A new Program setting has been created so that the program administrator can specify whether to delete child responses or remove the member ID from the response instead of deleting it.

The program setting is called “Delete Member API Nullifies Member ID on Response Objects”. 

For response records specified in the program setting, the system will delete the member ID but not the response record. For response records not specified in the program setting, the system will delete the member ID and the response record.

This enhancement enables the program to choose to retain anonymised data while complying with a member deletion request. 

There will be an online help update in June in the Program Settings Section here

 

Notable Fixes 

  • Fixed an issue where the system was ignoring the number of decimal places configured for a Member Metric.
  • Fixed an issue where gift card qualification using lookups was not processed by the system correctly.

 

Loyalty Version 22.1 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 22.1.1 

Features

All new features will be available to customers upgrading to version 22.1. Contact your Cheetah representative for more details where configuration assistance is required.

 

Add Funds to Existing Gift Card Reward

Background

Many loyalty programs issue cash equivalent rewards to their members, often at specified earn thresholds, either as single-use coupons or loaded onto a single “Stored Value Reward” digital gift card that can be redeemed across multiple purchases.

For the Stored Value Reward use case, Cheetah has supported issuing Gift Card rewards where each redemption would generate separate Gift Cards, however this has the challenge of maintaining separate reward balances across each Gift Card.

 

Solution

In this release, Cheetah has enhanced Gift Card rewards so when a member is issued a reward, the system will create a new Gift Card instance if one doesn’t already exist, or if a Gift Card reward of a certain type has already been issued, the system will add value to the balance of the existing Gift Card reward.

This has the benefit of allowing brands to surface a single reward balance so members can access a unified view of their “Reward Cash”, and because there is only one balance to manage.

In addition, the Gift Card object has been enhanced to support qualification rules similar to Coupon Offers, for instance:

  • The Gift Card class can be configured with a set of eligible or ineligible Product Categories or PLUs (Price Look Up codes).  When defined, Gift Card value can only be redeemed for eligible products.
  • The Gift Card class can be configured with a minimum purchase subtotal. When a value above 0 is defined, the system will check whether an order submitted has a subtotal equal to or greater than the value configured on the Gift Card class to determine whether the order is eligible to redeem Gift Card value.

 

Introduced “Delete Member” Member API

Apple App Store Review Guidelines now mandate that apps requiring consumers to create an account, allow consumers to delete the account from within the app.  This new rule is set to take effect by the end of June 2022.

To support this use case, Cheetah has added a Delete Member endpoint to the Member API.  It allows members to initiate a request to delete their member profile in Cheetah Loyalty, and to confirm their request by either specifying their password or to have the system trigger a one-time code and to use that value to confirm the request.

Once confirmed, the system will delete the consumer’s member record in Cheetah Loyalty, and remove all related data in the system.

More information on the Delete Member API is available in the Member API documentation.

 

Introduced ValueLink Gift Card Integration

For brands that use ValueLink gift cards, it is now possible to integrate Cheetah Loyalty gift cards with ValueLink to support purchasing, linking, and viewing ValueLink gift card details in the context of a loyalty program.

Contact your Cheetah representative to request enablement of the integration in your program environment.

 

Introduced New Integration Id Member Attributes

To help brands needing to manage additional external system identifiers on a member record, we’ve introduced a set of new integration NN_id attributes in this release e.g. integration7_id, integration8_id, integration9_id, integration10_id, and integration11_id.

Members can be searched by these attributes in the Member screen in the Cheetah admin console, and the POS API has also been enhanced to support member lookup by these new integration id attributes.

 

Introduced Retro Claim Barcode for Sparkfly Integration

For brands using the Cheetah-Sparkfly POS Integration, it is now possible to configure Cheetah to return order details when no member is assigned to a check so a scannable barcode can be generated by the POS system on a receipt.

The barcode is meant to provide an easy way for consumers who weren’t added to a check to initiate a retroactive claim to earn credit for the purchase.

The feature is enabled and configured by new program settings - Print Retro Claim Barcode (false by default - this setting enables the feature), Retro Claim Barcode Format (QR or Barcode), and Retro Claim Barcode Content (configurable with references to retro claim elements like location, transaction id,  business date, and subtotal).

Configuration instructions will be added to Online help here as a new section in this Program Settings Page.

 

Enhancement to Purchase Gift Card Member API

To support the ValueLink gift card integration, an enhancement has been made to the Purchase Digital Gift Card Member API to support a card_uid input.

Card_uid is the internal identifier that ValueLink returns in their Add to Wallet flow, which when passed in the Purchase Gift Card Member API, provides a unique id the Cheetah Loyalty system can pass back to ValueLink to get the gift card details like card number, pin, and current balance.

 

Introduced Update Punch Card Type Program API

It is now possible to programmatically update Punch Card Type objects via the Cheetah Program API, meaning that Punch Card metadata can now be updated from external systems in addition to the existing support for creation of metadata.

 

SKU Criteria on Punch Card Overrides Global Exclusion List

System behavior has been enhanced to give credit to order line items that match the specified SKU criteria on a personalized punch card even if the SKU appears on the Global Exclusion List.

 

Introduced New Punch Card Punch Criteria “Qualifying Line Amount Subtotal”

When configuring punch cards with sku or category criteria, it is now possible to specify a qualifying line amount subtotal so the system can determine whether the order meets the configured threshold or range for the amount spent on qualifying line items.

The line items included in the qualifying line amount subtotal are only those with skus or categories matching the sku and category criteria on the punch rules.

 

Introduced New "Between" Comparison Operator on Punch Rule Criteria

Previously, Punch Card credits could be awarded for purchase values above a specific amount, for example, all purchases of $5 or more would be awarded a punch.

It is now possible to configure punch rule criteria in personalized punch cards that can evaluate a criteria between two values. For example, a brand could now give a punch card credit for a purchase value between $5-$10. 

An example payload for an issued punch card illustrating the between operator for the total criterion is shown in Appendix I.

 

Introduced the Ability to Configure Punch Card Limit Week Start Day and Time

When Punch Card Limits are used to control how many punches can be awarded in a given time period, and the period specified is a Week, the system now allows marketers to specify the day and time the weekly period starts.

This configuration is managed as a Program Setting. See Appendix II for details. 

 

Reminder Moments are Now Supported wi​th Multiplier Offers

Multiplier Punch Cards are used for time limited campaigns where the usual punches are multiplied by the configurable multiplying factor, such as x 2 for a “Double rewards day”.

These Multiplier Punch Card types are now integrated with reminder moments, which means that scheduled email or push messages can be configured for these campaigns.

 

Notable Fixes

Fix for Translation Export CSV File

As part of the enhanced support for Multiple language content, marketers can export a .CSV file with the existing translations in the content object (offer / reward / challenge) including all the fields where member facing text can be entered for the configured languages. This then enables the import of translations into the same object to streamline the configuration process for multiple languages. 

The .CSV file included content that was irrelevant to the translation process and has now been removed to improve the user experience.  

 

Fix to Allow Cancel and Reissuance of External Punch Cards

Fixed an issue that prevented canceling and reissuing a member punch card.

 

Performance Fix for Punch Card Campaigns

Improved SQL query performance related to ‘Choice’ punch cards.

 

Performance Fix for Retro Claim

Improved query optimization for requests to retroactively claim orders.

 

Performance Fix for Places

Optimized performance of queries to retrieve Place data.

 

Fixed an Issue with the SFMC Connector

Introduced a fix to support long scope values for the SFMC Connector.

 

Appendices

Appendix I

An example payload for an issued punch card illustrating the between operator for the total criterion is shown below:

  • The matcher element for the between operator is "bet".
  • The lower end of the range to compare is specified as "min_value".
  • The upper end of the range to compare is specified as the "max_value".

{

    "member_integration_id": "MP022811",

    "execution": "async",

    "personalization": {

        "recurrence_enabled": true,

        "prizes": [

            {

                "punches": 1,

                "punches_types": "Static",

                "has_metric": true,

                "metric_name": "point",

                "metric_amount": 75

            }

        ],

        "punch_rules": [

            {

                "label": "Generic Named Punch1",

                "name": "gen_np1",

                "total": {

                    "matcher": "bet",

                    "min_value": "50.00",

                    "max_value": "74.99"

                   

                }

            }

        ]

    }

}

 

Appendix II

The configuration to specify the day and time the weekly period starts for punch card limits is managed as a Program Setting, and is available in the Cheetah Admin Console under Program > Settings > Program Settings.

A new section in Online Help under program settings entitled “Punch Card Weekly Limits” has been added here

  • Week Start Day - indicates the day of the week the weekly limit period begins.  This value defaults to Monday but can be configured per the business requirements.
  • Week Start Time - indicates the time, in 24 hour notation, that the weekly limit day begins.  This value defaults to 00:00 but can be configured per the business requirements.

While issued punch card personalization does not set the week limit start day or time, the following example is provided to share how issued punch cards can specify a limit of 4 punches in a week (one of the Rewards Together MVP use cases):

{

    "member_integration_id": "TEST-DARW-001",

    "execution": "async",

    "personalization": {

        "recurrence_enabled": true,

        "prizes": [

            {

                "punches": 4,

                "punches_types": "Static",

                "has_metric": true,

                "metric_name": "point",

                "metric_amount": 25

            }

        ],

        "punch_rules": [

            {

                "name": "sr_transactions_only",

                "label": "SR transaction",

                "channel": {

                    "type": "fixed",

                    "value": "sr_reward"

                }

            }

        ],

        "limits": {

            "card_limit": {

                "response_rate": 4,

                "response_rate_unit": "week"

            },

            "continuity_period": {

                "punch_period_num": 1,

                "punch_period_unit": "week"

            }

        }

    }

}

 

Loyalty Version 22.0 Release Notes

Major Feature: Multiple Language Campaigns

This enhancement has been enabled in preview mode for the current release, meaning that it can be deployed into customer staging environments for assessment.

Background

Marketers very often run campaigns across multiple markets meaning that content
must be provided in multiple languages or locales*.
Currently, content objects such as Offers, Rewards and Challenges can only be
configured in a single language.
This results in complexity for the marketer as they must configure one duplicate
object for each language with no easy mechanism to input translations. Categories are assigned to each object so that calling applications such as Mobile Apps and websites know which object to target for the required language.
It also results in complexity for the data analyst since responses to objects such as
multi question surveys are received in multiple languages and therefore need to be
translated to a single language in order to conduct data analysis.

 

Solution

A major content management enhancement to Offers, Challenges and Rewards so that:

  • marketers can more easily configure and manage multiple language campaigns
  • data analysts can easily report on multiple language campaigns

This initial release includes support for:

  • All Offer types
  • All Challenge types except Ratings, Multiple Choice and Text Surveys since they
    are covered under Multi Question Surveys
  • All Reward types
    The solution does not currently support Punch Cards, Badges and Wallet

Availability

This enhancement can be made available in staging environments upon request to all customers who upgrade to Release 22.0.0. Please contact your Cheetah Representative.
Where campaigns are already in operation across multiple languages / locales, please discuss with your Cheetah representative to assess any actions required to transition to the new approach.


Updated Member API documentation has been published to the CES Help Center here


Details on how to configure the required languages / locales in Program Settings is here under "Member Content Locales"

Other online help updates have been completed in the applicable sections.


Supported Use Cases by Persona, via the Loyalty UI

Admin:

  • Configure the program to support the required languages and/or locales
  • Set a default language to serve as the “stored” language used for data analysis
    and to return when requested language is not configured

Marketer:

  • Create new content objects and easily configure member facing text or other translatable content** in the languages / locales configured for the program
  • Export configured member facing text from a single content object in the correct
    file structure to enable addition of all translations applicable to the defined
    object and configured languages
  • Import translations created offline for a single Content Object using the
    previously exported file
  • Preview and amend content for each language from within the Content Object.

Data Analyst:

  • Analyze responses received in multiple languages without manual intervention
    to translate and aggregate responses
  • Analyze data about the languages / locales from which the responses were
    received

Member:

  • Calling application (website or mobile application) determines the required
    language and requests it via the Member API

* locale means a language and its associated region, so that regional variations in languages can be
accounted for where required, e.g. French (France) French (Senegal) or English (US) English (UK) English (Canada). Where the term language is used alone in this document, the term locale applies equally.

** translatable content means content other than member facing text that needs to be different due to language / currency / clothing sizing differences by locale. If content varies for any other reason, it is treated as a different campaign.

 

Prevent “Double Dipping” with POS Integration

Background

Where Loyalty programs use multiple channels or methods to submit transactions, and each channel uses different unique identifiers, there can be a risk of points being accrued to an account twice from duplicate orders.

Solution

Introduction of a globally unique identifier for use on Cheetah orders and for
eCommerce and POS integrations, through both the POS API and Sparkfly API.
For online ordering flows the eCommerce system can submit an order both to Cheetah directly, and to the Point of Sale system for fulfilment that in turn relays it to Cheetah after fulfilment. This means that Cheetah receives the order twice.
The presence of a globally unique identifier allows Cheetah to recognize a single order coming through both channels and therefore is able to prevent creating a duplicate order.
Details on how to use this new functionality will be available in online help later this
month.

Availability

This enhancement is available to all customers upgrading to this release. 


Notable Fixes

  • Added system retry support to SVS Gift Card integration.
  • Added support to get Vantiv Gift Card balance when getting a Gift Card by Id.
  • Added support for Gift Cards to be returned when using Sparkfly integration with staff-selected rewards.
  • Fixed an issue where points were incorrectly calculated when an OLO order included a non-Cheetah discount.
  • Fixed an issue where Cheetah coupon offer discounts were incorrectly calculated when an Aloha discount was applied to the order.
  • Fixed an issue where Triggered Actions caused an unexpected Tier change.
  • Fixed an issue where admin user roles were incorrectly assigned when authenticated via an external Auth Provider.

 

Loyalty Version 16.0 Release Notes

Configurable Point of Sale Message (via Sparkfly)

Background

When a loyalty program Member is making a purchase, such as paying a bill at a  restaurant, the server can enhance the customer experience if they can view details of  the Member’s account. For example:  

  • Advising the Member of their current points balance enables the Member to  make the decision whether to redeem their points.  
  • Status and lifetime value information provide the server with context for  interacting with the Member.  
  • Displaying rewards available to the Member enables the server to provide  personalized service by helping the Member use their rewards, increasing  emotional loyalty. 

Solution

This release introduces a new Program Setting called “Discount Display Message  Content.” This feature is intended for Loyalty programs that use our Point of Sale (POS)  integration via the Sparkfly POS system. 

This new feature enables a marketer to configure a template for a pop-up message to  display at the POS when the Member is added to the check or bill.  

Optionally, you can configure the POS message to utilize a “relative” time zone when  displaying Offer expiry times. Loyalty program Members register with the program in the  specific time zone according to their residential address. However, for programs that  operate across multiple time zones, redeeming an Offer could take place in a different  time zone. If an Offer is being redeemed in a different time zone than the Member’s  residence, the exact expiry date/time can be adjusted accordingly. For example, let’s say  a Member has traveled to a different time zone, and they want to redeem an Offer that  expires at midnight. The Offer will expire at midnight local time, as opposed to the time  zone in which the Member resides. 

For instructions on configuring the POS message template, please see Appendix I in the PDF file "Version 16.0" attached below. This enhancement is available to all Cheetah Loyalty customers upon upgrade to Release 16

 

OAuth Application Enhancement for JSON Web Tokens

Background

OAuth is a protocol that lets external apps request authorization to access Member  data, such as Loyalty Member Profiles. OAuth enables that authorization to be  monitored, throttled, or revoked at any time.  

A registered OAuth application in the Loyalty platform is assigned a unique Client ID and  Client Secret, which can be used by the client application. For example, mobile apps or  websites can request authorization to Member data via Cheetah Member and Program  APIs. 

For Cheetah Loyalty, some applications use JSON Web Tokens (JWT) for authenticated  API access to the Loyalty Member Profiles or other Member data. A JWT is a public key or  standard way of encrypting and decrypting data. This method is used by some  applications for data sent from an external application via API, to enable OAuth  authenticated access to data in the receiving application, in this case Cheetah Loyalty. 

The sending application “signs” the JWT string, and the consuming application, Cheetah  Loyalty, verifies that signature using a public certificate provided by the sending  application. 

Upon verification, the platform will decode and accept the data; however, the data can  be decoded without verifying the signature. Therefore, no sensitive or Personal  Identifying Information (PII), such as email address, password, or credit card details,  should be sent using JWT. 

Within the Loyalty platform, you can manage your OAuth configurations on the Admin >  Access > OAuth Applications screen. You can find additional information about this screen within the Loyalty Online here.  

 

Solution

Additional support for OAuth using JWT has been added in this release of Cheetah  Loyalty. The platform now supports the use of a shared secret key with a specific  encryption algorithm namely “HS256.” 

Cheetah Loyalty is now able to decrypt the HS256 algorithm for applications that use it  for OAuth, using a shared secret key. 

This enhancement is available to all Cheetah Loyalty customers using OAuth with JWT upon  upgrade to Release 16.

 

Configurable Landing Page

Background

Currently, the Dashboard is displayed when a user signs into Cheetah Loyalty. However,  some roles may prefer a different landing page. For example, it may be beneficial for  Customer Service Representatives to automatically view the Member CSR screen when  logging into the platform, as this is the screen where they do most of their work. 

 

Solution

This release of Cheetah Loyalty now offers the following three choices for the landing  page when users log into the platform. The landing page can be specified at a global  level, and for a specific Role. For screen shots please see the PDF file "Version 16.0" attached below and for instructions on configuring the default landing page, please see Appendix II in the same document. 

 

Notable Fixes

  • Incorrect and different numbers of decimal places were showing in different  places, such as: Members > Members and Members > CSR > People. This  discrepancy is now fixed so that a single decimal place displays throughout the  application. 
  • Sparkfly Point of Sale integration incorrectly processed orders that attempted to  redeem multiple Reward Offers. This issue has been resolved, so that the  platform correctly processes those orders and redeems multiple Offers when  present. 
  • Some Punch Cards were not displaying the configured Prizes within the platform  user interface. Prizes now display correctly as configured. 
  • When a user clicked an Order record in Cheetah Digital’s Engagement Data  Platform (EDP), the user was incorrectly routed to a page in Loyalty. The platform  now routes the user correctly to the Order record. 
  • An issue where Order details were not displaying correctly in Members > Orders  has been fixed. 
  • The purchase or addition of credit to Vantiv Gift Cards was not processed  correctly; this issue has been resolved. 
  • An issue with the Member Merge feature not operating correctly is now fixed.
  • An issue with editing tab names in the application is now fixed.
  • An issue where Visitors were receiving a New Member Email Confirmation is now  fixed. 
  • Confirmation instructions were not being sent to imported visitors that  converted to a full Member via an application using Single Sign On (SSO). This  issue has been resolved. 
  • An internal server error message displayed on the Content Page is now fixed. 

 

 

Archive

 

Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles