Ranking parameters
Restaurant owners using Feasty have the right to understand how their venues are positioned on the map, in search results, and in matchmaker sessions. This document discloses all ranking parameters and their relative weights, in compliance with Article 5 of EU Regulation 2019/1150 (P2B).
1. Main ranking parameters
Every restaurant in the Feasty database has an aggregated bundle of signals. The algorithm combines them
multiplicatively with default sorting by quality (dominantTier) and distance (geohash query). All
fields are publicly accessible (except those marked server-only).
| Parameter | Role | Data source |
|---|---|---|
restaurantStats.dominantTier |
Primary quality signal | Weighted-mean tier with recency decay (Scoring v2 — see §2) |
restaurantStats.scoreNumericAvg |
Numeric 0–10 (B2B dashboard) | Recomputed by requestRestaurantScoreRefresh callable (every 7d / cron 30d) |
restaurantStats.ratingsCount |
Tie-break + Proof of Work cap (§3) | Public review counter |
| Geographic proximity | Hard filter (map, matchmaker) | Geohash query against restaurant lat/lng |
restaurantStats.trendingScore |
Recency boost | Time-decaying counter (proportional to fresh reviews) |
inMembersLists (matchmaker) |
Social signal boost | Query against lists of matchmaker session members |
restaurantStats.isPromoted |
Sponsored — separate bucket with "Ad" label | Requires b2bSettings.tier == 'premium' + active campaign in adPlacements/* |
1.1. "Discover" feed — ordering of user content
Since 24 August 2026 the "Discover" tab in the app is no longer a plain timeline: it orders user reviews with an automated formula. A review is about a specific restaurant, so the ordering indirectly affects that venue's visibility — which is why we disclose the parameters here alongside the others, even though what is ranked is user content, not the venue.
| Parameter | Nature | Weight |
|---|---|---|
| Author's relationship to the viewer | Primary signal | ×3.0 followed · ×1.6–2.0 followed by the viewer's followees · ×1.0 everyone else |
| Review tags someone the viewer follows | Signal from the viewer's graph | Relationship counted as at least ×2.0 when the author tagged someone the viewer follows — does not add up with the author's relationship (the higher of the two applies) |
| Review likes | Social signal | Multiplier (1 + like count) |
| Age of the post | Time decay | Divided by (age in hours + 2)^1.4 |
| Venue city matching the viewer's city | Local boost | ×1.3 |
isPromoted status or any other paid parameter —
sponsored content lives in a separate bucket labelled "Ad" (§4) and can never influence organic ordering.
Nor does it profile: the formula uses no browsing history, no dwell time and no model of the viewer's preferences.
The score is computed when the feed opens and is never stored.
The viewer can switch at any time to the "Trusted" tab, which shows only followed people in chronological order —
no ranking at all.
2. Review weights (Scoring v2)
Each review contributes to its tier bucket with a weight computed multiplicatively from the signals below.
Floor and ceiling are applied at the authorWeight level (0.3 – 2.0) and recencyMul
(floor 0.15).
| Signal | Multiplier value |
|---|---|
| Author account age | <7 days → ×0.6 · 7–30 days → ×0.85 · ≥30 days → ×1.0 |
| Author followers | 0 → ×0.8 · 1–9 → ×0.9 · ≥10 → ×1.0 |
| Author lifetime reviews | <5 → ×0.7 · 5–19 → ×0.85 · ≥20 → ×1.0 |
| Low-variance flag (author almost always same tier) | ×0.5 |
| Author prestige | Standard → ×1.0 · Elite → ×1.5 · Connoisseur → ×2.0 |
| Review age (180-day half-life) | max(0.15, 0.5 ^ (ageDays / 180)) |
3. Proof of Work cap (ratingsCount < 10 → tier capped at A)
Regardless of the average, a restaurant with fewer than 10 reviews cannot display as S or S+. The tier is capped at A until the threshold is exceeded.
Rationale: A single 5-star vote (even from a Connoisseur) should not elevate a venue to "elite" status. The tier must be earned through repeated agreement across many reviewers. This cap protects against manipulation and accidental over-promotion of newly opened venues without sufficient sample size.
4. Sponsored — labelling and placement
Every restaurant displayed with isPromoted == true carries a mandatory "Ad" label
visible in the first frame. The label is uniform across the entire application — we do not use variants like
"Promoted", "Featured", "Top choice" or other ambiguous forms.
- Visually: sponsored entries appear in a separate section or in the first viewport position, never "mixed in" with organic results without a label.
- Opt-out: users can disable sponsored results in settings (
users/{uid}.uiPrefs.hidePromoted). Once disabled, queries skipisPromoted == true. - Audit trail: all campaigns are logged in the
adPlacements/*collection with 6-year retention (Polish commercial-claims limitation period).
Legal basis: P2B Art. 5(2) (EU 2019/1150) + DSA Art. 26 (Digital Services Act).
5. Algorithm change procedure (15-day notice)
Any material change to ranking parameters or their weights MUST be announced at least 15 days in advance of deployment, per P2B Art. 3(2).
Technical mechanism: configuration config/rankingAlgorithm.{version, activeFrom, params} with a
server-side cron that respects activeFrom. Restaurant owners receive:
- In-app notification in the B2B panel (
https://business.feasty.com.pl) — "Announcements" section - Email with 15-day notice to the account owner's address
- Update of this page with the new version (changelog below) and effective date
Version changelog
| Version | Active since | Main changes |
|---|---|---|
v2.0 |
15 September 2026 | Description correction, ranking unchanged: removed the ×1.2 “verified visit” factor — nothing ever recorded a verification method, so it never applied; corrected the basis of the 15-day notice (P2B Art. 3(2)) and the appeal channel (restaurant panel). |
v2.0 |
17 May 2026 | Scoring v2 launch — recency × authorWeight × tierToScore (180-day half-life), Prestige multipliers (Elite ×1.5 / Connoisseur ×2.0), verified visit ×1.2. PoW cap moved to applyProofOfWorkCap. Closed-beta MVP exemption: 15-day notice skipped because zero live B2B users at launch. |
v1.0 |
March 2026 | Initial release — modal dominant tier + ratingsCount counter + geohash distance. |
6. Anti-manipulation
The algorithm is protected by multiple layers of anti-manipulation mechanisms:
- Rate limits on reviews per user (daily / weekly / monthly cap)
- Tier distribution caps per user (max 20% S+, max 40% S+S combined — you cannot "give out" only top scores)
- Low-variance flag reduces the weight of authors who almost always rate at the same tier (×0.5)
- Server-only
authorWeight— value is invisible to client and to the reviewer - Prestige from cyclical cron — author tier cannot be "purchased"; it is a function of review history
- Flagged review exclusion — moderation-flagged reviews (DSA Art. 17) do not contribute
- Deterministic review IDs (
${uid}_${placeId}) — one user = one review per venue
7. Appeals (DSA Art. 20)
Restaurant owners have the right to appeal any algorithmic decision that negatively affects venue visibility (e.g. tier downgrade, hiding, B2B suspension).
- Internal procedure: account suspension — appeal in the restaurant panel (“Appeal” tab), answer within 14 days; other matters — contact@feasty.com.pl
- Mediators (P2B Art. 12 — at least two outside the court):
- Mediation Centre of the Court of Arbitration at UOKiK (Warsaw, Plac Powstańców Warszawy 1)
- Court of Arbitration at the Polish Chamber of Commerce (Warsaw)
- Competent court: court with territorial jurisdiction over the defendant's seat (Operator: Poland)