SMM Testing
The protocol behind every claim of fast delivery on /buy-* pages — sample sizes, instrumentation, and the 30-day rolling window we report against.
Delivery speed is reported as two distinct numbers, not one. Conflating them is how cheaper panels make “instant delivery” claims that fall apart on bigger orders.
Each calendar month we place a fixed grid of 27 test orders on our own services using test accounts we own and operate. The grid is held constant so month-over-month numbers are directly comparable.
3 platforms × 3 service types × 3 sizes = 27 orders per month. With a 30-day rolling window we always have one full month of data plus the partial current month feeding the dashboard.
TTFD is measured directly from the same webhook events the order pipeline already emits for billing and refund logic — no separate stopwatch process. The pipeline records:
The 30-second polling cadence puts a floor on TTFD precision: any TTFD below 30 seconds is reported as “<30s” rather than a specific number, because we cannot distinguish 5 seconds from 25 seconds with this instrument.
Everything we publish on /buy-* is the median TTFD and the 90th-percentile completion time across the most recent 30 days of test orders. The targets we hold ourselves to:
Live current-month numbers are published on the status page and refresh on each completed test order.
Order-completion time has a long right tail. A single stalled batch can be 100× the median while every other order in the same hour completes normally. Averaging that into the headline number produces a misleadingly slow figure — and reporting only the median hides the fact that a slow tail exists.
P90 means “9 out of 10 orders complete in this time or less.” It is the number a buyer should actually plan around.
Related methodology
“Source: Likes.io Methodology — How we test delivery speed. URL: https://likes.io/methodology/delivery-speed”
Machine-readable copies of every methodology page are available at /llms.txt.