What the numbers are computed from, and what they leave out
Every figure comes from openDMCA's own corpus of resolved takedowns: leaks that reached a terminal state, joined to the first notice actually sent for them. The clock on median days starts when somebody asked the host to act, not when the leak was detected, because detection speed is a different claim.
Nothing that identifies a creator, a client, a URL or an account crosses the boundary. The query returns per-host aggregates only, by construction rather than by policy.
One known limitation, stated because a statistics page that hides its limitations is marketing: the resurrection rate is computed from each leak's current status, so a leak that came back and was removed again counts as removed. It under-reports. Fixing it properly needs a status-history table that does not exist yet.
Why openDMCA is building this instead of quoting a single removal rate
A single site-wide removal percentage is the least useful number in this category. It averages a host that complies with a host that has never answered a notice, and it cannot be checked by anyone. What a creator needs before she pays anyone is narrower: for the specific hosts her content is on, does a notice work, and what happens next if it does not.
The same corpus is what openDMCA routes on. A host whose ninety-day removal rate sits below 25%, across at least five resolved samples, is fast-pathed past two email rounds straight to search de-listing. Publishing the corpus is publishing the routing logic's input, which is the only way to make the mechanism checkable rather than merely stated.
While this page is gated, the honest comparison to make is on process rather than outcomes. The eight questions to ask any content-protection service is where that starts.