# MTU vs Event Pricing: How Product Analytics Tools Bill Users, Events and Sessions

Canonical URL: https://www.martechdevs.com/blog/mtu-vs-event-pricing

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder at [Martechdevs](https://www.martechdevs.com) and [Growth and Analytics Partners](https://www.growthandanalytics.com)

[LinkedIn](https://linkedin.com/in/jafrinalo)

Last updated: 2026-10-19

Monthly tracked user (MTU) pricing charges for tracked identities under a vendor’s monthly counting rules; event pricing charges for recorded actions. Sessions and monthly active users use different boundaries again. Compare the same workload, identity handling, features and contract period in each quote. Events per user help describe the workload, but the cheaper bill also depends on rates, allowances, overages and which events are identified.

## What is the difference between MTU and event pricing?

A monthly tracked user (MTU) represents a counted identity with qualifying activity; an event represents a recorded action. One person can produce many events, and one real person can appear as several unlinked identities. Your forecast must reproduce the vendor’s counting rule rather than treating a customer count as the invoice quantity.

| Unit | What you need to count | Why another metric cannot substitute |
| --- | --- | --- |
| MTUs | Qualifying identities within the vendor’s billing scope and month | Devices, anonymous IDs, merges and imports can change the total |
| Events | Billable captured actions under the product’s exclusions | A user can generate one event or thousands |
| Sessions | Activity grouped by the vendor’s session boundary | One identity can produce many sessions |
| MAUs | Active visitor identities within the specified active-user window | A rolling window can differ from a calendar-month count |

Our [product analytics implementation service](https://www.martechdevs.com/product-analytics) starts by measuring those inputs and fixing identity defects before modeling the quote. Choosing a cheaper unit does not repair an event stream that records a retry as a new business outcome.

Keep the definition attached to the number. “We have 10,000 users” could mean registered accounts, paid subscribers, people active this month or browser identifiers. Only the last two might resemble the billed population, and even then the scope and identity rules need checking.

## Which analytics products bill by users, events or sessions?

Amplitude, Mixpanel’s Enterprise MTU option, Pendo and Segment can use identity-based units. Mixpanel’s default pricing and PostHog’s product analytics use events; Heap uses sessions. Segment is a customer data platform, so its bill purchases a different job from an analytics subscription.

The references below describe the stated billing unit and recurring free allowance. They are not equivalent feature packages. The Mixpanel Enterprise minimum is USD per year; other paid rates depend on volume, selected plan and terms.

| Product | Billing unit to check | Public reference | What the quote still needs |
| --- | --- | --- | --- |
| Amplitude | MTUs or events | Free lists 2 million events/month; Plus lists up to 700,000 MTUs or 70 million events | Chosen unit, purchased volume, events-per-MTU allowance and overage rules |
| Mixpanel | Events by default; MTUs through Enterprise sales | First 1 million events/month free on the relevant current plans; MTU Enterprise starts at USD 20,000/year | Event or MTU terms, add-ons and the exact workload price |
| PostHog | Anonymous and identified analytics events, plus separate product meters | First 1 million analytics events/month free across the two event classes | Identified-event share, groups, replay and other enabled products |
| Heap | Sessions | Free up to 10,000 sessions/month | Session volume, retention and required paid features |
| Pendo | Monthly active users (MAUs) | Free up to 500 MAUs | Visitor identity, application scope and included products |
| Twilio Segment | MTUs with other usage limits or meters | The Connections plan and its throughput rules determine the allowance | Workspace population, source types, throughput and destinations |

Sources: [Amplitude pricing](https://amplitude.com/pricing), [Mixpanel pricing rules](https://docs.mixpanel.com/docs/pricing), [PostHog event classes](https://posthog.com/docs/data/anonymous-vs-identified-events), [Heap pricing](https://www.heap.io/pricing), [Pendo pricing](https://www.pendo.io/pricing/) and [Segment usage rules](https://www.twilio.com/docs/segment/guides/usage-and-billing/mtus-and-throughput).

Use the [Mixpanel pricing guide](https://www.martechdevs.com/blog/mixpanel-pricing) for its event tiers and MTU option, and [PostHog’s pricing guide](https://www.martechdevs.com/blog/posthog-pricing) for identified events and the other product meters. A free event allowance does not establish that the account-level analysis, retention or access controls you need are included.

### Sessions and active-user windows need their own forecast

Heap’s pricing page defines a web session as ending after 30 minutes of pageview inactivity; its mobile boundary is five minutes of inactivity. A frequent visitor can therefore create many billed sessions while remaining one tracked identity. Do not derive Heap’s bill by dividing events by an assumed universal number of events per session.

Pendo defines MAUs as unique visitors active over the last 30 calendar days. That rolling population differs from a UTC calendar-month count. For example, activity on the last day of one month can still be inside a rolling window early in the next month. Preserve the actual window when comparing usage exports.

## How do Amplitude and Segment decide which identities count?

Both count anonymous activity, but their identity and aggregation rules determine whether an anonymous visit and a later known user become one billed identity. Implement the genuine relationship, then inspect the billing result.

### Amplitude: organization scope and a month-end calculation

Amplitude’s [MTU guide](https://amplitude.com/docs/admin/billing-use/mtu-guide) uses device IDs for anonymous users and user IDs for known users, joining legitimately linked activity. Counting uses UTC calendar months; finalized counts are not revised for later anonymous-user merges.

Test identities and unlinked devices can increase counts. Mapping, identify and group-identify calls, plus Experiment Exposure and Assignment events, do not add MTUs. Sampling customers are ineligible for MTU pricing.

The [Plus terms](https://amplitude.com/plus-plan-terms) count MTUs once per organization, with a per-project exception for specified older accounts, and define an event allowance of purchased MTUs × 1,000. Use the purchased limit; observed users do not automatically create an allowance of that size. Confirm the account’s contract before combining projects.

Exceeding the event allowance can add synthetic MTUs under the documented rule. Keep the detailed calculation in [Amplitude’s synthetic MTU example and Plus terms](https://www.martechdevs.com/blog/amplitude-pricing); a low unique-user count alone is not a complete forecast.

### Segment: known IDs and unlinked anonymous IDs

Segment’s [MTU and throughput guide](https://www.twilio.com/docs/segment/guides/usage-and-billing/mtus-and-throughput) counts unique user IDs and anonymous IDs that were not linked to a user ID, across the workspace’s sources. A person who logs in on the app but remains anonymous on the website can therefore contribute a known app identity and a separate web identity.

In a simplified monthly example, the app links `app_anon_A` to `user_A`, while the website leaves `web_anon_A` unlinked. The forecast contains two identities: `user_A` and the website ID. A legitimate website-to-user link changes that expected count; sharing a browser or resembling another person’s profile is not sufficient evidence for the link.

An event source can introduce people who never used the product. Object Cloud Sources instead add retrieved objects to throughput without increasing MTUs. Inventory both, using [how Segment bills MTUs](https://www.martechdevs.com/blog/segment-pricing) to separate their usage.

### Mixpanel Enterprise: obtain the MTU definition in the order

Mixpanel’s [pricing documentation](https://docs.mixpanel.com/docs/pricing) offers the MTU Enterprise plan through sales rather than online checkout. Ask for its identity, project scope, included events, overage and import rules in writing. Do not copy Amplitude’s 1,000-events-per-MTU allowance into a Mixpanel forecast merely because both plans use the same acronym.

## Which workload measurements make the price comparison useful?

Measure events per counted identity, the anonymous identity share and the anonymous event share. The last two can differ dramatically, which matters when a product prices anonymous and identified events differently.

Start with these calculations after applying the vendor-specific eligible population:

```text
events_per_tracked_identity = billable_events / tracked_identities
anonymous_identity_share = unlinked_anonymous_identities / tracked_identities
anonymous_event_share = anonymous_events / all_analytics_events
```

Keep zero-user and incomplete-identity cases unresolved rather than dividing by a substitute customer count. The ratios describe your workload. The cost comparison still needs a quote for that workload and the required features.

### Example A: a logged-in business application

Assume 8,000 counted identities generate 400 events each during the month. The workload is 3.2 million events. If an Amplitude Plus MTU contract purchases 8,000 MTUs with the documented 1,000-event allowance, its allowance is 8 million events and this workload uses 40% of it. The purchased volume is an explicit assumption, not a public quote for that package.

Mixpanel’s [published volume examples](https://mixpanel.com/pricing/) list a four-million-event configuration at USD 504 per month on monthly billing or USD 360 per month equivalent with annual billing. That is a planning reference above the sample workload; it does **not** prove that 3.2 million events are automatically rounded up and charged as four million. Obtain the applicable price for 3.2 million and its growth case.

If an MTU quote costs less than the comparable event configuration after required add-ons, it wins that cost comparison. If its minimum commitment, features or overage treatment makes it more expensive, spare event allowance does not create a saving. Price the actual package.

### Example B: anonymous acquisition with a busy logged-in product

Assume 150,000 unlinked anonymous identities each generate four events, and 5,000 known identities each generate 300 events. These populations are deliberately disjoint for the example; do not add them if your identity implementation has already linked some of them.

| Population | Counted identities | Events per identity | Total events |
| --- | ---: | ---: | ---: |
| Unlinked anonymous | 150,000 | 4 | 600,000 |
| Known | 5,000 | 300 | 1,500,000 |
| Combined | 155,000 | 13.55 average | 2,100,000 |

Anonymous identities represent **96.77% of identities**, but only **28.57% of events**. The known population produces 71.43% of the event volume. Pricing PostHog as though 96.77% of the events were anonymous would materially misdescribe the workload.

If a contract purchased 155,000 MTUs with 1,000 events per MTU, the allowance would be 155 million events, of which this workload uses about 1.35%. That low utilization makes an event-priced quote worth comparing. It does not establish the winner without the MTU rate, event-class prices, minimum spend and features.

PostHog’s [anonymous and identified rules](https://posthog.com/docs/data/anonymous-vs-identified-events) also matter over time: past anonymous events remain billed as anonymous after linking, while future events for an identified person are captured as identified. A known internal ID can count as identified without an email address appearing in the event.

### Calculate the break-even point from the quotes

Use the cost function each vendor actually offers. In a deliberately simple fictional contract, suppose a tracked-user package costs USD 240/month and the alternative costs USD 0.0001 per billable event after one million free events, with identical required features and no other fees.

The event bill equals USD 240 at 3.4 million total events: one million free plus 2.4 million × USD 0.0001. Below that point the event bill is lower; above it the fixed tracked-user package is lower, provided its user and event limits still hold. These rates are invented to demonstrate the method, not attributed to a vendor.

Real contracts can have tiered rates, commitments and multiple meters. Replace the simple equation with those terms. A quote that leaves a required group-analysis add-on unpriced cannot yet establish the cheaper usable answer.

## How should you forecast the billed units before signing?

Forecast at least several representative periods from the actual collection plan, with separate normal, growth, launch and import cases. The purpose is to identify the inputs a vendor quote must cover, rather than to manufacture one universal user total.

1. Inventory web, app, backend, warehouse-import and third-party event sources.
2. Define each vendor’s billing window, identity scope and excluded events.
3. Count eligible events and identities, retaining anonymous and known populations separately.
4. Reconstruct sessions or rolling active-user windows only when that is the proposed meter.
5. Add the features and operational services required by the intended analysis.
6. Ask for quotes using the same workload cases and commitment period.

Use [a tracking plan with an owner for every event](https://www.martechdevs.com/blog/tracking-plan) so added instrumentation has a business purpose. When comparing identity counts, [merge anonymous and known users](https://www.martechdevs.com/blog/identity-merge) only where there is a legitimate link. Rotating IDs or collapsing unrelated users to change a bill damages the analysis.

| Workload case | Input that changes | Quote question |
| --- | --- | --- |
| More anonymous acquisition | Unlinked identities and usually low-frequency events | Does the user meter rise faster than event volume? |
| More active product usage | Events per known identity | Does an included event allowance or identified-event meter become binding? |
| New event source | Its population, event volume and identity linkage | Is its usage counted within the same workspace or organization? |
| Historical import | Imported events and historical user-month combinations | Which billing period receives the usage? |
| New paid feature | Groups, replay, exports or other enabled products | What must be added to the base price for the intended answer? |

Keep your forecast distinct from a dashboard’s active-user metric. A product report can exclude internal traffic or apply filters after collection, while billing still counts eligible ingested usage. Confirm where the exclusion acts before expecting it to reduce the invoice.

## What can make an import or identity repair change the bill?

Imports can charge in the ingestion period, and identity repairs do not always revise a finalized billing count. Preserve both the event’s historical date and the date the vendor accepted it.

Amplitude’s [backfill guide](https://amplitude.com/docs/admin/billing-use/mtu-guide) charges historical usage in the import month, but its wording conflicts on users appearing across several imported months. It describes user-month counting while an example counts one user across three months once. Get a sample billing estimate instead of turning either passage into a guaranteed charge.

Mixpanel’s [pricing guide](https://docs.mixpanel.com/docs/pricing) bills imports in the ingestion period for ingestion-time accounts; some legacy accounts instead use event timestamps. Confirm the account’s model. Its excluded identity-management events include `$identify`, `$create_alias` and `$merge`; that exclusion does not cover every custom event that changes an identity field.

For a legitimate identity repair, compare the pre-repair and post-repair entity graph and then check the billing counter. Keep a known person using two devices, a shared device used by two people and an unlinked anonymous visit in the acceptance set. A lower count alone is not evidence that the mapping improved.

Before a large backfill, confirm the applicable allowance, spending response and maximum acceptable collection interruption. Do not discover after loading that the import consumed the budget needed for current production events.

## How should you reconcile the first invoice?

Match each invoice line to its actual meter and billing window, then explain differences from the forecast. Separate unexpected volume from a changed rate, allowance or product scope.

Use [Amplitude’s organization billing view](https://amplitude.com/docs/admin/billing-use/mtu-guide) where supported and [Mixpanel’s usage view](https://docs.mixpanel.com/docs/pricing) for Owners and Billing Admins. Reconcile these counters separately from an ordinary active-user chart with different population rules.

PostHog’s invoice terminology needs particular care: its “person profiles” line represents identified **events**, not the number of people. The “events” line covers anonymous events, and the first one million analytics events are free across both classes. [PostHog billing definitions](https://posthog.com/docs/data/anonymous-vs-identified-events).

Use a reconciliation sheet with the product, unit, window, included quantity, actual quantity, rate, expected charge and actual charge. Split a discrepancy into volume, rate and scope components. Agree an investigation threshold with the budget owner based on money and business risk rather than treating any universal percentage as acceptable.

## When should you change unit, plan or tool?

Change the billing arrangement when the same required workload costs less under a supported alternative after transition and operating work. First remove accidental duplicate collection and unneeded events; then compare a unit change with a plan change and migration.

| Situation | Useful next comparison | What can invalidate the apparent saving |
| --- | --- | --- |
| Few identities with substantial legitimate activity | MTU quote versus event quote at the same feature level | Events-per-MTU overages or a high minimum commitment |
| Many low-activity anonymous identities | Event quote versus the full identity-based quote | The smaller known population generates most identified events |
| Session-oriented product analysis | Actual session quote versus event/user package | Session boundaries or required add-ons differ |
| Temporary import or launch spike | A planned usage allowance versus a long-term upgrade | Contract terms make the larger commitment persist after the spike |

Amplitude’s [Plus terms](https://amplitude.com/plus-plan-terms) specify one-month or twelve-month renewing terms. They permit additional usage charged at 1.0 times the applicable unit fee and possible suspension or termination above 200% of purchased event or MTU volume. They do not establish a general right to switch units mid-term. Get the new unit, allowances and effective date in writing. Mixpanel’s MTU option requires a sales quote.

Use the [Mixpanel, Amplitude and PostHog pricing comparison](https://www.martechdevs.com/blog/product-analytics-pricing) for complete configuration examples before moving tools. A lower event invoice can lose its value if migration, required add-ons or recurring engineering work cost more than the saving.

## Checklist

- [ ] The forecast uses the vendor’s unit, identity scope and billing window.
- [ ] Anonymous identity share and anonymous event share are separate.
- [ ] Web, app, backend, imports and third-party sources are included.
- [ ] Legitimate identity links are tested without collapsing different people.
- [ ] Purchased MTU limits and event allowances are recorded separately from observed usage.
- [ ] Required groups, replay, export and access capabilities are priced.
- [ ] Normal, growth and import scenarios have matching quotes.
- [ ] Overage, spending-limit and renewal responses are understood.
- [ ] Invoice differences can be traced to volume, rate or scope.

![Count the vendor-specific workload, apply the complete quote, resolve unmatched scope and reconcile usage after adoption.](https://www.martechdevs.com/assets/blog/mtu-vs-event-pricing.svg)

The useful decision is a priced, maintainable measurement system. If identity or collection makes the forecast unreliable, [book a free analytics audit](https://www.martechdevs.com/martech-ai-audit) or [request a scoped product analytics quote](https://www.martechdevs.com/product-analytics#get-quote) with the event sources and contract scenarios you need to reconcile.

## Frequently asked questions

### How should a shared kiosk affect a tracked-user forecast?

Treat the kiosk as a shared device rather than assuming its device identifier represents one customer. Decide which activity can be linked legitimately to a signed-in person and which remains anonymous, then test logout and the next visitor. A single device can understate people while frequent resets can create more anonymous identities. Forecast the vendor’s resulting identifiers and keep the limitation visible in customer analysis.

### How should rounding be handled in an analytics cost forecast?

Keep full precision through the workload and tier calculations, then round the displayed currency according to the agreed billing rule. Ask whether the vendor rounds each line, each tier or only the final amount; those methods can produce small differences. Preserve the unrounded model beside the invoice comparison. Do not change event counts to erase a rounding difference or mistake that difference for extra collection.

### How should finance compare a quote that bundles several applications?

Request the included applications, workspaces, identity scope and shared allowances in writing before adding their user totals. The same person may be counted once in one commercial scope and separately in another. Keep required features and internal data boundaries intact while comparing the bundle with separate purchases. A combined contract is useful only when its counted population, rights and operating responsibilities are understood.

### What should you do if the first month has no representative usage history?

Use a bounded measurement period and label the forecast’s uncertainty instead of inventing a normal month. Include the workflows expected at launch, likely traffic sources and the feature configuration that will actually run. Set a review point before a long commitment and preserve the raw counts used in the estimate. A quiet pilot with logging disabled cannot establish the operating bill of the launched product.

### How should parallel collection be budgeted during an analytics migration?

Forecast each destination’s full billable stream for the overlap period. Sending the same business action to two vendors does not create a shared allowance between their contracts. Keep the overlap long enough to validate the required cohorts, then assign a cutover owner and stop date. Separate this temporary cost from the continuing destination bill so the migration budget does not become an unnoticed permanent duplication.

## Sources

1. [Amplitude: Pricing](https://amplitude.com/pricing).

2. [Amplitude: MTU billing guide](https://amplitude.com/docs/admin/billing-use/mtu-guide).

3. [Amplitude: Plus Plan Addendum](https://amplitude.com/plus-plan-terms).

4. [Mixpanel: Pricing, billing units and usage](https://docs.mixpanel.com/docs/pricing).

5. [Mixpanel: Published event-volume prices](https://mixpanel.com/pricing/).

6. [PostHog: Anonymous and identified events](https://posthog.com/docs/data/anonymous-vs-identified-events).

7. [Heap: Session-based pricing](https://www.heap.io/pricing).

8. [Pendo: MAU pricing and definition](https://www.pendo.io/pricing/).

9. [Twilio Segment: MTUs and throughput](https://www.twilio.com/docs/segment/guides/usage-and-billing/mtus-and-throughput).