How Pricing Works

An overview of how pricing works for destinations

Hightouch uses a concept called Monthly Active Records to determine your usage of the application. For each destination, every month, we calculate the number of unique records that were successfully sent to a destination. We dedupe all records by destination to ensure that you are not billed twice for syncing the same record, even if you are using multiple syncs. We also remove the first successful sync from the calculations. The total number of unique records by destination is aggregated to determine your Monthly Active Records.

Below is an example of how we calculate this for a hypothetical customer:

Pudgy Pies Example

Pudgy Pies Inc. has several destinations for their data: Slack, Hubspot, and Intercom. They send data about their customers to each of these destinations. For Slack, they send a message for every new order every minute. In Hubspot, they send customer information from their application every five minutes. Intercom also receives customer information every five minutes.

Their model might look something like this:

CustomerID

CustomerName

Location

TotalOrders

1

Claire

Australia

50

2

Pedram

Canada

150

They have the following syncs set:

Sync ID

Destination

Schedule

1

HubSpot

Every Five Minutes

2

Slack

Every Minute

3

Intercom

Every Five Minutes

For each destination, we remove the first successful sync run from our calculations. This lets you backfill data without being charged for your initial setup. For all subsequent runs in the given calendar month, we count the distinct primary IDs by destination. In this example, we are using CustomerID as the primary identifier. Imagine the following runs for the HubSpot Sync:

Sync ID

Run ID

Date

Unique IDs

1

100

Jan 1 2021

100

1

101

Jan 2 2021

2

1

102

Jan 3 2021

2

We would exclude RunID 100, then for each unique in the subsequent runs, we would look at all the customer IDs, remove duplicates, and then bill only for the unique set that remains. In our case, this will be 2 MARs, as the same two records were updated on Jan 2 and Jan 3.

Last updated

Was this helpful?