CDP Guidelines for Data Sanity and Campaign Governance

These guidelines explain the data formats and procedures for ingestion and avoid data redundancy.

Impact of Compromised Data Sanity

On CDP Profiles

Lemnisk uses a combination of Primary and Secondary user identifiers around which the data is stitched. In cases where data is not cleaned by removing duplicates of these ‘user identifiers’ before ingesting, multiple profiles get merged together into one user and only the latest identifiers remain. This will result in profiles with the wrong email IDs, phone numbers, names, browser details, etc. Sometimes the merging of multiple profiles results in the blacklisting of profiles, which means that these profiles will not be stored in the CDP and hence non-usable. These will only remain as part of the event logs.

On Active Use Cases

Active use cases will see fewer impressions as segment audience sizes will drop as profiles merge into each other based on wrong merging logic. Moreover, personalized communication will have errors including but not limited to name-based macros, policy information-related macros, and other user-level product offers created by CDP business users. Further, if CDP profiles get merged based on the wrong merging logic, it is also possible that use case impressions will get served to users who are not supposed to be part of a segment in an ideal scenario.

On Reporting

While due to a drop in audience sizes, general campaign performance will drop. This also impacts reporting and analytics. Clients trying to analyze and identify potential audiences will see a drop in performance numbers that are misleading. Moreover, the quality of data being fed into AI models will also be hampered, for example, lead scoring models that predict the propensity of leads to convert.

Client Guidelines to Ensure CDP Data Sanity

Via Offline File Ingestions

Offline fine ingestion is a way of ingesting customer data into the Lemnisk system. The file can have things like user attributes, user identifiers, offer details, and PII data about the user like email Id, phone number, etc.

• Phone Numbers should be represented in E.164 format. Not complying with this will break profile match rates within the CDP and with FB/Google Ads

• Email IDs should be in all lowercase letters. Not complying with this will break profile match rates within the CDP and with FB/Google Ads

• The File to be ingested should always be shared via the SFTP server.

• The File should be in a tsv(tab-separated values) format.

• The order of fields should be fixed and should not change between different successive versions of the same file.

• The user identifier columns are case-sensitive and hence these values should not change across multiple files.

• The first column should not be blank for any of the records in the file

• If the last column is blank in any of the records, it should be enclosed in double-quotes.

• The data in the file should be UTF-8 encoded.

• If the column value contains a tab character, the whole value should be within a double quotes

• The double quotes used within the value enclosed in double quotes should be escaped with a backslash. For example “Harriet Jacobs writes, \“She sat down, quivering in every limb\””

Email ID sent to CDP should be in small caps.

Phone numbers should always be sent to CDP in E.164 format.

Via Website/ App

Lemnisk can collect event data from sources like websites and apps through Lemnisk SDKs. While data from the website can be collected through JavaScript SDK, data from apps can be collected through Android, iOS, Flutter, and React Native SDKs. These SDKs need to be installed into the website or app so that the events can flow into the Lemnisk system. These events are then stored in the Lemnisk CDP which can be used to target the users through various channels and destinations.

For Lemnisk clients that use Adobe Launch as a tag manager, Lemnisk publishes its private extension within their Launch Extensions Catalog - this offers a marketer-friendly way to send website events to the Lemnisk CDP.

Following is the process to ensure data sanity through the Website/App:

• Tracking plan: Lemnisk will provide the document that contains the details of events and how and where it needs to be implemented depending on the use cases provided by the customer

• Vetting process: The tracking plan will also be reviewed and approved by the Lemnisk team to check the feasibility of the event flow and tracking. For any internal template best practices managed by the client teams cross-functionally, the client needs to conduct a thorough internal review process and inform Lemnisk about any changes needed, which the Lemnisk team will evaluate. Refer to the guidelines mentioned below for standardization of key variables that flow into the CDP.

1. Any amount should always be in number format without any spaces, commas, etc. The currency and price should not be in the same property, rather they should be captured in different properties as different data points.

Right Method:

1lmSmtObj.track("event_name",{ 2 "price": 3500, 3 "currency": "INR" 4})

Wrong Method:

1lmSmtObj.track("event_name",{ 2 "price": "3500", 3 "currency": "INR" 4})

