How to build a marketing analytics dashboard with Claude Code

Rule of thumb: if the numbers must arrive without anybody exporting a file, if you need forty connectors maintained by somebody else, if clients expect a branded portal, or if a platform’s API changing is a problem you want to buy your way out of, rent, and if one free report in Google’s own tool already answers your question, use it and spend the fortnight on something else. Build when the meter is the problem: when the fifth client, the eleventh dashboard or the fourth data feed is the thing standing between you and looking at your own numbers, and when what a conversion means in your business is a definition you would rather own than accept. The survey figure above is the honest reason this is worth the effort: buying another tool is the thing this profession is already good at, and it has not moved the integration score in two years.

* The free-tier line that matters here is not the 500 MB of database, which holds years of campaign rows because this data is small and narrow. It is the pause: a free project stops after a week of inactivity, and a dashboard that gets read at the end of each month is exactly the project that goes quiet for a week and greets somebody with an error. Pro, from $25/mo, ends the pause, keeps 7 days of backups, and raises the allowances that matter once people are downloading board exports: 250 GB of egress (then $0.09 per GB) and 100 GB of file storage (then $0.0213 per GB), the latter being where your uploaded CSVs pile up.

Either way the dashboard is yours, and the only running costs are a database plan and a few cents of model usage a month. What differs is who builds it: a developer you pay up front, or you, describing each piece to an AI tool.

Prices and rates from supabase.com, developex.com, developers.openai.com and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Get it running, and write down what a conversion is

   An app booting against your own database, and a CLAUDE.md carrying the two definitions everything else in this build resolves to.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a marketing dashboard (organisation, data source, channel, campaign, impression, click, conversion, cost, revenue, dashboard, widget, reject) and recording two standing rules. First: a conversion means exactly one thing across this whole project, written out in a sentence I will give you, and no screen ever computes a rate for itself. Every rate comes from one place that guards its division, so a card can never show infinity. Second: every row belongs to an organisation, every access rule has to test both what the person may do and which organisation the row belongs to, and neither half is ever left out because the other one looks sufficient.

   Put both in the file, not only in this message. The second rule sounds like a technicality and it is the whole difference between a dashboard you can hand a client and one that shows them somebody else’s spend, and it is the rule most easily lost three weeks later, when a new widget needs a policy in a hurry.

2. 02

   Model the organisation first, then everything hanging off it

   The schema, with an organisation on every row from the very first migration. No sign-in and no screens yet, which makes this the cheap moment to discover your own exports carry a field nobody planned for.

   PromptModel the organisation and the campaign dataCopy

   Write the data model as Supabase migrations, with no authentication yet and an organisation reference on every table from the start. Organisations. Members linking an account to an organisation. Data sources, one row per file or platform somebody imports from, carrying the import’s status and counts. Then the campaign data in two shapes so I can choose later: a wide table of one row per date, channel and campaign with impressions, clicks, conversions, cost and revenue on it, and alongside it a campaign dimension with separate fact tables for sessions, cost and conversions. Then a rejects table holding every row an import refused, with the line number, the raw row and the reason. Then dashboards, and widgets belonging to a dashboard carrying their own type, title, configuration and position. Seed two organisations with deliberately awkward data: one with a campaign whose name contains a comma, one with the same fortnight imported twice.

   Ask for the second organisation now, not when you get to permissions. A single-tenant database hides every mistake you are about to make about who can see what, and a second organisation full of plausible-looking campaigns is the cheapest instrument you will build all week for finding them.

