Entity Properties
Say you're the Campaign Manager for an Insurance House. Effectively managing customer data for individuals with multiple policies can be challenging. Traditional systems, often rely on a single user identifier which is disadvantageous setup to capture various information especially when a customer holds several policies with different, or similar contact details (mobile numbers, email addresses). However each policy requires a standard set of information to be captured, distinctly under the 'Policy' categorisation.
Lemnisk addresses this by enabling marketers to define 'Entities' within their Customer Properties. This feature allows for the comprehensive capture of multiple products or interests within a single user profile. For instance, by defining a 'Policy' entity, marketers can store, segment, and communicate with a user for each individual policy that meets specific segmentation criteria.
Use Case
Lets Assume, a user of your Insurance House purchase more than one insurance policy from your organisation and you have to communicate to the user whose policies are lapsing within 30 days, to nudge them to renew as soon as possible.
By creating each policy purchased as an entity with the details like price, expiry date etc, you can capture, segment and visualise data of your users categorised by every policy they've purchased.
For this use case, we'll create a Entity Customer Property called 'Policy', with the following sub-properties:
policy_id: Unique identifier for the specific policy.
policy_type: (e.g., "Car Insurance", "Life Insurance", "Health Insurance").
premium_amount: The cost of the policy.
start_date: When the policy coverage began.
expiry_date: The exact date the policy coverage ends.
insured_asset: (e.g., Insured person's name for life insurance).
status: (e.g., "Active", "Lapsed", "Renewed").
Every property under Policy entity could be used for segmentation as well as content personalisation.
Once Lemnisk starts collecting policy information in the events, you can proceed to create segments with rules like expiry_date IS LESS THAN 30 Days from NOW AND policy_type EQUALS Car Insurance and use policy_id as Macro Personalisation in the Email or Whatsapp communications you would set up on this segment.
Advantages
Hyper-Personalized Communication: Instead of generic messages, marketers can tailor communications specifically for each policy a user holds. This means a customer with a car policy and a life insurance policy can receive distinct, relevant messages for each, even if they share the same contact details.
Precise Segmentation and Targeting:
'Entities' allow for highly granular segmentation based on policy-level attributes (e.g., policy type, coverage amount, renewal date, claim history, specific riders). This enables marketers to communicate with the same user, for every policy that user holds and qualifies the segmentation criteria.
Enhanced Cross-Sell and Up-Sell Opportunities: By understanding each policy a customer owns, marketers can identify natural opportunities for cross-selling complementary products or up-selling higher coverage, based on the speicifc Entity (Policy) which qualifies for tha user.
Streamlined Data Management and Accessibility: 'Entities' provide a structured way to store the user's entity-wise information — like Policies purchased, Account held with a Bank, Mutual Funds holdings; within a unified customer profile, making it easier for marketers to access and utilise the customers interests and purchase information.
Steps to create Entity customer property
Below are the steps to define and Entity Customer Property (say Policy) in the Lemnisk.
Navigate to > Data pipeline > Customer Properties
Name of the property: Enter the name for your customer property. This name will be used in payload.
Display name of the property: Enter the display name for your property. This name is to identify your property.
Data type: Declare the data type as Entity.
Add property: Click Add property and add a property to the the entity. You can add upto one additional-level of entity within an entity. This is used to store a sub-product within a product, for example - a Rider within a Policy.
Unique Identifier - One property within an entity has to be defined as the unique identifier for that Entity, using which, segmentation and stitching if incoming events and properties will take place.
Last updated