Data Model
How events, users, groups and ad data relate in Vendo, which keys join them and when Vendo makes each join.
Last reviewed September 15, 2026
Vendo maps every table that enters your workspace to one of four data types: events, users, groups and ad data. A table that you have not mapped yet is a custom table.
This page tells you how the four types relate. Each type has its own page with its fields:
| Data type | What one row is | Example |
|---|---|---|
| Events | An action at a point in time | A page view, a purchase, an email open |
| Users | A person and the traits of that person | A Shopify customer, a HubSpot contact |
| Groups | A thing that is not a person, with its own ID | A company, a product, a deal |
| Ad Data | Platform-reported ad performance for one day | Spend and clicks of one campaign on May 20 |
Identity resolution, calculated properties, metrics, audiences, attribution and destinations all use these four types.
How the Data Types Relate
- A person has one profile. Vendo merges the user records of one person from all your sources into one profile. The key of the profile is
vuid. - A person does many events. Each event identifies its actor with an identifier, for example a user ID, an email address or a device ID. Vendo finds the profile that has that identifier.
- An event can be about groups. For example, a purchase event is about a product, and a product is a group. One event can join groups of more than one type at the same time.
- A person can belong to many groups. For example, a HubSpot contact can be linked to more than one company.
- Ad data does not identify people. Ad platforms report totals for each day, campaign and ad. Vendo relates ad data to events through the date and the UTM values, and attribution relates ad clicks to conversions through click IDs.
Join Keys
| From | To | Key | How many | When Vendo joins |
|---|---|---|---|---|
| User records | Profile | Shared identifiers, for example email, phone, device ID or customer ID | Many records to one profile | Each identity run |
| Events | Profile | The identifier on the event, through the identity graph | Many events to one profile | When a query runs |
| Events | Groups | An event property, or the key of the group type (for example product_id, sku_id, company_id) | Many events to one group of each type | When a query runs |
| Users | Groups | A membership field on the user, for example company_ids | Many users to many groups | When a query runs |
| Ad data | Events | The reporting date and the UTM values | Many to many, by day and campaign | When a report runs |
| Sessions | Conversions | Click IDs (gclid, fbclid and others) and utm_source | Many touchpoints to one conversion | Each attribution run (daily) |
| Audiences, calculated user properties | Profile | vuid | Many to one | When the audience or property runs |
Events Join People When a Query Runs
Vendo does not write the profile key into your event rows. When a query runs, Vendo joins each event to the identity graph with the identifier on the event, and then to the profile.
Because of this, earlier events of an anonymous visitor join the correct profile after the visitor identifies. For example, page views with only a cookie ID join the profile after the visitor signs up with an email address on the same device.
Two identifiers link only when they are on the same record. Vendo does not use names to link records.
Groups Work Like Lookup Tables
A group table adds properties to other rows through a key. For example, a purchase event has a sku_id property. The vendo_product group has a row for each SKU, with its price and category. When you break down purchases by product category, Vendo joins each purchase to its product row.
Lookup tables are groups in Vendo. Map a reference table as a group, and select its group type.
Example: One Customer Across Sources
A customer clicks a Meta ad, looks at your store, signs up, buys a product and becomes a HubSpot contact.
| Step | Record in Vendo | Data type | How it relates |
|---|---|---|---|
| 1 | Meta Ads reports spend and 120 clicks for the campaign on May 20 | Ad data | Relates to the sessions of May 20 with the same UTM values |
| 2 | A page view with a cookie ID, utm_source=facebook and an fbclid | Event | Attribution uses the fbclid to give credit to Meta Ads |
| 3 | A sign-up event with the cookie ID and the email address | Event | Links the cookie ID and the email address in the identity graph |
| 4 | A Shopify customer record with the email address | User | Merges into the same profile |
| 5 | A Shopify order with the customer ID and sku_id=SKU-001 | Event | Joins the profile, and joins the vendo_product group row for SKU-001 |
| 6 | A HubSpot contact with the email address and two companies | User | Merges into the same profile, and links the profile to two vendo_company groups |
After identity runs, one profile holds steps 2 to 6. The page view from step 2 joins that profile, although it had no email address.
Where the Data Is in BigQuery
Each workspace writes to its own BigQuery dataset. Raw source tables keep the platform, the source and the stream in the table name.
| Table | What it contains |
|---|---|
identity_graph | One row for each identifier, with the vuid of its profile |
identity_profiles | One row for each profile, with its primary email, phone and identifiers |
customer_properties | Customer properties from each connection |
customer_360 | Profiles joined to their customer properties |
dim_customer | The history of each customer. A new row starts when a customer changes |
attribution_summary | Attribution credit for each conversion and touchpoint |
conversion_events | Conversions that destinations can send to ad platforms |
Some tables that identity runs create have a suffix after the name. Use the Data Catalog to find the exact table names in your workspace.
How the Layers Fit Together
Layer 1: Data types
event · user · group · ad_data (custom tables are not mapped yet)
Layer 2: Computed concepts
Profiles · Calculated properties · Metrics · Audiences · Attribution · Data Studio models
Layer 3: Destination outputs
Audience syncs · Conversions (in the format of each ad platform or tool)Layer 1 is mapped source data. Layer 2 makes new fields and objects from Layer 1. Layer 3 puts Layer 2 results into the format that each destination expects, for example a Meta conversion or a Klaviyo list.
Audiences and conversions are not Layer 1 data types. They exist only on the destination side.
Legacy Names You May Still See
Vendo changed an older model of eight types into the four data types. You can see the older names in some sources, destinations and pages:
| Legacy term | Current data type |
|---|---|
events | Event |
user_properties, contacts | User |
group_properties, lookup_table | Group |
ad_data | Ad data (no change) |
email_messages, revenue | Event (details in properties, or Layer 2 metrics) |
custom | Custom table (not mapped yet) |
audiences, conversions | Layer 3 destination outputs, not source data types |
Related
- Events, Users, Groups, Ad Data and Custom Tables
- Identity Merge: how Vendo links the records of one person
- Customer 360: the merged profile of each person
- Attribution: how conversions get credit
- Metrics: definitions that use these data types
- Orchestration: the order in which sources, identity, models and destinations run