App Store reviews to BigQuery
Every App Store review as a row in your own project, carrying the storefront country and the language it was written in. The two questions App Store Connect will not answer become ordinary SQL.
- Set up in under five minutes
- No demo required
128,412 rows
Destination table
fjord-analytics.reviews.app_store_reviews
| review_date | score | country | review_text |
|---|---|---|---|
| 2026-09-07 | 5.0 | Australia | Lost signal above the treeline, map kept working. |
| 2026-09-07 | 1.0 | Japan | 検索に日本語が入力できません |
| 2026-09-06 | 4.0 | Canada | Route planning is quick. Water refills next? |
| 2026-09-06 | 5.0 | Germany | Höhenlinien sind gut lesbar, auch bei Sonne. |
They love how easy we've made it
10 000 Slack notifications
Online Pet Supplies Retailer
6000 reviews routed to Zendesk
European Bank
Monitoring 12 platforms
Marketing Software Company
100 000 reviews across 97 tours
Tour operator in Iceland
4500 locations monitored
Luggage Storage & Lockers
5000 AI replies generated
Sushi Restaurant Chain
App Store reviews reach BigQuery through a live sheet
There is no managed BigQuery destination to click. Reviewflowz keeps a Google Sheet in your Drive current: a new App Store review is a new row within half an hour, an edited review updates its row, and a removed review loses it. One CREATE EXTERNAL TABLE against the sheet URL and app_store_reviews queries like any other table. For a native partitioned table, load from the Review API.
R 
reviews Reviewflowz Sheet in
your Drive External
table
Run once CREATE EXTERNAL TABLE
reviews.app_store_reviews
OPTIONS (
format = 'GOOGLE_SHEETS',
uris = ['https://docs.google.com/...'],
sheet_range = 'Reviews'
)Prefer a native partitioned table? The other road is the Review API and a load job you run on your own schedule.
The question App Store Connect will not answer
Apple files every review under a storefront, and Reviewflowz writes it onto every row as the country. App Store Connect will never show you seven storefronts between 4.4 and 4.7 while Japan sits at 1.6. In BigQuery that is a GROUP BY. A crash drops every country together. A broken translation drops one. Which country tells you which team to call.
Query editor -- rating by storefront since 4.2 shipped
SELECT country,
ROUND(AVG(score), 1) AS rating,
COUNT(*) AS reviews
FROM `fjord-analytics.reviews.app_store_reviews`
WHERE review_date >= '2026-09-01'
GROUP BY country
ORDER BY ratingTry it Free for 14 days
Your review history imports the moment you connect, so there is something to reply to from the first minute.
The build Apple never attached to the review
Apple leaves the app version off every review, so no review tool can tell you which build a one-star is about. Your warehouse can. Join reviews to your releases table on the date: 4.1 sits at 4.6, 4.2 drops to 2.9, and the 4.2.1 hotfix recovers to 4.5. Subscriptions, ticket volume and refunds join the same way.
app_store_reviews Your project, your rules
The table lives in your Google Cloud project, in the region you picked, under the IAM and retention policy you already run. You choose what flows out: pick the App Store listings, then the storefronts per listing, and add a score filter if you want one. The localisation team gets just its markets and the support lead gets just the low scores, from the same account.
Your Google Cloud project
fjord-analytics.reviews
Location
europe-west1
Access
your IAM
Retention
your policy
What flows in
Fjord Fjord Pro Leave it empty and every storefront is included.
FAQs
Is there a native BigQuery connector?
No, and it would be dishonest to imply one. Reviewflowz syncs a Google Sheet in your own Drive, and BigQuery reads that sheet as an external table with a single CREATE EXTERNAL TABLE statement. If you would rather have a native partitioned table, the Review API plus a scheduled load job gets you there. Both are ordinary work for a data team, and neither needs a demo.
How current is the table?
Reviewflowz checks the App Store every two hours by default, every ten minutes on the high-frequency setting, and syncs the sheet every 30 minutes. An external table reads the sheet at query time, so a query you run now sees whatever the last sync wrote. A load job into a native table is as current as its schedule.
Which columns does the table have?
The review id, the app, the platform, the review date and time, the score, the title, the full text, the storefront country, the detected language, the reviewer nickname, the tags and a link back to the review. Apple does not attach the app version to a review, so there is no version column. Join your own releases table on the date to get per-build numbers back.
Does the first load include our App Store history?
Yes, on a paid plan: one click loads every past App Store review, so the trend line is full from day one rather than in three months. During the free trial new reviews arrive as they are posted, and the history loads once you subscribe.
What happens when a reviewer edits their review after we ship the fix?
The row updates in place with the new score and text, so a query over it moves with the correction. When Apple removes a review from the store, the row is deleted on the next sync, which means the table never holds a version of the truth the App Store no longer does.
Do I need a demo to get started?
No. Connect your App Store listing and the Google Sheet yourself in under five minutes, then run one CREATE EXTERNAL TABLE against it. 14 day free trial, no credit card.
Reviews belong next to the release that caused them.
Set up in under five minutes. No demo required.