Business Tier Pricing

Overview

Hightouch Business Tier pricing is custom depending on your use case. One component of your Business Tier could be the number of unique records we help you sync. This pricing structure lets you use Hightouch freely by syncing as many fields as you like without worrying about overages. The price per row decreases as you sync more volume through the platform.

The metric for this consumption based pricing is monthly queried rows (MQRs).

Monthly queried rows (MQRs)

Monthly queries rows (MQRs) is the total number of rows you expose to Hightouch before deciding which to activate. MQRs correlate with the amount of data you sync through Hightouch in a given month across your workspaces.

Like other data infrastructure tools, Hightouch uses 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.

Here are a couple of examples to help illustrate how to estimate MQRs:

• A B2C e-commerce company uses Hightouch to sync user data to an email tool and several advertising platforms. Their data models only represent Users, so their MQRs are the total number of customers in their database in a given month.
• B2B SaaS company uses Hightouch to sync User and Account records to a CRM, and Invoice records to an ERP. Their MQRs are the sum of unique Users, Accounts, and Invoices they query and push downstream.

What is an MQR?

MQRs are the number of unique primary keys returned when we query your source according to your model definitions. A primary key is a unique identifier that specifies a distinct row in a Hightouch model.

You define the query and primary key we use when you create your models. For an accurate MQR count, you must choose consistent primary keys across models if they represent the same underlying source data. See the deduplication examples for more information.

How are MQRs calculated?

The same row can only count to your MQRs once per month, irrespective of whether it's synced multiple times or not at all. (This can happen because the row didn't change over a month).

That means MQRs correlate with the amount of data in your source systems, and you don't have to predict how many rows 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 since MQRs don't consider the number of fields a record has or how frequently you update them.

For example, consider two data models querying the same source with different criteria:

If each model returns two million rows, but one million of those rows overlap, the total MQR count is three million:

• two million from model A
• plus two million from model B
• minus one million due to deduplication

To better understand deduplication, check out the following examples.

Consistent primary keys

Suppose one user appears in the query results for three different models on the same source. Even if you sync the user to three destinations, it counts as one MQR.

Inconsistent primary keys

Suppose the same user appears in the query results for two different models on the same source. One model defines the primary key as the user's email and the other defines it as user_id. In that case, despite syncing the same record, it counts as two MQRs.

Detecting primary key overlaps across different entities

Sometimes different underlying entities could have the same primary key values; however, we shouldn't deduplicate them because they represent different rows. For example, both user and account IDs could be auto-generated: 1, 2, 3, 4. In this example, while the primary keys are the same, the underlying rows are different and shouldn't be deduplicated in the MQR count.

To avoid primary key overlaps in this situation, we keep a dictionary of 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 its model represents Users and deduplicate it with other models that sync to other User endpoints.

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

For example, the following two rows have the same primary key yet count as two MQRs since they represent different rows.

Pricing FAQ

Why is consumption pricing based on queried rows versus actively synced records?

Hightouch uses total queried rows versus records synced downstream because it can be difficult for customers to forecast how often records will change state within a given month or how often they'll be making tweaks to existing syncs.

If we were to count actively synced records vs. queried rows, it would mean that:

• Adding a new field to an existing sync would trigger a backfill on all records and increase consumption-based spend
• Changing a definition on an existing field would trigger a backfill on all records and increase consumption-based spend
• Adding a new destination would trigger a backfill on all records and increase consumption-based spend

We find that the total query volume is a good approximation of sync volume over time. That empowers you to use Hightouch freely without surprise overages or constantly weighing the value of certain fields or use cases.

Do you restrict the frequency of syncs or the number of destination fields?

No.

Does forwarding event data count toward my MQRs?

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

What is the definition of a destination?

Check out the self-serve pricing docs to learn more about how Hightouch defines and counts destinations.