Detailed information about the latest releases of Marigold Loyalty.

Loyalty Version 23.4.0 Release Notes

All features and fixes are automatically available to all customers upon upgrade to version 23.4.0 unless otherwise stated.

Features

Rebranding to Marigold Loyalty

Cheetah Loyalty has rebranded to Marigold Loyalty, as part of the Marigold portfolio of marketing solutions. We will be applying the Marigold branding across the product portfolio with unified brand elements to reflect a refreshed user experience. 

 

New in Integrations

Integrations | Audience Sync with Engage+

Background: Customers could import a list of members to messaging, but the process was manual. 

Solution: The new solution enables marketers to schedule a segment export to Engage+ to export any kind of segment at a cadence using a marketer friendly scheduler UI. The marketer only needs to configure a one-time connection to Engage+ using S3 or SFTP. Engage+ can use the segment file from Loyalty to trigger messaging campaigns to target members in the segment. These could be triggered, event based, or scheduled campaigns.

An Online Help update, a setup guide, and a user guide will be coming soon.

 

Integrations | Profile Streaming for Engage+

Background: Clients should have the ability to share member profile data through a seamless, unified integration from Marigold Loyalty to Marigold Engage+.

Solution: The Profile Stream feature offers a streamlined data flow from Marigold Loyalty to Marigold Engage+, allowing marketers to create personalized and targeted campaigns with higher accuracy, delivering more consistent results. Profile Streaming is a data stream from Marigold Loyalty to Marigold Engage+, without the need for queries, exports and imports, triggered actions, or scheduled jobs. 

The Profile Stream Loyalty feature enables you to configure and manage which member attributes, preferences, and metrics should be shared across Marigold products to enable personalization related to the member profile in a campaign. 

The selected details are sent any time a value changes in Marigold Loyalty, which means higher accuracy delivering more consistent results, reducing latency that may have been experienced in other methods, and gives marketers the opportunity to create consistent, personalized campaigns that drive engagement, retention and loyalty.  

Note: Early Adopter Access available in October to the North American and EMEA regions through the end of 2023. The feature will become available to other regions in phases beginning in Q1 2024.

An Online Help update, a setup guide, and a user guide will be coming soon.

 

Connectors | Marigold Engage Connector

Background: It was not previously possible for Marketers to configure Marigold Loyalty to send messages via the Marigold Engage product.

Solution: It is now possible for Marketers to configure triggered actions and scheduled jobs in Marigold Loyalty to send messages via Marigold Engage. There is a new connector for Engage that is included in Marigold Loyalty, and once connector profiles are configured, it is possible to use those profiles with triggered actions and scheduled jobs to initiate requests to update Engage profiles and send personalized messages linked to transactional journeys. Specifically, the new connector profile includes the ability to specify the name of the connector profile and other Engage details including the client’s Engage organization, the Engage domain, the API Client Id, and the API Client Secret.

An Online Help update, a setup guide, and a user guide will be coming soon.

 

Scheduled Jobs | Loyalty Scheduled Jobs Send Messages via Marigold Engage

Background: Grant Anniversary and Send Expiry Notifier scheduled jobs in Marigold Loyalty were previously able to send via Marigold Engage+ and a few external solutions, but could not send via Marigold Engage.

Solution: Grant Anniversary and Send Expiry Notifier job types now include Marigold Engage as a sending channel option. When the marketer selects the “Send Messages via Marigold Engage” option, the scheduled job configuration panel will display settings that allow the configuration of the Engage connector profile, the Engage journey, the specific language to be used in the message, and personalization parameters.

An Online Help update will be coming soon.

 

Triggered Actions | Loyalty Triggered Actions Send Messages via Marigold Engage

Background: Triggered Actions were previously able to send via Marigold Engage+ and a few external solutions, but could not previously send through Marigold Engage.

Solution: Marketers are now able to configure triggered actions to send messages via Marigold Engage when processing activities, metric changes or tier changes.

A new action, "Send Message via Marigold Engage", is now available for Marketers to use to configure triggered actions to send messages via Marigold Engage. The action will send any configured data that is included as part of the personalization details of the trigger in a request to Engage to (a) create or update the Engage profile associated with the Loyalty member email address, and (b) leverage the data elements configured in the trigger to personalize the message sent via Marigold Engage.

An Online Help update will be coming soon.

 

New in Program Settings

Program Setting | Offer Sorting Hierarchy Enhancement

Background: Marketers need the capability of returning the offer with the highest discount on an Item Discount Offer when using the POS APIs [Stellar, Sparkfly, OLO]. 

Solution: Marketers using Marigold Loyalty can control the sorting of qualified offers returned by commerce integrations using OLO, POS, and Sparkfly APIs. This setting is being enhanced to support discount strategy-based sorting for Discount Value at the program level.  

• The Offer Sorting Hierarchy program setting now supports the option to select a Discount Strategy
• Marketers can specify whether the program’s discount strategy should be based on Max $ Amount or Calculated Discount in the offer sort. 

An Online Help update for this setting can be found here.

 

Program Setting | Payment Networks and Payment Types

Background: Clients did not have the ability to configure payment types and network types to send specific payment information. 

Solution: Two new attributes that can be used in POS transactions, Payment Networks and Payment Types, are now available for clients to configure Payment Networks and Payment Types in a POS transaction via the Program Settings page. Both of them accept String data type, and values in POS calls  have to match what is being set. The values are case insensitive and every value sent is converted to lowercase. 

• Configure your payment type: venmo, paypal, credit_card, debit_card, etc.
• Configure payment network: visa, mastercard, etc.

An Online Help update for this setting can be found here.

 

Program Setting | Week Start Day/Time for Punch Cards Description Update 

Background: In Release v23.3, the Program Setting Punch Card Weekly Limits (Day and Time Settings) was updated to allow users to configure weekly limits for Standard Punch Cards in addition to the existing External Punch Cards. However, the Program Setting Descriptions for Week Start Day and Week Start Time still reflected that the evaluation was for External Punch Cards only.

