The dashboard audit: what to cut, then what to verify

Every dashboard grows, because nobody ever deletes a tile

Dashboards get built once and edited forever, and every edit is an addition. Someone asks whether we can see paid separately. Someone wants the blog split out. A campaign launches and gets its own row, and then the campaign ends and the row stays, because removing it is a decision and adding it was only a favour.

Nothing about that process is anyone’s fault, and it has a predictable end state. The page fills with tiles that were each justified on the day they arrived and have never been assessed together since. The cost isn’t clutter as an aesthetic problem. It’s that a reader who has learned most of the page doesn’t concern them stops scanning it and goes straight to the one number they came for, at which point the dashboard has quit being a dashboard and become a slow way to look up a single figure.

So the job has two halves, and most advice covers one of them. The first half is cutting the thing back to the tiles that change a decision. That half is well-trodden and it’s the easier one. The second half is establishing that the tiles which survived are telling you the truth, because a number on a Data Studio tile, which Google called Looker Studio until April 2026, can be wrong in several documented ways that produce no error, no warning and no visible symptom. Do the first half alone and you get a tidy dashboard that someone eventually stops trusting.

Three questions, asked of every tile

Work through the dashboard one tile at a time and answer three things in writing. Written down matters, because the exercise collapses the moment it becomes a conversation about whether a chart is nice to have.

Start with who reads it. Name a person or a role, or write “nobody” and mean it. This is the question that does most of the work, and the answers are informative even when they’re uncomfortable: a tile usually exists because somebody asked for it once, in a meeting, in a different quarter, and asking who reads it now is how that gets said out loud.

The second question is what decision it changes. Not what it shows. If the number doubled next week, what would somebody do on Monday that they wouldn’t have done otherwise? A tile whose honest answer is “we’d mention it” is reporting, not deciding, and reporting belongs on a page people visit deliberately rather than on the one they open every morning.

Third, when was it last actually looked at? You find this out by asking, and it’s a friendlier conversation than it sounds, because nobody enjoys defending a chart they haven’t opened since March.

Then give each tile one of four verdicts. Keep is for anything that survived all three questions, and it should be a small set. Merge catches the pairs and triplets: three tiles showing sessions, users and pageviews are one tile with a dimension selector, and the merged version is the one people read. Demote moves a tile to a second page instead of deleting it, which is the verdict that lets a cautious team make progress — quarterly detail is real, it just isn’t front-page material. Delete is what’s left. Data Studio keeps a version history you can view, restore and delete revisions from, so a deletion you regret costs you a minute rather than an afternoon.

Expect the page to end up much shorter than it started. That’s the exercise working.

The cut is the easy half

A tile can pass all three questions, sit on a clean six-tile page, be the exact number a director asked for, and still be wrong.

Think about how dashboards actually die. It’s rarely a redesign. Someone in a meeting reads a figure off the dashboard, someone else has GA4 open on their laptop, the two numbers don’t match, and there’s a short awkward moment that nobody resolves. Nothing gets fixed afterwards, because the discrepancy is nobody’s job. What happens instead is that everyone in the room privately downgrades the dashboard, and within two months people are pulling their own numbers again and the report someone was paid to build gets opened once a quarter out of guilt.

That’s a trust failure, and trust failures are recoverable if you find them before somebody else does. So take each surviving tile and reconcile it once against its source: open the number in GA4, or in Ads, or wherever it comes from, for a closed period like last month, and see whether the two agree. Where they don’t, work through the mechanisms below before assuming something exotic. Then write the answer on the dashboard, so the next person doesn’t have to find it twice.

What Data Studio changes on the way to the tile

Four behaviours, all documented by Google, none of them visible on the page.

Blends are the first place to look, because they inflate and collapse in the same operation. When Data Studio builds a blend it uses a left outer join by default, and Google’s own guidance warns that multiple matches for the join condition can produce more rows in the blended data than exist in the leftmost source. Join daily spend to a table broken out by product, and every day matches several product rows, so the spend repeats down the join and the total on your tile is a multiple of what you spent. The same feature loses rows at the other end: before joining, Data Studio groups and aggregates each table on the dimensions you selected, and identical rows collapse during that step if those dimensions don’t include something unique per record. Include a genuinely unique field in each table’s dimensions even when no chart displays it, and match the granularity of the two sides before you blend rather than after. A blend holds at most five tables, which is worth knowing before you design around one.

Then there’s the date range control, whose reach is narrower than its position on the page suggests. It applies to charts whose data source has a date dimension, and Google documents two ways for a chart to sit outside it: a chart with its own date range property set overrides the control, and a control grouped with a chart affects only the charts in that group. Either may have been done deliberately, months ago, for a reason the report has no way to record. The consequence is two tiles on one screen describing two different periods while appearing to answer the same question. You can settle it in ten seconds — move the date control to an odd window like a single Tuesday and watch which tiles fail to move.

Freshness is the one that catches people in the meeting itself. The Google Analytics connector refreshes every 12 hours by default, and Google’s own freshness page then disagrees with itself about shortening that: the options table offers 1 hour and 4 hours, and a note further down the same page groups Google Analytics with the products whose rate can’t be changed. Google Ads, Search Console, Campaign Manager 360 and YouTube Analytics sit squarely in that second group. So check the interval on the report itself, then treat it as a ceiling: Data Studio fetches again once the threshold has passed, so a report never shows you anything older than its own interval. On a twelve-hour setting that still leaves a tile up to twelve hours behind, which is enough for a figure quoted at nine on Monday to be describing where things stood the night before.

