Personalized offers

Contents

Currently, personalized offers are not supported by NCR.

Overview

Personalised offers (also called config offers) are a specific type of offer that is only available to selected guests. These need to be handled slightly different to systemwide offers, and those details are covered in this document.

Please make sure that you understand https://rbictg.atlassian.net/wiki/spaces/RDP/pages/4226712293 before reading this document.

Data structure

All offers, regardless of their type, are stored in our Loyalty Platform. We also use a CMS platform called Sanity, where our team and the franchisee can set up marketing materials such as the offer's name, description, and images. Additionally, they can define within Sanity how the offer works, including rules for redemption, limitations, any requirements, and some other miscellaneous aspects of each offer.

It’s important to understand that both of these systems store and handle data separately from each other, some data gets synced between platforms, and some data does not. Sanity for example has all the images for any given offer, whereas the Loyalty Platform does not. The same is true in the other direction, the Loyalty Platform contains the records for Personalized offers, whereas Sanity does not.

 

The way we like to think about it is, that for any content displayed to the final user, we want to usually use the data from Sanity. For any business rules and logic, like which offer should be displayed to which user we want to use the data from the Loyalty Platform.

Also, please keep in mind that personalized offers will only come from the Loyalty Platform, and their Sanity ID will point to a Configuration Offer, like a Many-to-One relationship.

Retrieving personalised offers

This is an example Sanity GraphQL query that returns personalized offers:

query getSanityOffers { LoyaltyOffersUI(id: "feature-loyalty-offers-ui-singleton") { # Available for all users. # You can use these to lookup assets from global. sortedSystemwideOffers { _id loyaltyEngineId name { enRaw } } # These are config. offers (templates). # You should use these only to display content (images, names, etc). # You can use these to lookup assets from the actual Personalized offers. liveConfigOffers { _id loyaltyEngineId name { enRaw } } } }

Processing personalized offers

This section explains how the Loyalty API endpoints must be used to process orders that contain personalized offers.

Identify

This endpoint can be used without any changes to support personalised offers.

Validate and Update

When sending a request containing personalized offers to https://rbictg.atlassian.net/wiki/spaces/RDP/pages/4961140780 or https://rbictg.atlassian.net/wiki/spaces/RDP/pages/4947771470, it’s important to include the personalized offer’s loyaltyEngineId. In this case, the incentiveId does not need to be sent.

Example request

{ "channel": "Restaurant", "created": "2021-05-04T13:39:47Z", "loyaltyId": "$loyaltyUserId", "serviceMode": "$serviceMode", "status": "PENDING or CLAIMED", "transactionDetails": { "currency": "USD", "order": [ { "incentiveId": "$sanityOfferId", "loyaltyEngineId": "$offerLoyaltyEngineId", // (Optional) Use this field for all Offers if supporting Personalized Offers "name": "$5.00 chicken sandwich meal", "price": 5.00, "productId": "$offerPlu", "productType": "offer", "quantity": 1, "referenceId": "5", // line id "tax": 0.50 } ], "payments": [ { "amount": 500, "type": "$paymentMethod", "ccToken"?: "$panToken" } ], "posVendor": { "matchingId": "$smgCode", "operator": "$operatorId", "posType": "$posVendorName", "storeId": "$rbiStoreId", "supportingPos": "POS vendor name (optional field)", // vendor to return plu for "terminal": "$terminalNumber", "transactionId": "$posTransactionId" } }, "transactionId": "$loyaltyTransactionId" }

Example response

{ "loyaltyId": "$loyaltyUserId", "points": 14464, "pointsEarned": 50, "pointsRedeemed": 0, "transactionId": "$loyaltyTransactionId" }

Â