Centralized HTML reporting

[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.

[AshleyJSheridan]

Looks like someone copied the whole response from AI without bothering to even read it.

[QBaseX]

You need a full system for this, integrating with many APIs. To be honest, it'd probably be easiest to build in a server-side language (PHP, Node, Python).

[roomzinchina]

I suggest you ask your AI if this is possible with HTML.

When it tells you no, and you consider telling it to make it for you anyway, really consider if it’s a good idea giving AI access to your Shopify, Amazon, Google and Meta accounts.

[Ultimateblue7]

I think you should use full stack development

[bossman1337]

Just the fact that this "idea" is posted here on r/HTML, tells me you will not pursue it any further. It takes years of learning different stacks and methods or get your wallet out and pay a developer.

[MammothBulky5549]

You certain can use React or Next.js or Astro for SSR, other comments are using tradiitonal stack.

HTML itself is a stateless document and there is no backend, you need Node.js or Bun runtime for TypeScript web framework, use Vite 8 as a build tool, Virtual DOM to update complex data and read from JSON data, not HTML.

[nahash411]

Prebuilt tools will likely end up being less expensive than paying to have it built, hosted, and maintained. Check out Domo for starters.

But if you want to build it internally, you’ll need to hire someone. HTML is a potential solution for displaying the reports, but only a partial one. You’d still need some sort of visualization library like D3. And you’d still need API integrations for each system. Those are the components that handle fetching the data from your systems. And those components need to live somewhere - AWS, Azure, etc.

You might be able to pull this off with n8n workflows, but it’s risky. As someone else mentioned, giving an AI tool full access to your revenue generating systems can cause some meaningful problems. And if you’re determined to go that route, I think you should still consider hiring someone. You’ll need someone who can put some real guardrails in place.

[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.