Currency is the last one, and it bites hardest on group reporting. Data Studio performs no currency conversion of its own: a revenue total spanning an AED store and a SAR store adds the figures as though the units matched, then formats the result in whichever currency the field is tagged with. A GCC group with a UAE entity and a Saudi one has two currencies before it has two dashboards, and the obvious next request is a single revenue number for the board. Something upstream has to do that conversion, and if nobody can say which rate it used or when it was last updated, the tile isn’t a revenue figure yet.

What GA4 changes before Data Studio ever sees it

Some tiles arrive wrong, and no amount of report-side debugging will find it.

Start with the (other) row. It appears in a report, exploration or Data API response when the number of rows in a table exceeds that table’s row limit, and everything past the limit gets bundled into a single row labelled (other). Google counts any dimension with more than 500 unique values in a single day as high-cardinality, and page paths, event parameters carrying IDs, and campaign names generated from a template are the three that cross that line first, once a site has the traffic or the page count to reach it. So a landing-page table that looks complete may be showing you a top slice and a bucket. Google’s advice is to prefer standard reports, whose aggregate tables make this less likely; for a dashboard builder the working version of that is to stop stacking secondary dimensions and filters onto a tile that already sorts on something high-cardinality.

Thresholding removes rows rather than bundling them. When a report, exploration or API call includes demographic data, GA4 withholds rows where the numbers are small enough to risk identifying somebody. The threshold is system-defined, Google doesn’t publish it, and you can’t adjust it. On a dashboard this surfaces as a demographic tile whose totals sit below the same period’s session count, with nothing on the page to explain the difference.

Retention gets blamed for gaps it didn’t cause. On a standard property the setting keeps user-level and event-level data for either 2 or 14 months, and Google is explicit that it governs explorations and funnel reports rather than the aggregated standard reports. A tile mirroring a standard report that shows nothing for last spring has some other cause, and the first thing to check is whether the property was collecting at all. Set retention to 14 months today instead of next quarter. Raising it applies to the data you have already collected and not already deleted, so it reaches back as far as the old setting left anything standing, and everything the 2-month default has already cleared out stays gone. Google waits 24 hours before the change takes effect, which is the window for undoing it.

A true number still misleads when the comparison is wrong

Every tile above can be individually correct while the comparison beside it isn’t, because a comparison asserts that two periods are alike.

Unequal windows are the crude version. “This month” against “last month” compares 30 days to 31 without saying so, and a month-to-date figure against a complete previous month compares an unfinished race to a finished one. Fix it by naming the window on the tile.

The subtler one spans a change in measurement. If cross-domain tracking was fixed in June, then July against June measures the fix, and any conclusion drawn about campaign performance from that comparison is an artefact of the repair. Keep a dated list of every tracking change on the dashboard itself — a text box with three dated lines in it is the highest return-per-minute item in this entire audit. The container changes that alter what gets sent belong on that list as much as property-level work does.

The third is seasonal, and in the GCC it has a specific shape. Ramadan moves roughly ten to eleven days earlier each Gregorian year. In the UAE and Saudi Arabia it began on 1 March in 2025 and ran twenty-nine days; in 2026 it began on 18 February and ran its full thirty, ending on 19 March. So a March-on-March tile across those two years sets nineteen days of Ramadan against twenty-nine. Both months are mostly Ramadan, so the comparison looks fair, and the ten-day gap between them still lands on the tile as performance. February is where the contrast is total: eleven days of Ramadan in 2026 and none at all in 2025. Either way the difference the dashboard reports is the calendar rather than the work. Year-on-year is still the comparison leadership asks for, so give it to them with the periods aligned to Ramadan instead of to the Gregorian month, and label the tile with what it’s actually comparing.

What you’re left with after both passes

One decision question per dashboard. Not one team, not one channel — one question, phrased as a question, written at the top of the page. “Are we buying traffic that converts?” beats “Marketing Overview”, because it tells you immediately which tiles belong and which don’t.

Below that, order tiles by how quickly they change what someone does, putting the number that triggers action in the corner the reader starts from. That is the top left in English and the top right in Arabic, because the scanning pattern mirrors with the script, which decides the layout on any report a bilingual team reads both ways. Give each tile the one comparison that makes it legible and no more.

Then add two things. A name, meaning the person who owns this report and fixes it when it breaks, written on the page where a new joiner can see it. And a review date, three or six months out, that gives somebody permission to delete tiles again. Without a scheduled cull, the accumulation starts over the day you finish.

All of this assumes the property underneath is measuring what you think it is. If the reconciliation pass turned up gaps you couldn’t explain, the next place to look is the settings that decide what your reports can say at all, and where a dashboard and a raw export disagree by design, that’s a question about which tool is allowed to answer what. Both sit further up the same chain, laid out in full across the analytics audit.

Standing offer

The hard part is deciding what to do first

Bring us a URL, an audit report, or a proposal you're not sure about. We'll tell you which problems deserve budget this quarter, and you'll leave with an order of operations you can hand to whoever does the work, whether that's us or not.

Book twenty minutes