Google reviews to Power BI

Reviewflowz publishes an OData v4 feed, and Power BI’s built-in OData connector reads it. There is nothing to install: no download, no AppSource listing, no Power Query M to write. Get data, OData feed, paste the URL, tick the tables you want. The same URL opens in Excel or Tableau if somebody asks.

The credential is 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 the moment you revoke the token.

Behind the URL are six tables, named the way your saved report will bind to them: Reviews, ReviewProfiles, Locations, RatingsHistory, ReviewSummary and ReviewChanges. Nobody has to guess at a schema or ask us for one, because the feed publishes its own metadata and Power BI reads it before it reads a single row.

Setup is the same at three sites or thirty. Connect the Google Business Profile listings, create the connection, paste the URL. Under five minutes on the Reviewflowz side, with no call with a salesperson standing in front of it.

Google reviews are left by people who walked in, so volume follows footfall and has a weekly shape. Saturdays run about three times a Tuesday. A loyalty card launch or a bank holiday shows up within a day or two, at some sites and not others.

A monthly average erases both. One number a month cannot tell you that the weekend team is carrying the rating while the weekday one is not, and it cannot tell you that a campaign moved reviews at nine sites and did nothing at three. Those are the two facts an area manager would act on.

The review date is on every row as a real datetimeoffset, so reviews per day is a column chart rather than a data project. Split it by rating and the busy weekend separates itself from the bad one, which are easy to confuse when you only have a total.

Then put review volume beside the numbers you already model. Revenue per site, footfall per site, covers per session: the outliers explain themselves once the two sit on one page, and neither of them had to leave the workspace to meet.

A connection is a token: created in Reviewflowz, revoked in Reviewflowz. Give the agency running your local listings 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 four Bristol sites, so does every report built on their token. The permissions are the ones you already set up in the app rather than a second set that drifts away from them over a year.

The list shows who created each connection and when it was last used, and a revoked token stays on it with the date it went. That trail is kept on purpose, because “which report was still pulling this” is a question that only ever gets asked after the fact.

One connection feeds every report. The estate-wide page the board reads and the single-site page a manager opens are two reports on one feed, filtered in Power BI, not two pipelines kept agreeing with each other.