Publishing principles
How PanelCompare ranks SMM panels
Every number below is rendered from src/lib/scoring.ts — the same file the ranking pipeline runs. The page cannot drift from the formula, because it is calling it.
Last updated by The PanelCompare editorial team
Does paying PanelCompare change a panel’s position?
No. Affiliate status, sponsorship and paid placement appear nowhere in the ranking formula, and this is checkable rather than assertable: the whole formula is one file, and it contains no field describing a commercial relationship. The database does carry an is_affiliate flag and an is_sponsored flag — the first decides whether an outbound link carries rel="sponsored" and a visible partner tag, the second decides whether a panel appears in a slot labelled Sponsored, outside the ranking. Neither is read by the scoring code.
What we can be paid for is listed on the disclosure page, including which specific outbound links are monetised today.
What goes into the overall score?
Five components, weighted. Price and trust carry 60% between them because those are the two questions a buyer is actually asking: can I afford it, and will it deliver. Support carries the least because a chat widget is easy to install and hard to verify. The weights below are read from the exported OVERALL_WEIGHTS constant at render time.
| Component | Weight | Scale | What it measures |
|---|---|---|---|
| Price | 30% | 0–10 | Median of this panel’s per-service price ratios against the market median for each service. |
| Trust | 30% | 0–100, rescaled to 0–10 | The itemised trust score below. Every input is an observation, not an opinion. |
| Features | 18% | 0–10 | Capability flags weighted by what it costs a buyer when each one is missing, plus catalogue breadth. |
| Reliability | 14% | 0–10 | Uptime over the last 30 days, with response time as a tiebreaker. |
| Support | 8% | 0–10 | Published channels, overridden by buyer ratings of support wherever we have at least three. |
| Total | 100% | ||
Source: OVERALL_WEIGHTS in src/lib/scoring.ts, read at build time. The headline score is rounded to one decimal place.
How is the trust score calculated?
Trust is 100 points across 6 components, then a penalty for unanswered complaints applied after the sum. The weights answer one question: how much would it cost an adversary to fake this signal? Domain age and a completed test purchase are expensive to fake. A TLS certificate is free, so it is worth nothing here and is not a component at all.
| Component | Max | What is measured | Why it is weighted this way |
|---|---|---|---|
| Domain age | 20 | Registration date from RDAP/WHOIS, scored on a square-root curve that reaches full marks at five years. | Age cannot be bought retroactively, so it is the strongest defence against a panel that exits and reopens under a new name — and it exposes a “since 2014” footer on a domain registered last year. |
| Uptime, last 30 days | 25 | Successful HTTP and API probes as a share of all probes over the last 30 days, weighted by how many probes we have. | It is the only component we generate continuously ourselves, and a collapse in availability is the earliest observable signal of a provider failure or an exit. |
| Catalogue freshness | 10 | How recently this panel’s catalogue synced successfully into our index. | A catalogue we cannot re-read is a catalogue whose prices we cannot stand behind. Staleness costs points even when the panel itself is fine. |
| Verified buyer reviews | 20 | Volume and average rating of reviews where a moderator saw proof of purchase. Volume saturates around 50 reviews. | Both halves matter: five glowing reviews are weaker evidence than eighty mixed ones, so the score multiplies quality by volume rather than averaging stars. |
| Verification | 15 | Ten points where we placed a real order and it delivered; five where the owner proved control of the domain. | A completed test purchase is the only signal here we generate ourselves against a panel that has an incentive to look good, which is why it carries the most weight in this component. |
| Published policies | 10 | Published terms (3), a published refund policy (4) and a reachable support channel (3). | Cheap to satisfy and cheap to fake, so it is worth little — but a panel with no published terms and no reachable support has told you something. |
| Total | 100 | ||
Source: component maxima read from computeTrust() in src/lib/scoring.ts at build time.
What does an unanswered complaint cost a panel?
The penalty is applied after the component sum, so it can pull a panel below any score its other signals earned. Only published complaints with no owner response count: a report the owner has answered on the record is a disagreement, not evidence, and a panel that verifies domain ownership can always reply. The curve is logarithmic and capped, because the tenth complaint tells you far less than the first.
| Unanswered complaints | Points deducted |
|---|---|
| 1 | −12.0 |
| 2 | −16.7 |
| 3 | −20.0 |
| 5 | −24.7 |
| 10 | −31.7 |
| 25 | −35.0 |
Source: computeTrust() evaluated at each complaint count. The deduction is capped at 35 points.
What do the trust bands mean?
The bands are defined once, in trustBand(), and are the same everywhere they appear: 80 and above is high trust, 62–79 established, 42–61 limited history, below 42 unproven. A new panel is unproven by construction, and that is a statement about our evidence rather than about the panel.
How is the price score calculated?
For every service a panel actually sells, we take its price as a ratio of the market median for that same canonical service, then take the median of those ratios. A ratio of 0.5 — half the market — scores 10. A ratio of 1.0 scores 5. A ratio of 2.0 scores 0. The score is computed only where a panel competes, so a narrow catalogue is neither rewarded nor punished for the services it does not carry.
| Median ratio to market | Reads as | Price score |
|---|---|---|
| 0.40× | 60% below the market median | 10.0 |
| 0.50× | 50% below the market median | 10.0 |
| 0.75× | 25% below the market median | 7.1 |
| 1.00× | At the market median | 5.0 |
| 1.50× | 50% above the market median | 2.1 |
| 2.00× | 100% above the market median | 0.0 |
Source: computePriceScore() evaluated against a synthetic three-service catalogue at each ratio.
Why the median of ratios rather than a comparison of averages?
Because comparing average prices measures a catalogue’s composition rather than its pricing. A panel that lists only the two cheapest categories on the market — Instagram likes and TikTok views, both priced in fractions of a cent — has a low average price and tells you nothing about what its followers or watch hours cost. Taking each service as a ratio against that service’s own market median removes the composition entirely: every row is compared only with its like, and the median of those ratios is unmoved by one outlier row.
This matters more here than in most markets, because several of these markets are bimodal. YouTube subscribers have a bot tier at $0.02–$0.72 that describes itself as high-drop with no refill, and a real refill-guaranteed tier clearing near $14.40, with nothing meaningful in between (PanelCompare domain research, 6 September 2026). A mean across those two tiers describes nothing anyone can buy.
Two guards sit on the calculation. Ratios outside 0.02× and 20× are dropped as data errors or bespoke services rather than price signals — a service priced at a hundred times the market is usually a different product wearing the same name. And a panel with fewer than three comparable services scores a neutral 5 rather than a flattering 10, because three rows are not a price policy.
How are features, reliability and support scored?
Feature weights reflect what it costs a buyer when a capability is missing, not how impressive it sounds. A refill guarantee protects the purchase itself; an auto-subscription saves clicks. The weights below are measured by flipping one flag at a time against a zeroed input set and reading the difference, so they are the code’s weights rather than a description of them.
| Capability | Points | Why |
|---|---|---|
| Refill guarantee | 1.60 | The only durability promise with a mechanism behind it. |
| Public API | 1.30 | Required for automation, and independently verifiable. |
| Drip-feed | 1.20 | Pacing control on large orders. |
| Cancel button | 1.10 | The only post-order control a buyer has. |
| Geo-targeting | 0.90 | The largest price driver in any catalogue. |
| Child panels | 0.80 | Matters to resellers, not to end buyers. |
| Mass order | 0.60 | Bulk submission without the API. |
| Subscriptions | 0.50 | Convenience, not protection. |
| Free balance | 0.50 | Lets a buyer test delivery before depositing. |
| Catalogue size (full marks at 10,000 services) | 0.70 | Log-scaled: the step from 50 to 500 services matters, the step from 5,000 to 50,000 does not. |
| Payment methods (full marks at 8 or more) | 0.40 | Rail diversity is a recovery path, not a convenience. |
| Platforms covered (full marks at 15 or more) | 0.40 | Breadth of supply relationships, inferred from the synced catalogue. |
| Refill window bonus | 0.30 / 0.45 / 0.50 | At 30d / 90d / 365d. The curve flattens hard past 90 days because long and lifetime windows are frequently unhonoured in practice. |
Source: computeFeatureScore() evaluated one flag at a time. The final score is clamped to 10, so a panel with every capability does not exceed the scale.
What does uptime score?
Uptime is squared before scaling, which makes the difference between 99% and 95% much larger than the difference between 80% and 76% — because at the top of the range availability is the product, and at the bottom the panel is already unusable. Response time is a tiebreaker worth 1.5 points at most: a panel that is up but slow still takes your order. Below five probes in 30 days we do not score the component at all.
| 30-day uptime | Reliability score |
|---|---|
| 100% | 9.85 |
| 99% | 9.68 |
| 95% | 9.02 |
| 90% | 8.24 |
| 80% | 6.79 |
Source: computeReliabilityScore() at 60 probes and an 800 ms average response.
What does support score?
Published channels set a floor, and buyer ratings override it. Where at least three verified reviewers have rated support directly, that evidence is worth 65% of the component and the presence of a chat widget only 35% — because a widget is a purchase and a response is a behaviour.
| Support setup | Score |
|---|---|
| No published channel | 3.00 |
| Ticket system only | 5.00 |
| Live chat only | 5.50 |
| Both channels | 7.50 |
| Both, and buyers rate support 4.5/5 | 8.31 |
Source: computeSupportScore() at each combination.
What does the arithmetic look like on a real panel?
The example below is whichever panel currently ranks first, chosen by the ranking itself rather than by us, and every figure is read live from the index. Its five part scores go into the weighted sum; the result is the number shown on PanelFollows’s page.
- Panel
- PanelFollows
- Trust
- 39.5 / 100
- Overall
- 5.0 / 10
panelfollows.com
Unproven
Recomputed on this page: 5.0
Step 1 — the itemised trust score
| Component | Points | Max | What we observed |
|---|---|---|---|
| Domain age | 10.0 | 20 | WHOIS lookup pending — scored neutrally until we have a date. |
| Uptime, last 30 days | 12.5 | 25 | Only 0 checks so far — not enough to score. |
| Catalogue freshness | 10.0 | 10 | Prices synced within the last 24 hours. |
| Verified buyer reviews | 7.0 | 20 | No verified reviews yet. Scored below neutral, since an unreviewed panel is unproven. |
| Verification | 0.0 | 15 | Not independently verified yet. |
| Published policies | 0.0 | 10 | Missing at least one of: terms, refund policy, reachable support. |
| Trust score | 39.5 | 100 |
Source: the stored trust_breakdown for panelfollows.com, written by the same computeTrust() whose maxima are tabulated above. Last updated Sep 7, 2026.
Step 2 — the price score, and what an average would have said instead
PanelFollows currently has fewer than three services with a market median to compare against, so its price score is the neutral 5 rather than a measured figure. That is the intended behaviour: a thin sample is not a price policy.
Step 3 — the weighted sum
| Component | Score | Weight | Contribution |
|---|---|---|---|
| Price | 5.0 | × 0.30 | 1.500 |
| Trust | 39.5 → 3.95 | × 0.30 | 1.185 |
| Features | 7.6 | × 0.18 | 1.368 |
| Reliability | 5.0 | × 0.14 | 0.700 |
| Support | 3.0 | × 0.08 | 0.240 |
| Overall, rounded to one decimal | 5.0 | ||
Source: the five stored part-scores for panelfollows.com, run back through computeOverall() on this page. The stored headline is 5.0; if these two numbers ever disagree, the index is stale and that is a bug worth reporting.
What happens to a panel we have not measured yet?
Missing data lowers confidence, not the score. Where we have no observation for a component, the panel is awarded that component’s neutral share and the interface says the component is unmeasured. Punishing an unknown would make the ranking track how long we have been watching a panel rather than how good the panel is — which would quietly favour incumbents and disadvantage every new entrant.
Two components deviate from that rule deliberately. A panel with no verified reviews scores below neutral, because an unreviewed panel is genuinely unproven and the alternative would let a brand-new panel share a score with one that has eighty verified purchases behind it. A panel we have never synced scores zero on catalogue freshness, because in that case the prices on its page are hand-entered rather than live, and we would rather say so in the score than only in a footnote.
Thin samples are pulled toward neutral rather than treated as certainty. Three successful probes is not evidence of reliability, so the uptime component is confidence-weighted by probe count and only scored at all above five probes in 30 days.
What does this score not measure?
Stating the gaps is part of the methodology, because a score that implies more than it measures is worse than no score. These are the things we do not currently know, and would have to build a measurement programme to learn.
- Whether refills are actually honoured. We score the advertised refill window, not observed honouring. Measuring the real thing needs a test-order programme or structured dispute intake, and until it exists the refill-window figures we publish are labelled as an industry estimate.
- Real drop rates and delivery times. Advertised start-time bands are averages a panel computes itself from recent orders, and they are frequently gamed. We record them as claims, not measurements.
- Delivered quality. No comparison site can inspect the accounts a panel sends. Quality tiers in our data are the panel’s own labels, normalised — not verified.
- Common ownership, in full. We can infer clone pairs from shared copy, assets, registrant data and payment endpoints, and we disclose what we find — but an operator who separates those signals properly will not be detected.
When does a score change?
When an observation changes. Scores are never edited by hand, and there is no override field in the schema for a human to reach for. What varies is how quickly a change reaches the page, which is set by each route’s revalidation window.
| Page type | Refreshes at most every |
|---|---|
| Price tables and service pages | 30 minutes |
| Panel profiles and best-of lists | 6 hours |
| Editorial pages, including this one | 1 day |
| Legal and policy pages | 7 days |
Source: the REVALIDATE constants in src/lib/site.config.ts.
Questions about the formula
Can a panel pay to rank higher on PanelCompare?
No. The ranking formula lives in one file, src/lib/scoring.ts, and it takes no input describing affiliate status, sponsorship or payment. Sponsored slots exist, are labelled Sponsored, and sit outside the ranking rather than inside it.
What happens to a panel we have not measured yet?
Missing data lowers confidence, not the score. An unprobed component is awarded its neutral share and labelled unmeasured, because punishing an unknown would make the ranking track how long we have been watching a panel rather than how good the panel is.
Why is the price score a median of ratios rather than a comparison of average prices?
Because averaging lets a panel score well by listing only the two cheapest categories on the market. Taking each service as a ratio to that service’s market median, then taking the median of those ratios, measures a panel only where it actually competes.
How often do scores change?
Price tables revalidate at most every 30 minutes, panel profiles every 6 hours, and this page every 1 day. A score moves when an underlying observation moves — a new probe, a fresh catalogue sync, an approved review — never by hand.
Think a number here is wrong?
Every figure on PanelCompare carries the date it was captured, and every one of them can be challenged with evidence. The process, including what counts as evidence and how long a correction takes, is written out on the about page. Panel owners can also reply on the record to any complaint published against them.