Methodology
How the Agent Traffic Index is computed
Written before there is any data, so the rules were decided when nothing was at stake in deciding them.
The index aggregates requests observed by gateways our customers installed. The subject of every number is a site, an agent, or a request. No number here has a person as its subject, and none ever will.
Nothing on this page is an ARS score, so nothing here carries a grade or a measured/heuristic split. These are counts and shares from our own event log.
Floors
What has to be true before a cell is published
k = 25 independent stores per cell
Every published cell must be computed over at least 25 distinct stores. The floor lives in the SQL as a HAVING clause, not in the reporting layer, so a cell that does not clear it cannot be selected in the first place.
It is not a tunable and it is not a starting point. There is no configuration value, no environment variable, and no admin toggle that lowers it.
No store may be more than 20% of a cell
k alone is not sufficient for volume metrics: 25 stores where one of them is 95% of the traffic is that one store with extra steps. Every cell therefore also carries a per-store contribution cap of 20%, computed from a real per-store CTE rather than from a summary column.
A cell that fails the cap is withheld; it is not rescaled, capped, or winsorised into publishability.
Independence is defined, not assumed
A store counts toward k when it is not first-party, has not opted out, and cleared 100 events in the 30-day window. Without the minimum-events predicate, k would count stores that sent us a single request.
trymumm.com posts events into the same log through the public ingest path. First-party stores are excluded from the numerator, the denominator, and k — an independence floor that counts our own store is not a floor.
Opting out is total
A per-store opt-out removes the store from the numerator, the denominator, and the k count. It is not a suppression of the store's name — no store is ever named here — it is a removal of the store's data from the computation.
The opt-out must be in the merchant terms before the first publication, not after it.
Publication
How and how often
Monthly, and cadence is a privacy parameter
Publication cadence sets the resolution available to a differencing attack. Two consecutive snapshots differ by whatever changed between them; the shorter the period, the smaller and more attributable that difference is. A weekly series over a small population leaks more than a monthly one over the same population, at identical k.
So cadence is decided on privacy grounds and not on engagement grounds. It will not be shortened because a chart would look livelier updated weekly, and any change to it is a privacy review, not a product decision.
Shares and percentiles. No absolute total.
Published cuts carry shares of a mix and distribution percentiles. There is no absolute network total, and no cut publishes a total alongside all of its parts — that combination lets any single part be recovered by subtraction, which defeats the floor that was applied to it.
This was an explicit correction to an earlier design that published an exhaustive requester-mix partition and a network total one line below its own rule forbidding exactly that.
Pre-declared cuts only
The cuts are fixed and published in advance. There is no query builder, no interactive slicer, and no filter parameter on the page. A per-query floor is not a control when the caller can compose an unbounded number of queries over the same population.
Snapshot tables, never live queries
Numbers are published from a snapshot written by an explicit job, with one audit row per publish recording what was computed, over what window, under which floors. A page that queries the live event log renders a slightly different population on every request, and nothing about that population was ever reviewed.
Not built yet
What still has to land before the first publication
Listing this is cheaper than publishing a number we would have to retract.
The snapshot table and the audit rowPlanned
Neither exists yet. Until they do there is no code path on /agent-traffic that can render a share — the page holds a counter and nothing else.
The ARCHITECTURE.md subsection for this crossingPlanned
The canonical docs describe MUMM reading Rebilder data. This index is merchant data flowing to the public, which is a different crossing with different rules, and it needs its own subsection before the first publication rather than after it.
Merchant terms covering the opt-outPlanned
The per-store opt-out has to be in the terms a merchant agreed to before any of their traffic contributes to a published number.