Solution: In this release, the Program Setting Descriptions now have been updated to change the label “External Punch Card Limits” to a more unspecified label of “Punch Card Limits” to encompass both External and Standard types:

 

An Online Help update for this setting can be found here.

 

New in Program API

Program API | Additional Filtering Capability for Response Endpoints

Background: For certain API requests/responses, additional filtering can be applied to filter Results with Categories; however, this filter was not available for Program API Challenges Responses, Reward Responses, or Member Rewards Responses.  

Solution: An enhancement to the following API endpoints has been implemented to include the additional filtering parameter for Results with Categories:

• GET /program/api/challenges/responses
• GET /program/api/rewards/responses
• GET /program/api/members/[member_id]/rewards/responses

For more information, see the Program API documentation here.

 

Program API | Get Member Offers and Get Member Offer Responses 

Background: The Program API for the Get Member Offers and Get Member Offer Responses endpoints did not return the Offer Label (Display Name) of the Offer; the response only returned the internal_name and description.

Solution: An enhancement to the endpoints to add the Offer Label (Display Name) of the Offer has been implemented for the following endpoints:

• GET <base_url>/program/api/members/<id>/offers
• GET <base_url>/program/api/members/<id>/offers/responses

For more information, see the Program API documentation here.

 

New in Points Engine

Points Engine Improvements | Tier Enhancements

Background: Tiers did not expire automatically and relied on member activity to trigger tier expiration. Tiers also did not consider negative earns during tier calculations. 

Solution: Automatic expiration of tiers is now supported by enabling marketers to schedule the tier expiration job from the Scheduled jobs UI. Before this is done, a migration job needs to be run. Clients will have to contact their respective Customer Success managers, who will coordinate internally to set up the client for using the Tier expiration job. 

Additionally, we now handle any negative earns in Tier calculation and ensure that tiers are assigned correctly. We have also made improvements to how members are downgraded when their tiers expire and ensure members are assigned the correct tier rather than downgrading to the lowest tier. 

A user guide for this enhancement will be coming soon.

 

Other Enhancements

Offers | Coupon Offers Apply Quantity-Based Limit for Other Discount Types

Background: In Release v23.3, an enhancement was implemented for the ‘Free' Discount Type only. This enhancement allows for the ability to configure a limit on the quantity of qualified items the system should apply a qualified discount to, respect that limit, and return the appropriate discount calculation. Customers should be able to use the same functionality with other discount types: Amount, Percentage, BOGO, New Price and Bundle Deals.

Solution: Utilizing the existing Limit field within Item Discount Coupon Offers, an enhancement has now been implemented for Quantity-Based Limits for the remaining Discount Types — Amount, Percentage, BOGO, New Price, and Bundle Deals.

This capability is available across POS, Sparkfly, and OLO Point of Sales.

A user guide for this feature can be found here.

 

Member CSR | Member Attribute “Birthday” Validation

Background: Currently, the Member and the Member CSR People screen allow manual update of the Member’s birth date field. The field currently does not have validation surrounding the date input and can be updated with an erroneous date, e.g., 0001-03-01. For Customers who may have exports set up, which include this field, an invalid date can cause external processing errors when importing the field.

Solution: While the validity of the date itself is not possible to evaluate, validation surrounding the year entered has been implemented. After the date is entered, the system will evaluate and provide alerts/ error handling  for the following:

• For Past Dates: 
  • Upon entering a past date e.g. 0003-03-03, Users will be alerted by an error message: “Birthdate year cannot be earlier than 1900”.

           

• The date cannot be saved until corrected or removed.

• For Future Dates:
  • Upon entering a future date e.g. 2025-03-03, Users will be alerted by an error message: “Birthdate cannot be in the future“.

          

• The date cannot be saved until corrected or removed.

Note: This change will also impact imports to the Loyalty product and updates to the birthdate via API. If the birthdate year is prior to 1900 or in the future, the import or API update will fail. For programs who do not collect the birthdate year, it is recommended the year default to 1900.

An Online Help update for this feature can be found here.

 

Member Sign-up | Population of Location Attributes

Background: When a member signs up or updates their profile from a store location, currently Location Attributes such as Place Name and Place ID are not populated in the Activity generated. 

Solution: When a member performs a sign up or update to their profile details from a store location, the activity generated for member sign up or update will now include Place Name, Place ID, Place Integration ID, and Latitude and Longitude of the Place. 

 

Resolved Issues

Offers | Cloned Offer Fixed Usage Period 

Resolved issue when cloning an Offer with a Fixed Usage Period type; the cloned Offer’s Usage Period values reflected an offset equal to the Timezone’s difference from UTC. Usage Period DateTime values should now be the same as the parent Offer when cloning.

 

Loyalty Version 23.3.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.3.0 unless otherwise stated.

Features

Challenges | Multi-Question Survey enhancement for linked Member Attributes and Preferences

Background: When a Multi-Question Survey Challenge has a Bind to a Member Attribute or Preference, and the bound Attribute or Preference is configured with drop-down values (Domain List or Key/Value Pair List), the Answers configured within the Challenge Question:

• May be different from the values configured in the Member Attribute or Preference and
• Challenge Responses require an Answer ID to be passed in the API call, versus the text value; the Answer ID is not the expected valid value required for the value to save to the Member profile. 
• The disconnect between the Challenge Answers text, Answer IDs, and the expected value text for the Member Attribute or Preference causes inconsistencies with saving member responses from the Challenge to the member profile.  

Solution: An enhancement to Multi-Question Survey Challenges has been implemented for configuring the Challenge answers. When the question is bound to a Member Attribute or Preference, which has been configured as a drop-down list, the valid values for the Attribute or Preference will automatically import as the Question’s answers. This reduces Challenge configuration time, assists in Challenge answers maintaining consistency to the expected values of the Attribute or Preference, and allows the responses for the Challenge to be saved to the Member Profile.

