Customerlabs CDP Documentation
Vivenu is a powerful and flexible ticketing platform that empowers event organizers to take full control of their ticketing operations, with built-in CRM and marketing automation capabilities.
Marketing teams connect Vivenu with CustomerLabs 1PD Ops to send their customer, ticketing, and transaction data to create unified customer profiles in CustomerLabs 1PD Ops
Getting Started
Codelessly connect your Vivenu CRM account with CustomerLabs 1PD Ops by following the steps below.
The Step-by-Step Guide to Configuring Events in Vivenu CRM
Step 1: Sign In to CustomerLabs
- Log in to CustomerLabs
- Copy the tracking code from the homepage.
2. Navigate to Sources
- Navigate to the source section and choose the custom source
- Name the custom source name Vivenu CRM and copy the webhook URL.
3. Sign In to Vivenu CRM:
- Sign In to Vivenu CRM
- Navigate to the Webhook section and create a new Webhook
4. Webhook Configuration:
- Click on the Create a webhook and name it as purchase configuration
- And choose the event as a transaction.complete
- In this case, translation. completed denotes the purchase event, similarly you can turn on the toggle as per your requirements and click on save changes
5. Testing the webhook
- After configuring the webhook, make a test purchase to check if the events are being received via webhook.
- CustomerLabs→Source→ Vivenu CRM and configure the workflow
- To configure the workflow follow the steps.
What is a Workflow?
A Workflow helps you to turn the raw data you receive from the source into specific event data based on the workflow configuration which includes filtering and modifying the parameters. You can create multiple workflows inside a Source. A workflow is a one-time setup that constantly receives customer data & updates user profiles in CustomerLabs in real-time.
Once a Source platform is authenticated, users can build workflows without writing a single line of code.
How to build a Workflow?
The four-step process to build a workflow are as follows,
Step 6: Setup the workflow
Name your workflow
This helps you quickly select relevant workflows – just for internal purposes.
Example: If you want to receive the data of users whose stage is changed to “Lead” in your CRM through this workflow, you can name this workflow as “lead_updated” or “lead_created”.
Workflow Delay
Workflow delay is recommended when you have multiple workflows in a source.
The data coming into the source will be sent across the workflows at the same time if the workflow delay is not given. This may result in concurrency issues.
For example, Whenever a user enters from the source, CustomerLabs checks if the user is already available in the database or assigns a unique user id to the user. Say, you have 4 workflows for the source and when the data is sent across all the workflows at the same time, 4 new user ids will be created for the same user if the user is not there in the database. Hence, setting up the delay time will make sure the new user is assigned a single unique id.
Step 7: Choose sample data
To receive event samples, trigger an event in that particular Source. For example, if you’re setting up a workflow to receive contact information as and when it gets updated in your CRM. Update a test contact in your CRM to receive event information in CustomerLabs.
You will be able to update up to 5 samples at once. Fetching sample data in a few source platforms might take time. In that case, please wait for some time before you try again.
You can view the incoming sample data and select the sample that suits your use case.
You can view the incoming sample data and select the sample that suits your use case.
Note: While selecting the sample, ensure the data contains no parameters with
null values as given in the image
The Customer Labs will not process parameters with null values. This is because null values are not considered valid data by the destination. If the sample data consists of any field with a null value, it will not be pushed to the destination.
We suggest passing all the required parameters with a value or an empty string.
For example, if the parameter is “first_name”, you could pass the value “John Doe” or the empty string
” “. Only if you pass all the required parameters with a value or an empty string, we can process the data and send them to the integrated destinations successfully.
Step 8: Event Configuration
Event configuration is the final and most important step of the workflow setup.
8.1. Event name
You can assign an event name by selecting from the drop-down as shown below. Choose the event as a custom event and name the purchase event as cl_purchase or as specified in the requirements and you can bring in any stages or lead data information
| Event type | Description |
| Custom event | Lets you give a new custom name to your incoming event |
| Dynamic event | Lets you choose the name of the incoming event as sent by the Source |
| Create or update group | Can be chosen if the incoming event is an account level update |
| Create or update user | Can be chosen if the incoming event is an user level update |
| Assign group to user | Lets you add company level updates to user |
8.2 User identity mapping
User identity mapping in CustomerLabs helps in merging incoming user/contact data to existing information.
You can choose upto 3 different identifiers including external IDs to map user information. These external IDs will be stored by CustomerLabs to create an enriched user profile.
If you add Facebook as a Destination, CustomerLabs will sync the facebook_fbp to Facebook so that you can easily target the right users thus considerably increasing the audience match rates. Some of the common user identifiers supported by CustomerLabs are shown below.
| ID type | Description |
| identify_by_email | User email address |
| identify_by_phone | User phone number |
| google_analytics_client _id | Unique identifier for a browser–device pair that helps Google Analytics link user actions on a site |
| facebook_fbp | User identifier saved automatically by the Facebook pixel that uses first-party cookies |
| facebook_fbc | User identifier saved automatically by the Facebook pixel that uses first-party cookies when a user clicks on ad |
Product details:
Product attributes can be added for events related to E-commerce/other business categories such as Product viewed, Product clicked, Purchases, etc. Details such as product sku, product ID, product variant, and product size can be added under product details and choose line_items from the dropdown.
Event Properties:
Additional information pertaining to the event can be added under event properties. The Mandate fields are: value, currency, transaction id and order id. The transaction ID can be mapped to transaction number or order id.
6. After completing the configuration as required, click on Save Workflow.
To send the user traits to the destination, you must map the user details under this section. This mapping process will allow you to send this valuable user information to the intended destination.
For example, if you’ve set up a workflow to receive all contact updates from your CRM to CustomerLabs. Information such as Contact first & last name, phone, email, address, company, lifecycle stage, job title etc. can be added under user traits. One such scenario would be when you want to run an email campaign with Klaviyo, you should add email ID as a user trait in this section to pass this information to Klaviyo or any such destinations in this case.
Source Logs
Source Logs show a list of events received by the source webhook before being sent to the workflows for event processing. There may be a delay in displaying the events items of up to 10 minutes, which is currently optimized.
You can see the logs by clicking on “Logs” from a particular source as shown below.
Every single message received by CustomerLabs will have a unique message id and we’ll be logging them so you can see how it is being processed in various workflows before appearing in the event manager.
Source ‘Data in’ log
The below image shows the log data of the message received from that particular source and data variables in JSON format.
Source ‘Data out’ log
The below image shows 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.
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 is in draft mode, the message as “Mapping not found” is thrown.
b) Filter condition failed – When a workflow filter condition is failed, this message is 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 the 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 of requests the systems will take up to 10 minutes to process the data.
