App Store reviews to Power BI
Power BI knows your installs, your revenue and your crash rate. It does not know what anyone said. Reviewflowz publishes an OData feed, so every App Store review arrives as an ordinary row with its score, its storefront and its language attached.
Set up in under five minutes • No demo required
All my offline maps vanished
“Updated last night and the downloaded folder is empty. Nothing on the ridge but a grey screen.”
Australia storefront 7 September 2026
| Score | Country | Language | Tag | Review text |
|---|---|---|---|---|
| 1.0 | Australia | English | Offline maps | Updated last night and the downloaded folder is empty. Nothing on the ridge but a grey screen. |
The text cell is clipped for width here. The column holds the whole review.
The column your model does not have
Your Power BI model already knows how many people installed the app, what they paid and how often it crashed. It does not know what one of them said. App Store reviews arrive as one row per review: the score, the date, the storefront, the language, the reviewer, the title and the full text.
That changes what a rating is on a dashboard. A 4.2 on its own is a number somebody screenshots into Monday’s deck. A 4.2 with three hundred rows behind it, sliceable by storefront and by tag, is a page the product manager opens instead of an export they ask you for.
The tags arrive filled in. Reviewflowz reads each review in the language it was written in and files it under the themes your users raise, so a Japanese one-star about search and an English one land on the same tag and count once, in the same bar.
And it is not one table. Reviews sits beside your ratings history, your review profiles and a change stream, so one report can chart the store rating over eighteen months and the reviews that moved it.
Refresh in Power BI and the words arrive with the numbers.
Power BI has read this format for years
Reviewflowz publishes an OData v4 feed, and Power BI’s built-in OData connector reads it. Nothing to install, nothing from AppSource, no Power Query M to write: Get data, OData feed, paste the URL, pick your tables. The same feed opens in Excel or Tableau if somebody asks.
The credentials are one token you create inside Reviewflowz. Paste it into the user name field and leave the password blank. That is the whole authentication story, and it ends when you revoke the token.
Then Power BI refreshes on its own schedule. Incremental refresh works too, because the review date is a real datetimeoffset the feed can filter on, which is exactly what Power Query folds a RangeStart and RangeEnd window into. The first load brings your history, then the dataset pulls the window.
A deletion is a row, not a silence. The feed carries a change stream of inserts, updates and deletes, so a reviewer who edits a one-star into a four-star after your fix ships, and a review Apple takes down, both reach the model as events. The report never quietly diverges from the store.
$filter=ReviewDate ge RangeStart and ReviewDate lt RangeEnd
ReviewDate is a datetimeoffset, so Power Query folds the window into the feed.
One storefront that looks nothing like the others
Apple files every App Store review under a storefront, and Reviewflowz writes that storefront onto every row. Country is a real dimension in the model, not something you infer from the language. Drop it on a bar chart and the report answers a question you could not ask before.
The shape is the diagnosis. A crash drops every market together. A translated string that no longer fits its button, a payment method one bank rejects, a keyboard that fights the input field: those drop exactly one market while the rest do not move. Seven storefronts between 4.4 and 4.8 and Japan at 1.9 is not a mood, it is a ticket with an owner.
Language sits beside country, detected from the text itself, so a German review left on the Swiss storefront still slices the way you expect.
Build the visual once and it stays true. Every refresh feeds the same chart, so the quarterly localisation review is that page with a different date range selected, not an export somebody reformats the night before.
Average rating by storefront
Apple files every review under a storefront, so country is a column.
Seven storefronts move together. One that drops on its own is a localisation problem, not a crash.
Watch the release, not the post-mortem
App Store reviews do not arrive evenly. They pile up in the hours after a release and the days after a featuring, so a bad build reads as a run of one and two stars in a few markets before the crash reporter has finished agreeing with them.
Put reviews per day on a column chart, split by rating, and mark the ship date. The red band appearing on Tuesday afternoon and shrinking again after Friday’s hotfix is the rollout, drawn. Nobody built a dashboard for that. Somebody added one visual.
Mark it by date, because the date is what Apple gives you. The App Store Connect API does not return an app version with a review, so there is no version column to model on and the date axis is the release axis. That costs less than it sounds: you know when you shipped, and every review carries when it arrived.
Reviewflowz refreshes each App Store listing about every couple of hours, so the rows are in the feed while the engineers are still at their desks. How fast they reach the report is then your refresh schedule, which is a setting rather than a project.
New reviews per day
Mar 4 to Mar 17 1 to 2 stars 4 to 5 starsMarked by ship date. The App Store Connect API does not return a version with a review, so the date axis is the release axis.
Ordinary DAX over an ordinary table
A rolling 28 day average rating is a CALCULATE and a DATESINPERIOD. The share of one and two stars is a DIVIDE. Reviews per thousand installs is a measure across two tables you already have. No plugin, no proprietary metric language, because the reviews are a table like any other table.
Which means the question gets better. Not “what is our rating”, since the App Store prints that on the listing, but “what is our rating among people who reviewed us in the two weeks after a release, in the markets where we ship a translation”. That one has an answer and an owner.
Put the measure on a card, put the storefront on a slicer, and the leadership number stops being a monthly assembly job. It is a page in the workspace they already open, on the refresh schedule you set, in a file they already trust.
And when somebody asks where a number came from, the answer is a row with a date, a country and the sentence a person wrote. A review is evidence, which is a rare thing to have sitting behind a KPI.
Rolling rating 28d =
CALCULATE(
AVERAGE( Reviews[Score] ),
DATESINPERIOD(
'Date'[Date], MAX( 'Date'[Date] ), -28, DAY
)
) +0.4 vs the previous 28 days
One token per connection, and you can take it back
A connection is a token: created in Reviewflowz, revoked in Reviewflowz. Give the agency building your localisation dashboard one of its own, end the engagement, revoke it, and their report stops refreshing that afternoon. No shared password, and no export you cannot un-send.
A token carries the access of the person who created it. If that user only sees the DACH apps, so does every report built on their token. The permissions are the ones you already set up rather than a second set that drifts away from them over a year.
The feed serves the account, so filtering happens in Power BI where the report lives. One connection feeds the quality page the whole company reads and the narrow low-rating page the support lead opens, and neither of them needs a pipeline of its own.
Setup is the same at one app or eight. Connect the App Store listing, create the connection, paste the URL into Power BI. Under five minutes on the Reviewflowz side, with no call with a salesperson standing in front of it.
BI connections
A token carries the access of the person who created it.
Created by dana@, sees every app
Last used 6 minutes ago
Created by lars@, sees Fjord DACH only
Last used 3 hours ago
Revoke a token and its report stops refreshing. Nothing else changes.
Stop pasting App Store screenshots into the deck
Set up in under five minutes. No demo required.
How do App Store reviews actually get into Power BI?
Through an OData v4 feed that Reviewflowz publishes. You create a connection in Reviewflowz and copy its feed URL, then in Power BI choose Get data, OData feed, and paste it. Authenticate with the token as the user name and a blank password. Power BI’s navigator lists the tables and you load the ones you want. There is no custom connector to install and no Power Query M to write.
Which columns arrive?
One row per review with the app, the platform, the title, the full text, the score, the review date, the reviewer’s nickname, the country, the language and the tags, alongside tables for your ratings history, your review profiles and a change stream of inserts, updates and deletes. The App Store Connect API does not return an app version with a review, so there is no version column.
Does the report refresh on its own?
Yes. Power BI’s scheduled refresh pulls from the feed on whatever cadence you set, and incremental refresh works as well because the review date is a datetimeoffset the feed can filter on. On the Reviewflowz side each App Store listing refreshes about every couple of hours, so the feed is already current when Power BI asks.
Can we chart rating by app version?
No, and nobody honestly can. The App Store Connect API does not return an app version with a review, and Reviewflowz does not invent one, so a rating-by-build measure would be fiction. Mark releases on the date axis instead: reviews cluster in the days after a ship, so the shape is there. The storefront is on every row, so market-level analysis is real.
Does the first load include our App Store history?
Yes. Connecting an App Store listing loads its review history, so the trend line is full from the first refresh rather than filling up over the next quarter. After that the feed carries what changed.
Which plan includes the BI feed?
The BI feed is a Premium feature and it is not part of the free trial, so budget for that rather than discovering it on day three. Everything else works the way the trial suggests: you connect an App Store listing yourself and see your reviews in minutes.
Do I need a demo to get started?
No. You connect your App Store listing and create the BI connection yourself, in under five minutes. If you get stuck, support is the people who build it.





