When an analytics setup hits the free plan ceiling, traffic is the first thing blamed. Yet in the setups I have measured, the ceiling is set not by the visitor count but by how many rows are written per visitor. Two sites with identical traffic can diverge by a wide margin in quota consumption, because an event carrying eight properties and a bare event differ by up to nine times.
This article covers what the billing unit is, how the monthly budget of your own setup is derived, where the quota goes, and at which threshold a plan change or self-hosting starts to make sense.
What the Billing Unit Is
Cookieless analytics tools do not count the same thing. In one product the billing unit is the pageview, in another every interaction, in a third every field attached to an event is a separate record. Which product counts which can only be read from that product’s own usage definition; the price table does not answer it. The question to settle before picking a plan is not the price, it is the unit.
Umami writes it out plainly. Usage is measured as pageviews to a website plus custom events and stored custom event properties; every pageview counts as one event, and every stored property counts as an event as well.1 So a single custom event carrying an eight key segment object draws nine units from the quota rather than one.
The tool’s own usage panel shows the same split: events, event data, session data and heatmap data are listed as separate items. On my own site that breakdown says forty percent of monthly consumption comes from events and sixty percent from event data. In other words most of the quota is spent not by the behavior I measure but by the labels I write next to that behavior.
The Monthly Budget Calculation
The calculation has three items:
daily units = pageviews + custom events + stored property rows
monthly budget = daily units x 30You can read these three numbers from the dashboard or from the row counts in the export files. A weekly average gives a more accurate result than a single day sample.
On my own content site, an eight day window measured like this:
| Item | Over eight days | Monthly equivalent |
|---|---|---|
| Pageviews | 1,464 | ~5,500 |
| Custom events | 6,865 | ~25,700 |
| Property rows | 12,567 | ~47,100 |
| Total units | 20,896 | ~78,400 |
The free plan ceiling is one hundred thousand events a month.2 So pageviews use seven percent of the quota and all the rest comes from measurement design. If traffic doubles, consumption doubles, and that is unavoidable. The controllable multiplier is the number of rows written per page: adding two properties to every event produces the same effect without touching traffic at all.
For comparison, running the same calculation over a three day window on a high volume ecommerce setup put daily consumption at roughly forty four thousand units. At that rate the free plan ceiling fills in about two days. Had all custom events been switched off in the same setup, leaving only pageviews, the ceiling would have filled in about eleven days. At that scale the free plan is not a quota management problem, it is a structural mismatch.
Where the Quota Goes
Four patterns inflate consumption, and all four arise from an intent to enrich the measurement.
A segment object attached to every event. Fields like page type, content language and membership status are valuable for analysis, but they do not change through a session. Attached to every event, they write one row per event. In my own setup, seventy percent of eight day consumption came from a single segment event.
A property carrying a constant value. A field that has not been populated yet, sent with its default value, spends quota and carries no information. A property holding the same value on every row produces no distinction in analysis.
Nested objects. Umami stores event data flattened, and nested fields expand into separate rows with dot notation. A four key sub object looks like a single field in the dataLayer while drawing four units from the quota.
Events repeating per threshold. A scroll measurement firing at the twenty five, fifty, seventy five and one hundred percent thresholds writes four events for every page read to the end. The design may be correct, but its cost is four per page rather than one.
Where the Savings Are
Ordered from the largest effect to the smallest:
Move segment information to the session level. For fields that stay constant through a session, a session property replaces an event property. On the Umami side that happens through a umami.identify() call, and when the object argument carries no identity field, no identity is assigned to the visitor and only a tag is written onto the session. On a site averaging seven events per session, the same information is stored with roughly seven times fewer rows. Session properties are listed as a separate item in the usage panel, so it is safer to assume they are metered; the usage definition does not mention that item explicitly. The cost is not zeroed out, its scale changes.
Use an allowlist. Instead of attaching an entire measurement object to the event, pick the fields analysis actually uses one by one. Derived metrics like scroll speed variance and acceleration smoothness can be queried as parameters on the GA4 side; with no reporting counterpart in the cookieless tool, they are cost and nothing else.
Reduce the number of thresholds. A four threshold scroll measurement cut to two thresholds halves the volume. The lost information stays limited, because which threshold was crossed is already carried in the event’s own field.
Trim visibility events. A CTA appearing on screen is an observation, not a decision. Events of that kind are usually the highest volume, lowest decision value item on the list.
Exclude your own traffic. Test and preview sessions both consume the quota and distort the rates. An internal traffic rule in the tag manager plus a separate marker for preview sessions is enough for this.
The Footprint of Consent Events
For a setup that wants to measure consent decisions, three details matter on the quota side.
The decisions themselves are cheap. Accept, reject, preferences screen and withdrawal events happen at most a few times per session.
The impression count can be expensive. The banner reappears on every page until a decision is made. Counted raw, a single undecided visitor inflates the denominator and burns quota at the same time. Counting the impression once per session solves both problems together.
Adding properties to decision events is usually unnecessary. Since what is measured is the decision itself, writing language or page type next to it spends quota and adds little to the analysis. How the consent rate is measured, and which questions the export cannot answer, is covered in a separate article that is only published in Turkish for now. How decision events are sent without depending on the tracker, and which fields are stripped from the payload, is covered in setting up Umami with GTM in a consent compliant way.
What Happens at the Ceiling
On plans that bill overage, collection continues and the excess is charged. On the free plan the send request is rejected.
The real problem is not the rejection, it is the silence. In the source of the Umami tracker, the send function does not check whether the response succeeded; it goes straight to reading the body and falls into an empty catch block on failure.3 No retry, no console warning. All that remains in the dashboard is a line dropping to zero, which can just as easily read as a traffic decline.
The practical consequence is this: when the measurement system itself is not monitored, data loss can run for weeks unnoticed. The usage counter deserves a daily look through the first month after setup and a weekly one after that. Tracking quota consumption like a measurement metric also shows which event is growing before the ceiling arrives.
Which Decision at Which Threshold
| Situation | Symptom | Decision |
|---|---|---|
| Monthly budget under the ceiling, single site | Quota consumption steady, property count controlled | The free plan is enough |
| Budget exceeds the ceiling, volume rising steadily | The ceiling fills within days or weeks | Move to a paid plan, overage is billed per unit |
| Which property to store became a billing question | Measurement decisions are made under quota constraints | Evaluate self-hosting |
| Data will move to a warehouse and join other sources | The managed plan’s export paths are too narrow | Self-host, for database access |
| Where the data sits is a contractual matter | Location is set by client or regulation | Self-host, for data location |
The ordering works like this.
The free plan is enough for setups whose monthly budget stays under the ceiling and that measure a single site. Content sites usually fit that band, but fitting depends on the event design staying disciplined. In the setup I measured, a single segment event was spending seventy percent of the quota, and without fixing that any traffic growth would have brought the ceiling closer.
A paid plan is the first option once the budget exceeds the ceiling. Billing overage per unit turns the quota from a hard wall into a movable threshold. Given that the free plan fills within days at ecommerce scale, the decision in that band does not even require arithmetic.
Self-hosting is not decided on cost. At small and medium scale, the monthly gap between the managed plan and a server rarely covers the maintenance time. Three situations justify self-hosting:
- Direct database access is needed. When a data layer is being built to move into a warehouse and join other sources, the managed plan’s export paths stay narrow.
- Event volume has turned the quota into a permanent constraint. Once the question of which property to store stops being a measurement decision and becomes a billing decision, removing the constraint frees the design.
- Where the data sits is contractually decisive.
In return, version tracking, backups and database maintenance appear. There is also a side effect worth noting: session replay and heatmaps, locked to the top plan on the managed side, sit one setting away on your own server. With the price barrier gone, turning them on by accident gets easier too, and the moment replay is on, a cookieless setup becomes session recording.
Limits
The numbers here come from two measurement windows, one of eight days and one of three, and carry no seasonality. On your own setup the calculation deserves at least a week of data.
Prices and quota definitions change. The definitions and ceilings in this article were checked on 27 August 2026; confirm them on the product’s own page before deciding.
Finally, saving quota is not a goal in itself. Every deleted property leaves a question unanswered in the analysis. The right question is not “how do I lower the quota” but “which field feeds which decision”; a field with no answer already costs twice, once on the invoice and once as noise in the report.
Footnotes
- Umami, the frequently asked questions section of the Pricing page: “Usage is measured by counting pageviews to a website plus any custom events or custom event properties stored.” Checked on 27 August 2026. ↩
- Umami Cloud plan ceilings, from the same page: one hundred thousand events a month and a single site on the free plan, one million events plus a per unit overage price on the paid plan. Checked on 27 August 2026. ↩
-
The
umami-software/umamirepository, versionv3.3.1ofsrc/tracker/index.ts, the send function. ↩
- 01 The billing unit differs from tool to tool. Umami states its definition plainly: every pageview is an event, every custom event is an event, and every stored property counts as an event too. A single event carrying an eight key segment object draws nine units from the quota; nested objects flatten with dot notation and write a separate row for every sub key.
- 02 The monthly budget comes out of a simple sum: pageviews plus custom events plus property rows, averaged per day and multiplied by thirty. On the content site I measured, pageviews were only seven percent of the quota.
- 03 When segment information moves to the session level instead of being attached to every event, the same information is written once per session rather than once per event. A property carrying a constant value spends quota without carrying information.
- 04 When the quota runs out the send request is rejected, and because the tracker never checks the response there is no retry and no warning. If the measurement itself is not monitored, the data loss can go unnoticed for weeks.
- 05 The plan decision follows scale, the self-host decision follows need. What justifies self-hosting is not a few dollars a month, it is direct database access, the disappearance of the quota concept, and where the data sits.
+ What exactly is counted on the free plan of an analytics tool?
It varies by product, and it is the first thing to check before buying. By Umami's definition, usage is measured as pageviews to a website plus custom events and stored custom event properties; every pageview is one event, and every stored property counts as an event as well. On tools that count pageviews only, the same setup costs far less, while on tools that count events and properties a rich data layer can fill the ceiling quickly.
+ How do I calculate the monthly quota consumption of my own setup?
Adding up a single day of data in three items is enough: pageview count, custom event count, and the number of stored property rows tied to those events. The sum of the three gives daily unit consumption, and multiplying by thirty gives the monthly budget. You can read the figures from the dashboard or count the rows in the export files. As a measurement window, a weekly average is safer than a single day, because the weekday and weekend gap skews a one day sample.
+ Does moving properties from the event to the session level really reduce the quota?
It reduces it by the volume ratio. Fields like page type, language and membership status that stay constant through a session write one row per event when attached to every event, and one row per session when moved to a session property. On a site averaging seven events per session that is roughly a sevenfold difference. Session properties are listed as a separate item in the usage panel, so it is safer to assume they are metered; the cost is not zeroed out, its scale changes.
+ How much does measuring consent banner decisions affect the quota?
The decisions themselves are cheap, the impression count can be expensive. Accept, reject and preferences screen events happen at most a few times per session. The banner impression, on the other hand, can fire again on every page until a decision is made; without per session deduplication the acceptance rate reads lower than it is and the quota is spent for nothing. Adding properties to decision events is usually unnecessary too, because what is being measured is the decision itself.
+ What happens when the quota runs out, does the data arrive later?
On plans that bill overage, collection continues and the excess is charged. On a free plan the send request is rejected and cannot be recovered afterwards. The critical part is the silence: because the tracker does not check the response code, no error shows in the console and all that remains in the dashboard is a line dropping to zero. That is why the usage counter deserves a weekly look, and a daily one through the first month after setup.
+ At what point does self-hosting make sense?
The decision is not made on cost, because at small and medium scale the gap between the monthly price of the managed plan and the price of a server rarely covers the maintenance time. Self-hosting makes sense in three situations: when direct database access is needed, when event volume has turned the quota from a measurement decision into a permanent constraint, and when where the data sits is contractually decisive. In return, version tracking, backups and database maintenance become yours.