Why Per-Profile Customer Data Platform Pricing Breaks at Scale (With Cost Curves)

Per-MTU and per-profile customer data platform (CDP) pricing breaks at scale because the bill tracks how many identities you hold, not what you earn from them. Extrapolating Twilio Segment's published rate of $10 per 1,000 monthly tracked users above 100,000 gives about $6 million a year at 50 million MTUs; Salesforce's published $240 per 1,000 profiles per year gives $12 million at 50 million profiles. Negotiated contracts discount these figures, but the shape stays linear: more identities, more cost.

Who this is for: finance and technology leaders at high-traffic commerce and telecom businesses who are about to sign or renew a per-identity contract. It belongs to the high-load commerce and telecom hub.

The meters you are actually buying

Vendors use three meters, and each fails differently at scale.

Two details matter for forecasting. First, Segment's own documentation says it counts each unique userId plus each unique anonymousId that has no associated userId, and that a person who is anonymous on the website and then identified in the app can count as two MTUs 4. Second, the Twilio pricing page labels the plan limits as "visitors" while defining the overage unit as monthly tracked users, and its FAQ describes the Team overage as $10 per 1,000 where the table shows $12 for the first band 1. Ask for the contract definition, not the web page.

Cost curves

The figures below are arithmetic on the published rates, with these assumptions stated so you can challenge them:

Past 100,000 MTUs the effective Segment rate settles at about $0.01 per MTU per month, so cost grows in a straight line 1. The Salesforce Profiles price is $0.24 per profile per year, also linear 2.

Older practitioner reports point the same way. A Hacker News thread about Segment's pricing records a team paying about $30,000 per six months and rebuilding event routing for roughly $500 per month 5. That is anecdotal and dated, but it shows the behaviour the curve produces: at some scale, teams stop buying and start building.

The anonymous-traffic multiplier

For a high-traffic site the largest driver is rarely customers. It is anonymous visitors, who count as MTUs 14. Several things inflate the count:

The table shows list-rate arithmetic for a business with 1 million known customers and varying monthly anonymous distinct IDs.

The business, its customers and its revenue are identical in every row. Only the visitor-to-customer ratio changed.

Mitigations that do not require changing vendors: send only consented, identified or high-intent events to the platform; keep anonymous browsing in a cheaper analytics store; resolve identity on your side with first-party identifiers where lawful; and exclude bots at the edge.

Unit economics: paying for identities that never buy

A metered identity bill is indifferent to whether the identity ever converts. Take the last row of the anonymous-traffic table (21 million MTUs, $2,521,500 a year at the extended Team rate) and assume, purely for illustration, that 2% of those identities make a purchase in the year. That is 420,000 buyers, and the identity meter alone costs $6.00 per buyer per year, before any activation, storage or warehouse cost. The 1-million-MTU baseline in the same table costs $121,500, which is $0.12 per identity. The assumption is ours, not a benchmark; replace it with your own conversion data. The pattern holds whatever the number: the meter scales with audience size, while revenue scales with buyers.

Subscription businesses see a different version of the same problem. A telecom operator's profile count is close to its subscriber count and rarely falls, so a per-profile price becomes a fixed, growing tax on the customer base, and a data-layer decision made at 5 million subscribers is still being paid for at 30 million. See the telecom article.

Peak-event behaviour

A distinct-user meter responds to spikes unevenly. In a promotion month the extra visitors raise that month's MTU count, while throughput limits can bind at the same moment. Segment documents a throughput allowance expressed per MTU (its example is 250 API calls and objects per MTU, so a 10,000-MTU plan allows 2.5 million per month), counts each object in a batch individually, and says Business plans often have custom limits 4. Credit-based models shift the exposure: segmentation, activation and query work during a peak consumes Flex Credits at rates set in the contract, and Salesforce notes that credits apply to non-profile usage 2. Self-hosted, flat-licence models move the constraint to your own capacity, which you can test before the event; our peak-load activation test plan shows how.

How vendors respond

The published responses are consistent: the highest tier is custom. Segment's Business plan is custom pricing with "custom volume" 1; Salesforce tells buyers to contact sales for detailed pricing and notes that its pricing is subject to change 2; Adobe does not publish prices 3. Beyond that, discounts and credits are negotiated case by case, and we have not found a public schedule of them. Treat the first quote as the opening of a negotiation, and use the checklist below.

The flat-licence alternative

A flat licence prices the software by deployment tier, not by identity or event. PrivyCDP, for example, is licensed annually or perpetually by deployment tier, with infrastructure, DevOps and cloud or hardware scoped separately and no MTU or event metering 7. We do not publish PrivyCDP prices in articles; the licensing page explains the structure.

The honest comparison is not "flat is cheaper". It is where the curves cross. Self-hosting adds infrastructure and operations cost, and if that total is $X per year, the list-rate curves reach $X at:

Below those volumes, a metered SaaS plan is usually the cheaper and simpler answer. At 100,000 MTUs the Team rate extends to about $13,500 per year, which is small next to the people cost of running a platform, and nobody should self-host to save it. The flat model wins at the high-load end, where identities number in the tens of millions, traffic is spiky, and the meter has no ceiling. Build your own version with the TCO model and the 3-year TCO guide.

Negotiation checklist

1. Get the contract definition of MTU or profile, in writing, including anonymous, duplicate and test IDs.
2. Ask whether bots and internal traffic are excluded and who proves it.
3. Ask what period the count covers and whether billing is on peak, average or end-of-month.
4. Set an overage rate and a cap, and ask for the rate to hold across tiers.
5. Ask for a true-up window and a right to reduce volume at renewal.
6. Request the throughput and API-rate limits as contract terms, not documentation.
7. For credit models, attach the full multiplier table per operation to the order form.
8. Ask what happens at a promotion peak: grace, burst allowance or immediate overage.
9. Get price protection for the full term, including renewal caps.
10. Require data and identity-graph export in open formats at no charge.
11. Check which features sit behind higher tiers (for example, Segment lists HIPAA eligibility under Business only 1).
12. Model the exit cost before signing, using the CDP pricing explained guide and the Segment and Salesforce deep dives. Compare quotes in the CDP pricing index.

---

This article describes published vendor prices as read on 17 October 2026; prices change and negotiated terms differ.