Note: Answer Auto-Import capability is only supported at this time for programs, which do not have Additional locales configured in Program Settings.

 

Program Setting | Enable Week Start Day/Time for Standard Punch Cards

Background: Currently the Punch Card Program settings for Week Start Day and Week Start Time only support External Punch Cards. 

The Week Start Day Program Setting determines the day the week starts for evaluation of external punch card limits. The Week Start Time Program Setting determines the time (in HH:MM) the week starts for evaluation of external punch card limits

Solution: Enhanced the program settings functionality to also support Standard Punch Cards. 

 

Point of Sale | Offer Response Hierarchy Rules inclusion of Offer Categories

Background: Currently the Standard Offer Sorting Hierarchy for POS (Point of Sale) is set to 1. coupon type 2. discount type 3. usage end 4. discount value 5. created at. A Program Setting was introduced earlier this year to provide Customers with the capability to adjust the sort or omit certain Offer attributes from the sorting returned by the POS. However, there may be cases where a Qualified Offer needs to be presented first or last in the sorting hierarchy based on promotions run by the program. 

Solution: To expand on the enhancement earlier this year, an additional capability has been added to the Offer Sort Hierarchy Program Setting to allow the inclusion of Offer Categories in the POS sorting hierarchy. Categories may be included as a “First Categories” or “Last Categories” sort option.

• First Categories: Selected categories will be first in the sorting hierarchy before offer attributes
• Last Categories: Selected categories will be last in the sorting hierarchy after offer attributes.

Note: The additional Category options in the Program Setting will only display if the Offer Category is configured with the ‘Available to Offer Sort Program Setting’ indicator within the Edit Offer Category screen.

 

Offers | Coupon Offers apply Quantity-Based Limit for Free Discount Type

Background: Currently the ability to apply a quantity-based limit for qualified items related to an Item Discount Coupon Offer is not available for Customers who require a restriction.

Solution: Utilizing the existing Limit field within Item Discount Coupon Offers, an enhancement has been implemented for the ‘Free' Discount Type only.  This enhancement allows for the ability to configure a limit on the quantity of qualified items the system should apply a qualified discount to, respect that limit, and return the appropriate discount calculation.

This capability is available across POS, Sparkfly, and OLO Point of Sales.

 

Coming Soon: Quantity-Based Limits for remaining Discount Types (Amount, Percentage, BOGO, New Price and Bundle Deals)

 

Offers | Coupon Offers BOGO Discount Type apply discount to lowest priced qualified item

Background: For buy-one, get-one (BOGO) coupon offers, the system should make  it possible to configure the coupon with 2 or more primary qualified items and the lowest priced qualified item should be discounted.

Current system behavior is as expected when 2 Qualified items are configured and presented in a transaction. However, when there are more than 2 Qualifying items configured, the current behavior is not discounting the lowest of all qualified items in the transaction.

Solution: An enhancement to the system behavior was implemented to discount the lowest priced qualifying item in the order when more than 2 Qualifying items are configured in the BOGO offer. e.g. 

2 Qualifying Items by SKU: 

4190 - Item A $10

4195 - Item B $5

• Transaction contains 3 items, 2 items qualify for the BOGO Offer
• Result Discounts Lower-Priced Qualifying item (Item B)

3 Qualifying Items by SKU: 

13579 - Item A $7

24680 - Item B $3

11111 - Item D $15

• Transaction contains 4 items, 3 items qualify for the BOGO Offer
• Result Discounts Lowest Priced Qualifying item (Item B)

 

Points Engine | Automatic Point Expiration 

Background: To expire points, members need to perform an activity in the system or an API call to get the Member information, which would trigger point expiration evaluation.

Solution: We now have a job that will evaluate which members are eligible for expiration and automatically expire points for the members. The job can be configured by marketers from the scheduled jobs UI of type Metric Expiration.

 

Order Rules | Ability to filter on Segments and Tiers to Order Rules

Background: Marketers would like to apply order rules to a set of members in a program rather than to everyone.

Solution:  We introduced the ability to filter order rules on Segments and Tiers. A point to note is that only Golden record segments will be returned, similar to any segment linked to any other object on the platform. In addition, only the primary tier scheme is available to use as a filter.

 

Commerce | Ability to accept Payment information

Background: By collecting payment information, marketers will have the option to use this information in different ways on our platform, e.g., in Order rules, Punch cards, etc.

Solution: We now accept payment information in Stellar POS API and Orders. Payment information can include details like payment type, payment, network, last four digits of card, tokenized card number, amount, currency, and an integration ID for payments (if a client provides this information).

In future releases, we will expose this information in order rules and punch cards. The current release only accepts the information and displays it under Orders - Payments.

 

Punch Cards | Reminder Moment Audience Performance Optimization

Background: The system evaluates the audience for each reminder moment variant independently and when multiple variants are configured at or near the same scheduled time, audience evaluation is done serially for each variant as it is processed.

Solution: To reduce the time it takes to evaluate the audiences for reminder moment variants, we’ve introduced an optimization to evaluate reminder moment variant audiences in a batch if the variants are scheduled within a short window of time, e.g., an hour.

This behavior is controlled through a new Program Setting called “Reminder Audience Freshness TTL”. By default, the value is 0 (no batching), but if using Punch Card Moments and batching are desired, the recommended setting is 3600 (representing 1 hour).

 

Fixes

Members CSR | Member Documents upload

Corrected issue when documents are uploaded to a Member Profile: the documents uploaded were visible across all Member Profiles. Expected behavior is that documentation uploaded to a Member’s Profile should only be accessible within that specific member’s profile.

 

Offers | Content Localization/ Image Upload not displaying correctly for certain Locales

Fixed issue when calling the Member Get Offers API and applying the Accept-Language Header for a locale: the default locale’s Image was returned regardless of the locale indicated in the API call. Expected behavior is that the Image uploaded for each locale is returned when the Accept-Language parameter is applied, as well as the other content relative to locale entered in the Content Editor: Subject, Header, Sub-header, Body, Details, and CTA.

 

