Amplitude’s pricing has historically been tied to monthly tracked users, a model that rewarded a large, engaged audience without punishing teams for logging events generously. As of mid-2026, Amplitude moved to a volume-based model closer to what Mixpanel has run for years, where the events you send — not just the users you have — become the thing that determines cost. For a team that built its instrumentation habits under the old model, that’s a meaningful shift: an event taxonomy that was “free” to expand liberally is now a direct cost lever, and nobody has necessarily gone back to check whether every event still earns its place.
The practical danger is that event volume is rarely reviewed as its own metric. Teams watch tracked users, DAU, and feature adoption, but the raw count of events fired per session tends to grow quietly as new features ship, each adding a few more _viewed, _clicked, and _loaded events without anyone removing the ones that stopped being useful. Under volume-based pricing, that slow accumulation compounds directly into spend, and a debug or QA build that logs to the production project can inflate a monthly count before anyone notices the anomaly in a bill rather than a dashboard.
Data Points to Track
- Total events sent per day, broken down by event name, so the highest-volume events are visible and can be judged on whether they’re still worth their cost
- Events per session, tracked as its own trend line, to catch a taxonomy that’s quietly bloating rather than staying flat as features are added and removed
- Event volume by source — production app, staging, QA builds, and internal tooling — since non-production traffic hitting a billed project is a common, avoidable cost
- Duplicate or near-duplicate event names, surfaced by comparing event definitions against actual usage, since taxonomy drift is one of the biggest hidden volume drivers
- Property count and payload size per event, since some pricing tiers also weight on data volume, not just event count
Setup Steps
- Route non-production builds to a separate Amplitude project or a sampling filter, so QA and staging traffic never lands in the billed production event count.
- Audit your event taxonomy against actual dashboard usage and deprecate events that nobody queries, rather than leaving them to accumulate volume indefinitely.
- Set a per-session event budget as a soft engineering guideline, and flag new features in code review if their instrumentation plan pushes noticeably past it.
- Build a volume dashboard inside Amplitude itself, tracking daily event count and its rate of change, so a spike is visible the same day it happens rather than at the end of a billing cycle.
- Review high-cardinality properties attached to high-volume events, since a property that logs a unique value per event (like a raw timestamp string) can inflate data volume without adding analytical value.
Actionable Insights
With event volume tracked by name and source, a rising bill stops being an abstract “usage went up” and becomes a specific finding: this event fires on every scroll rather than once per session, or this staging environment has been pointed at production for three months. The same data also gives product and engineering a shared basis for taxonomy decisions — instead of debating in the abstract whether an event is “worth tracking,” the volume and cost it actually carries becomes part of that conversation. Teams that get ahead of this now will find the migration to volume-based pricing is a taxonomy clean-up opportunity rather than a surprise increase to budget for.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert