Search documentation...

K

Business Tier Pricing

This page is for Business Tier pricing only. Please visit our main pricing page to see what's included in our Business Tier packages and whether it's a fit for your company. To receive a quote, please contact Hightouch sales. For our self-serve plans (Free, Starter, Pro), please refer to our pricing and terms.

Overview

Hightouch Business Tier pricing is based on the number of unique records we help you sync. This structure lets you use Hightouch freely by syncing as many fields as you please without worrying about overages. The price per record decreases as you sync more volume through the platform.

Business Tier plans typically have two components:

  1. Platform fee: a base fee that provides access to Business Tier features and destination integrations
  2. Consumption-based pricing: our primary consumption model, based on Monthly Queried Records (MQRs), the number of unique records you sync through Hightouch

Monthly queried records (MQRs)

MQRs correlate with the amount of data you sync through Hightouch. Each month, we calculate the number of monthly queried records (MQRs) across your workspaces. MQRs are the number of unique primary keys returned to us when we query your data. A primary key is a unique identifier that specifies a distinct row in a Hightouch model.

Similar to other tools in data infrastructure, Hightouch employs a logarithmic pricing scale. As your monthly usage increases, the cost per MQR decreases. The more records you sync in a billing period, the cheaper the incremental cost per record.

A couple of examples to help illustrate how to estimate MQRs:

  • B2C eCommerce company is using Hightouch to sync user data to an email tool and several advertising platforms. Their data models only represent Users, so their MQRs are simply the total number of customers in their database.
  • B2B SaaS company is using Hightouch to sync User and Account records to a CRM, and Invoice records to an ERP. Their MQRs would be the aggregate sum of unique Users, Accounts, and Invoices they are querying to then push downstream.

What is an MQR?

MQRs are the number of unique primary keys returned to us when we query your data. A primary key is a unique identifier that specifies a distinct row in a Hightouch model. We only query the data that's described in your models.

Primary keys are deduplicated across all your models. This means that a primary key being synced to multiple destinations will only count once.

For a simple example, consider 2 data models in Hightouch:

The total MQR count here is 3 million. 2 million (from model 1) + 2 million (from model 2) - 1 million (due to deduplicating).

Further, we only count a record once per month, irrespective of whether it syncs multiple times or no times (because the record hasn't changed). This correlates with the amount of data in your source systems. It means you don't have to predict how many records will change each month. If you add a new field and need to update an entire table, you don't have to worry about a spike in overages.

Pricing FAQ

Why are MQRs based on records queried vs. records actively synced?

The reason we use total records queried (vs. those that are actually sent downstream) is that it's often hard for customers to forecast how often records will be changing state within a given month, or how often they'll be making tweaks to existing syncs.

We find that the total query volume is a good approximation of sync volume over time, and this empowers you to use the product freely without getting surprised with overages or constantly weighing the value of certain fields or use cases. For example:

  • Adding a new field to an existing sync would trigger a backfill on all records
  • Changing a definition on an existing field would trigger a backfill on all records
  • Adding a new destination would trigger a backfill on all records

Most of our customers have tables where only a subset of records are changing. As a result, our pricing model already incorporates this behavior, while still making it so you don't have to worry about one-time backfills or changes.

How do you deduplicate MQRs?

Each month we count the number of unique primary keys returned to us across all your models. Primary keys that show up multiple times only count towards one MQR.

Primary keys are defined by the user when a model is set up. it's incumbent on the user to choose consistent primary keys across models that represent the same underlying source data.

Example 1: standard set-up

The following counts as 1 MQR:

UserModelPrimary KeyDestination
Jane DoeRecent sign-upsjane@acme.comBraze Users
Jane DoeHigh-intent usersjane@acme.comSalesforce Leads
Jane DoeAll usersjane@acme.comAmplitude

Example 2: inconsistent primary keys

The following counts as 2 MQRs:

UserModelPrimary KeyDestination
Jane DoeRecent sign-upsjane@acme.comBraze Users
Jane DoeHigh-intent users123456Salesforce Leads

Example 3: detecting primary key overlaps across different entities

Sometimes different underlying entities could have the same primary keys, however we don't want to deduplicate these because they represent totally different records. For example, customer IDs could be auto-generated: 1, 2, 3, 4, meanwhile Account IDs could also be auto-generated: 1, 2, 3, 4. In this example, while the primary keys are the same, the underlying records are different and they should not be deduplicated in our MQR count.

To avoid overlaps of primary keys in this situation, we keep a dictionary of our destination endpoints and classify categories of the underlying record types (Users, Companies, Invoices, etc.). For example, when a model is syncing to the User object in Iterable, we know it's a model that represents Users, and then duplicate it with other models that are also syncing to any other User endpoints.

Furthermore, some destinations like HubSpot and Salesforce, have completely custom objects. In this case, these records aren't deduplicated across models at all.

The following counts as 2 MQRs:

NameModelPrimary KeyDestination
Jane DoeHigh-intent users123Salesforce Leads
acme-slugAll projects123Salesforce Custom Object

Do you place restrictions on the frequency of syncs or number of destination fields?**

No.

Does forwarding event data count towards my MQRs?

No. Pushing behavioral events like Order Completed to an analytics tool or the Facebook Conversions API doesn't count towards your MQRs number

What is the definition of a destination?

A destination is a unique account of a downstream SaaS tool or platform (not counting sandbox or staging instances). An example might be Salesforce CRM, Facebook, or NetSuite. Many times there are several different endpoints and use cases for the same destination, which doesn't result in multiples.

For example, if you're sending a customer list to Facebook Custom Audiences and also forwarding events to the Facebook Conversions API for the same account, this would all just count as 1 destination.

    Need help?

    Our team is relentlessly focused on your success. We're ready to jump on a call to help unblock you.

    • Connection issues with your data warehouse?
    • Confusing API responses from destination systems?
    • Unsupported destination objects or modes?
    • Help with complex SQL queries?

    Feature Requests?

    If you see something that's missing from our app, let us know and we'll work with you to build it!

    We want to hear your suggestions for new sources, destinations, and other features that would help you activate your data.

On this page

OverviewMonthly queried records (MQRs)What is an MQR?Pricing FAQWhy are MQRs based on records queried vs. records actively synced?How do you deduplicate MQRs?Do you place restrictions on the frequency of syncs or number of destination fields?**Does forwarding event data count towards my MQRs?What is the definition of a destination?

Was this page helpful?