3. 03

   Hand over a real export, not a tidy invented one

   Go and download a real month from one ad platform before this step, and put the file in the project. This is the step where Claude Code working on files on your own disk is worth the most: it can open your export and tell you what is in it before writing anything.

   PromptImport a real exportCopy

   A real CSV export from my ad platform is in the project. Read it before you write anything and tell me what you found: the exact column names, the date format, whether fields containing commas are quoted, how it writes a zero or a missing value, any totals row at the bottom, and anything you cannot map onto my schema. Then build the import: a private storage bucket restricted to CSV and scoped so a person reaches only their own folder, and a server-side function that parses an upload with a parser that handles quoted fields properly rather than splitting on commas, checks the required columns are present, validates every row (dates parseable and inside a period I state, numbers numeric, nothing negative that cannot be, channel recognised), inserts what passes and writes every failure into the rejects table with its line number and reason. Never drop a row silently. Handle a re-upload as a decision: key each row on date, channel and campaign, and let me choose per import whether an existing row is skipped or overwritten. Then import my real file and show me three things: the accepted count, the full reject list with reasons, and the total spend of the accepted rows so I can compare it with the same figure in the ad platform.

   That last number is the point of the whole step. A total you can check against the platform it came from in ten seconds is what turns this from a plausible dashboard into one somebody will spend money on the strength of, and it is far easier to compare now than after two more layers of aggregation exist above it.

4. 04

   The six rates, then a library people compose from

   The arithmetic first and in one place, then the widgets over it. Ask for the rates as something the database computes rather than something a chart works out, because six widgets each doing their own division is how two cards on one board end up disagreeing.

   PromptBuild the rates, the widgets and the filtersCopy

   First the six rates, computed in one place and never in a component: click-through rate, cost per click, cost per thousand impressions, cost per acquisition, return on ad spend, and return on investment. Every one of them guards its division so a day with no impressions or a campaign with no conversions returns nothing rather than infinity, and I want to see what each returns for a zero case before we go on. Then the widget library: a line chart, an area chart, a bar chart, a pie chart, a metric card showing one number, and a data table. Each widget stores its own metric, grouping and title, and a dashboard stores the widgets on it and their positions as data so somebody can rearrange a board without a developer. Then one server-side function that answers a widget’s query, and build its database client from the caller’s own credentials rather than a service key, so the database applies that person’s permissions to every widget including ones added next year. Then four filters that apply to the whole board at once (date range, channel, campaign and country) passed into every widget’s query rather than filtering in the chart, and remembered between visits.

   Insist on seeing the zero cases before moving on. Every one of these six rates divides by something that is legitimately zero on a quiet day, and the first time anybody notices is when a client asks why their cost per acquisition is infinity. It is a ten-minute conversation now and an embarrassing one later.

5. 05

   Sign-in, three roles, and the rule with two halves

   Your database now holds what you spend and what it earned, and three kinds of person who should not have the same power over it. This is the step to read slowly.

   PromptAdd auth, roles, and the access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a profile row per account. Joining an organisation happens on the way in, and a person cannot choose or change which organisation they are in afterwards. Add a role enum of 'viewer', 'editor' and 'admin' in a roles table kept out of the account’s own record, plus a SECURITY DEFINER function that reads it, and give roles an organisation, so somebody is an editor of one organisation rather than an editor everywhere. Then row-level security on every table, and write every policy as two clauses joined: what this role is permitted to do, AND that the row belongs to the organisation this person belongs to. Never let a role check stand alone as if it were a boundary. On top of that, a per-dashboard grant table so a viewer can be given one specific dashboard, checked alongside the role rather than instead of it, and reachable from an invitation so the grant can exist before the account does and transfer when it is accepted. Then prove six things by querying as a signed-in account: the second organisation’s campaign rows are unreachable, its dashboards are unreachable, an editor of one organisation cannot update a dashboard belonging to the other, an admin of one cannot grant themselves access to the other’s dashboard, a viewer cannot create a widget, and a viewer cannot open a dashboard nobody shared with them.

   The third and fourth checks are the ones nobody thinks to run, and they are the reason this step exists. Both are performed by an account behaving entirely legitimately right up to the final clause, which is exactly what a rule that checks the role and forgets the organisation cannot tell the difference between.

