Atlas PPC Auditor
Making Google Ads findings reviewable, from account data to methodology.
Innovation & Strategy Analyst · Atlas contributor · 2026 · beta
I added model-output recovery, structured evidence and checkpoint methodology to Atlas’s Google Ads auditor.
In sixty seconds
I added model-output recovery, evidence and methodology to a Google Ads auditor now in beta.
- was
- A planner needs to inspect account settings and interpret campaign content.
- now
- Deterministic and model-assisted checks return findings with review criteria and evidence.
- the decision
- Retry unusable model output, and make the resulting finding inspectable.
- the run
- PPC Auditor demo →
- where it sits
- the map →
Opened · The account finding
A planner needs more than a score to decide what to fix.
A Google Ads audit reviews account settings, structure and campaign content. Atlas combines data checks with model-assisted analysis. My work made its findings easier to inspect and helped the engine recover when model output could not be parsed. The auditor is still in beta, according to my account of its current use.
The finding has to explain the check behind it.
Blocked · A response that cannot be used
A successful model request can still return a failed checkpoint.
One recorded failure involved truncated or garbled JSON. The API response arrived, but the parser could not recover a usable result. Retrying only timeouts or rate limits left that problem untouched. Separately, large evidence lists could make an otherwise useful audit difficult to persist within Firestore’s document limit.
Recovery needed to follow the failure boundary.
Reassigned · Rules first; interpretation second
I kept explicit account checks and model judgment distinct.
The engine runs deterministic checks first. Full scope then runs model-assisted checks; quick scope uses the deterministic path. I added a parse-level retry of the full model call with a larger output budget, separate from transient-request retries. I also added evidence and methodology so a planner can see what each finding examined and how to verify it.
A recoverable result still needs a reviewable explanation.
In progress · Trace the finding
0 of 92 checks, 0 findings.
checks
- Waiting for the audit.
findings0
- Waiting for the audit.
Scripted simulation on invented account fixtures. Check counts and elapsed animation time are demonstration values.
The result points to its source, criteria and limits.
Checkpoint methodology names the data sources, review criteria, verification steps and limitations. Structured evidence connects observations to affected account entities. Saved-run preparation trims oversized evidence progressively and marks the loss of detail. The intended workflow is analysis and planner review; the inspected audit path does not change campaigns.
One decisionA parse retry gives unusable model output another chance, at the cost of another call and potentially more tokens. Evidence trimming trades retained detail for a smaller stored result.
What brokeThe JSON fix raised the output floor and added a larger-budget retry; its historical PR also reduced concurrency. These are implementation changes, not a measured latency or accuracy improvement.
When it breaks
- JSON remains invalid after retry
- the system The affected checkpoint retains an error rather than becoming a pass.
- seen by The planner reviewing findings
- A check is skipped or unavailable
- the system Inspect its status. The current score counts all returned result entries in its denominator.
- seen by The planner interpreting the grade
- Evidence is too large to save intact
- the system Trim and mark truncation; minimal preparation still cannot guarantee every payload fits.
- seen by The saved-run reviewer
Completion, score and trustworthy evidence are different things.
Closed · The beta implementation
Recovery and explainability are the supported results so far.
My merged work supports a concrete account of parsing recovery, evidence, methodology and persistence preparation. A completed audit can still contain checkpoint errors, and its pass-rate score is not a model-quality metric. I have not included the old thirty-second comparison: the available records do not establish a matched benchmark or measured review-time savings.
Beta evaluation should measure findings and the work of reviewing them.
Next
Do again
Make the analysis useful enough that a planner can challenge it.
I would evaluate known account cases, track unavailable checks and reviewer corrections, and measure duration and model cost for each scope. That gives the next engineering change something concrete to improve.
Execution and failure walkthrough
Simplified implementation diagram. The examples below are synthetic, manually selected scenarios; they do not run Atlas or reproduce a production incident.
- 1Select account and scope
- 2Read Google Ads data
- 3Run deterministic checks
- 4Run model checks in full scope
- 5Calculate score and attach methodology
- 6Save findings for planner review
Synthetic walkthrough · Trace a finding
- Input
- Synthetic account: customer.auto_tagging_enabled = false.
- Failure or finding
- The deterministic auto-tagging checkpoint fails.
- Implemented response
- A planner can inspect the account setting and check the criterion. Model-assisted naming findings require a separate review of the names supplied to the model.
- Limit
- A failed setting and an interpretive recommendation have different evidence requirements.
System diagrams · Carl Illustration Engine
Static implementation models, with no runtime telemetry. Expand a view to inspect its branches; scroll wide diagrams sideways or open the SVG at full size.
Google Ads auditor: scope, evidence and review
Auditor: unusable model output and oversized evidence
Broader contribution history
Selected source-reviewed contributions from distinct revisions. Diagrams and walkthroughs use abstract or invented inputs.
Account history needs a different explanation
My related Change Reporter contributions address what changed in an account, alongside the auditor's question of what is configured now. The broader history includes GAQL corrections, saved sessions, account overview, report exports and later review-workspace changes. Those contributions belong to the account-analysis story, with their own evidence limits.
An account event is not proof of its performance impact.
In the selected September report-processing contribution, a reviewer can exclude cards and edit the narrative. A pure filter rebuilds selected change groups and manual/automated counts. Clearing an override removes its top-level and nested forms; that prevents an old edit from surviving invisibly in the generated view.
I also repaired a boundary between campaign data and coverage metadata. The inspected follow-up excludes metadata entries from the neglected-campaign processor and baseline matching, so a truncation marker cannot become a fictional campaign row. That is a concrete data-contract fix, not a claim that every heuristic is accurate.
Inspect: Change Reporter edits, storage and retained evidence
Metadata must stay outside campaign rows.
The saved-report path distinguishes two kinds of evidence loss: trimming change history and compacting baseline history. It reconciles the saved-change count with the retained array and gives the UI and PDF different disclosures for those conditions. A readable export should not suggest that all queried evidence survived storage.
I keep the archive's scope visible.
One limitation remains in the selected neglected-campaign calculation: it searches returned changes for a campaign and uses “Never” when none is found. Absence within a fetched history window does not prove that a campaign has never been edited. I would explain that limit before using the label as an operational recommendation.
An invented walkthrough starts with three grouped events and one campaign baseline. The reviewer excludes a card, edits the summary, then clears the edit. The reconstructed result should update its selected counts and remove the override. A storage-compacted version should disclose lost detail, and a metadata sentinel should never appear as a campaign.
The fixture makes retained scope visible.
This walkthrough uses invented account events. I did not query Google Ads, generate a live model report or change a campaign during case-study research. The source supports the implemented processing and disclosure contracts; causal performance gains and operator time savings still need measured records.
How the contribution developed
My authored history connects model-output recovery and deterministic checks with evidence/methodology, then adds later review workspaces, checkpoint guidance and Change Reporter processing. The chapter history keeps those changes and supporting test/export repairs attached to their original dates and states. The August audit snapshot and later September report patches remain separate source revisions.
Explore all Atlas contributions →Ask me about
- What does the grade actually measure?
- The inspected calculation divides passed checkpoints by all returned result entries. Warning, failed, skipped and error entries do not count as passes. The grade therefore mixes account findings with execution gaps; it is not campaign performance or model accuracy.
- Can you rerun one checkpoint?
- The inspected single-checkpoint entry point is a stub returning skipped. I do not present individual reruns as an implemented recovery feature.
- What remains after minimal storage trimming?
- Status, an abbreviated observation, methodology and selected source metadata can remain, while detailed affected entities are dropped. A reviewer must account for truncation when checking a saved finding.
Built with
Hire me
I'd build this for your team.
I am looking for an applied-AI engineering role at a company with real operations to automate. The résumé is one page.