Monthly queried rows (MQRs)

Overview

One component of your Business tier plan could be the number of unique rows being queried within your workspace. This pricing structure lets you use Hightouch freely by syncing as many fields as you like without worrying about overages.

The name of the metric Hightouch uses for consumption-based pricing is monthly queried rows (MQRs).

What are monthly queried rows?

Monthly queried rows (MQRs) are the total number of rows you expose to Hightouch before deciding which to activate. The same row only counts once per month towards your MQRs, irrespective of whether it's synced multiple times or not at all. (This can happen because the row didn't change over a month).

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 expose to Hightouch 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, regardless of how many tools they push customer information to.
• 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.

View MQRs

You can view your MQRs in the Billing tab on the Settings page.

The table shows:

• each of your workspace's MQRs in a separate column
• total MQR across all workspaces in the organization in the total MQR column farthest right
• percent change of the total MQR from the previous month

Inspecting your MQRs can help you compare MQR usage between workspaces and gain a holistic view of your total usage. This view also enables you to monitor your usage versus your contractual entitlement.

In a broader sense, this view can also help you gauge the value of your data. If the number of synced or activated records grows faster than your MQRs, it means your single source of truth is being used more widely across your organization.

For example, suppose a B2C e-commerce company syncs user data to various organization tools. As their customer base grows, their MQRs grow in a one-to-one relationship. If they continue adding destinations they sync user data to, starting with their CRM and email marketing tools but growing to various ad platforms and support tools, it won't affect their MQRs. But it will affect how widely their data is being used to help the business and provide value.

How are MQRs calculated?

Hightouch counts MQRs as the number of unique primary keys your models return. 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.

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

See the deduplication examples for more information.

MQR calculation in Customer Studio

For audiences you build in Customer Studio, the only models that matter for MQRs are your parent models. Parent models define the primary dataset from which you want to build your audiences.

The number of audiences, audience sizes, the number of destinations to which you sync audiences, and the frequency at which you sync audiences have no impact on MQRs. If you define multiple parent models that overlap, Hightouch deduplicates them as it does with any other models. Hightouch also deduplicates parent models with other non-audience models you may have built.

MQR deduplication

MQRs track the total number of rows you expose to Hightouch via your model definitions. If your model definitions overlap—that is, different models return some of the same rows—Hightouch ensures you only pay once for the same row. The process of identifying and eliminating duplicate rows across all your models is known as deduplication. To better understand deduplication, refer to the 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.

The MQR system collects primary key values from Hightouch models, deduplicates those primary keys across models, and arrives at a final count of unique primary keys per-model group. In this example, the model group includes all three models because they use the same underlying source data and primary key values, even if the primary key column name differs.

For a given model, Hightouch tracks the primary key column name and, during the collection phase, extracts and saves the values from that column. When the deduplication across models occurs, it doesn't matter if one model's primary key column is sign_up_email and another's primary key is user_email. All that matters is the compared values. The values (jane@acme.com) are the same in this case, so they only count 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, 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 it 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.

Deduplication between audience syncs and other syncs

When building audiences in Customer Studio, you need to define a parent model you can use to build multiple audiences you can sync to multiple destinations. For example, you may have a Users parent model that you built audiences off of—for example, cart abandoners, high LTV customers, etc. You can then sync those audiences to various advertising destinations. Outside Customer Studio, you may also have a Users model you use for syncs to other tools like Braze or Salesforce.

Assuming you've used consistent primary keys between your Users parent model and models you're using to sync to non-advertising destinations, Hightouch deduplicates the same users found between your audiences' parent model and non-audience models. The example row below counts as one MQR:

If you sync data both via Customer Studio and outside of it, you can estimate your MQRs as the number of rows in your parent model plus rows from other models that can't be deduplicated with your parent model.

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 tweaking 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.

Does forwarding event data count toward my MQRs?

Pushing behavioral events like Page viewed to an analytics tool doesn't count towards your MQRs total. Conversion events you send to Conversions APIs (CAPIs) such as Facebook CAPI do count towards MQRs.

How can I see which models impact my MQRs most?

The MQR table in the Billing tab shows total MQRs for a workspace and across all workspaces. If you want to see how different models contribute to your MQRs within a workspace you can do so from the Models overview page.

Click the sorting option in the top right and select Largest. The overview page then lists your models from largest to smallest. You can use this view to approximately understand which models contribute more to to your MQRs.

This view helps you to "approximately" understand model impact since MQRs are deduplicated across models. This means that even if you delete your largest model, if most of its rows are shared with other models, it won't significantly reduce your MQRs.

How are MQRs calculated with audiences?

When building audiences in Customer Studio, Hightouch uses the parent models you define to calculate MQRs. If you're also syncing data outside of Customer Studio, you can estimate your MQRs as the number of rows in your parent models plus any non-audience models. Hightouch deduplicates any MQRs counted from your parent models with non-audience models.

Do you count anonymous versus known MQRs differently?

When syncing user data, you may not have a complete picture of the user whose information you are syncing. For example, you may only have an anonymous ID, and not the user's email address or name. These types of records count the same towards MQRs as known user records since each still has its own unique primary key.

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

All pricing plans allow unlimited destination data fields and Business tier plans allow unlimited sync frequency. Check the pricing page for more information.

What is the definition of a destination?

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