Amplitude moved off monthly-tracked-user pricing this month, joining Mixpanel on a model that bills by event volume instead. For teams that have spent years treating event tracking as functionally free once the SDK was installed, that’s a real shift. Under MTU pricing, a chatty feature that fired fifty events per session cost the same as a quiet one firing five, as long as the same user triggered both. Under volume-based pricing, every additional event is now a line item, and nobody on most product teams has ever had to think about analytics instrumentation as a cost centre before.
The risk isn’t the pricing change itself — it’s that most event schemas were never designed with volume in mind. Autocapture tools, debug logging left on in production, redundant events fired by two different SDKs tracking the same user action, and page-scroll or mouse-move events sampled far more granularly than any dashboard actually uses are all common, and all now show up directly on an invoice instead of disappearing into a flat-rate plan. Teams that don’t track volume by source will find out what’s expensive only when finance asks why the bill tripled, at which point the fix is a rushed audit instead of a deliberate decision.
Data Points to Track
- Event volume by feature and team, not just totals — which parts of the product generate the most events relative to the insight they actually produce
- Autocapture vs. manually-instrumented event ratio, since autocapture tools are convenient but tend to generate far more volume per session than deliberately designed tracking plans
- Redundant event rate — the same user action captured more than once by overlapping SDKs, plugins, or destinations
- Debug and internal-testing event leakage into production event counts, from staging builds, QA accounts, or logging flags left on after a release
- Sampling rate per high-frequency event type (scroll depth, mouse movement, video progress ticks) against how often that granularity is actually queried in a dashboard
Setup Steps
- Pull a volume breakdown by event name and source from your analytics platform’s usage dashboard before the next billing cycle, so the current baseline is known rather than assumed.
- Flag any event type responsible for a disproportionate share of volume relative to how often it’s referenced in reports, dashboards, or experiments.
- Audit autocapture configuration and disable capture for elements or pages that aren’t tied to a specific analysis need.
- Add a source tag to every event (feature, team, environment) so volume can be attributed and reviewed on an ongoing basis, not just investigated reactively.
- Set a sampling policy for high-frequency, low-value events and apply it consistently, rather than letting each team choose its own default.
Actionable Insights
A small number of event types usually account for most of the volume, and they’re rarely the ones anyone would guess without looking — a background heartbeat ping or a granular scroll-tracking event will often dwarf every conversion and revenue event combined. Cutting or sampling down those types is almost always lower-risk and higher-impact than trimming the events product and growth teams actually build reports on.
Redundant events deserve their own audit pass: a signup captured once by the primary SDK and again by an experimentation tool’s own tracking layer isn’t just a cost problem, it’s a data-quality one, since the two counts can silently drift apart over time. Fixing the duplication both lowers the bill and removes a source of numbers that don’t reconcile.
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