How to build a marketing analytics dashboard with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   A board on screen, and two rules written down

   Start with what you can see, and fix the two definitions in the same breath so they are not retrofitted later.

   PromptSet up the projectCopy

   Start a React and Tailwind project for a marketing analytics dashboard: a shell with a sidebar, a filter bar across the top and a grid the widgets will sit in. Use placeholder numbers for now and mark clearly in the code that they are placeholders. Then record two rules for everything that follows. 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.

   Ask for the placeholders to be marked as placeholders. On a build that starts with the screens, invented numbers are the thing most likely to survive into something somebody screenshots for a client, and a comment in the code is the cheapest way to make sure they get removed rather than forgotten.

2. 02

   The widget library and the editor, while it is cheap

   The step to spend real time on, because this is what people will judge the dashboard by and this is what this tool is best at. Six widget types, and a board somebody who is not you can rearrange.

   PromptBuild the widgets and the filtersCopy

   Build the widget library: a line chart, an area chart, a bar chart, a pie chart, a metric card showing one number with its change, and a data table with sorting. Each widget stores its own metric, grouping and title, and a dashboard stores the widgets on it and their positions as data rather than in code, so somebody can add, move, resize and remove widgets and have the layout persist. Then four filters across the whole board at once (date range, channel, campaign and country) held above the widgets and passed into each one rather than applied inside a chart, and remembered between visits. Make the empty state of every widget explicit and different from zero: a widget with no data yet must not look like a campaign that spent nothing.

   That last sentence is the one to insist on, and it is specific to this kind of application. Nothing and zero look identical on a chart, they mean completely different things to somebody deciding a budget, and getting the empty state right now is far easier than explaining the difference to a client later.

3. 03

   Turn around: real data, from a real export

   Download a real month from one ad platform before this step. Everything above this line is a mockup until this prompt has run, however good it looks.

   PromptImport a real exportCopy

   Connect a Supabase project, then replace every placeholder number with real data. First the schema, with an organisation reference on every table: organisations. Members. Data sources carrying an import’s status and counts. A wide campaign table of one row per date, channel and campaign with impressions, clicks, conversions, cost and revenue. A campaign dimension with separate fact tables for sessions, cost and conversions. A rejects table with the line number, the raw row and the reason. Dashboards and widgets. Then the import. Here is a real CSV export from my ad platform. Read it first and tell me the exact column names, the date format, whether fields containing commas are quoted, how it writes a zero or a missing value, and anything you cannot map. Then build a private bucket restricted to CSV and scoped per person, and a server-side route that parses an upload with a parser that handles quoted fields properly rather than splitting on commas, checks the required columns, validates every row, inserts what passes and writes every failure to the rejects table. Never drop a row silently. Key rows on date, channel and campaign so a re-upload is a choice between skipping and overwriting. Then import my file and show me the accepted count, the full reject list, and the total spend of accepted rows so I can compare it with the ad platform.

   Expect this step to change the screens you built in step 02, and let it. Real campaign names are longer than invented ones, real channel lists are untidier, and a table that looked balanced with six tidy rows will need work with forty real ones. That is the step doing its job, not going wrong.

4. 04

   The six rates, in one place, behind a query that respects the asker

   Move every calculation out of the components built in step 02 and into one place, then put a single query route behind the widgets. This is the least visual step in the build and the one that decides whether two cards can ever disagree.

   PromptBuild the rates and the query routeCopy

   Move all arithmetic out of the components and compute the six rates in one place: click-through rate, cost per click, cost per thousand impressions, cost per acquisition, return on ad spend, and return on investment. Every one 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. Then one server-side route that answers a widget’s query, taking the widget’s stored metric and grouping plus the board’s four filters, 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 go through the widgets from step 02 and make sure not one of them still calculates a percentage, a ratio or a total for itself.

   That last instruction is the whole reason this step is separate. Building screens first means arithmetic ends up in components, which is fine until two components disagree in front of somebody senior, and the cheapest moment to pull it all out is now, while you still remember which chart did what.

5. 05

   Three roles, and grants on single boards

   The permission model, and the one part of this build that cannot be judged by looking at it. Note that the roles here are about who may edit a board, so they change what step 02’s editor is allowed to do.

   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.

   Then go back to the editor from step 02 and hide what a viewer cannot do. The database refusing an action is what keeps you safe. A button that does not appear is what stops a client emailing to ask why the dashboard said no, and you want both, in that order.

6. 06
   Destination

   The summary, a ceiling on it, and one channel reconciled

   The written paragraph at the top of the board, the cap on its spending, the exports, and the check against the platform the numbers came from.

   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 route that calls the model, and instruct it 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.

   One thing to watch on a build that started from the screens: the summary is a visual element with a factual job, so it is unusually tempting to tune how it reads. Tune the layout as much as you like and leave the instruction alone. The sentence forbidding it to invent a trend is doing more for this dashboard than any amount of typography.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.