CDP | JAS '22

I. Pre-computed extended fields

In the airline industry, miles (equivalent of points) are awarded based on distance traveled by a customer between an origin and destination city pair. When a flight booking of a customer is sent to our CDP, the miles information for a booking between origin and destination is not typically made available in the booking file by the airline system. The CDP is expected to compute the distance for any city pair sent.

For supporting this, we now have an import profile to pre-compute and populate the distance between city pairs that is sent in the transaction add call. That is, for a given airline, the routes or city pairs and distance between them are known upfront. Using the import profile, you can upload the distance between city pairs into the CDP beforehand. When a booking comes with a specific origin and destination pair, the miles field is automatically filled with the appropriate distance.

Origin, destination and miles are all transaction extended fields. Based on origin and destination value passed in the booking, miles value is fetched from the CDP (you have already given the value in import) and added against the miles extended field. Note that this enhancement is not specific to city pairs use case above or origin/destination extended fields alone. This can be utilized for any use case where an extended value needs to be derived based on values passed in other extended fields.

II. Transaction Requests for Receipt Scanning Loyalty Programs

A new type of request entity - transaction request - has been built to support Customer Service Representative (CSR) workflows for receipt scan-based loyalty programs. In receipt scanning loyalty programs, which are typically run by Consumer Packaged Goods(CPG) companies, customers make a purchase at a store, scan the purchase receipt and upload it to an app or web portal of the company running a loyalty program to earn points.

The interpretation of the uploaded receipt is typically done by a receipt scanning service that is able to identify the line items, pick the quantity, amount and other relevant to the items specific to the brand that is running the program from the receipt and then make a transaction add call to the CDP for points earning. This interpretation of the receipt by the scanning service might be inaccurate at times and these will have to go through a manual review process by CSRs of the brand.

For this purpose, we will have built a transaction requests entity where these inaccurate interpretations of receipts can be parked for review. CSRs can review the content (via a frontend app such as Member Care) of the transaction and images of receipts uploaded by the customer, modify it if needed and then approve it so that the transaction is captured and points are issued to the customer.

III. External identifier for Behavioral Events

Similar to bill number for transaction events, we now have support for an external identifier for Behavioral Events. Brands will now be able pass their own identifiers for each event they send to our CDP. As a result, they will be able to achieve two things - First, when the same event is sent more than once to the CDP, the CDP will be able to reject duplicates based on configurations set for Behavioral Events based on external identifier passed (similar to bill number in transaction entity). This way, points will not be issued more than once for the same event and brands will be able to avoid unnecessary liability. Second, brands will be able to audit events accurately as events can be tagged using the external identifiers passed from the event source itself.

IV. Customer Status Update Event Notifications

Whenever the Customer Status of a customer is updated, you will be able to see the status update along with reason, if any, as a part of the CustomerUpdated event. This will be useful in several scenarios where downstream applications are dependent on event notifications. For example, let’s say that a customer has been identified as a fraud and his/her/their status has been changed to a FRAUD CONFIRMED status label. In such a scenario, the downstream apps should be aware of this change so that they can take corresponding actions. This will now be possible with the release of this enhancement.

V. Auto Generation of Customer External ID

Typically, in cases where mobile or e-mail is not the primary identifier, the external identifier is used as a customer’s primary identifier. This external identifier is nothing but a customer identifier that is generated by a brand and passed to our CDP during customer registration.

However, in certain industries, the CDP is expected to generate the customer identifier for every customer who registers. For example, in the airline industry, the customer primary identifier is something called Frequent Flyer Number (although mobile or email are typically captured during customer registration). This number, abbreviated as FFN, is generated by the loyalty system (in our case, our CDP) as an identifier when a customer registers. The FFN is expected to be of a specific length and have a check digit (MOD7 or MOD10) at the end of it. Think of this as something similar to credit card numbers.

We now have support for generating the customer external identifier on our CDP for customer registration events. The length, offset and check digit of the external ID can be pre-configured and the numbers will be generated accordingly every time a customer registers.

VI. Connect+ Enhancements

