# Google Ads Analytics Dashboard

**One reporting surface for two million events a day.**

The client's campaign reporting lived in four places: the Ads interface, GA4, a set of exported spreadsheets, and their own order database. Reconciling them was somebody's weekly job.

Canonical: https://technologiesninja.com/project-google-ads-dashboard.html

- Category: Analytics · Marketing
- Result: 2M+ events / day
- Store: MongoDB
- Status: In production

## The problem — Four sources, one weekly argument.

Every Monday someone exported campaign data, pasted it beside order data, and produced a report that disagreed with the ad platform. By the time it was reconciled the week had moved on.

The underlying issue was that no single system held campaign performance and actual revenue together at the grain decisions needed — search term, match type, device, geography.

At two million events a day, naive queries against the event store were not survivable during business hours.

## The hard parts — The volume changes the design.

- Two million events a day makes ad-hoc aggregation across raw events untenable
- Google Ads API quotas and pagination constrain how often data can be pulled
- Search-term and match-type data arrives at a different cadence than conversions
- Reporting queries must not compete with the transactional workload
- Attribution windows mean yesterday's numbers legitimately change tomorrow

## Architecture — Ingest, aggregate, serve.

01. **pull** — Scheduled jobs fetch campaign, search-term and conversion data within API quotas
02. **land** — Raw responses are stored in MongoDB, immutable, for replay
03. **aggregate** — Queued workers roll data into pre-computed views at the reporting grain
04. **join** — Aggregates are matched against the client's own order records
05. **score** — A custom scoring model ranks campaigns on contribution, not clicks
06. **serve** — The dashboard reads pre-computed views; ApexCharts renders them
07. **revise** — Late-arriving conversions trigger recomputation of affected windows

**Stack:** Laravel · Google Ads API · MongoDB · ApexCharts · Redis · Horizon · GA4

## What shipped — What the dashboard covers.

- Campaign, ad group, search term and match type performance in one place
- Device and geography breakdowns at reporting grain
- Conversions joined to the client's actual order records
- A custom scoring system ranking campaigns by contribution
- Pre-computed aggregates so reporting never blocks transactional load
- Recomputation when late conversions change a closed window

## Result — The weekly reconciliation stopped existing.

**2M+** — Events processed per day

Two million events a day flow through the pipeline and land in a single reporting surface, joined to real orders.

The Monday reconciliation job disappeared, and campaign decisions moved from click volume to contribution.

Because raw responses are retained immutably, any figure in the dashboard can be traced back to the API response that produced it.

## Read next

- Case study: [Click Fraud Detection Platform](/project-click-fraud-detection)
- Case study: [Shopify Attribution Tracking](/project-shopify-attribution)
- Service: [Tracking & Analytics](/service-tracking-analytics)
- Service: [Laravel Web Applications](/service-laravel-development)
- Article: [Queue Architecture for Scalable Laravel SaaS](/blog-laravel-queue-architecture)
- Case studies: [All case studies](/projects)

## Next step

How long does your weekly report take to trust?

- Book a consultation → /contact

---
© 2026 TechnologiesNinja · Built and maintained in-house