Data Types in Lemnisk

Lemnisk captures all the User Behaviour and User Attributes information via various parameters, be it in App/Web Events, REST API or Offline Files. Listed below are the data types that Lemnisk supports while ingesting data.

Lemnisk will govern the data sanity when it receives real-time events from your App, Wesbite or REST API. Any deviations to the defined data type (defined in Events Dictionary or Customer Properties) of the incoming event, will result in failing of the event, which will be captured and reported in Event telemetry.

Data Type	Operators ( These are the operators available shown while creating Customer properties)	Description
STRING	Equals, Not equals, Contains, Does not contain, Starts with, Ends with, Is Present Is Present → True/False True: The data point exists and is not empty/null/undefined False: The data doesn't exist or it's empty/null/undefined	A sequence of characters, such as letters, numbers, symbols, and spaces typically used to represent text-based information.
NUMBER	Equals, Not equals, Contains, Does not contain, Starts with, Ends with, Greater than, Less than, Is Present Is Present → True/False	This represents numerical values, which can be either integers (whole numbers) or floating-point numbers (numbers with decimal points).
EMAIL	Is Present (checks for value) Is Present → True/False True: The data point exists and is not empty/null/undefined False: The data doesn't exist or it's empty/null/undefined	An Email data type represents an electronic mail address. It is a specialised form of a string that adheres to a specific format. If Email is defined as the data type, the CDP will hash and store the respective values as a security measure to store PII data. As the data is hashed and stored as STRING, it can be accessible for targeting.
PHONE	Is Present (checks for value) Is Present → True/False True: The data point exists and is not empty/null/undefined False: The data doesn't exist or it's empty/null/undefined	This data type is specifically designed to store telephone numbers which often accommodates various international formats and may include country codes or extensions. If Phone or Email are chosen, the CDP will hash and store the respective values, making it accessible for targeting.
ENTITY	Properties within the Entity are further defined as one of the above 4 data types, and segmentation rules apply to the Entity properties, not the parent Entity as a whole.	Entity data type is used to store multiple products/purchases information against a single user, where numerous details of every purchase is to be stored, and communicated for. For example Policies, Leads, Flight Bookings etc.

Key Considerations when defining Data Types

When defining data types for customer properties and event properties within the Lemnisk CDP, it's crucial to understand the implications of your choices.

1. Validation and Consistency

• Source Validation: Properties defined in the identify event and otherIds section of a track event are rigorously validated against the Customer Properties section. This means any incoming data must conform to the predefined data type.

• Offline File Validation: All properties imported via offline files are also subject to the same data type validation and will be displayed in Customer Properties.

• Strict Type Checking: If an incoming customer property has an invalid data type (e.g., a number sent for a String field), it will be reported as a failure in the Event Telemetry section. This ensures data integrity and governance of the model defined in the CDP.

2. Impact on Segmentation and Macro Personalisation

• Segmentation: Data types directly influence how properties can be used for segmentation. For instance, Number types support numerical operators (e.g., greater than, less than), while String types allow for text-based comparisons.

• Data Type Changes: Modifying the data type of an existing Customer Property or Event property is not allowed. This is because the earlier history of data ingested cannot be modified, and hence, future segmentation would be infeasible. If you wish to change the data type of an existing property, simply create a new property and start using the same.

3. Special Data Types for User Identifiers and PII

• Phone and Email Hashing: When you select Phone or Email as a data type for a customer property, the CDP will hash and store these values. This process makes the data targetable while potentially enhancing privacy by not storing the raw values in an unhashed format which is directly accessible.

• Editing Restrictions: For User Identifiers and PII customer properties, users can only edit the Display Name. This restriction helps maintain the integrity of crucial identification fields.

4. Creating Customer Properties

When creating new customer properties, these fields are essential:

• Name (Mandatory): This is the unique, actual name used for validation and internal referencing across identify events and offline files.

• Display Name (Optional): This user-friendly name appears in macros and segmentation. If left empty, the Name will be used.

• Data Type (Mandatory): Currently, for newly created customer properties, the supported data types are String, Number, or Date.