Loyalty Version 23.2.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.2.0 unless otherwise stated.

Features

Effectivity Periods | UX Redesign

Background: Streamline the UX for the Effectivity Period screen to enhance the display of the Effectivity Period configuration. This  can display/hide fields based on the Period Type selected.

Solution: For the following areas of the Admin Console: Offers, Challenges, Rewards, Badges, Punch Cards, Events and Codes; the Effectivity Period display has been modified to simplify these configurations:

• The Effectivity Period for Period Type in the Response and Usage sections has been converted from a Radio Button to a Drop-down selection. 
• The Period Type will continue to to default to Same and will use the objects main effectivity to determine the effectivity for Response and Usage Periods. 
• No additional fields will display in the Effectivity Period Screen when Same or Always is selected. 
• Once the Period Type is updated to Relative or Fixed,  the configuration fields associated with these period types will be displayed and configurable.

 

Offer Effectivity Periods | Extend Member Preferred Location Time Zone to Relative Period Type

Background: Extend the recent enhancement for Offer Effectivity using Member Preferred Location TimeZone to Offer Relative Response and Usage Periods.

Solution: A new indicator, Preferred Location TimeZone, has been added for Offers within the Response Period and Usage Period Effectivity configuration screen for Relative Periods.

• Relative Periods use attributes to determine the effectivity based on Minute, Hour, Day, Week, Month or Year with a greater than/less than [> / <] variable for start and end.
• For Relative Effectivity Response Period the effectivity is relative to the Publish Date of the Offer. Configuring the Preferred Location TimeZone in a relative response period will apply the TimeZone of the member’s preferred location to determine the effective start and end for the response period. 
• For Relative Effectivity Usage Period the effectivity is relative to the Response Date of the Offer. Configuring the Preferred Location TimeZone in a relative usage period will apply the TimeZone of the member’s preferred location to determine the effective start and end for the usage period. 

 

Note: member.place_integration_id must be set up to ensure member’s preferred location. For use of a Custom Attribute as an alternative, see the new program setting, Place Integration ID Override.

You can find the instructions in the Online Help here and Coupon Offers Guide here.  

 

Member CSR | Accept Punch Card

Background: Customer Service Representatives (CSR) did not have the ability to Accept a Punch Card in order for a punch to be valid.  There is now support for CSRs to manually Accept a Punch Card action on behalf of a member. 

Solution: A new menu option, Accept Punch Card, has been added to the Member CSR Screen More Menu under the category Punch Card. 

• When the Accept Punch Card option is selected, the user will be presented with a dialog screen displaying a list of active punch cards available to be accepted (if applicable for the member). From this dialog window, the CSR can accept or cancel the change. 
• The CSR will receive a success message once the action completes. If for any reason the action fails, a Failure message will be displayed listing the reason for failure.
• In addition the Accept Punch Card has been added to the CSR Role Permissions menu for Resource Type of Members to grant or revoke access to this menu item. 

 

Dynamic Reward | Points Converted to a Variable Discount 

Background: Loyalty’s Dynamic Rewards allow customers the ability to dynamically reward a member with a variable discount based on their point balance. Brands are able to retrieve member’s point balance via an API call. Using the balance retrieved, calculate the cost of the rewards, and apply the applicable discount. A secondary API call is then completed to debit the points from the member based on the number of points converted to a discount, or in the case of a return, credit the points previously deducted.  Currently the reward response API endpoints do not allow responses for Dynamic Rewards without a custom API in place. 

Solution: A new Program API endpoint, Redeem Reward, is enabled to allow responses for Dynamic Rewards using a form parameter.

• The parameter’s expected use is for the Reward Type Dynamic Reward.
• The form parameter allows both the Debit [deduct the primary metric from members] and Credit [refund the primary metric to members].
  • Program API endpoint:
    • POST <base_url>/program/api/rewards/<id>/respond

 

POS | Support line item quantity > 1 for ALL discount types 

Background: Line item quantity > 1 is only supported for Free, Percentage, BOGO and Bundle Deals using OLO POS.

Solution: The system now supports quantity > 1 for all discount types and ALL POS types.

 

Points Engine | Automatic Point Expiration for Last Activity Expiration

Background: Point expiration process needed an activity to be generated or invoked by calling the Member API.

Solution: The system now supports automatic expiration for Last activity expiration. Customers who want to enable this feature must request it from the Technical Services team. After initializing  the job for the first time, the expiration job will run everyday to check members eligible for point expiration and expire their points.

 

Points Engine | Point Expiration information in APIs

Background: Account Summary in Profile API and Get Member in Program API did not include information regarding member point expiry.

Solution: The above APIs now have a section to return how many points are expiring, when they are expiring, and what type of metric that is expiring. 

 

Points Engine | Last Activity Expiration

Background: Last Activity Expiration was present in the UI but required improvements on the backend to ensure reliable expiration of points. 

Solution: We introduced a marketer friendly UI to configure Last Activity expiration under the Rules page. Enhancements were made to the  Last activity expiration, where a member has to perform a qualifying activity to remain active. Clients are now able to specify a whitelist or blacklist of qualifying activities with a minimum point value associated with the activities. This gives them greater flexibility over which activities keep member’s points from expiring.

Fixes

Badges API | Image URL displaying missing image

A correction and enhancement to the Badges API where the base response for a Badge was missing the image url and displaying “missing image” when a badge had not yet been granted to a user. This modification will now populate the image url in the response with the uploaded image, regardless of whether the badge was granted to a member.

 

Campaigns | Member Preview not accounting for Member Preferred Location TimeZone

A correction has been addressed to offer evaluation and display in Member Preview of Campaigns. The Member preview displays the qualifying and available offers and the evaluation is now inclusive of Preferred Location TimeZone, when applicable, to determine offer effectivity for the member being previewed. 

 

Offer APIs | Account for Preferred Location TimeZone when additional Parameters are applied