We have released a couple of minor enhancements on Connect+ in the last quarter:

Join based on common file name

As of now, Connect+ ingests or joins files based on a first come first serve basis. That is, the file (s) that is first uploaded in the source FTP folder is picked first for ingestion or join. Although this may work for API templates, it led to issues in join templates.

For instance, let’s say a user wants to join two files - File 1 and File 2 on a weekly basis - and push into another FTP folder. File 1 CSVs are named in the following format - File_1_20211201, File_1_20211202 and so on. File 2 CSVs are named in the following format - File_2_20211201, File_2_20211202 and so on. Now let us say that the user uploads 7 files (one file for each day) of File 1 and File 2 respectively every Sunday and wants to join the files based on the date on which they were generated. That is, File_1_20211201 should be joined with File_2_20211201. Similarly, File_1_20211202 should be joined with File_2_20211202 and on.
Until now, this was not possible as the File 1 and File 2 files were joined based on the time at which they were uploaded in the source FTP folder. For example, if File_1_20211201 was uploaded first followed by File_2_20211202, Connect+ used to attempt to join these two files instead of waiting for the right join file - File_2_20211201.

With the common file name join enhancement, you can tell Connect+ to wait for the right file to join using the naming convention used for files. In the case above, you can direct Connect+ to join only when the dates match in the names of File 1 and File 2.
Data Reconciliation Summary Report

We released the data reconciliation template in the last quarter for identifying events missed from ingestion in our CDP when compared to source data. For example, with the reconciliation template, a brand can compare transaction data between its source and Capillary CDP to identify transactions that got missed from ingestion in the CDP. Post identification, missing data can be ingested using the transaction add template on Connect+ itself.

To make the Connect+ user experience better, we have introduced a summary report for every reconciliation dataflow that runs on Connect+. Whenever a source file is processed and compared to data in our CDP, a summary report is parked in a FTP folder giving some useful information on the reconciliation job that was attempted. This includes data such as number of rows in the source file, number of unique matches with the data on the CDP (depending on what is being subject to reconciliation) and so on.

V. Member Care new UI Enhancements

On the Member Care new UI, we have the following enhancements released

Customer Data Audit Logs

Brands using the new UI will now be able to view customer data audit logs (if enabled) on Member Care under the Events -> Audit Logs section. Currently, only the following aspects of the customer can be logged:
a. Custom fields
b. Extended fields
c. Identifiers
d. First name and Last name
e. Card status (linked to customer)
f. Subscription status
g. Customer status

Note that this is a limited release and we will be rolling it out only to a few brands.
Role Based Access Control in the new UI

We have introduced RBAC in the new Member Care UI as well. Until now, any user of an org who had access to Member Care was allowed to use the new UI completely (without restrictions, if UI was enabled in an org ). Now, with RBAC applied to the new UI, role-based restrictions that were present in the old UI will be applicable to the new UI too. With this, we will be going ahead and enabling the new Member Care UI in all orgs in OND’22 quarter.

Note that you will be able to seamlessly switch between the new and old UI still. However, the new UI will become default.
Line-level data export

You will now be able to export line-level data of a specific transaction in the new UI. Please head to Transactions -> Events -> Transaction (select any) -> Line item details to initiate the download

VI. Custom Pages on Member Care

Member care already supports a few "native" actions such as change identifiers, retro transaction linking, goodwill points/coupon issual and so on. In the last year or so, we have been getting requests to enable Customer Service Representatives (CSRs) who use Member Care to perform "custom" actions such as editing customer profiles, linking/ delinking customers to partner programs, add transactions and others. Such "custom" actions (or actions customized to needs of a brand's CSR team) can now be enabled on Member Care via Sharingan custom pages. For example, let us say that a brand wants to allow its CSR to modify specific attributes of customers. This can be accomplished by building a custom page on Sharingan and embedding it Member Care. Only CSRs who have access to Member Care will be able to use these embedded pages. Also, on Sharingan, a page can be built for custom actions using any Capillary built APIs. There will be no need for any kind of onboarding.