Built around how you read your data — not a generic template.
A private, live dashboard — your own URL — that pulls your real website traffic out of Google Analytics, mixes in your own data, and turns it into a few numbers that actually tell you what to do.
Google Analytics' default screens — a wall of charts you scroll past, never sure which number matters or what it's telling you to change.
A handful of metrics you chose, framed as decisions: "traffic's up but signups flat — fix the page, not the ads." Built around how you think.
Same muscle as Class 1: you describe what you want, Claude builds it, you refine. Today we point that muscle at your data.
If you did the prerequisites, two connections already exist — that's why class time is for building, not installing.
Google Analytics — Claude can read your real traffic (read-only).
Supabase — your own database, empty and waiting, with Claude connected to build in it.
1. Move your analytics into your database, on a schedule.
2. Build a dashboard on top of it — designed around your decisions.
3. Ship it, lock it, and put it somewhere you'll actually look.
Not set up yet? Follow the prerequisites guide.
No real data yet? Analytics empty, or didn't get your Google tag installed in time? You can still build everything today with realistic practice data — the next slide shows you how.
If your Google tag wasn't installed in time — or your analytics is still empty — you can build the entire dashboard today on realistic practice data. Once your Supabase connection is set up, paste this into Claude Code:
Claude fills your database with ~90 days of practice data, shaped exactly like real Google Analytics — so your dashboard won't change when you swap in your real numbers later.
Going live later is easy. Because the sample data matches the real shape, your finished dashboard just works once real analytics starts flowing — nothing to rebuild.
It records everything that happens on your site: visitors, pages, where they came from, what they did. It's real and it's read-only — Claude can look, never change it.
The catch: it's raw, and it lives locked inside Google.
The database that holds your data. Claude can build in it freely — keep a copy of your analytics, add your own data (signups, sales, notes), and shape it however the dashboard needs.
This is where the real work happens.
Analytics is just the start. As you record more about your website and business — signups, sales, support tickets, ad spend — it all lands in this same Supabase. The more you record, the deeper the insights you can draw across all of it.
When you connected Claude to Supabase, you installed its MCP server — a remote control Supabase hands to Claude: a set of clearly-labeled buttons it can press to do real things, reliably. Without it, Claude can only talk; with it, it can act.
Claude can only tell you what to do — "create a table like this" — and you'd have to do it yourself in Supabase.
Claude presses the buttons itself — creates tables, runs queries, deploys functions — directly in your real database.
"Isn't that just an API?" An API is the raw machinery a service exposes; an MCP server is a standard wrapper around it, built so an AI can use it reliably without custom wiring. Like a universal remote — one set of controls any tool can offer.
It's tempting to start with the pretty charts. Don't. A dashboard is just a window onto data — and right now there's no data to look at. If you design the screens first, you're guessing at numbers that don't exist yet.
Part 1 (now): the data pipeline. Part 2 (after it's proven): the dashboard — in a fresh session.
"Database" sounds technical. It isn't, really. Your Supabase project is a stack of tables — and a table is a spreadsheet with named columns and rows.
One spreadsheet for one kind of thing. A daily_traffic table might have columns for date, visitors, and signups — one row per day.
You never touch it directly. Claude creates the tables, fills them, and reads from them — through the Supabase plug you connected. You just say what you want stored.
That's the whole mental model. Tables = spreadsheets. Claude designs them and does the typing; you just decide what data you want stored.
Your analytics is in Google. Your database is in Supabase. Something has to carry data from one to the other. That something is a serverless function — a tiny program that runs without a computer of your own to host it. (Supabase calls its version an edge function — same thing, their branding.) Think of it as a small robot that fetches numbers from Google Analytics and drops them into your database table.
At its core it's just a program that does one job. You decide when it runs — on a schedule (say, every morning) or on demand when you trigger it. No laptop open, no server to manage. Claude writes it and deploys it for you.
For the robot to read your analytics, it logs in as the service account you set up in the prereqs — basically an email address Claude uses to access your data. That's the credential that lets the bridge cross.
Paste this and let Claude build. Note the last line: don't just build it, test it and show you real rows before you trust it.
Notice the wording: describe the goal, not the how. You don't need to know about tables or functions — that's Claude's job.
Claude shows you real rows of your real numbers in the table, and the job is scheduled to keep running. Don't move on until you've seen real data land.
Once you've seen real rows, stop here. The dashboard is a fresh session, for a reason.
🧪Analytics still empty? The GA pull above will come back with nothing to store. Load ~90 days of practice data instead — paste this and build the whole dashboard today:
/impeccable init. Now you design.Start clean: open a fresh Claude session and run /impeccable init to lay down the dashboard's design foundation — exactly like the website in Class 1.
The pipeline was data work — no look, no feel. /impeccable init gives the project its PRODUCT.md and DESIGN.md. Tell it: this is my private analytics dashboard, and here's the vibe.
It's internal — only you ever see it. No brand to match, no one to impress. Go wild with the look; as serious or silly as you want, easter eggs and all.
Pick a whole aesthetic — make checking your numbers something you enjoy:
This grows into your whole-business cockpit. Today it's a GA4 panel — but like your database, it's the one place you'll build every view: customer service, acquisition, product, SEO & AEO (next class). Don't worry about fitting it all in now — you can always rearrange the layout and add new views as you go.
Google Analytics dumps raw numbers on you and never says what to do with them. A good dashboard fixes that — built around the decisions you actually make, not a generic template.
Tell Claude the decisions you care about and have it build the screen that answers them — lead with the answer, not a wall of charts.
Most people don't know what to ask for — that's fine. This is where Claude shines: ask it to suggest the metrics worth watching for a business like yours. It surfaces things you'd never have thought to include.
One rule, whoever picks the metrics: the dashboard must explain itself — every number says what it means and what to do about it.
Analytics hands you raw counts — visitors, page views, sessions. The insight is usually in the numbers you build from them. A raw count says "what happened." A synthetic metric says "is that good, and is it getting better?"
500 visitors. 12 signups. 40 views on the pricing page. Numbers with no verdict attached.
Signup rate (12 ÷ 500 = 2.4%). Week-over-week change. Traffic-to-pricing ratio. Now each number argues for a decision.
This is the difference between a dashboard that reports and a dashboard that tells you what to do next.
The first build just gets your information on the screen — rough and ugly is expected. Here's the loop that takes it from there:
/craft. Tell Claude to use Next.js, not plain HTML — an interactive dashboard needs it./bolder, with direction — not just "make it bolder." Say what you like, don't like, and what's missing. (For a dashboard, bolder means clearer — stronger hierarchy, not louder colors.)Most important — it's a living dashboard. The real refinement starts once you use it: that's when you find what's useful, what's noise, what's missing. You keep reshaping it as you work — it's never "done."
While you're looping, you don't want to ship to Vercel and wait a minute to see each tweak. A local preview runs the dashboard right on your laptop and refreshes the second Claude changes something — so the loop above happens in real time, right in front of you.
You set up nothing. Just tell Claude:
Say "in my web browser" — it matters. Without it, the preview can open in a cramped little panel inside VS Code. That phrase pops it open full-size in your real browser (Chrome, Safari…). Leave the tab up while you build — it updates itself. When it looks right, then you deploy.
Same move as the website in Class 1: push it to Vercel and you get a real link that's always up — so your dashboard is something you actually open, not a thing you have to run by hand.
This is a separate deployment from your Class 1 website. Different project, different URL — that's expected. Two next things matter before you share it: lock it, and decide where it lives.
It's live the moment Claude finishes — but right now anyone with the link can see your numbers. Fix that next.
This dashboard shows your real business numbers. It should not be open to anyone with the link. There are two layers you can lock it at:
Vercel has a built-in gate — Deployment Protection. Flip it on, set one password, done. No code, nothing to build. You do this yourself in the Vercel settings (a quick browser click).
Want proper accounts (and maybe more than one viewer later)? Have Claude build a real login page using Supabase Auth — the same Supabase you already connected. More to build, but it's a true login.
For a dashboard only you look at, the Vercel password is plenty. Reach for Supabase Auth when you want named accounts or to share it with a teammate — and it's not just email/password: you can add "Sign in with Google" (or any other provider) and even passkeys. Don't know how? Just ask Claude.
Your dashboard is a separate deployment with its own Vercel URL. That's completely fine to leave as-is. But if you'd like it under your own domain, you can give it a tidy address like dashboard.yourdomain.com.
Bookmark the Vercel URL and move on. Nothing to set up. Honestly, plenty good for a private dashboard.
If you own a domain, point a subdomain at it: dashboard.yourdomain.com. Cleaner to remember, and it sits alongside your main site.
There's no wrong answer — it's your dashboard. As long as you can get to it, you're done.
This is the same habit from Class 1, and it holds today too. When something doesn't work — the pipeline errors, the dashboard's blank, the deploy fails — you don't go hunting for the fix. You describe what happened to Claude and let it diagnose:
Claude reads the error, knows the usual causes, and walks you through it — the same way it ran the whole build. It can almost always get you unstuck.
Still stuck after a couple of tries? Email me at eric@stratengineai.com and I'll walk you through it.
Want this kind of decision tooling built for your whole business — not just your website? That's what we do at StratEngine. Come talk to me: eric@stratengineai.com.