How to build a marketing analytics dashboard with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   A workspace, a database, and two rules written down

   An app running with Postgres beside it, and one request that fixes the definitions everything after resolves to.

   PromptSet up the projectCopy

   Create a React 18 + Vite + TypeScript app with Tailwind for a marketing analytics dashboard, add a Postgres database to this workspace, and get it running with the connection string in Secrets rather than anywhere the browser can read. Then fix the vocabulary before we build anything: organisation, data source, channel, campaign, impression, click, conversion, cost, revenue, dashboard, widget, reject. Two rules to hold throughout, written into the project’s notes rather than only agreed here. 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.

   Check where the connection string ended up before you go further. It belongs in Secrets and nowhere else (not in a file the browser downloads and not in a repository) and this is the one moment in the build where that is a ten-second check rather than an incident.

2. 02

   The schema, in the Postgres that just appeared

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

   PromptModel the organisation and the campaign dataCopy

   Write the data model as migrations against the workspace Postgres, 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.

   This is ordinary Postgres, which is the useful thing to remember all the way through: the migrations here, and the access policies in step 05, work exactly the way they would on any other Postgres host. What is different is only where identity comes from, and that is the next-but-one step.

3. 03

   A real export, imported by your own server

   Get a real month out of one ad platform and put it in the workspace. Here the import runs on the same server that hosts the app, which makes this a good moment to decide it should eventually run on a timer too.

   PromptImport a real exportCopy

   A real CSV export from my ad platform is in this workspace. 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: object storage for uploaded files, private and reachable only through my own server, restricted to CSV and scoped per person, plus a server endpoint 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. Make the whole thing safe to run twice with the same file, because it will be. Then import my real file and show me 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.

   The instruction about running twice safely matters more on this tool than the others, because the workspace makes it easy to put this import on a timer later, and the difference between an import that is safe to repeat and one that is not only shows up once nobody is watching it run.

4. 04

   Six rates once, then a library your own server answers for

   The arithmetic in one place, then the widgets over it, and a single query endpoint behind them that answers according to who is asking.

   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 endpoint that answers a widget’s query, taking the widget’s stored metric and grouping plus the board’s filters, and have it resolve the caller from the session and apply their permissions to the query, rather than querying as the database owner and filtering afterwards. 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.

   Note the wording about the query endpoint, which differs from the other five guides for a real reason: with no hosted identity service handing the database an account, filtering by the caller is something your own server has to do deliberately. Getting that one endpoint right is what makes every widget added later safe by default.

5. 05

   Sign-in your server owns, three roles, and both halves of every rule

   The step carrying the most weight on this tool. Sessions live on your own server, so the announcement of who is asking (and which organisation they belong to) is code you own rather than something a service does for you.

   PromptAdd auth, roles, and the access rulesCopy

   Add email-and-password sign-in owned by my own server: sign-up, login, logout, a 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. Then have the server announce to the database, on every request, which account is asking and which organisation it belongs to, and write every access policy to read that announcement. 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 announcement is the line to check by hand. If the server ever fails to make it, the policies do not complain. They simply stop distinguishing between people, and what they stop distinguishing is one organisation’s campaign spend from another’s. Test it by removing the announcement deliberately once and watching what the second organisation can suddenly see.

6. 06
   Destination

   The summary, a ceiling, 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, then publish, which on this tool is the same workspace.

   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 function that calls the model, with its provider key in Secrets, 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.

   Once the reconciliation is clean, publish, and consider publishing the import on a timer as its own scheduled release while you are there. A dashboard is only as current as its last upload, and the difference between a tool people check and a tool people forget is usually whether somebody has to remember to feed it.

One rule outranks the rest here: the database connection string and any model provider key live in Replit’s Secrets and nowhere else: not in anything the browser downloads, and not in a repository. Treat either one that escapes as burned, and replace it the same day.

All of these are Replit rather than a third party, so the choice is shape rather than vendor, and this build wants two of them: one to serve the pages, and Scheduled for the import once you would rather not do it by hand. Review who the app is visible to before the first release, since Publishing is what sets it, and on this application that setting decides who can read what you spend.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.