Scores are GEO-specific
The same bookmaker can score differently in different countries because legality, payments, competition set, and local product quality differ.
Jump to sectionPublic methodology
How R.org rates bookmakers and why the labels stay visible.
This page explains how GEO-specific scores work, how source and freshness labels should be read, what each block measures, and how missing data or low-confidence states are handled in public UI.
How to read R.org
The whole system should be understandable in under a minute.
This orientation layer exists so users can move from broad trust-verification into deeper methodology sections without drowning in formulas.
Source labels matter
Declared, tested, calculated, editorial, and user-generated signals stay visibly distinct across the product.
Jump to sectionFreshness stays visible
Important metrics show update or test timestamps so the system never pretends to be timeless.
Jump to sectionPartial data is explicit
Missing blocks do not become zero by default. Coverage thresholds decide whether a score is full, partial, or withheld.
Jump to sectionMethodology stays tied to live pages
Every section maps back to ranking pages, operator reviews, bonuses, complaints, and player-signal surfaces.
Jump to sectionGlobal Score
Global Score is one framework, but it is always calculated per GEO.
The same bookmaker can rank differently in different countries because the comparison set, payment methods, availability, and local product conditions are not identical across markets.
Line Quality
30%
Largest sportsbook-performance block in current GEO.
Payments
20%
Practical access and payout transparency matter heavily.
Bonuses
15%
Commercially important, but still secondary to core product quality.
Support
10%
Reachability and resolution quality remain visible.
Web UX
10%
Expert-reviewed web experience contributes materially.
Native App UX
5%
App quality matters, but does not dominate a web-strong operator.
Trust / Reliability
10%
Complaint handling and User Score add accountability.
Full score
Coverage >= 80%Enough weighted block coverage exists to show a normal Global Score without qualification.
Partial score
Coverage 50-79%A score is still shown, but with an explicit Partial data state because not all weighted blocks are present.
Insufficient data
Coverage < 50%The score is withheld instead of pretending weak evidence is a stable product truth.
Source labels and freshness
Interpretive labels belong in the product, so they must be explained clearly here.
The goal is not to create more jargon. It is to make sure users understand what kind of evidence they are reading before they trust a number or a verdict.
Declared
Value comes from operator-published information. It stays labeled as declared rather than being styled like direct test evidence.
Example
Declared withdrawal speed
First-party tested
R.org directly tested the signal through walkthrough or support interaction instead of relying only on operator claims.
Example
First-party tested response time
Calculated
The value is computed from normalized inputs inside the current GEO, not copied from a single operator claim.
Example
Calculated Global Score
Editorial
This layer reflects structured product interpretation where explanation matters more than pretending every judgment is raw telemetry.
Example
Editorial bonus interpretation
User-generated
The signal comes from players through approved reviews, comments, and complaint participation.
Example
User-generated review
Last updated
Used for declared and editorial content where the source value itself was refreshed.
Example
Last updated
Last tested
Used for first-party tested signals such as support response or UX walkthrough observations.
Example
Last tested
Calculated from latest available data
Used when a score or value is generated from current normalized inputs rather than one direct source entry.
Example
Calculated from latest available data
Methodology block
Bonuses
Bonus quality is judged inside bonus-category context, not by one fake universal formula.
Why it matters
A welcome bonus should not be scored with the same logic as cashback or acca boosts. Category-specific evaluation prevents misleading comparisons.
Main components
- Category-specific scoring logic
- Offer readability and key-condition visibility
- Eligibility and restrictions context
- Category-relative score interpretation
Source logic
Bonus pages mix declared operator data with editorial interpretation and visible freshness labels.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See a live bonus pageMethodology block
Line Quality
This block evaluates sportsbook strength from the market-quality perspective inside the current GEO.
Why it matters
It is the most sportsbook-native performance signal and therefore carries the highest weight in MVP.
Main components
- Margin Quality
- Coverage Depth
- Live Coverage
- Time-to-open
- Limit Quality
Source logic
Line Quality is calculated from GEO-relative comparisons and may include sport-specific trend context.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See line-quality heavy reviewMethodology block
Payments
Payments focuses on practical access, payout transparency, and method fit in the current GEO.
Why it matters
Users care more about understanding how money moves than about empty operator reassurance.
Main components
- Withdrawal speed — 40%
- Fees — 20%
- KYC impact on payout — 15%
- Payment method coverage by GEO — 15%
- Deposit speed — 5%
- Min/max limits — 5%
Source logic
Declared withdrawal speed and declared deposit speed remain visibly declared rather than being dressed up as first-party proof.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See a payments block in practiceMethodology block
Support
Support evaluates whether the operator can actually be reached and whether cases move forward meaningfully.
Why it matters
Support quality becomes trust-relevant once real users need help, especially during payout or verification friction.
Main components
- First response time — 35%
- Resolution time — 30%
- Available channels — 15%
- Support hours / availability — 10%
- Supported languages for current GEO — 10%
Source logic
Declared availability is separated from first-party tested response and resolution timing.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See a support-first reviewMethodology block
Web UX
Web UX explains how easy, clear, and stable the sportsbook feels in real use.
Why it matters
A sportsbook can look polished and still be high-friction. This block captures practical usability rather than marketing polish.
Main components
- Registration friction — 25%
- Navigation clarity — 20%
- KYC friction — 20%
- Bet slip / coupon usability — 20%
- Mobile web usability — 15%
Source logic
This is partly expert-review driven. Checklist and walkthrough evidence is normalized into rubric-based scoring.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See a web UX blockMethodology block
Native App UX
Native App UX evaluates availability and practical use of iOS and Android routes in the current GEO.
Why it matters
App quality matters, but an operator is not forced to zero if web quality remains strong and no native app exists.
Main components
- Native app availability — 20%
- App onboarding friction — 20%
- App navigation clarity — 20%
- Bet slip usability in app — 25%
- App stability / performance impression — 15%
Source logic
When no native app exists, the block remains visible as a no-app state and weight is redistributed instead of hard-zeroed.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See a no-availability edge caseMethodology block
Trust / Reliability
Trust tracks whether operator behavior still looks credible once player complaints and sentiment are visible.
Why it matters
This block makes the system accountable after the commercial click, not just before it.
Main components
- Complaint / dispute handling quality — 65%
- User Score — 35%
- License status shown as fact only
- Public complaint metrics: resolved, unresolved, ignored, median resolution time
Source logic
Trust mixes calculated complaint outcomes with user-generated sentiment, while license remains outside the numeric score.
Live product example
Methodology should feel tied to real UI rather than detached from the product.
See trust in practiceMissing data and confidence
Honesty about uncertainty makes the product stronger, not weaker.
This section explains why some scores show "Partial data", why some are withheld, and how unlike signals are normalized into a shared 0-100 system.
Normalization into 0-100
Every block score is normalized into 0-100 so the top-level score can combine unlike inputs without pretending they started on the same raw scale.
Declared and tested metrics are GEO-relative
Declared numeric metrics and first-party tested metrics are normalized inside the current GEO rather than compared globally in the abstract.
Checklist and expert-review logic
Rubric-driven metrics such as Web UX are converted into 0-100 through fixed scoring rules instead of vague hand-waving.
Low-sample handling
Low-sample metrics are confidence-downgraded or withheld rather than being styled like stable evidence.
FAQ
The last layer of trust is usually one more concrete question.
FAQ supports understanding and search depth without overwhelming the methodology sections above it.
Why can the same operator have different scores in different countries?
Because Global Score is GEO-specific. Payments, legal competitor set, availability, and local product conditions differ by market, so one static worldwide score would be misleading.
What is the difference between declared and tested data?
Declared data comes from operator-published information. First-party tested data comes from direct R.org walkthroughs or interactions. The page keeps those states visibly distinct.
What does Partial data mean?
It means enough data exists to show a score, but not enough weighted block coverage exists to present it like a fully-covered profile.
How do user reviews affect ratings?
User Score contributes inside Trust / Reliability, but it does not replace the main product-score logic. Low volume is labeled instead of hidden.
Why is license not part of the Trust / Reliability score?
License status is shown as a fact and affects availability and CTA handling, but it is intentionally kept outside the numeric trust score to avoid double-counting legal state as product quality.
How often is methodology updated?
Methodology is updated whenever scoring rules, source logic, or visibility rules materially change. The page itself carries a visible last-updated date for accountability.
See this in practice
Methodology should always map back to live product surfaces.
These links are there to bridge explanation and product use, not to act like disguised conversion traps.
See the live GEO ranking
Open the UK bookmaker ranking and map the methodology language to a real money page.
Open live pageSee a full operator review
Review pages show Global Score, User Score, block scores, labels, and trust signals together.
Open live pageSee a bonus page
Bonus pages keep offer analysis condition-first and visibly separate declared from tested logic.
Open live pageSee complaints and player voice
Open the complaint hub to see how case statuses, process logic, and private-vs-public boundaries are presented.
Open live page
Leave a comment
Logged-in users only
Alex from Manchester
34 likes
This page makes the difference between declared speed and tested speed much clearer than most affiliate products ever do.
R.org Editorial
18 likes
That separation is deliberate. If the source type changes how a user should interpret a number, it should be visible in the interface and here in methodology.
Discussion
Users can challenge the methodology instead of simply trusting it.
Comments on this page should stay especially calm and clarifying because the goal is interpretation, not noise.