Skip to content
MAX GOLDBERG
← ALL WORK/

CASE / 01 OF 7

2026 · Independent consulting stack

Google Ads Optimization Engine

406 TESTS

IN PLAIN TERMS

Businesses spend millions on Google Ads, where one careless change can quietly waste weeks of budget. I built software that inspects an entire account every week the way an auditor inspects books, explains what it found in ranked order, and ships approved changes with a safety system that shows exactly what will change before it happens and proves afterward that it worked.

The situation

In 2026, after a decade running paid programs as large as $40M a year with teams of up to 13, I was the solo consultant responsible for a personal-injury law firm's Google Ads program: a seven-figure annual budget, dozens of campaigns, and weekly decisions about budgets, bids, and search terms. Reviewing an account that size by hand takes hours and still misses slow regressions. Editing it by hand is riskier: one misapplied change can quietly damage weeks of performance, and there was no team behind me to catch mistakes.

My job

Keep performance improving week over week, and make it structurally impossible for a change I shipped to hurt the account. Both halves mattered: analysis that catches problems earlier than a human skim, and an execution path safer than human hands.

What I built

  • Seventeen analyzer modules, each inspecting one dimension of the account: budget pacing, impression-share diagnostics, brand versus non-brand split, change history, GA4 cross-reference, incrementality, lead quality, and cost per signed case
  • One command that runs them all and produces a ranked readout where every recommendation cites the data behind it
  • A claim-verifier that checks every dollar figure in outbound reporting against the API before a stakeholder ever sees it
  • Offline conversion pipelines that feed the firm's actual signed cases back into bidding, so the account optimizes toward real clients instead of raw form fills
the analyzer library
$ ls google_ads_analyzer/analyzers/

ad_creative.py         conversion_tracking.py   ga4_cross_reference.py   landing_page.py
auction_insights.py    cpsc.py                  incrementality.py        lead_quality.py
brand_split.py         device.py                is_diagnostics.py        multi_language.py
budget_calculator.py   findings.py              claim_verifier.py        predecessor.py
change_history.py

17 modules. cpsc.py is cost per signed case: the number a law firm actually runs on.

The part I am proudest of is what the system refuses to do. Every live change is first rendered as a dry run: a plain diff showing before, after, and the rationale. Nothing executes until a human approves that exact diff. New campaigns are always created paused. After execution, a postflight step re-queries the live account and confirms reality matches the approved plan before the run is allowed to call itself successful.

mutation safety gate · live launch run
$ python3 launch_campaign.py --spec launch_spec.yaml --mode live

========================================================================
MUTATION DRY-RUN — explicit approval required
========================================================================
Type:       campaign_budget.create
Target:     customers/[REDACTED]/campaignBudgets
Identifiers:
  campaign_name = '[CLIENT] - New Practice Area - CA'
Before:     None (new resource)
After:      daily_budget=[REDACTED], delivery=STANDARD, shared=False
Rationale:  approved launch spec, hash 21aa7b29...fffb7b56
------------------------------------------------------------------------
Type "y" or "yes" to execute. Anything else cancels.
========================================================================
y

  phase budget     done   customers/[REDACTED]/campaignBudgets/...5724
  phase campaign   done   customers/[REDACTED]/campaigns/...1202   (created PAUSED)

  postflight: re-queried live resources, state matches approved spec
  run archived: reports/launch_20260610_180540.json   mode=LIVE (hard fail)

Condensed from a real campaign launch, June 2026. Client identifiers redacted; the dry-run wording is the tool's verbatim output.

How a change ships

01
Analyzers scan the full account and rank what they find
02
A proposed change is rendered as a dry-run diff: before, after, rationale
03
A human approves that exact diff, or nothing happens
04
The change executes through the API; new campaigns start PAUSED
05
Postflight re-queries the live account and proves it matches the plan
06
The run is archived with its spec hash for the account's change history

Every live change takes this path. No step is skippable.

The results

406

automated tests passing

suite run July 2026

17

analyzer modules, one per account dimension

100%

of live changes postflight-verified

≈6 HRS

of weekly analysis returned to strategy

hours of review down to minutes

  • Weekly full-account analysis went from hours of manual review to minutes, and ran every week in production
  • A value-based bidding migration and a signed-case optimization program shipped onto the live account entirely through the safety pipeline
  • Every production mutation in the system's history carries a matching postflight verification record
  • The firm's leadership ran on its weekly readouts: plain-English reports whose numbers were machine-verified before sending
  • Built solo with Claude Code as the development environment; the test suite is what makes that speed safe

The pattern is portable. Any team running serious paid media on top of a CRM, whether Litify, Salesforce, or HubSpot, has the same gap between dashboards and safe execution. This system is what closing that gap looks like: marketing operations run with the discipline of production software.