Contents
Multi-source Dashboards
The layer a client actually looks at. Every source a business has, their web analytics, their Google listing, their point of sale, their social, pulled into one dashboard that answers the questions an owner actually asks, in language they actually use.
The data is everywhere. The answer is nowhere.
A business owner can already log into four dashboards. Analytics here, their Google profile there, the point of sale somewhere else, social in a fifth tab. Each one shows a slice. None of them answer the questions that actually matter. Is marketing bringing in money, which channels are pulling their weight, and what should I do next week?
A dashboard that just re-displays those slices in one place isn't worth much. The job is to combine them. Put traffic, bookings, revenue, and reach against each other so the relationships show, and shape the whole thing around decisions instead of dumping every metric a tool can export.
One view, every source
Built in Looker Studio on top of the pipeline data, the dashboard unifies four sources that normally never meet: web analytics for traffic and on-site events, the Google Business Profile for how the listing performs in search and maps, the point of sale for real revenue and service mix, and social for reach and engagement. It's organized into tabs a non-technical owner can move through. An at-a-glance overview, then acquisition, engagement, revenue, and content. Each one answers a specific question rather than showing everything at once.
Built around decisions, not metrics
The hard part of a dashboard isn't pulling the data. It's deciding what not to show. Every source can export hundreds of metrics, and a dashboard that includes them all is a wall an owner bounces off. So each view is built backward from a question. Acquisition doesn't just list traffic sources. It puts sessions and bookings side by side so you can see which sources actually convert, not just which send the most clicks. Revenue ties the point-of-sale numbers to the day of week and the service mix, so a slow Monday or a high-margin service is obvious at a glance.
The language matters as much as the layout. The same translation discipline from the audit work applies here. An owner sees "booking starts" and "phone clicks," not event names and parameter keys. The dashboard is for the person paying for it, not the person who built it.
It recommends, not just reports
The piece I'm proudest of is on the content tab. Most reporting stops at "here's how your posts did." This goes a step further. It scores recent posts on reach and engagement and surfaces boost candidates, the specific posts worth putting ad money behind, with a suggested spend calculated from how they performed. That's logic I built into the dashboard, not a feature that came in the box. It turns a report the owner reads into a recommendation the owner can act on. That's the difference between a dashboard that gets opened once a month and one that drives what happens next.
One template, many clients
The dashboard is a master template, not a one-off. The structure, the calculated fields, the recommendation logic, and the plain-language framing are built once; a new client is a new instance wired to their own pipeline data. That's what makes it a service rather than a favor. Onboarding a business is connecting their sources and pointing the template at them, not rebuilding from scratch.
And it sits at the end of a system I built end to end: the data pipelines pull each source on a schedule and land it in clean storage; the dashboard reads from there. Ingestion, storage, presentation. One chain, built to run.
What it demonstrates
The skill to unify sources that don't naturally talk, the judgment to build around an owner's real questions instead of dumping every available metric, and the instinct to push past reporting into recommendation. A client-facing layer that makes scattered data legible, and tells the owner what to do with it.