6. 06
   Destination

   A summary that can only say what it knows, then reconcile

   The written paragraph at the top of the board, the ceiling on what it may spend, the exports, and the part most builds skip: check one channel against the platform it came from before anybody makes a decision from it.

   PromptAdd the summary, the cap, and reconcileCopy

   Add the written summary at the top of a board, built so it cannot invent anything. Compute first, with queries: this period’s totals for each metric, the same totals for the previous period of equal length, the change in each, and the same per channel and per campaign. Send only those computed figures to one server-side ai function, and instruct the model to describe what it was given without inventing a comparison, trend, projection or cause that is not in the numbers, and to say when a change is too small to matter. Print the figures it was given underneath and name the two periods. Then cap it before I ship: record every call with the account, the feature and the tokens used, and enforce a per-account hourly limit and a project-wide monthly limit I can change without redeploying, refusing politely when either is reached. Then exports: the board as a PDF, and the rows behind any single widget as CSV. Finally, reconcile with me: take one channel for one month, put your figures beside the same figures in the ad platform they came from, and account for every difference, including the rows sitting in the rejects table.

   Do this before anybody else sees the dashboard, on a month you already know the shape of. Every difference will be one of three things (a rejected row, a definition you and the platform disagree about, or a date landing in another time zone) and all three are cheap now and expensive in front of a client.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

Prove all of it by querying as a signed-in account rather than reading the code back. Make a second organisation with its own numbers and check, one query at a time, that it cannot be reached, including the two that look legitimate right up to the last clause: a viewer opening a dashboard nobody shared, and an editor updating a board belonging to somebody else entirely.

All eight serve a dashboard well enough that speed is not the deciding question. Three others are: whether the plan permits commercial use, since Vercel’s Hobby tier does not and client reporting is commercial. Whether it publishes from a private repository, given what this code sits beside. And whether a deep link resolves for a browser that has never seen your site, because a shared dashboard is a link somebody sends.

Rewrite the written summary so it can only describe numbers it was given. First compute, with queries: this period’s totals for each metric, the same totals for the previous period of equal length, the change in each as an absolute and a percentage, and the same per channel and per campaign. Send only those computed figures to my ai function, and instruct it to describe what it is looking at without inventing any comparison, trend, projection or cause that is not in the numbers I sent, and to say when a change is too small to be worth a sentence. Print the figures it was given underneath the summary, name the two periods being compared, and if a metric has no previous period to compare against, have it say so rather than skip it.

Add a "why did this move" action on any metric card. Compute the answer first with queries: the campaigns and channels contributing most to the change between the two periods, with each one’s absolute contribution and its share of the total movement, and whether the movement came mostly from cost, from volume or from conversion rate. Then send only those computed contributions to my ai function for two or three sentences in plain language. Show the contributing rows underneath, and where a single campaign accounts for most of the movement, have it say that plainly rather than listing three things as if they were comparable.

After every import, run a check for rows worth a second look, computed with queries: amounts far outside the usual range for that campaign, cost-per-acquisition or return-on-spend figures orders of magnitude away from that channel’s norm, dates outside the period I said I was importing, days that already had data before this upload, and any metric that moved more than a threshold I set. Then send the flagged rows to my ai function for one line each on why it might be a mistake, and show me the list with an accept or investigate action per row. Nothing is edited or deleted automatically, and the flagged count sits beside the import summary where the reject count already is.

Add a panel where I type a question about my own campaign data in ordinary words. My ai function turns it into a read-only query, runs that query under my own access rules so it can never reach another organisation’s rows, and uses the model only to word the answer. Under every answer, show me the query that ran, the rows it returned, and the period and filters that were in effect. Two hard rules: when a question needs data I do not import, it says so rather than estimating, and it never answers from what it already knows instead of from a query. It writes nothing, ever.

Add a spending ceiling to my ai function before I ship any of the features above. Record every call with the account that made it, the feature it came from, and the tokens it used. Then enforce two limits I can set without redeploying: how many calls one account may make in an hour, and a total for the whole project per month, refusing politely and telling the person when either is reached, rather than failing silently or charging on. Show me current usage against both limits on an admin screen, and log a refusal the same way as a call so I can see when a limit is doing something.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.