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.
Known limitations, stated because a statistics page that hides its limitations is marketing: a leak that came back more than once counts once in the resurrection rate, since only its last return is stored. A removal is counted only when openDMCA's own check found the page gone; one a person marked by hand is left out until a check confirms it.
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, skips the follow-up notice and moves up to search de-listing, with the rest of the escalation ladder still to follow. 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.