How we compute the numbers on this site
Every customer-outcome claim on RateTap's marketing pages comes from the production database — not estimates, not testimonials. This page is the audit trail.
Where the numbers come from
There is one source: the live RateTap production database (Neon Postgres). A single TypeScript script, platform/scripts/compute-marketing-stats.ts, queries that database via the same Drizzle ORM client used by the application and prints aggregate outputs along with sample sizes. We re-run it before each material site update and save a JSON snapshot at platform/scripts/marketing-stats.json so claims are reproducible.
Definitions
- Paying restaurant
- A row in the
restaurantstable whosesubscription_statusisactive,trialing, orpast_due, and whoseis_ownerandis_regionalflags are both false. Owner and regional rows are admin/dashboard views, not real restaurant locations, and are excluded from all customer counts. - Tracked location
- An active location with at least two Google rating snapshots in the
google_rating_snapshotstable, with a gap of at least 7 days between the earliest and latest. Locations below this threshold are excluded from rating statistics because their observation window is too short to draw conclusions from. - Guest tap
- A row in the
reviewstable representing one guest rating submission through a restaurant's RateTap flow. Each tap captures a star rating, optional feedback, and optional staff attribution. - Guest issue detection
- Every guest is offered the same choice between Google's review form and private feedback; the platform does not route guests by a star threshold. When feedback is submitted,
classifyReview()classifies its written content as praise, mixed, complaint, or urgent. Ratings at or below 2 are urgent regardless of the text, and ratings at or below 3 are never praise. Any result other than praise is actionable: it is something a human needs to act on, and this is what the site's "guest issue" counts mean. - Staff attribution rate
- The percentage of guest taps where
staff_idis non-null — i.e., the tap can be tied to a specific staff member. Computed across the fullreviewstable for paying restaurants. - Median vs. mean
- We report both. The median better describes a typical customer's experience because it's robust to outliers; the mean reflects the platform-wide aggregate. When a single number is shown on the site without qualifier, it's the median (less flattering, more honest).
- Observation window
- For each tracked location, the number of days between the earliest and latest Google rating snapshot.
Where the Google rating data comes from
The Google star ratings and review counts on the site are not self-reported by the restaurant. They come from each location's Google Business Profile, queried via the Google Places API. We capture a snapshot when a restaurant first signs up, then on a recurring schedule afterward. The full snapshot history is in the google_rating_snapshots table; the script above uses the earliest and most recent snapshots for each location to compute deltas.
What the snapshot below contains
As of August 19, 2026, the production database held:
- 12 active restaurant locations across 5 brands (the founder's operating group).
- 23,664 guest reviews captured.
- all 12 locations currently between 4.5 and 4.8 stars on Google, pulled from each location's Google Business Profile.
- Before July 8, 2026 the flow routed guests by rating; since then every guest chooses between a Google review and private feedback, whatever the rating. Private feedback alerts the manager in real time.
- most reviews carry the staff code of the card that was tapped (see the October 10 figures below for the current share).
October 10, 2026 figures
Pulled read-only from the production database for the 30 days from September 10 to October 10, 2026, across the same 12 locations:
- 5,128 guest ratings captured.
- 65% of guests chose Google (network share since July 8, 2026, n = 15,929).
- 23% of guests who gave 1 to 3 stars still chose Google (96 of 414 since July 8, 2026). The choice screen is the same for every rating.
- 7.5% of ratings had no server attached (387 of 5,128), so about 9 in 10 are tied to a server.
- Private feedback fell from about 20% to about 10% of weekly ratings between July and October, while the 5-star share stayed near 94%.
These describe what guests chose. They do not show that RateTap caused any change in Google review counts or ratings.
See the case studies page for the per-location breakdown. The aggregates above are sample-size-aware: every average we cite has its n attached.
Google review velocity
We take daily Google Places snapshots of each location’s review count. For each interval we count increases of 1 to 25 reviews; larger jumps are excluded as place-ID corrections. Before launch is December 21, 2025 to March 19, 2026; after launch is March 19 to October 10, 2026. 11 of 12 locations are included (León has no pre-launch snapshots).
Per location, new Google reviews ran 0.41 to 0.93 a day before launch and 2.99 to 7.80 a day after.
This is association, not proof. There is no control group, the after window is about 2.3 times longer, and season and organic growth are not separated.
Why we publish this
The previous version of this site contained marketing claims that were not backed by data — fabricated customer testimonials, invented aggregate ratings, and unverifiable performance multipliers. We removed all of it and replaced it with what the production database actually shows. We document the methodology so that anyone reading our marketing — customers, prospects, AI assistants citing our site, regulators — can trace any claim back to its source.
If you want to interrogate any number, the script that produces it is open and reproducible. Ask in the demo and we will walk through the query.
Update cadence
The numbers above are accurate as of the snapshot date at the top of this page. We re-run the script and refresh the site when material milestones change (new customers, significant rating shifts on existing customers, methodology improvements). The script itself is run on-demand against the live database; no manual data entry is involved.
Limitations and honest caveats
- Sample size is small. 12 tracked locations is enough to describe RateTap's installed base accurately, but it is not large enough to claim industry-wide effect sizes. Any reader extrapolating these results to "all restaurants will see the same outcome" is over-reaching the data.
- Selection bias. The 12 tracked locations are the operating restaurants of the founder's group, plus early adopters. They were highly motivated to deploy RateTap correctly. Outcomes for less-motivated operators may differ.
- We do not claim a measured rating uplift. Early Google snapshots for several locations reflected incomplete or mismatched Google Place IDs that were later corrected, so first-versus-latest rating deltas are not reliable and we do not publish them. We report only what we can verify directly: reviews captured by the platform and each location's current Google rating. We do not claim RateTap is the sole driver of any rating.
- Attribution counts taps, not reviews on Google. Every in-platform review carries the staff code that was tapped. Once a guest opens Google's review form, the eventual Google review (if posted) is attributed via Google's own systems, not RateTap's.
- "Captured" means a guest completed a rating in the platform, not a confirmed Google review. Every guest is offered Google's review form, but whether the guest then posts on Google is outside our measurement.
Want to see the dashboard the data comes from?
Book a 15-minute demo. We'll walk through the live data for one of the case-study locations.
Book a demo