- Headline result
- 7 tools → 1 view
- Client
- Sweden's largest motorcycle education platform
- My role
- Operations Lead, designed and built it
- Scope
- GA4, Search Console, Shopify, ActiveCampaign, GoHighLevel, SamCart, legacy analytics
- When
- August - September 2026
The problem
As Operations Lead, every question about the business meant logging into a different tool. Traffic in Google Analytics, sales in Shopify, email in the CRM, search in Search Console, ads in two more dashboards. Comparing any two of them meant exports and a spreadsheet that was wrong by the time it was finished.
Twelve years of history sat in exports nobody trusted. Year-over-year signup comparisons were guesswork because the signup dates had been lost in a CRM migration years earlier. When traffic dipped, nobody could say whether it was seasonal, a Google update or a tracking problem, because the data sets had never been in one place.
The team needed one screen with numbers that agreed with each other. Not a BI project, a working tool.
What I did
One Supabase warehouse that ingests every platform, a set of per-day rollups the dashboard reads and a private Next.js command center on top. GA4 + Search Console + Shopify + ActiveCampaign + GoHighLevel + SamCart + the old Universal Analytics history → Supabase → materialized views refreshed by pg_cron → live dashboard with traffic, sales, email, SEO, ads and operations pages.
A daily mirror writes the rollups into eleven Google Sheets as a redundant copy the team can open without a login. If the dashboard ever goes down, the numbers are still there.
Ads came in last. Google Ads through the official API with a five-year daily backfill and a self-refreshing cron. Meta Ads through Meta's own tooling, which surfaced a pixel match quality of 4.4 out of 10 before a single ad was bought. That is the kind of thing you want to know before spending.
Most of it was built by orchestrating AI coding agents. Three Claude agents worked on the same live codebase at the same time, each in its own git worktree and branch, with a type-check and a production build gating every deploy. My job was the architecture, the data model and the gates.
How it works
Pull, never push, with one service account
Every source is read through its API with read-only access. Nothing writes back to a production tool. Big tables are partitioned by year so twelve years of history stays fast to query.
Historical from the warehouse, current from the live API
Numbers for past periods come from stored data. Numbers for today come from the live API with a stored snapshot as fallback. The dashboard never shows a blank tile because a provider is slow.
Recover the lost history properly
I rebuilt five-plus years of signup history by dating each contact from its true double-opt-in event across thirteen export files, deduped by email. Opt-outs were excluded so the archive stays GDPR-clean. 5,599 contacts unified and a broken year-over-year metric fixed.
Let the database do the refreshing
1.3M+ Search Console rows would make any page slow if queried raw. Per-page materialized views refresh every six hours inside Postgres with pg_cron. The dashboard reads a small table, not the ocean.
Self-healing ingestion
Every sync cron is wrapped: retry with backoff on transient errors, a heartbeat on success, an alert on real failure. A checkup against the destination table decides whether the sync is done, not an exit code.
Three agents, one repo, zero collisions
Each agent built in an isolated worktree on its own branch and its own dev port. I rebased their work together, ran tsc and next build as a pre-flight and deployed once. Zero reverts.
Results
- 7 platforms and 12 years of history unified in one warehouse
- 5,599 contacts unified from 13 export files, year-over-year signups fixed
- 1.3M+ Search Console rows kept fast with per-page materialized views, refreshed every 6 hours
- 5 live analytics pages shipped in one build cycle
- 5 years of Google Ads daily metrics backfilled, refreshed by a daily cron
- Meta pixel match quality of 4.4/10 found before any ad spend
- Surfaced a 2 to 3x organic recovery opportunity and diagnosed zero-click CTR erosion the team could not see before
- 11 Google Sheets mirrored daily so the team reads the numbers without a login
What this means for your business
A dashboard is not the point. The point is that the founder sees the whole business on one screen instead of logging into ten tools and that the numbers agree with each other. If your reporting is a monthly spreadsheet somebody assembles by hand, this is the same build at your scale: pull every tool into one database, let it refresh itself, put a clean view on top. Happy to grab a call to see which tools you run and where the numbers disagree today.
Tools
- Supabase
- PostgreSQL
- Next.js
- Vercel
- Google Sheets API
- GA4
- Google Search Console
- Shopify
- ActiveCampaign
- GoHighLevel
- Google Ads API
- Meta Ads
- Claude Code
Skills
- Business Intelligence
- Data Warehouse
- Dashboard Development
- Marketing Analytics
- API Integration
- Reporting Automation
- AI Automation
- Operations Manager
- Marketing Operations
Questions
Does a small business need a data warehouse?
If one question needs three logins, yes. It does not have to be big. One Postgres database, read-only API pulls from each tool and a few rollup tables. The dashboard is the easy part once the data lives in one place and refreshes itself.
How do you combine GA4, Shopify and email data into one dashboard?
Pull each source into its own tables on a schedule, then build per-day rollups that join them on date. Historical numbers come from the stored data, today's numbers from the live API with a snapshot fallback. Here that is Supabase with pg_cron doing the refreshing and Next.js on top.
Can AI coding agents build a production dashboard?
Yes, with gates. Three agents built this one in parallel, each in its own git worktree. Every deploy had to pass a type-check and a production build first. The agents wrote most of the code. I owned the architecture, the data model and the sign-off.
How do you recover customer data lost in a CRM migration?
Go back to the earliest evidence you have. Here it was thirteen export files with the original double-opt-in timestamps. Date each contact from that event, dedupe by email, exclude opt-outs and load it as history. 5,599 contacts came back and the year-over-year chart made sense again.