A fix was delivered for the Offer API endpoints to account for Preferred Location TimeZone, as applicable, in the responses when additional parameters are applied in the API call e.g. Placements, Category, Campaign etc. 

 

Loyalty Version 23.1.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.1.0 unless otherwise stated.

Features

Offer Supports Preferred Location Time Zone

Background: Programs that operate in multiple time zones would like offers to start and end at the same time in the time zone of each member’s preferred location.

Solution: A new indicator, “Preferred Location TimeZone”, has been added for Offers within the Edit Offer, Response Period, and Usage Period Effectivity configuration screens. 

• If the member has a preferred location specified with a time zone, then the system will apply the effectivity, response, and usage end, where applicable, in the time zone for the member’s preferred location.

Example: If Member A’s preferred location is in Eastern Time, and Member B’s preferred location is in Pacific Time, and the Offer is configured to end at 23:59:59, the actual time for each member would be relative to their preferred location.

• If the member has no preferred location specified, or the preferred location has no time zone specified, then the offer effectivity, response, or usage time zone would be the program time zone.

Note: member.place_integration_id must be set up to ensure member’s preferred location. For use of a Custom Attribute as an alternative, see details about the new program setting below, Place Integration ID Override.

There will be an online help update to follow explaining how to add the new indicator to offers here.

Place Integration ID Override

Background: Currently the system uses a standard attribute for configured Places, the Place Integration ID. This attribute is able to be set for a Member within their profile and used to indicate a preferred location, store, or property. The system also uses the Place Integration ID for additional functionality related to Offer Effectivity. The functionality assumes programs are using the standard attribute vs. a custom attribute. 

For customers who have enabled a custom attribute, such as Favorite Store, Favorite Location, or Preferred Property, the standard Place Integration ID requires an override in order for this new capability to apply the location time zone properly.

Solution: A new program setting called “Place Integration ID Override” has been added which will map to the custom attribute enabled for the program. Specifically, this new setting allows the program to use a custom member attribute as an alternative to Member Place Integration ID and link to the Place Integration ID to determine the time zone for a location, store, or property in the Member profile. This setting is required to be configured if the program is using Offer Effectivity based on a Member’s preferred location, and if the program has a custom attribute for locations. 

There will be an online help update to follow explaining how to enable this new program setting here.

Offer Response Hierarchy Rule Order

Background: Currently when offers are fetched by the POS APIs, the offer responses are sorted in a standard hierarchy: 1. Coupon Type, 2. Discount Type, 3. Usage End, 4. Discount Value, and 5. Created at. Programs do not currently have the flexibility to change the sort order for their program should this be required for any reason, such as to align with Program Terms and Conditions.

Solution: A new Program Setting, “Offer Sorting Hierarchy”, has been created to allow customers the ability to apply a different offer rule ranking. 

This new setting will allow the program administrator to select an offer response sort from a drop-down in the program setting. The order in which the offer attributes are selected will be the order with which the Rule will apply. For example, if the admin first selects Discount Value and then Usage End, the rule hierarchy will be the following for all offer responses: 

1. Discount Value
2. Usage End

Notes: 

• The program administrator may omit any offer attribute from the hierarchy; all five do not need to be indicated in the program setting, but the admin must identify a minimum of one.
• As a general default, customer programs will continue to use the standard order rule ranking outlined above, unless a different hierarchy is indicated within the Program Setting. 

There will be an online help update to follow explaining how to enable this new program setting here.

Loyalty Connector for Aptos POS

Background: Aptos POS required a connector to integrate with Cheetah Loyalty.

Solution: A new connector has been created to allow Aptos POS and its Loyalty and Customer management capabilities to integrate with Cheetah Loyalty. The connector supports the following capabilities:

• To configure default program settings to allow Cheetah to provide basic Loyalty Plan definition* details to Aptos. Note that the Program Settings for this connector can be found under the Aptos program setting group.
• To specify one or more rewards** to be available to the Aptos integration. This is accomplished by configuring a reward category called ‘Aptos’ in Cheetah, and attaching it to one or more rewards that are intended to be used by the integration.
• To see details of the Loyalty plan and rewards shared by Cheetah via Aptos.
• To create or update Loyalty members and send them to Cheetah via Aptos.
• To look up Cheetah Loyalty members by various attributes, view details of the profile, and attach the member to the Aptos transaction.
• To view and apply available program rewards to the transaction based on the member’s available points.
• To submit a transaction from Aptos to Cheetah via real-time API integration for the member to be awarded points and redeem any rewards.

Please contact your Cheetah representative or account manager to enable this connector.

*  The “Loyalty Plan definition” is an Aptos concept. It includes an identifier, a plan name, a start date, and other Aptos dependencies.

** Rewards in Aptos that are in the Loyalty plan are expected to be returned by the Loyalty platform. In Loyalty itself, a reward can be a coupon reward (points used) or coupon offer (no points used). 

There will be an online help update to follow explaining how to enable these new program settings here.

Platform Support for OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange (PKCE)

Background: Previously, Cheetah has supported a password grant approach where a Client ID and Client Secret were passed to authenticate a user and retrieve an access token to make subsequent requests to the Member API. However, this approach can be exploited if the mobile app or website exposes the API credentials.

Solution: Platform support has been added to implement more secure client application integrations with Cheetah by enabling OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange, or PKCE. PKCE is used to make OAuth 2.0 Authorization Code grant type more secure through additional code verification and challenges.

There will be an online help update to follow explaining how to obtain an access token via OAuth 2.0 Code Flow with PKCE here.

OLO Order Id Can Be Saved as Unique Order Identifier

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. Specifically for OLO, the POS usually has a different order identifier than OLO, so duplicate OLO orders can theoretically be created.

Solution: A new capability has been added to save OLO order identifiers as globally unique identifiers for Cheetah order records, eCommerce, and POS Integrations. This allows brands that have OLO integrations to capture the OLO order id in Cheetah as a unique key which can prevent duplicates if the OLO orders are submitted to the point of sale (POS) system and then transmitted to Cheetah in a retro claim file feed.

