This page describes Business Tier pricing considerations. Please visit the pricing page for the complete list of features Business Tier packages include. Don't hesitate to to receive a quote or discuss whether the Business Tier is a good fit for you.
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).
"Rows" vs. "records": Though some may use these terms interchangeably, Hightouch uses the term "rows" to refer to a set of horizontal data values in a source or model and "records" to refer to them in a destination.
Hightouch Business Tier pricing is custom depending on your use case. to understand your pricing structure and whether MQRs play a role.
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.
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.
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.
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.
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.
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.
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.