Twilio Segment Pricing: What You Pay and How to Control MTUs

Last updated: 8 September 2026.

Start with the product you actually need

The public Connections pricing lists Free at $0 for 1,000 monthly tracked users and two sources. Team starts at $120 per month for 10,000 MTUs and unlimited sources. Both list one warehouse destination; Free syncs daily and Team twice daily. Business uses a custom quote. Protocols is an add-on, and identity resolution with unified profiles is listed under CDP plans. Those capabilities should not be assumed to come with the Team subscription. Twilio Connections pricing.

Define the buying decision before comparing bills. Sending product events to an analytics tool, building a customer identity graph and running lifecycle journeys are separate requirements. A proposal covering all three cannot be compared fairly with a Connections-only invoice.

For each requirement, record the destination, delivery deadline and owner. “Send a completed signup to analytics within five minutes” is testable. “Have a CDP” leaves room for a large purchase with no agreed outcome.

If your only requirement is an overnight warehouse report, start by assessing that pipeline. If marketing needs governed audiences across channels, include the profile, activation and operational work. Our composable CDP guide explains how these responsibilities fit together.

How Team overages work

Twilio's dedicated monthly Team billing article specifies a $120 base, then $12 per additional 1,000 MTUs between 10,001 and 25,000, $11 between 25,001 and 100,000, and $10 above 100,000. Apply each rate to its band. Monthly Team overage rules.

Using those bands, the monthly base plus MTU usage is:

• 10,000 MTUs: $120.
• 25,000 MTUs: $120 + $180 = $300.
• 50,000 MTUs: $120 + $180 + $275 = $575.
• 100,000 MTUs: $120 + $180 + $825 = $1,125.
• 150,000 MTUs: $120 + $180 + $825 + $500 = $1,625.

These USD calculations exclude taxes, other usage charges, add-ons and downstream services. They assume the documented monthly Team plan, with no negotiated discount. The examples use complete thousand-user increments; confirm partial-increment treatment before reproducing an invoice.

There is a documentation inconsistency: the Connections page's FAQ says a flat $10 per additional thousand, while its detailed table and the dedicated billing article specify the bands above. Use the detailed rules for planning and obtain confirmation for your account. At 50,000 MTUs, the flat shortcut would understate the estimate by $55.

An MTU is not a paying customer or a session

Segment counts distinct userId values plus distinct anonymousId values that were not associated with a user ID during the billing period. The calculation spans the workspace's sources. Repeated activity under the same resolved identity does not create another MTU. MTU calculation rules.

That distinction changes your forecast. Customer records in your billing platform measure a different population from the people and anonymous identities your collection setup sees.

Consider a fictional month with three people:

• Ana visits the website anonymously, then signs in there as user_101.
• Ben uses a website and an app. Both send his stable user_202 after login.
• Cam visits from two anonymous browsers and never signs in.

Under those assumptions, the workspace contains four tracked identities: one for Ana, one for Ben and two unresolved browser identities for Cam. There are three humans, four MTUs and potentially hundreds of events. This example assumes valid identity associations and no other IDs.

Avoid calculating a workspace bill by adding source-level distinct-user totals. Ana appearing in two sources does not necessarily mean two workspace users. Use source totals to investigate changes and the deduplicated workspace total to reconcile billing.

Equally, adding every anonymous visitor to every logged-in user can double-count people who became identified during the period. A forecast should separate resolved users from unresolved anonymous identities, with uncertainty around the latter.

Why anonymous acquisition can dominate the bill

A fictional DTC store with 150,000 unresolved anonymous IDs would reach the $1,625 example even if only 2,000 people bought something. That is about $0.81 of Connections spend per purchaser, before the rest of the stack. It is a planning ratio, not an attribution model or evidence that Segment caused the purchases.

The useful question is what the anonymous data supports. Does it power audience suppression, acquisition analysis or a tested onsite experience? Name the workflow and the owner who would notice if it disappeared.

For a publisher with a large content audience and a small paid product, collecting every content-page visitor may have a different value from collecting signup and activation activity. Decide that deliberately before installing the same collection setup across every page.

Separate the usage meters

MTUs are only one part of the operating picture. A reduction in one meter does not guarantee a lower total bill.

Event throughput

At a configured allowance of 250 API calls and objects per paid MTU, a 10,000-MTU allocation represents 2.5 million calls and objects. Throughput is pooled across the workspace. Batching transport requests does not reduce the underlying count. Throughput calculation.

Suppose 5,000 users each generate 700 events in a month. That is 3.5 million events despite modest user volume. Removing duplicated page events could solve a throughput problem while leaving the MTU count unchanged.

Check your account's allowance and overage terms before using the example as a limit. Include background polling, repeated Identify calls and test traffic in the investigation; a tidy list of business events does not prove the SDK sends only those events.

Cloud-source records

Segment distinguishes event sources from object sources. Object cloud sources feed warehouse records; event sources can also feed event destinations. Inspect the connector's actual collection type, rather than assuming that every CRM or payments integration behaves alike. Source comparison.

Object sources do not increase MTUs, but retrieved records affect throughput, including repeated retrievals. Object billing rules.

Replacing a time-sensitive event with a periodically updated object can change the meaning of the data. An order's latest status is not a history of when payment, refund and cancellation happened. Choose the data model needed by the decision, then price it.

Reverse ETL

The pricing page lists 500,000 Reverse ETL records for Free and one million for Team. Segment measures records successfully processed per destination, so sending the same 40,000 records to three destinations gives 120,000 records of usage. Warehouse computation is an additional cost. Reverse ETL system and usage.