In addition, using this new feature will prevent duplicate order records from being created as long as the retro claim file feed includes the OLO order id in the order global unique identifier (guid*) column, and ‘guid’ is used as a match by option in the import definition. With this configuration, the system will check the imported order.guid against all existing orders and prevent creating a new order if the same OLO order id was used by an existing order.

* A “guid” (global unique identifier) is a 128-bit number created to uniquely identify resources.

There will be an online help update to follow explaining how to enable this new program setting here.

System Evaluates Punch Card Criteria on Orders Submitted via Sparkfly and OLO Integrations

Background: Previously, brands needed to configure triggered actions to implement punch card evaluation via Sparkfly and OLO integrations.

Solution: The system can now evaluate criteria on member punch cards when processing orders submitted via Sparkfly and OLO integrations.

There will be an online help update to follow explaining how to enable this new program setting here.

System Evaluates Offer Location Eligibility on Orders Submitted via Sparkfly and OLO Integrations

Background: Brands that submit orders to Cheetah via Sparkfly or OLO integrations wanted to allow or restrict offers from being returned, depending on whether the order location is permitted to access and redeem the offer.

Solution: Brands that submit orders to Cheetah via Sparkfly or OLO integrations can now configure the Offer Location Eligibility parameter.

Similar to Segment Eligibility which 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 neither Included nor Excluded Locations specified, then the offer is available in all locations. 
• When an offer is configured with Included Locations, then only those locations can access the offer.
• When an offer is configured with Excluded Locations, then only non-excluded locations can access the offer.

There will be an online help update to follow explaining how to enable this new program setting here.

Wallet Pass Prohibits Sharing Capability

Background: For customers who wish to enable a Pass that prohibits sharing within iOS or Android.

Solution: The Wallet Pass has been updated to allow for configuring the Pass to allow or prohibit sharing. Specifically, this new configuration setting prevents members from sharing their Loyalty card with non-members.

Note: This setting is a preventative measure only from within the Wallet App and does not prevent a user from sharing the pass in other ways, such as a screen print. 

There will be an online help update to follow explaining how to configure your wallet pass from sharing in iOS here and Android here.

Enhanced Performance of the Content Reward Pick Winner Process

Background: Previously, when trying to pick a large number of winners, the Content Reward Pick Winner process would intermittently fail.

Solution: The Contest Reward Pick Winner process has now been enhanced so even large numbers of winners can be successfully determined.

Enhanced the Certificate Inventory Threshold Email to Include Offer Name in Plain Text

Background: The email previously included the offer name as part of a hyperlink.

Solution: The Certificate Inventory Threshold email was enhanced to include a plain text offer name element to simplify programmatic parsing of the email message.

Program API | Campaigns Pagination

Background: Customers could not specify number of campaigns returned by the API.

Solution: Support has been added to the Program API Campaigns endpoint for page and per_page parameters to allow customers to now specify the maximum number of campaigns returned by the API.

Program API | Offer Response Fulfill Error Code Update

Background: Previously, the Program API Offer Response Fulfill endpoint returned an error code of “Code 500: Internal Server Error” when the Offer’s usage period was beyond the current date. This error was vague and did not describe why the process failed.

Solution: The endpoint error handling has been updated to return a more descriptive error code when this scenario is encountered. The new error code is “5004: Invalid, Offer Certificate no longer effective”.

Endpoint for reference: PUT <base_url>/program/api/offers/responses/<id or certificate_code>/fulfill

Member API | Badges Description and Categories

Background: Previously, Member API Badge endpoints did not include Badge descriptions and categories.

Solution: The Member API Badges endpoints have been updated to now include Badge descriptions and categories as follows:. 

• GET <base_url>/api/badges/me added description and categories
• GET <base_url>/api/badges/:id/me added description and categories
• GET <base_url>/api/badges added categories

Note: All Badge endpoints have been updated with Categories as a query parameter.

Fixes

Wallet Pass | Added Google Wallet callback eventType

For every delete performed by the user in Wallet, Google makes callbacks (event triggered data request/ response) to the merchant with details about the add or delete event. Support has been added for eventType: Delete to track uninstall of Wallet Passes on Android to fix Passes which seem to have disappeared from the Wallet.

Punch Cards | Fixed Intermittent Recurring Reminder Moment Failures

A fix was delivered for intermittent failures of recurring reminder moments on External, Choice, and Multiplier punch cards.

Punch Cards | Added Retry Logic to Handle Intermittent Timeouts When Sending to Cheetah Messaging

A fix was delivered to improve reliability of queued message sending and how that process handles intermittent timeouts when sending requests to Cheetah Messaging. Retry logic was added to the process to resend a request when non-permanent errors are encountered.

Punch Cards | Fixed an Issue where Queued Messages Were Retried in a Loop

A fix was delivered to prevent queued messages from being retried endlessly.

Punch Cards | Fixed Intermittent Issue Where Reminder Moment Statistics Were not Captured by the System

A fix was delivered to improve the reliability of the system to capture and record the audience and delivery statistics of Punch Card reminder moments.

Offers | Fixed Error when Attempting to Fulfill Certificate Offer after Removing Excess Certificate Codes

A fix was delivered so that offer fulfillment continues to work after removing unused certificates on an offer.

Offers | Fixed an Issue where Duplicate Certificate Codes were Issued

A fix was delivered to address an intermittent scenario where certificate offers, issued via triggered actions, would reassign the same offer certificate code value to different members.

Offers | Fixed a Memory Leak in Grant Anniversary Scheduled Job When Issuing Large Volumes of Offers

A memory leak in scheduled job processing of large volumes of offer issuance was fixed in this release.

Badges | Fixed an Issue where the System Displayed an Incorrect Badge Image when the Badge Includes Multiple Levels

A fix was delivered to ensure the system displays the correct member badge image for badges with multiple levels, where there are different images for each level.

Orders | Fixed Order Display Details for OLO Orders

