Key Takeaways
- A rating is not decoration on a profile, it is a field inside the search index and a boundary inside a filter, so a manipulated rating is a manipulated search result.
- Bought reviews are caught by scoring the authors, while review bombing is only visible from the target side, which is why one filter for both always fails.
- Requiring a completed order before a review is the strongest control available, and it costs you review volume that a young catalogue cannot easily spare.
- Rating extortion has no reliable model behind it, so the real control is a structured report field and a human who reads it inside a published window.
- If a restaurant can buy its way to the top of a category without buying an ad, your advertising inventory stops being worth anything.
- Account takeover on an owner login does more damage than a fake review, because whoever holds it can change a price, pull a dish and reply in the restaurant’s own voice.
- Location history and saved addresses are the most sensitive data the app holds and the least examined, so the retention period has to be a decision rather than a default.
Review Integrity Readiness
- Cap how fast any single listing’s displayed rating can move, before you build any classifier.
- Weight each review by its author’s verified order history instead of deleting suspicious ones.
- Freeze a rating under attack and notify the restaurant, rather than removing reviews.
- Publish an appeal route with a stated timescale and answer every appeal, including refusals.
- Log every review state transition with the listing average before and after each change.
Real Insights
- Review integrity belongs with search and ranking in your org chart, not with the profanity filter, because ranking is what it modifies.
- Reversible actions like holding and freezing can be automated hard; deleting a review and suspending a listing need a person and a record.
- Perceptual hashing every image upload against your own catalogue stops stolen listing photos outright and almost nobody does it.
- Owner responses are a genuine trust feature and a channel from a business to a named customer, so constrain the field before you ship it.
- Miracuves ships these controls inside the review and ranking layer of a ready-made restaurant discovery app, deployable in 6 days for eligible ready-made scopes.
On a Tuesday morning the owner of a 40-seat kebab house opens the partner dashboard and the number under the listing reads 3.9. On Monday it read 4.4. Nothing changed in the kitchen and nobody complained on the phone.
By Thursday orders are down by about a fifth. Not because customers read the new reviews and were put off, but because the listing fell out of the four-star-and-above filter half the neighbourhood browses with. A listing outside a filter is a listing nobody sees.
Eleven one-star reviews landed inside six hours. Nine of those accounts were created that week and none had ordered. The owner now writes a ticket into a queue with a seven-day response time, and by the time a human reads it the damage is a month old. This article is about the controls that stop that story, the ones that only look like they do, and the honest limits of all of them. It then covers the rest of the security surface a food delivery and restaurant discovery app carries: account takeover, payment and refund abuse, who may change what, and the customer data you are holding.
Zomato sells discovery, which makes every rating on it a ranking input and therefore a target.
A Rating Is a Search Result, Not a Decoration
On a platform like Zomato a manipulated star is a manipulated search result, not a cosmetic problem.
Most teams file reviews under content moderation. That is the mistake. On a food delivery and restaurant discovery app the rating is not a label on a listing. It is a field in the search index, a boundary in a filter, a term in the feed ranking function.
Image Source: AI-generated visual by Miracuves
Where the number actually lives
Trace one rating and you find it in four places: on the listing document the search engine queries, behind the “4.0+” toggle users tap without thinking, in the sort order when somebody chooses top rated over nearest, and usually in the home feed, because no operator curating a feed puts a poorly rated kitchen in the first row.
So a manipulated rating is a manipulated search result, and search results are the inventory you sell. The two revenue engines running on one audience both need the ordering of listings to be defensible. Commission needs orders reaching the right kitchens. Advertising needs position scarce enough to charge for.
Why the moderation framing understates it
A moderation problem is about what users see. A security problem is about an untrusted party changing a value the business depends on. Reviews are the second thing. Anyone with a phone number can write into your ranking function, and nothing about the write looks unauthorized.
Account security, payment fraud, cash handling and courier location data are a separate discipline with their own article on this blog. This one is about the surface only a restaurant discovery and delivery app has: the content deciding who gets found.
Bought Reviews and the Shape They Leave
A new listing appears on Monday. By Friday it carries twenty reviews, all five stars, all written in confident generic prose about fresh ingredients and warm staff. It now outranks a kitchen that spent two years quietly earning 4.3. No single review there is suspicious; each one passes any filter. The pattern is only visible across the set, which is the first design rule: score cohorts, not documents.
Account age and order history
The strongest single signal is boring. How old is the account, and what has it done besides write this review? An account created eleven days ago whose only act is one five-star review is not a customer. It is a pen.
Weight the review by what its author has actually done rather than deleting it. A reviewer with nine completed orders across four listings should move a rating far more than one with none. That is a weighting decision inside the ranking function, and it beats a delete rule because the attacker learns nothing about which accounts were caught.
Velocity against the listing’s own baseline
Absolute thresholds fail immediately. Five reviews in a day is unremarkable for a busy city-centre listing and impossible for a suburban one averaging three a month. The only useful velocity signal is relative: this week against the listing’s own trailing average, adjusted for order volume.
Reviews arriving faster than orders is the sharpest version. Nineteen orders and twenty-two reviews in a week is an arithmetic problem, and arithmetic is cheap to compute nightly across a catalogue.
Device and network clustering
Review farms are a workflow, and workflows leave a fingerprint. Accounts sharing a device identifier, several writing from one network in a short window, sessions that begin on the listing page rather than through search. None is proof, because families share phones and office networks carry genuine users by the hundred. Treat clustering as a multiplier on other signals, never a rule of its own.
Text similarity, and its decline
Cheap farms reuse phrasing, and near-duplicate detection across a listing’s review set catches that in one pass. Expensive ones generate each review separately and the signal returns nothing.
Be honest about this one. Text analysis is what founders reach for first because it feels like the clever part, and it has degraded fastest. Account history and order linkage have not, because faking those costs real money.
Review Bombing Is a Volume Problem, Not a Content Problem
A restaurant appears in a local argument. Within two hours it has sixty one-star reviews from real, unfaked accounts expressing a genuine if unrelated opinion. Content moderation is useless here, because every individual review is within policy.
This distinction decides whether a review system works. Bought positives are caught by looking at the authors, who are manufactured. Bombing is caught by looking at the target, because its authors are ordinary people acting once. Nearly every failed system applied author-side logic to a target-side attack.
Rate limit by target, not by author
Author-side rate limits are the reflex and they do nothing, because sixty people writing one review each break no per-author limit. The control that works is a ceiling on how fast one listing’s displayed rating may move, whoever is writing.
Concretely: cap how many new reviews can influence a listing’s public average inside a rolling window and hold the surplus pending. Nothing is lost and nobody is accused. They simply do not all land at once.
Freeze, do not delete
When a listing crosses its ceiling, freeze the displayed average at its pre-spike value and flag it for a human. Do not start deleting. Deletion is irreversible, invites accusations of censorship, and is exactly wrong if the spike turns out to be a real food safety incident with fifty genuinely unhappy customers. A freeze buys time for somebody to look, and the worst case becomes a rating stale for a day rather than wrong for a quarter.
Then tell the restaurant. A freeze the owner cannot see is indistinguishable from doing nothing, and one notification saying the pattern was caught and a reviewer is looking buys more goodwill than most retention features in the partner-facing feature set.
Rating Extortion and What the Platform Owes
The pattern is simple and old. A one-star review appears. Shortly afterwards the owner receives a message on a channel outside the platform offering to remove it for money, a free meal or a standing discount. Sometimes the same author works an entire street.
Only the platform can act
The restaurant cannot remove the review. The reviewer will not unless paid. The scheme works because the platform made itself the only party with the delete key and then made that key unreachable. Every hour your appeal route stays closed improves the extortionist’s economics.
You are also the only party who sees the pattern across listings. One owner sees a single hostile reviewer. You see one account hitting nine kitchens within a mile, six of which then reported contact. That view exists only if reports are structured data rather than support email.
The control is a human who reads
No model reliably detects extortion, because it happens off-platform and the artefact you hold is an ordinary negative review. What detects it is an owner telling you through a route designed to be used, and a person reading that message inside a defined window.
Give the report form a field for “I was contacted about this review” and an upload for the screenshot. That field turns a complaint into a queryable signal, and it is the cheapest anti-extortion control you will build.
Verified-Order-Only Reviews: The Strongest Control, and Its Price
Requiring a completed order before a review can be written is the single most effective control here. It filters nothing. It raises the price of a review from zero to the cost of a meal, and almost every manipulation economy collapses once the unit cost stops being zero.
What it actually costs you
Review volume falls, and it falls hard. Browsing outnumbers ordering by a wide margin, so the gap between people with an opinion and people with a receipt is enormous. Dine-in customers who found you through search and walked in cannot review. Neither can the person who ordered by phone.
For a new platform that shortage is existential. Listings with three reviews do not convert, and a catalogue of them does not look worth browsing. This is a genuine trade, not a best practice you failed to follow, and it sits inside the wider problem of How to Keep Restaurants, Riders, and Customers Happy Simultaneously.
The version most platforms should ship
Accept both kinds, weight them differently, label them differently. A review linked to a completed order carries a visible marker and full weight. An unlinked one stays published and visible at a reduced weight, or in a tab that does not feed the numeric average at all.
That keeps the volume that makes a catalogue browsable and the number that feeds search honest. It also gives a clean escalation: when a listing is under attack, restrict its rating input to verified orders, which ends a bombing campaign in minutes without deleting a single review.
Decide the verification levels before you build the schema. Retrofitting one onto a table of two hundred thousand rows means backfilling a value you can no longer determine, and dine-in is where coverage is always thinnest.
Incentivized Reviews: Real Customers, Compromised Signal
A card goes into every delivery bag. Leave us five stars, show the staff next visit, take ten percent off. Customer real, order real, meal possibly excellent. The rating is worthless anyway, because it now measures who is running a promotion rather than who is cooking well.
Why detection is weak here
Every signal from the previous section returns clean: aged accounts, real order history, varied devices, natural text, normal velocity. The only tell is distributional, a listing whose ratings are almost entirely fives with almost no fours against a category baseline where fours are common.
That tell is weak alone, because an excellent small kitchen produces the same distribution. Use it to prioritize a look, never to act. Anything stronger punishes your best listings first, the worst outcome for a platform that needs those restaurants to stay.
Policy beats detection
Write the rule plainly in the partner agreement: no consideration of any kind in exchange for a rating. Give it a stated consequence, run it complaint-driven rather than surveillance-driven, and act visibly when a customer reports a card in the bag.
There is a legitimate version worth explaining, because most owners are not trying to cheat. Asking every customer for a review is fine. Asking only the happy ones is not. Attaching anything of value to the star count is not. The line runs between soliciting feedback and buying one.
Founder Decision Signals
Speed
A velocity ceiling on each listing’s displayed rating is a few hours of work and stops the worst single-day damage. Ship it before any classifier.
Cost
The expensive part is never the model. It is the person who reads appeals. Budget reviewer hours per thousand listings like support headcount, and expect photos to consume more than text.
Scalability
Author-side signals scale automatically. Human appeals do not. Design the queue so a person only sees genuine ambiguity, or moderation cost grows faster than your catalogue.
Market Fit
Restaurants choose platforms partly on whether a bad review can be disputed. An appeal route with a published timescale is a partner acquisition feature, not an overhead line.
Photo Integrity Is the Half Nobody Budgets For
Photographs do more conversion work than text on a discovery surface, and they are the part of a listing most likely to be wrong. Three failure modes cover nearly all of it, and each needs a different response.
Image Source: AI-generated visual by Miracuves
Stock photography passed off as the kitchen’s own
A listing uploads a studio shot of a burger never made in that kitchen. The customer orders it, receives something visibly different, and complains as a refund request rather than a photo report. You pay twice, in the refund and in the churn. Studio lighting on a seamless background, stock-library dimensions and absent camera metadata are weak indicators that cluster usefully here.
Photos stolen from another listing
This one is fully solvable and most platforms do not do it. Hash every upload perceptually and compare it against every image in your catalogue, including ones you previously removed. Four images matching a competitor two streets away is not a judgement call. It is a match, and it should block the upload.
Images that are not food
Customer uploads bring everything: a screenshot of the receipt, a picture of the street, a pet, occasionally something harmful. A category classifier handles the bulk cheaply, and this is the one place in review integrity where automation beats a person outright.
Route confident rejections straight through and send the rest to a person. The unsure bucket will be larger than the demo suggested.
Designing the Moderation Queue So It Does Not Drown
Every platform ships a single flat queue and every one is six weeks deep within a year. A queue is not a list of things to look at. It is a scheduling problem.
Order by damage, not by arrival
A flagged review on a listing taking two hundred orders a week deserves attention before one on a listing taking four. A rating near a filter boundary matters more than one in the middle, because a tenth of a point at 4.0 changes visibility and a tenth at 4.6 does not. Score each item by the revenue and visibility at stake, then sort on that.
What automation is allowed to do alone
Draw the line and write it down. Automation may block a hash-matched image, reject a non-food photo above a confidence threshold, hold a review pending and freeze a rating. It may not permanently delete a review or suspend a listing.
The reason is asymmetry of error. A wrongly held review costs a day. A wrongly deleted one costs a relationship and a story that travels. Automate reversible actions aggressively; irreversible ones need a person and a record. The same economics drive The Out-of-Stock Trap: Why Cheap Delivery Scripts Ruin Restaurant Relationships.
The Appeal Loop: Route, Timescale, Outcome
A restaurant disputing a review needs three things and most platforms provide none. A route that is obviously where disputes go. A timescale stated before they submit. An outcome with a reason, including when the answer is no.
Where the dispute goes if you do not build one
It does not disappear. It arrives as a chargeback against the commission, a public post naming your platform, or a quiet decision to favour a competitor’s tablet at dinner. Each costs more than a moderation review would have.
Restaurants run on single-digit margins, and a rating drop hits revenue directly. They escalate through whatever channel exists, and the one you did not design is always the expensive one.
A refusal delivered well is an acceptable outcome
Most appeals should fail. The review is usually genuine and the owner unhappy about its content rather than its legitimacy. A rejection with a one-line reason inside the stated window still beats silence.
What destroys the relationship is not losing. It is submitting into a void and watching the rating stay wrong while nobody answers. Cap it at one appeal per review, with a second level only on new evidence, or a handful of owners who appeal everything will run a denial-of-service on your team.
Owner Responses: A Trust Feature With a Sharp Edge
Letting a restaurant reply publicly is one of the highest-value, lowest-cost features on a restaurant discovery app. A measured reply to a two-star review often reads better than the four-star reviews above it.
The abuse vector it opens
The reply field is a channel from a business to a named customer, and it gets used as one. Replies that identify the customer, disclose the address or invite the reviewer to continue privately are all common, and the last is how off-platform retaliation begins.
Constrain the field. One reply per review, a character limit, no contact details, no links, a scan for anything resembling a phone number or address. Dull constraints that prevent a genuinely serious category of incident.
Not a substitute for appeals
Some platforms ship owner responses and treat the dispute problem as solved. A reply under a fraudulent one-star review does not remove its effect on search position, and the owner knows it. The response addresses the reader. The appeal route addresses the number. You need both.
Ranking Integrity Is What All of This Protects
Step back from the individual controls and the business case is simple. A food discovery app sells placement: featured slots, category sponsorship, priority in a filtered list. That inventory has a price because position is scarce and unobtainable any other way.
Free manipulation destroys paid placement
If a restaurant reaches the top of a category for the cost of forty bought reviews, it will never buy an ad. The advertising line does not decline gradually. It stops working, because what you sell is available cheaper through the side door.
This is why review integrity belongs in the revenue conversation rather than the trust and safety one. Two of the revenue lines on a restaurant discovery and delivery app earn without an order being placed, and both are priced off the assumption that organic position is hard to obtain.
The conflict you have to declare
You own the ranking and sell placement inside it, so you have an obvious conflict of interest and the market knows it. The workable answer is separation and labelling: paid placement is visually distinct, bounded in slot count, and does not alter the organic ordering beneath it.
The unworkable answer is quietly blending paid and organic. It converts better for two quarters and worse forever after, because users learn the top of your list is not an answer to their question. Work both models against the platform you actually plan to operate before the first advertiser signs.
Treating reviews as a moderation feature
Filed next to profanity filtering, review integrity gets a support intern and no engineering time. It belongs with search and ranking, because ranking is what it modifies.
Deleting instead of holding
Deletion is irreversible and catastrophic when a spike turns out to be a genuine food safety incident. Holding a review pending costs a day and keeps every option open.
Rate limiting authors instead of targets
Sixty people writing one review each break no per-author limit. Bombing is only visible from the target’s side, and a ceiling on how fast one listing’s rating moves is the control that fires.
Launching without an appeal route
The dispute does not vanish because you gave it nowhere to go. It reappears as a chargeback, a public complaint, or a kitchen quietly favouring a competitor’s tablet.
Retrofitting order verification
Adding a verification level to a table of hundreds of thousands of rows means backfilling a value you can no longer determine. Decide the schema before launch, even if you enforce it loosely.
Skipping perceptual hashing on images
Photos stolen from another listing are fully detectable with a hash comparison against your own catalogue. Skip it and you handle the same complaint manually for years.
What to Log So a Rating Can Be Reconstructed Months Later
A restaurant will come back in March asking why its rating moved in November. If all you hold is a current average and the visible reviews, you cannot answer. The interesting part is what was removed, held or reweighted, and none of that is in the current state.
The record that makes the answer possible
Log every state transition on a review rather than its current state: created, published, held, released, removed, restored, appealed, upheld, overturned. Each entry carries a timestamp, the actor, whether that actor was a rule or a person, the rule identifier, and the listing’s computed average before and after.
That last field is the one teams leave out and the one that answers the question. With it, the March conversation takes four minutes. Without it, it takes a database archaeologist and produces a guess.
Keep the trail out of reach of the thing it describes
Reviews live in a table that gets updated. The audit trail must be append-only and must not share a deletion path with them. A moderator action that removes a review and its own history is not an audit trail. It is a shredder with a log-shaped interface.
Store the daily computed rating per listing alongside the version of the weighting function that produced it. Functions change, and recomputing a historical average with today’s weights gives a number nobody was ever shown. That series answers the hardest question an owner asks, which is whether your algorithm change moved their number rather than anything they did. Owning the store you query is the broader argument in Migrating from SaaS to Owned Infrastructure: A Peak-Hour Performance Comparison.
Four Attacks on a Rating, and the Control That Fits Each
| Attack | Who runs it | Sharpest signal | Control that works |
|---|---|---|---|
| Bought positive reviews | A farm hired by the listing | Author history, and reviews outpacing orders | Weight by verified order history, not deletion |
| Review bombing | A competitor or a brigade | Volume spike against the listing’s own baseline | Velocity ceiling per target, freeze the displayed average |
| Rating extortion | An individual working a street | Owner report plus cross-listing author pattern | A structured report field and a human who reads it |
| Incentivized reviews | The restaurant itself | An unusually flat five-star distribution | Enforceable policy and complaint-driven action |
No Control Catches Everything
Everything here reduces manipulation. None of it eliminates manipulation, and a platform that says otherwise is setting up a promise it will break in public.
A sufficiently funded attacker places real orders from aged accounts on residential networks and writes original text. That is indistinguishable from a satisfied customer, because at the level of one review it genuinely is one. What you can do is make it the only viable attack, which prices out everyone except the people who could have bought advertising anyway.
Say that plainly to restaurants. We reduce this, we investigate inside a stated window, we will sometimes be wrong, here is how you tell us. That posture survives a bad week. “Our system prevents fake reviews” does not survive the first screenshot.
The Security Surface This Article Has Not Covered Yet
Rating integrity is the security problem specific to a restaurant discovery app, and it is not the only one. The controls below are the ones every operator needs regardless of category. Each is worth scoping now, because every one of them is cheaper before launch than after.
Account Takeover on Both Sides of the Listing
Two populations hold accounts and they need different defences. A diner account holds saved cards, saved addresses and an order history. A restaurant account holds the listing itself: the menu, the prices, the photographs, and the reply voice that appears under every review. The second is the more valuable target, because whoever takes an owner account can change a price, pull a dish, or post a public reply that damages the business faster than any fake review.
Require a second factor on owner accounts specifically, and treat it as non-optional rather than as a setting. Owner accounts are shared in practice: a manager leaves, a part-time staffer knows the password, an agency did the onboarding and never handed it back. Invite people as named users rather than issuing one credential per restaurant, expire sessions on a fixed schedule instead of leaving them open indefinitely, and notify the registered owner whenever a reply is posted or a payout detail changes. Notification is a weak control alone and a strong one in combination, because it shortens the gap between compromise and discovery.
Payments, Refunds and the Abuse That Follows Them
Card fraud on a food discovery app looks like card fraud anywhere, and the standard answers apply. Tokenize rather than store, let the gateway hold the card, and keep card data out of your own database so that a breach of your systems is not a breach of anyone’s card. That limits the blast radius. It does not make the platform compliant with any standard, and it should never be described that way to a customer or an investor.
The abuse that actually costs an early platform money is refund abuse rather than stolen cards. One account claims a missing item on every third order. Another orders, disputes, and orders again from a new account at the same address. Neither is visible on a single order and both are obvious across a history, which is the argument for making a refund a decision with a record rather than a button support presses. Decide the value at which a refund needs a second pair of eyes, count refunds per account and per address rather than per order, and keep the reason code, because the pattern is the evidence.
Who May Change What
Access control is the thing founders postpone and then retrofit expensively. The question is not who may log in. It is who may change a price, approve a refund, edit a listing, export a customer list, or alter a payout destination. Write those down as roles before anyone builds a settings screen, because a platform with a single admin level ends up with a support agent who can do everything and an audit trail that cannot say who did.
The rule that holds up is simple. Every action that moves money, changes what a customer sees, or exports personal data leaves a row naming the person, the time and the previous value. That is what makes an investigation possible six weeks later, and it is the same log the rating work already depends on.
Personal Data and Where It Lives
A discovery platform holds more personal data than founders expect. Saved addresses, phone numbers, precise location traces from ordinary browsing, search history, and reviews that are themselves identifying. Treat that as a category of its own and decide four things: what is collected, how long it is kept, who inside the business can read it, and what happens when someone asks for it to be deleted.
Two specifics are worth settling before launch. Location history is the most sensitive material on the platform and the least examined, so choose a retention period deliberately rather than defaulting to keeping it forever. And a review is personal data as well as public content, which means a deletion request has to reach the review, the photographs attached to it, and the moderation record behind it. Building that path later means hunting down every copy you made in the meantime.
None of this competes with the rating work above. It sits underneath it. A platform that cannot say who changed a price cannot say who changed a rating either, and the same log answers both questions.
Build It In, or Bolt It On Later at Triple the Cost
Almost nothing here is expensive at the schema stage and almost all of it is expensive afterwards. A verification level on the review row, a state transition log, a per-listing velocity counter, a hash column on the image table. Four fields, decided in an afternoon.
What to ask a vendor or a build team
Ask where the rating is computed and whether the weighting function is versioned. Whether a review can be held without being deleted. What the appeal route looks like inside the partner app. Whether uploads are hashed against the catalogue. A platform that cannot answer has a review table, not a review system.
Our own answers, with what ships in the base package and what is separately scoped, sit on the facts page and in the scope and engagement detail. The 36-Month TCO Comparison: SaaS Delivery Builders vs. Owned White-Label Engines matters here, because a hosted builder that does not expose the review state model leaves you unable to answer a restaurant’s question at all.
Sequence it against launch
Before launch you need the schema, the velocity ceiling and the report form. In the first quarter, the appeal route with a published timescale and perceptual hashing. Author-side scoring can wait until you have enough volume for a baseline to mean anything, because a clustering model on a two-hundred-listing catalogue is noise with a dashboard.
That staging is why a ready-made discovery and delivery platform build usually reaches a defensible catalogue faster than assembling one from parts. Engineering effort is better spent on your ranking, or on work like Sub-2 Second Tracking: Load-Testing GPS Delivery Updates on Flutter and Laravel.
Final Thoughts: The Rating Is the Product
What Zomato has to defend is not a number on a card. It is the order the results appear in.
A discovery platform sells a judgement. Not food, not delivery, but the claim that the order of listings on the screen means something. Every control here protects that one claim, and the day it stops being true the catalogue becomes a directory anyone can reproduce.
Restaurants understand this faster than platforms do, because they live on the other side of the number. They forgive a rating that fell for a real reason. They do not forgive one that fell for no reason while nobody answered. The appeal route with a human behind it is not a cost centre. It is the part of the product they evaluate you on.
If you are scoping a discovery build and want to work the review model, the ranking weights and the moderation workflow against your own category and market, look at the full solution range and then book a working session with our team. We will go through the schema decisions that are cheap now and expensive in a year.
FAQs
Why is a fake review a security problem rather than a moderation one?
Because the rating is not decoration. It lives inside the search index, sets whether a listing clears a filter, and weights the feed. An untrusted party writing a review is therefore writing directly into a value your business depends on. Moderation asks what users should see. Security asks who is allowed to change a number that decides which listings get found and sold.
What are the strongest signals that a set of positive reviews was bought?
Account age and order history first: an account created days ago whose only activity is one five-star review is not a customer. Then velocity measured against the listing’s own baseline, especially reviews arriving faster than orders. Then device and network clustering as a multiplier on other signals. Text similarity works against cheap farms but has degraded fastest and should never be your primary signal.
How do you stop review bombing when every individual review is within policy?
Stop looking at the authors. Sixty people writing one review each break no per-author rate limit, so the control has to sit on the target. Cap how many new reviews can influence a single listing’s public average inside a rolling window, hold the surplus in a pending state, freeze the displayed average at its pre-spike value, and flag the listing for a human to review.
Should a platform delete reviews or hold them?
Hold them. Deletion is irreversible, invites accusations of censorship, and is exactly wrong when a spike turns out to be a genuine food safety incident with real unhappy customers. Holding costs a day and keeps every option open. Draw the line explicitly: automation may hold, freeze and block, but permanently deleting a review or suspending a listing needs a person and a recorded reason.
What can a platform do about rating extortion?
Not much automatically, because the demand happens off-platform and the on-platform artefact is an ordinary negative review. The workable control is a report form with a field for having been contacted and an upload for the screenshot, plus a person who reads it inside a stated window. You are also the only party who can see one account hitting many unrelated kitchens nearby.
Is verified-order-only reviewing worth the loss in review volume?
It is the single most effective control available, because it raises the cost of a review from zero to the price of a meal. The volume loss is real and hurts a young catalogue badly. Most platforms should accept both kinds, mark verified reviews visibly, give them full weight, and count unlinked reviews at a reduced weight or outside the numeric average entirely.
How should photo moderation split between automation and people?
Automate what is verifiable. Perceptual hashing catches images stolen from another listing outright, and a category classifier handles uploads that are not food at all. Send everything the classifier is unsure about to a person, and expect that bucket to be larger than a vendor demo suggests. Stock photography passed off as the kitchen’s own is only weakly detectable and usually needs a human.
What should be logged so a disputed rating can be reconstructed later?
Every state transition on a review rather than its current state: created, published, held, released, removed, restored, appealed, upheld, overturned. Each entry carries a timestamp, the actor, whether that actor was a rule or a person, the rule identifier, and the listing average before and after. Keep it append-only, separate from the review table, and snapshot the daily rating with its weighting version.
Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by any company or product named in this article.
Terms such as “X Clone” are used descriptively. It is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it.
The entire design and codebase of our products is built by our own team. Our products contain no code, design, graphics, or content originating from any third-party website or applications.
All third-party names and marks referenced in this article are the property of their respective owners, referenced solely to identify the services discussed.
