MAU pricing distorts identity infrastructure costs on spike days

At a glance

What this is: The article compares MAU and aDAU billing for identity infrastructure and shows how monthly active user pricing can dramatically overstate real usage during traffic spikes.

Why it matters: Identity teams need to understand how billing models shape cost predictability, procurement, and platform selection when user activity is intermittent or bursty.

By the numbers:

• Across Ory Network's customer base, the observed average is approximately 7.6%.
• Real-world usage patterns rarely produce consistent daily activity, and aDAU typically reduces costs by 30-75% depending on traffic pattern.

👉 Read Ory's comparison of MAU and aDAU pricing for identity infrastructure

Context

MAU pricing in identity infrastructure counts every unique user who authenticates during a month, so one high-traffic day can distort the entire billing period. For identity and access management programmes, that creates a mismatch between cost and actual usage, especially where authentication load is bursty rather than steady.

aDAU changes the unit of charge from monthly presence to average daily activity. That matters for IAM leaders because it aligns billing more closely with operational reality, which is often the better basis for forecasting, platform comparisons, and procurement decisions.

This is primarily a pricing and capacity question for identity infrastructure, not a security-control question. The governance issue is whether the billing model reflects the way human users actually consume the service across the month.

Key questions

Q: How should identity teams compare MAU and aDAU pricing models?

A: Start with actual usage behaviour, not vendor price cards. MAU is easier to understand but can overcharge bursty applications because it counts any authenticated user once per month. aDAU usually tracks cost more closely to daily consumption, so the better model depends on whether your users are steady, seasonal, or spike-driven.

Q: When does MAU billing become a poor fit for identity infrastructure?

A: MAU becomes a poor fit when a small number of spike days, event-driven logins, or one-off authentication surges dominate the month. In those cases, the invoice reflects peak monthly presence more than real service consumption, which makes forecasting and chargeback less reliable for platform and IAM teams.

Q: How do I estimate whether aDAU will materially reduce identity costs?

A: Estimate your average daily authenticated users from production logs, then compare that figure to the monthly unique user count. If the same users return across many days or your traffic is highly bursty, aDAU will usually narrow the gap between billing and actual usage. Use your own DAU/MAU ratio rather than a generic benchmark.

Q: What should teams ask before committing to usage-based identity billing?

A: Ask what is being measured, how spikes are treated, and whether pricing follows daily activity or monthly presence. You should also ask for examples from workloads similar to yours, because the right model for a work-week SaaS app may be a bad fit for consumer or event-based authentication patterns.

Technical breakdown

How MAU distorts identity infrastructure pricing

Monthly Active Users count each unique authenticated user once per billing month, regardless of whether that user logs in once or every day. That makes the metric easy to bill against but poor at representing compute demand, because it treats occasional and frequent users as equivalent. In bursty environments, a single campaign, launch, or seasonal event can pull one-time users into the bill for the full month. The result is a pricing model that behaves more like a high-water mark than a usage average.

Practical implication: teams should test whether MAU pricing matches their traffic shape before using it for forecast or vendor comparison.

How aDAU maps more closely to usage patterns

Average Daily Active Users sums daily active users across the billing period and divides by the number of days. A user who returns daily contributes far more to the average than a user who authenticates once. That makes aDAU better suited to applications with uneven traffic, because it smooths spikes and reflects daily load rather than monthly presence. In practical terms, aDAU is a more proportional billing signal when authentication volume tracks real usage rather than raw account count.

Practical implication: identity teams should use aDAU-style model when they need price to follow actual authentication activity.

Why usage overlap changes the MAU and aDAU gap

The size of the gap between MAU and aDAU depends on how much the same users return across the month. High-overlap workday applications keep MAU closer to daily activity, while low-frequency or event-driven applications produce much larger divergence. That is why the article’s examples show smaller savings in a work-week pattern and larger savings in cyclic or spike-heavy patterns. The underlying mechanism is not just volume, but repeat behaviour and user retention across days.

Practical implication: model billing against your own DAU/MAU ratio rather than assuming a generic industry average.

NHI Mgmt Group analysis

MAU is a billing proxy, not an operational identity measure. The article shows that monthly active user counts can overstate actual usage when authentication is uneven across the month. That makes MAU a poor stand-in for workload intensity in environments where identity traffic spikes around launches, events, or periodic workflows. For practitioners, the lesson is to separate presence from consumption when evaluating identity infrastructure economics.

