ht
Documentation
WelcomeConcepts

Get Started

OverviewCreate a sourceCreate a modelCreate a destinationCreate a sync

Working with data

How pricing worksWorking with syncsUsing the Live Debugger
Documentation/Working with data/How pricing works
ht
Documentation

How pricing works

Table of Contents
Overview

Overview

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:
CustomerIDCustomerNameLocationTotalOrders
1ClaireAustralia50
2PedramCanada150
They have the following syncs set:
Sync IDDestinationSchedule
1HubSpotEvery Five Minutes
2SlackEvery Minute
3IntercomEvery 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 IDRun IDDateUnique IDs
1100Jan 1 2021100
1101Jan 2 20212
1102Jan 3 20212
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.