Extraction itself does not add MTUs, but routing through the Segment Connections destination can. Reverse ETL and MTUs.

Ask which route each sync uses, which changes trigger another record and what happens beyond the included allocation. A system that permits continued processing is not promising unlimited included usage. Use a reverse ETL design with explicit audience ownership and update rules before choosing a sync frequency.

Cut avoidable cost without breaking the data

Treat each proposed change as an experiment with an expected billing effect and a data-quality acceptance check.

Open full diagram

Repair identity transitions first

Use a stable application user ID consistently across web, mobile and server collection. Verify that login associates the pre-login anonymous identity with the authenticated user. Test a return visit, logout, account switching and a second device separately.

Analytics.js reset() clears Segment identity and traits, including the anonymous ID. It does not clear every destination's independent state, and Segment documents additional care across subdomains. Analytics.js reset behaviour.

A reset on every route change can fragment one visit. A missing reset when a shared device changes users can mix two people's behaviour. Lowering the invoice by keeping the wrong identity is a data defect, not an improvement. Preserve legitimate logout and privacy behaviour; fix accidental churn in identifiers.

The identity merge guide covers the broader rules for deciding which records belong together. Billing optimisation must use those same rules.

Remove collection that has no consumer

For each event, write down the report, audience or operational action that uses it. If nobody can name one, investigate whether the event belongs in production collection.

Removing 90 of a user's 100 events can reduce throughput but will not remove that user if the remaining events still count. To forecast MTU savings, estimate the identities that would no longer send any counted activity, after considering every source.

Use a tracking plan to record the decision. For example, retire a mouse-movement event while retaining signup completion, payment success and the product action used to measure activation. Check dashboards and journeys before removing anything.

Do not share one fake user ID across visitors to reduce the count. That destroys person-level analysis and can contaminate audiences. Do not use identity workarounds to undo a user's choice to reject tracking.

Apply filters at the right point

A destination filter controls where data goes after collection. It should not be assumed to undo an MTU already counted upstream. Segment's filtering guide distinguishes destination routing from source-level event blocking. Filtering methods.

Business-tier source-schema blocking excludes blocked events from API and MTU calculations. Source Schema. Protocols also supports tracking-plan blocking, with additional considerations when violations are forwarded. Confirm entitlement and the exact mode before forecasting savings using the filtering documentation.

On a simpler plan, removing unnecessary event production in your own application may be the appropriate control. Verify browser and server paths; disabling a frontend tag while leaving a backend producer running might barely change usage.

Scope anonymous coverage to its job

If you remove Segment collection from an anonymous-heavy section, specify what measurement remains and what you are giving up. Possible losses include pre-signup paths, campaign-to-user association and audience membership.

A useful decision record could say: “Retain aggregate content reporting elsewhere; collect consented signup and product activity through Segment; accept that some article-to-activation journeys will be unavailable.” That is an architecture choice with a named limitation.

Do not quietly remove the top of the funnel and then celebrate a higher conversion rate. The denominator changed. Annotate the reporting break and compare matching populations.

Build a forecast you can reconcile

Record the actual billing-period dates first. Segment's Team cycle follows the end of the trial, so it need not match a calendar month. Annual Team plans still bill monthly MTU overages, and prepaid annual fees generally are not refundable after the trial. Billing and account rules.

Use at least one complete period and a forward view of launches, seasonal traffic and new integrations. A recent quiet week is a poor basis for an annual commitment.

Keep this review record in your planning document. These figures are hypothetical:

period: next_complete_billing_cycle
currency: USD
pricing_assumption: published_monthly_team_bands
base_case_mtu: 50000
launch_case_mtu: 100000
base_connections_estimate: 575
launch_connections_estimate: 1125
excluded: [tax, throughput_overage, add_ons, warehouse, destinations]
identity_change: remove_route_change_reset
acceptance_check: logout_and_account_switching_remain_correct
owner: analytics_lead

The difference between those scenarios is $550 per month. If a verified identity fix genuinely brought usage from the launch case to the base case, six engineering hours valued at $100 each would have a $600 one-time capacity cost. The simple payback would be roughly 1.1 months. This is an illustrative decision calculation, not a predicted saving or a cash refund.

Check operational signals separately from the invoice. Twilio says MTU usage is not real time: daily UTC processing includes deduplication before counters refresh. Usage emails are notifications, not a guaranteed spending stop. MTU usage timing.

A same-day counter that has not moved is insufficient evidence that a fix failed. Conversely, waiting for the bill is too slow to discover an SDK release generating a new identity per page.

Decide whether the platform earns its cost

Compare a maintained alternative against a maintained Segment implementation. Include engineering support, destination changes, incident response, consent propagation and the cost of recreating required workflows.

The Segment alternatives guide maps collection, delivery, identity and activation requirements to realistic replacement options. Use it to define equivalent scope before entering a cheaper subscription into the migration model.

Suppose an alternative is estimated at $250 monthly against $575 for the current implementation, with equivalent scope. That creates $325 of apparent monthly savings. A $6,000 migration takes about 18.5 months to recover before any change in support effort. In year one, the alternative costs $9,000 including migration, against $6,900 to stay.

Those figures are deliberately hypothetical. They demonstrate why a cheaper subscription can still be the more expensive near-term decision. Repeat the calculation with measured maintenance effort and a realistic implementation quote.

Before approving a renewal or migration, check:

If you need help turning that into an implementation decision, our data warehouse and CDP service covers the architecture and delivery work. Bring the usage breakdown, required workflows and renewal date. Those inputs make a useful scope possible.