Skip to content

Research

How ROAS Shield measures comment-to-hide speed

What we measure, what we exclude, and why the headline number stays withheld until real production data supports it. Published 2026-07-07.

What we measure

The clock starts the moment your webhook delivery arrives at our servers — not when the comment was posted on Meta, which is Meta's own clock and says nothing about our latency. Every ingested comment carries that received-at timestamp.

The clock stops when our system confirms the hide action succeeded against the Meta API. We write the hide-success audit record only after Meta's API returns success — never when the decision was made, and never optimistically before the call completes. In storage terms: the gap from the comment's received-at timestamp to the created-at timestamp of its hide-success audit record.

The published figure is the median of those gaps across every qualifying hide action, with the 95th percentile alongside it so a flattering average can never hide a slow tail.

What we exclude

Backfilled and polled comments are excluded. Comments can reach us by paths other than a live webhook delivery — a connect-time backfill of existing comments, or a poll-fallback sweep. Those paths measure how often we sweep, not how fast the pipeline reacts, so counting them would distort the claim in either direction.

The exclusion works by positive confirmation, applying going forward from the date this measurement shipped: a hide action qualifies only when its comment carries an explicit webhook-origin ingest-source stamp, recorded at ingestion time. Historical comments that predate the stamp are also conservatively excluded — we cannot prove after the fact which path they arrived by, so they do not count, even where including them might have flattered the number.

Why webhooks, not polling

This section describes only ROAS Shield's own architecture. Meta pushes a webhook to our servers the moment a comment is created on one of your connected Pages or Instagram accounts. Our endpoint verifies and stores the event and immediately hands it to a worker, which evaluates your rules and calls the Meta API to hide the comment where a rule says so. There is no schedule involved: reaction time is bounded by processing, not by how often anything checks for new comments.

A polling architecture — fetching new comments on a fixed interval — has a structural floor: on average half the poll interval passes before the comment is even seen. A webhook pipeline has no such floor, which is why we measure from webhook arrival and publish the real distribution instead of a theoretical claim.

Sample size and confidence

We publish nothing until the platform-wide aggregate clears a floor of at least 1,000 qualifying hide actions across at least 10 distinct workspaces over a rolling 30-day window. Below that floor, the public claim stays in its withheld state and this page says “not yet published” — a median computed from a handful of actions in one or two workspaces is an anecdote, not a claim.

The workspace floor also protects customers: no single workspace's traffic can ever be the aggregate, so the published number is workspace-anonymized by construction.

Limitations

It is an aggregate, not a guarantee. The number is a cross-workspace median over a rolling window, not a promise about any single workspace, page, or comment.

Upstream incidents move it. The measurement includes the Meta API call itself, so a slow Meta incident inside the window shifts the aggregate — that is honest (your comments really were hidden more slowly) but it means the figure is not a constant.

It always carries an as-of date. The published claim states when it was computed, and it is re-verified by an operator before each update — never extrapolated forward.

Last verified: not yet published.