Skip to main content
An MTU is a unique visitor bucketed into any experiment during a calendar month. One per person per month.
Billing page

Billing page. Plan, usage against your caps, and the upgrade path.

How it is counted

Every visitor gets a stable id (a UUID in localStorage and a cookie on your site’s eTLD+1). The first time in the month a visitor is bucketed into any experiment, they count as one MTU. Every subsequent bucketing that month, they do not. Counted server-side by hashing the visitor id and checking a Durable Object per organization. There is no client-side gate a misconfigured page can trip; the meter is entirely on our side.

What does not count

  • A visitor on a page with no experiment. Not counted.
  • A visitor who did not enter (allocation < 100 %). Not counted.
  • A blocked IP (Settings → Blocked IPs). Dropped before the MTU record is written.
  • An opted-out visitor (Visitor opt-out). The snippet never fires.
  • Preview mode. Preview does not send real beacons.

MTU across multiple sites

Your allowance is pooled across every site in your account. There is no per site cap, and no per site usage figure. One organization, one meter. How many MTUs a returning visitor uses depends on whether your sites share a domain, because the visitor id lives in that domain’s localStorage and cookie jar: Subdomains of one registrable domain share a visitor id, so they share the MTU. Two genuinely different domains cannot: browsers give each domain its own isolated storage, so the same human arrives as two unrelated visitors and is metered twice. No cross domain identifier exists to join them, and adding one is not something we plan to do. Different organizations always count separately, because the organization id is the salt in the hash.
Registering shop.example.com as a second site alongside example.com splits one visitor into two and bills you twice for them. Register the apex domain once. The same snippet covers every subdomain under it.

MTU across the month

Resets at the first of every month UTC. A visitor tracked in January starts fresh in February.

Going over

If you exceed your plan’s cap:
  • Already-bucketed visitors stay bucketed. Their variant does not change. Statistical validity of your running experiments is preserved.
  • New visitors stop being bucketed. They see the Original.
  • You get an email with a graph of your recent MTU consumption and a link to upgrade.
  • You are not auto-charged. The bill does not change on its own.

Downgrading mid-month

A downgrade does not lower your allowance mid-month. The smaller plan is scheduled for the start of your next billing period, so you keep the cap you are paying for until then. A test recruiting today will not stop recruiting because you picked a cheaper plan this afternoon. On the renewal date the smaller cap applies. If that month’s usage is already past it, the normal over cap behavior takes over: visitors already bucketed keep their variant, and new visitors stop being bucketed until the counter resets. Upgrades are the other way round. They apply within seconds of payment, and enrollment resumes within about five minutes if you were degraded. Downgrading does not delete data or archive experiments. History stays. See plans for what changes on the renewal date and refunds for the full cancellation shape.

Enterprise

If your MTU is much larger than the top public plan, contact enterprise@abtestly.com. Custom caps, custom pricing, custom SLAs.
Last modified on August 31, 2026