CaliberMind Entity Relations and System Tables

Data Model Overview

CaliberMind's data model is designed to be fluid, open, yet structured. Regardless of which CRM, Marketing Automation Tool, or priority data source, data are mapped and transformed to work with your B2B business. At its heart CaliberMind is a Customer Data Platform (CDP). That is:

  1. A data warehouse and data lake to store all types, shapes, and volumes of marketing data.
  2. A reporting & segmentation tool set.
  3. A workflow engine to bi-directionally sync data to and from the CDP.

One of the benefits of centralizing analytics and segmentation in CaliberMind is that we automate maintenance of creating a "marketing data lake". For example, an important question is: What was an account's engagement score last month vs this month? What is our pipeline month-over-month, etc.

This is only possible if you copy certain data as a snapshot each day-- which this model enables.

It also allows interoperability. Our customers can leverage our best practice reporting templates on top of our system tables and snapshots regardless of custom objects, Salesforce, Marketo, HubSpot, SAP... or even Google Sheets.

One system integrated to CaliberMind such as looks like this:

CaliberMind CDP - Entity Relationship Diagram (ERD)

CaliberMind Customer Data Platform entity relationship diagram

At a higher-level, many systems can integrate into this data backbone and it can be used to drive decisions and actions. For example you can import marketing campaign budgets from your CMO's spreadsheet and the Google AdWords API, and match ids in that spreadsheet to campaign ids in your CRM via `v_campaign`. This can be used in our Analytics Module to calculate ROI for each campaign.

CaliberMind Analytics Module lets you calculate campaign ROI

CaliberMind System Views & Tables

Each CaliberMind view is prefixed with v_. Admin user can modify system views in Settings >> System Views. Since system views are often complex, we copy the data from each view into CaliberMind system tables prefixed with `cm_`. This allows reporting to be much faster. There are cases when it makes sense to use 1 vs the other in queries, and lists.

When building operational lists that need the most current data, use the views (v_), when building reports or bulk process where time-sensitivity is less important, use the tables (cm_) since they'll load faster and be less intensive on your data base.

There are two categories of system views: parents and children. Parent system views end up as cm tables (see above). Children roll up date into parents.

Union of data sets in system parents

A UNION just mean adding data with the same columns vertically, to a data table. For example a parent v_event is a master view of events from other systems.

  • (data from system 1)


  • (data from system 2)


  • (data from system 3)

This concept can be applied to statistical models too, such as in v_attribution:

  • (data from model 1)


  • (data from model 2)


  • (data from model 3)

Data Dictionary

To see a master list of all default CaliberMind tables please refer to the Google Sheet, here.

Below is a list of all the most commonly referenced cm_ tables:

v_lead -- > cm_lead

A copy of your CRM leads table, however adds in Lead-to-Account matching.

v_opportunity -- > cm_opportunity

A copy of your CRM opportunity table, however adds in custom calculations for amount and probability.

v_person_company -- > cm_person_company

This is the primary profile table in CaliberMind. It's usually loosely based on CRM Accounts, Contacts, Leads, and Opportunities.

v_event -- > cm_event

A unionized view / table of all events from all systems and their respective unique ids. This is the foundational timeline used for other models like scoring and attribution.

v_scoring -- > cm_scoring

A unionized view/table of scoring model data, taking into account. Out of the box there are several scoring model templates in your instance of CaliberMind (Inbound90, Inbound180, etc.):

- persona of touch

- age of touch

- categories of touch (type, class, system, details, etc)

v_attribution -- > cm_attribution

Underlying table of revenue attribution, based on cm_event. All models are stored in the this table as union of child views. For example this table is:

v_engagement --> cm_engagement --> cm_engagement___snapshot

A point in time aggregation of engagement score by Account. This table is snapshotted so as to spot trends in the data.

v_engagement___trend -- > cm_engagement___trend

Calculates day-over-day, week-over-week, and month-over-month comparisons of engagement score by account.

v_funnel -- > cm_funnel --> cm_funnel___snapshot

Summarizes and snapshots each account or person_id in each stage of your funnel model created in the Funnel Builder.

How did we do?

Powered by HelpDocs (opens in a new tab)

Powered by HelpDocs (opens in a new tab)