Automate Client Reporting With n8n: Multi-Source Weekly Reports on Autopilot

Friday afternoon at most agencies looks the same: someone opens GA4 in one tab, the ad dashboard in another, a spreadsheet of campaign numbers in a third, and starts copy-pasting figures into a report template for each client. An hour per client, multiplied by however many clients, every single week. The numbers are stale by the time the email sends.

To automate client reporting with n8n is to delete that Friday ritual. One workflow pulls every data source, merges the numbers per client, drops them into a branded HTML template, and emails each client their own report on a schedule. The agency's role shifts from assembling reports to reading them before they go out.

The reason n8n fits this better than a single-vendor reporting tool: clients don't all live in one platform. One cares about GA4 traffic, another about ad spend, a third about a custom metric in a spreadsheet. n8n treats each as a node, so the report isn't capped by what one dashboard vendor decided to integrate.

What You Can Automate in Client Reporting

The reporting jobs that fit an n8n workflow:

• Pulling GA4 sessions, users, and conversions per client property
• Fetching ad spend and ROAS from the ad platform's API
• Reading custom KPIs (leads, revenue, pipeline) from a Google Sheet
• Merging all three into a single per-client dataset
• Computing week-over-week deltas so the report shows movement, not just totals
• Rendering one branded HTML report per client from a shared template
• Emailing each client their report and logging what was sent

The merge step is what turns three disconnected exports into one coherent report. The per-client loop is what makes it scale past two or three accounts without extra work.

The Client Reporting Pipeline

The structure every multi-source report follows:

Schedule → Fetch (parallel sources) → Merge per client → Render HTML → Send → Log

A concrete weekly run:

Schedule Trigger v1.2 (cron: 0 8 * * 1)  // Monday 8am
  → Google Sheets v4: read client list + custom KPIs
  → HTTP Request v4.2: GA4 runReport per property
  → HTTP Request v4.2: ad platform spend per account
  → Merge v3: combine by client_id
  → Code v2 (jsCode): compute WoW deltas, build HTML per client
  → Gmail v2: send one report per client item
  → Google Sheets v4: append "sent" log

The Merge node (v3) keyed on client_id is the hinge. Each source returns its own array; the merge aligns them so client A's GA4 numbers sit next to client A's ad spend and custom KPIs. Get the key wrong and you'll email client A's traffic with client B's spend, which is the kind of error that loses an account.

Step-by-Step Breakdown

1. Read the client list

A Google Sheet is the registry: one row per client with their client_id, GA4 property, ad account, contact email, and any custom KPIs. Adding a client is adding a row. This keeps the workflow logic stable while the client roster changes.

2. Fetch every source in parallel

Separate branches hit GA4, the ad platform, and the sheet's KPI columns. They run concurrently, so the report assembles in the time of the slowest single call, not the sum of all of them.

3. Merge per client

A Merge node (v3) in "combine by matching fields" mode aligns the branches on client_id. Now each item carries one client's complete metric set.

4. Compute deltas and render

A Code node calculates week-over-week change for each metric (a green number reads very differently from a red one) and substitutes the values into the HTML template. One item out per client.

5. Send and log

The Gmail or SMTP node runs once per client item, emailing each report to its own contact. A final Google Sheets append records what went to whom and when, so a "did the client get their report?" question has a one-line answer.

Implementation Patterns That Hold Up

Pattern 1 — Parallel fetch, single merge. Don't chain the data sources in sequence. Branch them off the trigger so GA4, ads, and the sheet load at once, then merge. A sequential chain that takes three slow API calls back-to-back can push a report past a timeout for no reason.

Pattern 2 — Template-driven HTML. The render step is substitution, not generation.

Code v2 (jsCode):
  const html = TEMPLATE
    .replace('{{client_name}}', row.name)
    .replace('{{sessions}}', row.sessions)
    .replace('{{sessions_delta}}', fmtDelta(row.sessionsWoW));
  return [{ json: { to: row.email, html } }];

Note the {{client_name}} and {{sessions}} placeholders are plain strings inside the template, swapped at runtime. No AI is involved in building a numbers report, and it shouldn't be — the figures must be exact.

Pattern 3 — Color-coded deltas. A raw number tells the client what happened; a delta tells them whether it's good. Compute the week-over-week change in the Code node and inject a CSS class so increases render green and drops render red. This single touch is what makes the difference between a data dump and a report someone actually reads. The App Analytics Dashboard template does this for GA4 data out of the box, flagging high bounce rates and zero-conversion channels automatically.

n8n Nodes You'll Use Most

The Merge node is the piece people underestimate. Its "combine by matching fields" mode is exactly built for this, but the matching key has to be identical across branches — client_id as a string in one source and a number in another won't align. Normalize the key type in a Code node before the merge.

Getting Started

1. Build the client registry sheet first. One row per client, every field the report needs. The workflow reads this, so get the schema right before wiring nodes.
2. Wire one source end-to-end. Start with GA4 alone: fetch, render, email to yourself. Confirm the numbers match what GA4's own UI shows before adding sources.
3. Add sources as parallel branches. Ads, then the custom-KPI columns. Merge on client_id after each addition and verify alignment.
4. Build the HTML template in one node. Brand it once. Test the rendered email against a real inbox, not just the n8n preview — email clients strip CSS aggressively, so inline your styles.
5. Turn on the per-client loop. Confirm each client gets only their own data. Send to internal test addresses before pointing at real clients.
6. Schedule and log. Monday 8am is a safe default. Every send writes a row so you can prove delivery.

One thing that bites agencies the first month: GA4's Data API has a daily quota per property, and a workflow that re-runs reports during testing can exhaust it before the real Monday send. Cache the GA4 response to a Google Sheet during development and read from the cache while you iterate on the HTML, then point at the live API only for the scheduled run.

If client reporting is part of a wider analytics setup, the n8n analytics automation guide covers the metric-collection patterns underneath. For agencies reporting on content performance specifically, the data reporting automation walkthrough maps the scheduled-digest pattern in more detail.

Start with one client and one source. Once that report lands in an inbox looking right, adding the second client is a spreadsheet row and the second source is one more branch.