aDAU introduces a more defensible proportionality model for identity infrastructure. By averaging daily activity, aDAU tracks service consumption more closely than a month-end count. That matters because identity platforms are increasingly judged on cost predictability as much as on access control features. For IAM and platform teams, the real decision is whether the commercial metric mirrors how the service is actually used.

Spike sensitivity is a governance issue when budgets drive architecture choices. If one anomalous day can multiply the bill by 5x to 7x, teams may avoid usage patterns or delay rollouts for reasons that have nothing to do with security or performance. That distorts procurement, forecasting, and internal chargeback. The practical conclusion is that billing design now shapes identity architecture as much as technical capability does.

Usage-based identity pricing is becoming a programme design question, not a procurement footnote. When the cost model follows daily behaviour, teams can compare vendors on proportionality instead of headline subscription size. That supports better lifecycle planning for seasonal, consumer, and bursty applications. Practitioners should treat billing metrics as part of identity governance, because they influence adoption decisions and platform sprawl.

For IAM leaders, the key concept is pricing proportionality. Identity infrastructure should be measured against the activity it actually supports, not a monthly maximum that captures one-off surges. Ory's example makes clear that the wrong billing unit can make stable platforms look expensive and volatile ones look normal. The practitioner takeaway is to model commercial risk alongside technical load before committing to a billing model.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, according to The 2026 Infrastructure Identity Survey.
• That leaves billing, access scope, and governance moving faster than many identity programmes can absorb, according to the same survey.

What this signals

Pricing proportionality: identity teams should treat billing design as part of governance, because the wrong unit of charge can distort architecture, forecasting, and adoption decisions. That matters most where authentication demand is bursty and monthly presence is a poor proxy for real consumption.

The commercial model can shape platform behaviour just as much as the technical control set. When usage spikes are normal, teams should expect MAU to exaggerate spend and should test alternatives against production telemetry rather than vendor assumptions.

For practitioners

• Benchmark your DAU/MAU ratio before choosing a billing model Use real authentication telemetry from production traffic, then test whether your workload sits closer to workday, spike, or cyclic behaviour. Compare that profile against monthly active user billing and average daily active user billing to see where the cost curve breaks.
• Model spike-day exposure separately from average load Run a month simulation with one or two abnormal traffic days so you can see how much a high-water mark inflates the invoice. This is especially important for product launches, compliance deadlines, seasonal events, and consumer login surges.
• Align procurement reviews to usage proportionality Ask vendors whether the billing unit reflects daily authenticated activity or monthly presence, and require both forecast scenarios in pricing discussions. That makes it easier to compare identity services on cost predictability rather than nominal subscription size.
• Track billing impact alongside identity metrics Pair access logs with finance reporting so the team can see whether growth, retention, or burst traffic is driving spend. If the billing model routinely penalises normal usage spikes, raise that as an architectural and commercial risk, not just a budget issue.

Key takeaways

• MAU can overstate real identity usage when activity is bursty, which makes it a weak proxy for operational load.
• aDAU better reflects day-to-day authentication demand and can materially reduce cost distortion for intermittent workloads.
• Identity teams should model billing against their own usage patterns before committing to a pricing model or platform contract.

Key terms

• Monthly Active Users: A billing metric that counts each unique user who authenticates at least once during a month. It is simple to administer, but it can overstate actual infrastructure consumption when the same user logs in only occasionally or when one spike day pulls many one-time users into the billing period.
• Average Daily Active Users: A usage metric that averages the number of unique authenticated users across the days in a billing period. It is often a better fit for identity infrastructure because it reflects daily activity patterns, not just monthly presence, and it smooths out short-lived traffic spikes.
• Usage Proportionality: The relationship between what a customer pays and the real load they place on the service. In identity infrastructure, proportional pricing is strongest when the billing unit tracks day-to-day authentication behaviour rather than a monthly high-water mark that overstates normal demand.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• The billing comparison calculator and slider examples that show how different traffic patterns change MAU and aDAU outcomes.
• The specific formula and assumptions used to estimate aDAU from MAU for your own application.
• The example patterns for launch-day spikes, work-week usage, and cyclic traffic that help teams benchmark their own environment.
• The pricing context for Ory Network workspace-based billing and how it affects subscription planning.

👉 Ory's full post includes the calculator logic, pattern examples, and pricing context behind the billing comparison.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.