Fixes were delivered to present the OLO order business date on the Orders detail page in local time versus UTC, which was causing some business dates to be displayed with incorrect values. Coupons applied are now shown in the order details page.

Order Rules | Fixed Case Where Order Rules Became Unusable if Associated Business Unit was Deleted

A fix was delivered to allow order rules to be available after the associated business unit was deleted from the system. Order Rules can now be reconfigured to point to a different business unit.

Members | Fixed a Batch Member Merge Failure When Multiple Members Share the Same Merged From Value

A fix was delivered to correctly merge member records even if they share the same “merged from” id value.

Challenges | Fixed an Issue where Updates to the Challenge Response Could not be Retrieved in Later Requests

A fix was delivered to allow updates to the challenge response via the Program API to be available to retrieve via later requests.

Offers | Fixed an Issue where Duplicate Certificate Codes were Issued

A fix was delivered to address an intermittent scenario where certificate offers, issued via triggered actions, would reassign the same offer certificate code value to different members.

 

Loyalty Version 23.0.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 23.0.0 unless otherwise stated

Features

Multi-Factor Authentication Support for Member API

This feature allows programs that use the Member API to support member authentication and prefer to implement a higher level of authentication security to enable the system to send a one-time passcode (OTP) that members must include when authenticating to successfully complete the process.

The feature is enabled via a set of new Program Settings under a grouping called “Member API MFA” and can support sending the OTP via Email, SMS, or optionally both channels. Mobile and Web applications that implement member authentication using the Member API that intend to use the feature need the following steps:

1. Change the implementation to accommodate prompting the member to confirm the preferred channel to send the OTP.
2. Add an additional API call to initiate the sending of the OTP on the preferred channel.
3. Allow the member to input the OTP and submit it to the system to successfully complete the authentication process.

POST <base_url>/oauth/token is the Member API Authentication endpoint that now supports multi-factor authentication.

Note: this feature is only for customers sending via Cheetah Messaging implemented with EDP Sends / Smart Sending enabled.

Online help update can be found here.

Member API Registration Endpoint Allows Signup Without Email

The Member API to register a new member previously required email to successfully complete the signup process.

In this release, it is now possible to enable the system to allow signup without needing to provide email. Mobile Phone, Card Id, and Username attributes are all now supported alternative identifiers and can be submitted for signup without including email.

Note:  this feature is only enabled on request, so please contact your Cheetah account manager to request that the “ALLOW_SIGNUP_WITHOUT_EMAIL” option be enabled in your environment.

Combined Gift Card Balance For POS, Sparkfly, and OLO Integrations

Gift Cards, which serve the purpose of a Stored Value Reward or a multi-use discount item that holds a balance, have been enhanced in this release to support returning a combined balance across all member gift card instances.

This capability can be important for brands that prefer to implement gift card expiration and that want to return a single reward balance to point of sale (POS) or ecommerce systems.

This feature can be enabled on Gift Card Classes that aren’t already configured to add value to a single card instance, and can be used in commerce integrations using the Cheetah POS API, Sparkfly, or OLO integrations.

When an amount is redeemed against the combined balance, the system will debit the amount against the member gift card instance that is expiring first, and then against other gift card instances expiring later until the entire redeemed amount is debited.

Optimized Sparkfly API Response Time Performance

The Sparkfly API was enhanced in this release to reduce API response time when members are attached to large orders via the Sparkfly integration, and when the system returns custom messages in the response.

Gift Card Program API Credit and Debit Endpoints Can Now Ignore Changes to Expired Cards

The Program API for Gift Cards has been enhanced to include an ‘ignore_expired’ parameter that when passed will suppress any attempted credits or debits if the card is expired. This can be useful when the program prefers not to allow changes to expired Gift Cards.

Challenges, Offers, Rewards, and Punch Card Resource Attribute Token Values Displayed in Content Editor

In this release the content editor has been enhanced to allow the display of resource attribute values that reference the same object type (such as Offer, Reward, Challenge, or Punch Card) that the content editor is defining content for.

For instance, if configuring the content for an Offer, it is now possible to include resource attribute content tokens that reference Offer elements such as the label or the date it was published. Then these attributes or elements can be  included in the Offer content.

This feature is now enabled for Challenges, Offers, Rewards, and Punch Cards.

Punch Card Type Reminder Moment Enhancements

Reminder Moments are contextually relevant messages sent automatically to Members based on their Punch Card activity. Reminder Moment audience definitions have been updated in this release to handle the case where a Punch Card Type is configured with an Automatic Start Type. This allows audiences to not have to check whether a member accepted the punch card.

Reminder Moments also have been enhanced to support recurring schedules with a reference to when a punch card became usable. This allows reminders to be sent on a specified day since the member punch card can start earning credit automatically.

Order Rule Fixed Amount Bonus No Longer Requires Qualified Item List

Order Rules configured with Fixed Amount bonuses no longer require the bonus to have qualified items configured.

Source Scheduled Job and Source Segment Information now available for Activity Reporting

Granting Object Details is a set of details the system writes to the activity to establish the activity context. For instance, when you have a reward that generates an offer for a member, the offer activity will include one or more attributes that indicate the granting object detail.

When generating activities from scheduled jobs, the system will now include the scheduled job and related segments used in the granting object details on the related activity. This allows reporting to be configured to highlight which job generates the activity and which segment was targeted.

Fixes

Fixed Mobile Wallet Passes Installed as Inactive

A fix was added to correct an issue that caused Mobile Wallet passes to occasionally be installed in inactive status.

Fixed Duplicate Image Appearing in Mobile Wallet

A fix was delivered to correct an issue where Mobile Wallet would incorrectly display two images when only one was added to the wallet pass configuration.

Fixed Extra Label Appearing Under Barcode in Mobile Wallet on Google

A fix was delivered to correct an issue where the Mobile Wallet pass would incorrectly display extra text below the barcode on the front of the wallet pass in Google Wallet.

Fixed Metric Transfer Reward Support for Metrics With Decimals

