From 0ab93965993e1467db5435f19ca541b9db05787a Mon Sep 17 00:00:00 2001 From: Samantha Crespo <100810716+samkcrespo@users.noreply.github.com> Date: Thu, 12 Sep 2024 14:45:08 -0700 Subject: [PATCH 1/3] Update mtus-and-throughput.md - mtus & reverse etl --- src/guides/usage-and-billing/mtus-and-throughput.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/guides/usage-and-billing/mtus-and-throughput.md b/src/guides/usage-and-billing/mtus-and-throughput.md index 9b1b3d5fd4..6c0084b17c 100644 --- a/src/guides/usage-and-billing/mtus-and-throughput.md +++ b/src/guides/usage-and-billing/mtus-and-throughput.md @@ -121,8 +121,12 @@ All Engage data are omitted from billing MTU and API throughput calculations, in Replays only affect your MTU count if you are using a [Repeater](/docs/connections/destinations/catalog/repeater/) destination, which might send data that hasn't yet been seen this month back through a source. -## MTUs and Reverse ETL -See the [Reverse ETL usage limits](/docs/connections/reverse-etl/#usage-limits) to see how MTUs affect your Reverse ETL usage limits. +## MTUs and Reverse ETL + +Data _extracted_ via Reverse ETL does not affect MTUs. However, when connected to the [Segment Connections Destination:](/docs/connections/destinations/catalog/actions-segment/), which is exclusively compatible with Reverse ETL, MTUs will be impacted. +- [Segment Connections Destination:](/docs/connections/destinations/catalog/actions-segment/) Events transmitted through the Segment Connections destination are treated as directed to a standard source, and will contribute to your MTU count. + +For further details on how Reverse ETL impacts your usage, see the [Reverse ETL usage limits](/docs/connections/reverse-etl/system/#usage-limits). ## Why is my MTU count different from what I see in my destinations and other tools? From 7811ff7cbc003b7cd9dbb3188c4b4d6d2b2af40a Mon Sep 17 00:00:00 2001 From: pwseg <86626706+pwseg@users.noreply.github.com> Date: Thu, 6 Feb 2025 10:30:29 -0600 Subject: [PATCH 2/3] minor rewording --- src/guides/usage-and-billing/mtus-and-throughput.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/guides/usage-and-billing/mtus-and-throughput.md b/src/guides/usage-and-billing/mtus-and-throughput.md index 6c0084b17c..f0e1f8eb77 100644 --- a/src/guides/usage-and-billing/mtus-and-throughput.md +++ b/src/guides/usage-and-billing/mtus-and-throughput.md @@ -121,12 +121,13 @@ All Engage data are omitted from billing MTU and API throughput calculations, in Replays only affect your MTU count if you are using a [Repeater](/docs/connections/destinations/catalog/repeater/) destination, which might send data that hasn't yet been seen this month back through a source. -## MTUs and Reverse ETL +## How Reverse ETL affects MTUs -Data _extracted_ via Reverse ETL does not affect MTUs. However, when connected to the [Segment Connections Destination:](/docs/connections/destinations/catalog/actions-segment/), which is exclusively compatible with Reverse ETL, MTUs will be impacted. -- [Segment Connections Destination:](/docs/connections/destinations/catalog/actions-segment/) Events transmitted through the Segment Connections destination are treated as directed to a standard source, and will contribute to your MTU count. +Extracting data with Reverse ETL does **not** count toward your MTU usage. However, if you send that data through the [Segment Connections destination](/docs/connections/destinations/catalog/actions-segment/), it **will** affect your MTUs. -For further details on how Reverse ETL impacts your usage, see the [Reverse ETL usage limits](/docs/connections/reverse-etl/system/#usage-limits). +The Segment Connections destination is built for Reverse ETL and treats events as if they’re coming from a standard source, meaning they contribute to your MTU count. + +For more information, see [Reverse ETL usage limits](/docs/connections/reverse-etl/system/#usage-limits). ## Why is my MTU count different from what I see in my destinations and other tools? From 99ffd3ce2de31403e3d13c6d4d05ae907001ab43 Mon Sep 17 00:00:00 2001 From: pwseg <86626706+pwseg@users.noreply.github.com> Date: Thu, 6 Feb 2025 10:31:10 -0600 Subject: [PATCH 3/3] remove some whitespace --- src/guides/usage-and-billing/mtus-and-throughput.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/guides/usage-and-billing/mtus-and-throughput.md b/src/guides/usage-and-billing/mtus-and-throughput.md index f0e1f8eb77..de50b9504d 100644 --- a/src/guides/usage-and-billing/mtus-and-throughput.md +++ b/src/guides/usage-and-billing/mtus-and-throughput.md @@ -29,18 +29,14 @@ For example, if your workspace's throughput limit is set to 250, this means that These objects and API calls are not tied to a specific user, but are an aggregate number applied to your workspace. Most customers never hit this limit, and Business tier plans often have custom limits. - - #### Batching and throughput limits You can sometimes "batch" API calls to reduce send times, however batching doesn't reduce your throughput usage. Batched calls are unpacked as they are received, and the objects and calls the batch contains are counted individually. While batching does not reduce your throughput, it does reduce the possibility of rate limit errors. - ## How does Segment calculate MTUs? Segment counts the number of **unique** `userId`s, and then adds the number of **unique** `anonymousId`s that were not associated with a `userId` during the billing period. Segment counts these IDs over all calls made from all sources in your workspace, over a billing month. Segment only counts each user once per month, even if they perform more than one action or are active across more than one source. - #### Example MTU counts Imagine that you have both a website and a mobile app. Both the website and mobile app have pages that you can use without being logged in, and both send Identify calls when a user _does_ log in.