Another Wrong Method:

1lmSmtObj.track("event_name",{ 2 "price": "3500 INR" 3})

2. Email ID should always be in lowercase. This should be explicitly written wherever email is being captured as a property. Right Method: [e-mail] Wrong Method: [e-mail]

3. Phone number must follow the E.164 format, i.e, the phone number should look in this format: +(country code)(phone number) Right Method: +918xxxxxxxxx Wrong Method: 8xxxxxxxxx

4. DoB must follow the YYYY-MM-DD format is the correct format. Right Method: 1992-12-28 Wrong Method: 1992/12/18 Another wrong Method: 18-12-1992

• Implementation: The customer will install the required SDKs into their system along with the events mentioned in the tracking plan so that the event flows from your system to the Lemnisk CDP

• Live events: Lemnisk will then check and verify if the live events are flowing from the website and apps into the CDP environment in the expected format where it can be used to target the users through different channels. If any discrepancy is identified between the tracking plan versus what was implemented by the client, Lemnisk will collate a list of such discrepancies and share it with the client within 2 working days of implementation.

Via REST API

The Lemnisk REST API enables you to integrate any third-party system with the Lemnisk CDP. It enables data ingestion through server-to-server integrations between the platforms due to which the events can flow from the server via REST API to the CDP. Whenever you make a call to the API, the request hits Lemnisk servers where the data is routed to one of the destinations configured for this source.

• A content-type header of application/json is required for data to be sent via Lemnisk REST API

• The API is authenticated via the API key which will be provided by Lemnisk

• The REST API supports only Identify and Track event types

• It allows a maximum of 500KB size per call. If these limits are exceeded, the API will respond with a 400 Bad Request

• The response body content type for each request (whether successful or fail) will also be application/json

For more information please refer to the standard REST API documentation provided by your Customer Success or Delivery POC.

Impact of Compromised Campaign Governance

On Customer Experience

One downside of not following the right levels of campaign governance is a direct impact on customer experience. While Lemnisk encourages our customers to use the CDP UI to create campaigns directly, a lack of check on the Segmentation criteria, Channel setup, Engagement setup, trigger points, Impression caps, and Segment priorities could lead to wrong users being targeted with wrong communications. This has a high negative impact when 1:1 hyper-personalization has to be served for known users such as existing leads, existing customers, inactive customers, loyalty program members, etc. It could end up serving the wrong product offers to the wrong customers, which could have a detrimental impact on the business especially in industries like BFSI, Telco, Retail, etc. Failure to review if the right Impression caps have been set could end up serving multiple banners to the users and spoiling their experience with the client's brand.

On-Use Case Performance

Failure in campaign governance inadvertently also impacts use case performance in the CDP. It may not always be apparent to Clients when they are setting up Segments on the CDP UI, but ineffective or wrong segment creation may drastically reduce the number of users who could have been part of the audience, thereby reducing the impact of that use case. Such impacts may become apparent only later when we try to dive deep into the reasons for the lack of campaign performance for a specific use case.

Client Guidelines for Campaign Governance

Maker Checker Process

• Campaigns should follow a Maker-Checker process where the Maker could either be the client-side business user or the Delivery POC from Lemnisk, but the Checker has to mandatorily be the Delivery POC from Lemnisk. In case the client is unable to reach their Delivery POC, an email should be sent to [e-mail] for review.

• The final activation of the use case will preferably be done by the Lemnisk Delivery POC - alternatively, the client can do so too, after an email approval from the Delivery POC. Delivery will verify, approve and activate. This should be followed for both UAT and PROD engagements.

Use Case Sign-off Conditions

• The above maker checker process can be maintained over an email thread. This thread should contain the details of the use case, details of the segments, engagements set up by the client (Segment IDs, Engagement IDs, trigger conditions), and the final go-ahead from the Delivery POC/ Business Analyst.

TATs for Review and Sign-off

• 1 working day for 5 or fewer Engagements. 2 working days for 6 to 15 Engagements. For anything more, the timelines will be shared on an email thread. In case the Delivery POC needs to publish new CDP data points to the UI for segmentation or debug an already set-up Segment or Engagement, a further timeline may be discussed with the client and shared via email.