Every agency I know has built the client a dashboard at least once. A Looker Studio page with the GA4 connector, a logo in the corner, twelve tiles, a date picker. The client opens it twice. The first time they say it looks great. The second time they email to ask what it means, and from then on the monthly update goes back to being a call.
I run SharpHaw, a small agency in Lisbon, and SharpOS is the workspace we run every client engagement in. Analytics is the surface I have rewritten the most, because the first version was exactly that dashboard. This post is what it became, what it deliberately doesn't do, and why it sits on top of PostHog instead of trying to be one.
TL;DR: SharpOS Analytics is a reading surface, not a collector. PostHog underneath, a thresholded "Needs attention" list on top, and every signal is one sentence with a link to the surface that fixes it.
What GA4 and Looker are for, and where they strain
Google Analytics 4 is a collector with a reporting UI attached. It is very good at the first job, and the people on r/GoogleAnalytics have been saying the second part out loud for a while: "They have shifted from an analytics tool to a data collection tool with GA4. It is an amazing shift for power users, but does not seem to sit well with regular users." Looker, and Looker Studio with it, is a builder: hand it sources and it will let you compose any chart you can imagine. Both are excellent tools for someone whose job is analytics.
The founder paying an agency is not that person. Their question is narrower and harder: what moved this month, is anything wrong, and what did you do about it. A blank canvas answers none of that, so someone at the agency fills the canvas with tiles, and the result is what our audience research keeps quoting back at us: "reports full of jargon, green arrows, and charts that don't really mean anything." One Hacker News commenter called it the "any data is good data" trap — big, beautiful dashboards full of irrelevant, misleading data. I have built that dashboard. It ships fast and it gets read never.
What Analytics does instead
One page, four tabs, one shared date range that lives in the URL.
Overview is the tab a founder opens. It carries a row of cross-source signals (visitors, Spotlight clicks, support conversations, satisfaction, uptime), one "Audience over time" chart with all three sources on a shared axis, and Needs attention: a deterministic, thresholded list where each row is one checkable sentence and a link to the surface that resolves it. The thresholds are code, covered by tests, rather than a judgement call made per client. A status page that isn't configured shows up there as a sentence, because an absent tile is indistinguishable from a healthy one that scrolled off. When nothing crosses a threshold, the list says "Nothing needs attention this period", which is an answer in itself.
Website is the organisation's own PostHog project, read in depth: five KPI cards with deltas against the previous equal-length period, visitors over time with the last period as a dashed line, traffic sources, top pages, devices, countries, entry and exit pages, UTM sources, week-one retention, a goal-conversion readout and a live "right now" tile. SharpOS installs no tracking and warehouses nothing for this tab. A platform admin connects the client's existing PostHog project once, the credentials stay server-side, and members read the result.
Spotlight and Support report on data SharpOS collects itself: link-page views, clicks and CTR by source, country and device; conversations by outcome, resolution and fallback rates, reply speed, unanswered questions with a link to triage them, and the assistant's token spend priced with the inbox's own table.
Roles do the rest. Any readable member sees Overview and Website; the two agency-internal tabs are editor and above; the whole surface sits behind the Analytics feature flag, and Spotlight and Support additionally need their own. You can open a fixture version of it here: Analytics in the SharpOS showcase — browser-only, no account, nothing you type leaves the tab.
How it works
Three decisions carry the surface.
Each tab loads only its own source. Website, Spotlight and Support are separate tabs with separate loading states, and opening one never fetches the others. That matters because the Website tab's PostHog request is metered upstream: someone who opened Analytics to read the Support inbox should not spend a website query. Once a tab has loaded, its data stays warm while you move between tabs, and the website dashboard is cached per date window, so switching back is instant.
Spotlight and Support numbers come from daily rollups. Both tabs read pre-aggregated daily rows rather than scanning the underlying conversations or click events, because no capped scan answers a ninety-day question honestly, and the busiest organisations are exactly the ones a scan would under-report. The counters are updated by the same operations that record each event, and if a timestamp is unusable the counter is skipped rather than the event being lost. A reporting number is never allowed to be the reason a visitor's message fails to save.
A hidden tab is not enforcement. The tab strip is derived from what your role and your organisation's flags allow, but every tab re-runs its own check when opened, and every query re-asserts the flag and the permission on the server. A direct URL is never looser than the strip.
One more, because it is the kind of thing that bites later: the conversion event a client chooses is the only piece of caller-supplied text that reaches the website analytics query, so it is checked against a strict allow-list of characters and refused if it doesn't match. It is never quietly "cleaned" into a different name. A goal either matches exactly or the query doesn't run.
There is also a pin control on every KPI card. A member can pin up to six metrics to the hub home, and the pinned tile and the card it came from read one definition — because the first version had two, and home was quietly drawing a clicks line under a CTR label.
What it doesn't do
It is not a BI tool. There is no report builder, no data blending, no SQL explorer, no custom dimensions. If the client's team has an analyst who lives in Looker, they should keep Looker. Analytics is read-only, and the Website tab is only as good as the PostHog project behind it. Anything beyond the core visitor and session metrics is best-effort: a failed optional query hides its own block rather than the page, which is the honest way to say "we couldn't get that this time".
Historical Support numbers rebuilt from the raw tables are approximations; everything written since the rollups shipped is exact. And a viewer sees two tabs rather than four, by design.
Where it sits in the service
Analytics is where the Ads Management and Conversion-First Websites work gets read: the board that moved a card this week is one click from the number the card was meant to move. It ships inside every SharpOS workspace, and the feature page is at sharphaw.digital/features/analytics.
The question I keep coming back to
If you report to clients, what is the one number they actually ask about, and does your dashboard lead with it or bury it under eleven others?
Part of the series SharpOS, surface by surface. Part 1, the replacement ledger and the row we couldn't replace: We replaced a 12-tool client stack with one workspace we built.
Top comments (0)