Customerlabs CDP Documentation
Understanding and Managing Events
All the information received by CustomerLabs CDP converted into a form of an event. Let’s take an example, if you are looking to get updated information of a customer from CRM, whenever the salesperson updates the data CDP will consume that information and transformed into an event which you can name anything you’d like.
Naming Events
Since CustomerLabs CDP is an event-based system it is recommended to follow a standard procedure while naming the events. Few recommendations are,
- use small cases with _ replaced for space for example: lead updated should be named as lead_updated.
There are a few events which are reserved, and avoid using those names for general events, as these events triggers a few internal workflows for unification, segmentation and other allied operations.
- create or update user,
- create user,
- update user,
- create or update group,
- assign user to group,
- added_to_segment,
- removed_from_segment
- error_log
This post will discuss in detail about each event and the use cases which you should be using them. See this documentation to learn more…
Debugging Events
You can check the event log in real-time when the servers are handling huge load the events processing may be delayed a bit.
Sources logs
Shows a list of events received by the the source hook before sent to the workflows for event processing, there may be a delay in displaying the events items upto 10 mins, which we will be optimising as we grow.
Every single message received by CustomerLabs CDP will have a unique messageid and we’ll be logging them and you can see how it is being processed in various workflows before appearing in the event manager.
Source Data in log
The below image show the log data of the message received by that particular source and data variables in JSON format.
Source Data out log
The below image show the log data of the message processed and sent to respective workflows along with a new message id.
Workflow Logs
Individual workflows will also have their own logs, and you can use them to see how the event is transformed including user traits, event attributes, group(account) traits, external ids, group(account) identities, and other attributes.
Events manager
Finally, you’ll be able to see the events in the events manager with all the enriched data. The workflow data out and event manager data will be the same.
Few tips on workflow status messages in data out
You’ll see the following messages in the workflows and the reasons are listed below.
a) Mapping not found – When a workflow in draft mode, we’ll throw this message as mapping not found.
b) Filter condition failed – When a workflow filter condition is failed, this is the message will be thrown.
c) User ID missing or Account ID is missing – We assume every event should have User identity or account identity fields, when the data is missing we’ll throw an error and event won’t be processed further.
d) Data not found – This message means the data is still being processed, sometimes when there are a lot requests the systems will take upto 10 mins to process the data.
