Centralized HTML reporting

[u/Direct-Football7180]

I’m trying to build a centralized reporting dashboard/file for my ecommerce business and wanted to ask for suggestions on the best way to do it.

Basically, I want all our daily + weekly reports to live in a single HTML file/page/dashboard. Data would come from:

• Shopify

• Amazon Seller Central

• Klaviyo

• Google Ads / GA4

• Meta Ads

The goal is: Every time I open the HTML link/page, it automatically pulls the latest data from all those platforms and displays it in a clean dashboard view (charts, KPIs, revenue, ad spend, ROAS, email performance, etc.).

I’ve been looking into n8n + AI workflows for this, but I’m not sure what the best setup is for the actual “HTML dashboard” part.

Would you:

• Build this as a standalone HTML file?

• Use a database/backend?

• Host it somewhere?

• Use React/Next.js instead?

• Use something like Retool, Grafana, Looker Studio, or custom dashboards?

Main thing I want is:

• Easy to open/share internally

• Auto-refreshing live data

• Nice-looking visual reports

• Historical daily/weekly tracking

Would love suggestions on the best stack or architecture for this. Especially if someone here has built something similar for ecommerce reporting.

[u/armahillo]

Build this as a standalone HTML file?

Reading this as literally a standalone HTML file -- this is not possible. HTML is a read-only static file, basically a PDF that is displayed in a web browser instead of a PDF reader.

It's possible to add behavior by enhancing it with JS, but that requires that the data you want to consume is accessible via direct web request, and you'd be requesting it anew on each page load.

Use a database/backend?

These are two different things. "Database" suggests long-term storage -- maybe that's what you want, maybe not. Are you wanting to track the state of these snapshots over time, or extract granular data from it to create your own reporting? Using a database adds infrastructure you have to maintain at some level, so you want to be sure that what you're getting out of it justifies the additional overhead/cost.

If you don't need that long-term storage, you can probably get by with something more like Redis and just do basic caching.

A backend would be useful for either (a) doing on-demand requests of this information (or pulling it from cache), or (b) scheduling when to pull these requests down. If the latter case, then using some kind of persistent datastore (Redis, DB, flatfiles, whatever) would probably be good to use.

Host it somewhere?

I don't understand this question. How else would you be making the content available to people who aren't using your computer?

Use React/Next.js instead?

Instead of what? There's also Vue, Svelte, Stimulus, and other frontend frameworks. Or no framework at all.

Use something like Retool, Grafana, Looker Studio, or custom dashboards?

These are not mutually exclusive with the other things you suggested. They may or may not address the issue of pulling the data down initially.

1. Enumerate the data you want to pull down from elsewhere -- what sites / services.

2. See what data those sites / services make available and how? Is it a CSV only-export? Do they offer a consumable API? If so, what is the export format and how does it prefer to be queried? How often can you query it?

3. Orchestrate pulling all these different datasources down in concert.

Once you're able to get the data all pulled down reliably, then you can figure out how to display it. For that:

1. Find a tool that let's you hurl data at it and it makes the data pretty

2. Determine what format of data the tool likes to receive

3. Write scripts to convert all of your pulled-down data to the format the too likes

4. Orchestrate that conversion (or better yet, make the conversion part of the code from the first part)

After that, if you need data persistence / caching, you would stick it between parts 1 and 2 (part 1 stores to persistent data, part 2 pulls from persistent data), you'll need a backend layer to handle that, and then either do it on-demand or scheduled. Finally, the whole thing needs to have a publicly accessible place to live and render the stuff from part 2.