A fix was added to correct an issue where Metric Transfer Rewards were not correctly handling metrics with decimals.

Fixed Intermittent Offer Certificate Code Reuse Issue

A fix was added to correct an issue where the same Offer Certificate Code intermittently would be issued to multiple members. The fix covers issuance through triggered actions, API, and the admin console.

Fixed Incorrect Handling in getExpiringMetric() Groovy Function

A fix was added to correct the handling of negative earn activities by the getExpiringMetric() function. Previously the function incorrectly calculated expiring points when earn activities that had negative values were encountered.

Fixed POS API Performance When Enabling Punch Card Evaluation When Using Segments

The performance of the POS API was optimized in this release to fix an issue where response times increased if Punch Card evaluation was enabled and the whitelisted Punch Card used Segments.

Fixed High Memory Usage in Punch Card Push Message Queue Service

A fix was delivered for memory usage by the queuing service used to send push messages triggered from Punch Card Reminder Moments.

Fixed Cross-Site Scripting Vulnerability

A fix was added to correct a cross-site scripting vulnerability found when using the <base_url>/is endpoint.

Fixed Lookup Content Token Update Issue

A fix was made to address a scenario where lookup content tokens lost their configuration when making an update.

Fixed Smart Quote Handling in Content Templates

A fix was added to correct the handling of smart quotes in content templates.

Fixed GET Campaign Program API Response Details

A fix was delivered to correct an issue where the GET Campaign Program API didn’t return expected created_at and updated_at data.

Fixed Incorrect Receipt UI Handling of PDF

A fix to the Receipt UI was made to correct handling of PDF receipt images.

Deprecated the Certificate Inventory Notifier Action from Triggered Actions

The ‘Certificate Inventory Notifier’ action was found to cause performance and scalability issues and has been deprecated.  There is a Scheduled Job action of the same name that can be used instead.

Loyalty Version 22.4.0 Release Notes

All fixes are automatically available to all customers upon upgrade to version 22.4.0

Fixes

Fixed Offer Certificate Import to Generate Offer Response and Set Usage Period Details

A fix has been made to allow the import of Offer Certificates, where the status is set to redeemed, to create an Offer Response and the usage_start and usage_end dates are specified in the import, so that these values are on the Offer Response record.

Fixed Offer Certificate Import to Lookup Member Based on Integration_Id Attributes

A fix has been made when importing Offer Certificates with an integration_id or integrationXX_id attribute value, the system will correctly lookup the member based on that value and return the member.id value to the import. This will enable linking the member to the Offer Certificate, and also the related Offer Response record, if created.

Fixed an Issue where Content Sources Did Not Return Offer Responses when Ordering Strategy Used First Expiring

A fix was made for Content Sources that use Offer Responses, to return data correctly, when the Ordering Strategy uses the option First Expiring.

Fixed an Issue with “Set Nearest Place” Inbound SMS Handler Action

Inbound SMS can include a handler definition that will create a new member record if the mobile phone used to send the SMS isn’t already in the system.  The handler can also include a Set Nearest Place action to link the member to the closest active place in the system based on a ZIP code provided in the Inbound SMS flow.

A fix was made to the Set Nearest Place action to correct an issue, so that members are correctly  linked to the place record closest to the member’s zip code.  

Optimized Performance of GET /punchcards/json_blocks Endpoint

A query optimization made in this release reduces the number of SQL calls to retrieve punch card data, slightly improving API response time.

Optimized Performance of POST /punchcards/accept Endpoint

A query optimization made in this release consolidates SQL queries and slightly improves API response time of this endpoint.

Loyalty Version 22.3.0 Release Notes

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-related program settings that were removed in this release and consolidated under the Tier Scheme Settings include:

• Default Tier Period
• 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.

Refer to Tier Scheme Settings section in the Online Help for more information.

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

Offer responses are generated in two scenarios:

• Members claim an offer that they are eligible for, at which point certificates will be allocated if applicable
• Offers are automatically assigned to members using a scheduled job, triggered action, or via a reward

Offer responses are most often updated through the API. However, there are some scenarios where brands have a requirement to update the offer responses from external systems, such as if the offer expiry is managed, or if offers are redeemed via an external system. These updates would need to be done on a regular schedule to keep offer responses synchronized across the external system and Cheetah Loyalty.

Solution

To enable offer responses to be updated via an external system, a new Response Identifier has been added, called "Id (Integer)", to the mappable fields in the offer response records. This new feature enables offer responses to be updated via a batch process from an external system, ensuring correct updates to the records without needing to use the API. This can be set to a daily schedule.

 

 

Updating the offer responses' status allows them to remain in sync with systems external to Cheetah such as POS or Ecommerce systems.

Refer to Offer Responses update and Response Identifier feature in the Online Help for more information on how to do this. 

 

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. 

Refer to Skip OCR Scanning program setting in the Online Help for more information.

 

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.

Refer to the Available Member Content Locales in the Online help for more information.

 

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.

Refer to Order Rules updates in the Online Help for more information.

 

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 Response Data to Preserve When Member is Deleted

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 anonymized data while complying with a member deletion request. 

Refer to Response Data to Preserve When Member is Deleted program setting in the Online Help for more information.

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.

Archive

• Version 23.4.0 Release Notes
• Version 23.3.0 Release Notes
• Version 23.2.0 Release Notes
• Version 23.1.0 Release Notes
• Version 23.0.0 Release Notes
• Version 22.4.0 Release Notes
• Version 22.3.0 Release Notes
• Version 22.2.0 Release Notes
• Version 22.1.1 Release Notes
• Version 22.1 Release Notes
• Version 22.0 Release Notes
• Version 16.0 Release Notes
• Version 15.0 Release Notes
• Version 14.0 Release Notes
• Version 13.0 Release Notes
• Version 12.0 Release Notes
• Version 11.0 Release Notes
• Version 10.0 Release Notes
• Version 9.0 Release Notes
• Version 8.0 Release Notes