Stage 1 of 6 · Engagement Kickoff

Two Years of Account History, and the Documents That Explain It

Most AI analysis begins with whatever data it is handed and no idea what any of it means. This stage is the difference. Before the first analysis runs, we load the account’s history and we write down the things the data cannot tell anyone, in structured documents the system reads every single night.

Historical Backfill

Roughly two years of account history is assembled into one place and structured so it can be analyzed as a whole rather than one export at a time. Campaign, ad group, keyword, and search-term performance. Conversions by action. Spend, impressions, clicks, and impression share.

Alongside the performance data, the account’s change history is reconstructed and loaded: what was changed, when, and by whom, as far back as the platform retains it. From that point forward the record only grows.

Every analysis the system runs on night one already has two years of context behind it. It knows what your normal looks like before it ever tells you something is abnormal.

Account Brief

A written document describing what the account actually is, maintained per client and read by the system on every run. It covers the business and what it sells, who the buyers are and in what priority, how the sales cycle actually works, and the seasonality the account moves with.

It also records what every conversion action means, which ones are core and which are secondary, and which are retired predecessors that should never be read as broken tracking.

This is the document that stops the system from recommending something that makes numerical sense and business nonsense.

Targets, Thresholds, and Constraints

A structured rules document holding the numbers the system measures against, per campaign family rather than as one account-wide average: target cost per acquisition, click-through rate, cost per click, and conversion rate.

It also declares the constraints that are invisible in the data:

Protected Terms. Search terms the system may never recommend removing, whatever the performance looks like, because they are defended for strategic reasons. The system still evaluates them and still reports on them. It is simply forbidden from recommending action.
Budget Pools. Sets of campaigns that share a budget and are managed as one number. Money moves freely inside a pool and never between pools. Without this declared, a system will happily recommend a reallocation that is structurally impossible.
Approved Landing Pages. A closed list of destinations, so an ad pointing somewhere unapproved is caught rather than assumed intentional. Temporary client-approved exceptions are declared with a mandatory review date attached.
Data Integrity Windows. Dates before which specific metrics are known to be unreliable, because tracking changed. Any comparison whose baseline crosses one of those boundaries is measuring the tracking change, not performance. The system is told where those lines are and refuses to cross them.

Every one of these exists because a system without it produced a confident recommendation that was wrong for a reason no amount of data could have revealed.

Campaign Mapping

A separate document declaring what each campaign is for: which searches it is deliberately built to catch, and which it is deliberately built to refuse.

The binding rule is that intent determines routing and performance never does. A search term is never moved between campaigns because it is performing well somewhere it does not belong. Performance determines only whether the intended routing is working.

The mapping runs on multiple independent axes, because campaigns divide along more than one line at once. The axes are different in every account: product line, offer type, buyer segment, geography, delivery format. A campaign can be correct on one axis and wrong on another, and the map is what makes that visible.

Campaigns are declared only where a real boundary dispute exists. An undeclared campaign is analyzed exactly as it was before the document existed. Undeclared is not unfinished, and the file says so in its own comments, so that nobody later mistakes deliberate restraint for an incomplete job.

02

Stage 2 of 6 · Nightly Collection

The Complete Account, Read and Recorded Every Night

Not a sample, not a summary, and not the top hundred rows. Every night the system reads the complete account and files it as a dated record that is never edited afterward.

The pipes run inward. The system uses APIs and scheduled pulls to bring data in, and nothing structured goes back out. Everything is collected, merged, analyzed and stored inside an isolated instance, and the briefing is the only thing that leaves it.

Performance Data

Every campaign, ad group, keyword, and search term that spent money in the trailing window. Conversions broken out by action. Impression share including the share lost to rank and the share lost to budget, so a campaign losing volume can be diagnosed as a bidding problem or a budget problem rather than guessed at.

Account State

A complete picture of what exists right now: budgets, bidding strategies, statuses at every level, ad copy and every asset within it, keywords, and every negative keyword at every level including shared lists and their memberships.

Fourteen separate report types per client per night, each one validated on arrival.

Change Capture

Every change made to the account that day, whatever time of day it happened and whoever made it, from three independent sources that are cross-checked against each other.

Why Three Sources and Not One

Google’s own change feed does not publish everything. Bulk edits made through certain paths and policy or approval transitions are structurally absent from it, and a system relying on that feed alone will report a clean night on a night when a great deal changed. We found that gap by measurement, not by reading documentation, and closed it by having the system compare each night’s account state against the previous night’s and record the differences itself. That comparison is the third source. It exists because the first two were not enough.

03

Stage 3 of 6 · The Account Archive

Private, Permanent, and Never Overwritten

Every client has an isolated archive. Data is never pooled across clients, never used to analyze another account, and never used to train anything.

The archive is a copy, not a source. The system doesn’t produce any of the underlying data; every number is pulled from the client’s own Google Ads account. The copy exists for speed, so two years can be queried in the moment, so each night can be merged into a running history, and so the API isn’t called every time a question is asked. The client’s account remains the system of record, and their access to it never depended on us.

Dated Account Snapshots

One per night, immutable. A snapshot is never edited after it is written. If something in it needs correcting, the correction is filed alongside it with a date and a reason, and the original stays exactly as it was.

A record that can be quietly edited is not a record. If the system could revise its own history, none of the rest of this would be verifiable.

The Change Record

A permanent, append-only history of every change made to the account: what changed, when, and under which login. It is only ever added to, never rewritten and never re-sorted.

Where the same change is captured by more than one source, the duplicates are reconciled rather than double-counted. Where a historical entry cannot be attributed with confidence, it is recorded as unattributed rather than guessed at. A blank is honest. A guess becomes permanent history and quietly corrupts everything downstream of it.

The Account Documents

The account brief, the rules and thresholds, and the campaign mapping, versioned alongside the data. This matters more than it sounds: a finding can always be judged against the rules that were in force on the night it was made, rather than against today’s.

Findings History

Every conclusion the system has ever reached about the account, retained so that each new analysis has to reckon with the last one rather than starting fresh and rediscovering the same thing weekly.

Operator Decisions

A separate record of questions that have been considered and closed. When the expert reviews a finding and rules that no action will be taken, that judgment is filed with the reason and a mandatory review date, and the finding stops being raised as new.

An entry missing its reason or its review date is treated as absent and raises a process flag, rather than being honored silently. A protection someone believes is in force and is not is worse than no protection at all. Each entry also captures the finding’s dollar impact at the moment it was filed, so if that number later moves materially the question reopens automatically rather than staying closed on stale grounds.

04

Stage 4 of 6 · The Analysis Team

Eight Specialists. One Job Each. Run in Strict Order.

This is not one general-purpose AI asked to look at an account. It is eight specialists, each with a single responsibility, a defined time budget, and a written specification stating exactly what it is permitted to conclude and what it is forbidden from claiming. They run in a fixed order every morning before the workday starts, because each one depends on the work of the last.

01

Data Validator

Pulls the reports from your account every night, then verifies every figure and every calculation before anything else runs.

Runs first, without exception. It confirms every expected report arrived, that the row counts are internally consistent, that the files describe the date they claim to describe, and that required columns are present and correctly typed. If the collection is incomplete or internally contradictory, the entire team stands down and the run halts loudly rather than analyzing data it cannot trust.

What it means for you: You never receive a recommendation built on partial data. A missing night produces an alert, not a quiet approximation.

02

Wasted Spend Detector

Checks every dollar spent against where it could have gone, so budget keeps moving toward the campaigns that earn.

Reads every search that spent money and every keyword serving against it, then checks both against the campaign mapping. It identifies spend that is not producing, and separately identifies routing problems where a campaign is catching demand that belongs somewhere else. Thresholds are set per campaign family rather than account-wide, and include a statistical floor so that a keyword with too little volume to judge is held rather than acted on.

What it means for you: Most agencies review search terms monthly at best. Yours are read every night, against your account’s declared design rather than against a generic idea of what good looks like.

03

Budget Pacing

Paces spend nightly, so you’re not losing impressions to underspend or absorbing an overspend you didn’t plan for.

Projects where every budget lands at month end, by channel and by budget pool, early enough in the month that there is still time to act. Because pools are declared, it will not propose moving money between budgets the account cannot move money between. It also checks the change record around any pacing shift, so a projection explained by a deliberate change is labeled as such rather than raised as a problem.

What it means for you: No end-of-month surprises, and no recommendations that are impossible to execute.

04

Anomaly Detector

Catches shifts in performance the night they happen, not in a monthly recap delivered too late to act on.

Compares current performance against the account’s own history rather than against an industry average, which means the baseline is your account and the sensitivity is tuned to your volume. Where a shift is found, it checks the change record around the inflection point and reports the movement as explained, unexplained, or explained by something that does not actually account for the size of the move.

What it means for you: A problem caught in a night costs a night. The same problem found on a monthly report has already cost a month.

05

Ad Integrity

Checks account health every night. Nothing disapproved, limited, flagged or broken goes unnoticed.

Verifies that every ad can actually run. Disapprovals and policy limits are the obvious cases. The harder ones are the reason this exists: an ad group can read as fully healthy at every status field the interface shows and still be serving nothing, because a single pinned asset carries a policy restriction and a pinned asset cannot be substituted. The ad cannot assemble, so it does not run, and nothing anywhere reports an error.

What it means for you: The most expensive failure in a paid account is the one that looks fine. This is the check for ads that are live, approved, funded, and silently earning nothing.

06

Why Engine

Joins changes to results. Turns “let’s try this” into “that worked, do more of it.”

Takes every finding the other specialists produced and tests it against the change record: is there something logged that actually accounts for this? It confirms, contradicts, or states plainly that nothing explains it. The bar is deliberately high. A change may only be cited as the cause of a movement if it can account for the direction and the magnitude. A budget increase logged the same week as a performance decline is a coincidence of timing, not an explanation, and the system is required to say so rather than take the convenient answer.

What it means for you: “Why did this happen” gets answered with evidence, or gets answered honestly with “nothing on record explains this.” Both are more useful than a plausible guess.

07

Report Writer

Ranks every recommendation by dollar impact, so the biggest problem is always the first one read.

Assembles everything into one briefing, ordered by severity and then by dollar impact within each severity band. It composes and it never concludes. It is forbidden from inventing a finding no specialist produced, from changing a severity or a dollar figure, from completing a partial answer into a confident one, and from overriding how a specialist resolved a prior finding. Each of those prohibitions is written down because a composer with access to raw material will use it analytically unless explicitly told not to.

What it means for you: The briefing is a faithful reproduction of what the analysis found. Nothing is smoothed over on the way to the page.

08

Record Keeper

A permanent, growing ledger of every change made to the account. It’s what lets the other agents explain performance instead of guessing at it.

Runs continuously rather than as a step in the sequence. It maintains the change history described in Stage 3 and reconciles the three capture sources against each other every night.

What it means for you: Institutional memory that does not leave, does not forget, and does not rotate off your account.

05

Stage 5 of 6 · Evidence Standards

What the System Is Required to Prove, and What Happens When It’s Wrong

The failure mode of AI analysis is not silence. It is a confident answer that nobody verified, delivered in the same tone as a correct one. Most of what we built is the verification, and the rules below are not aspirational. They are enforced constraints, and every one of them exists because the system once broke it and we made it impossible to break again.

Rule One

A Claim That Something Is Absent Requires a Complete Search

The system may not report that nothing blocks a search term, or that a negative keyword does not exist, until it has checked every level where the thing could exist: ad group, campaign, and every shared list the campaign belongs to. It must cite each one.

A negative conclusion drawn from a partial search is the most dangerous output in account analysis, because it reads exactly like a thorough one. “Nothing is blocking this” produces a recommendation to add something that is already there.

Rule Two

A Claim That Something Exists Requires Today’s State

Historical records prove that something happened, not that it is still true. A keyword created three weeks ago may since have been paused, removed, or never have served at all. Existence is resolved against the current state of the account, never against the change history.

These two rules are mirror images. The first forbids concluding absence from a partial search. The second forbids concluding presence from a historical one.

Rule Three

A Claim That a Change Caused an Outcome Requires a Comparison

The system may not assert that a change produced a result unless it has compared the account state before and after and cites that comparison. Proximity in time is not causation, and a change logged near a movement is a candidate, not an explanation.

Every Prior Finding Is Explicitly Resolved

Each analysis must account for every finding the previous one produced. It is resolved, carried forward, re-measured with both figures stated, or withdrawn because its premise turned out to be wrong. Silent disappearance is forbidden, because a finding that quietly stops being mentioned is indistinguishable from a finding that was fixed.

Corrections Are Permanent and Public to the Record

When the system gets something wrong, the correction is filed on the record with the reason, and the original stays. Wrong findings are not deleted. They are corrected in place, reviewed, and used to tighten the rule that let the error through.

The system withdraws its own claims. That is not a defect being disclosed reluctantly. It is the mechanism that makes everything else on this page verifiable, and any system claiming it does not need it should be trusted less, not more.

The Run Is Monitored From Three Directions

A health signal confirms every completed run. A separate check confirms the expected output actually exists, because a process can report success and produce nothing. A third watchdog raises an alert if a run is overdue entirely.

Why three: because each of the first two has been silent on a real failure at least once. Monitoring that has never been tested against a fault is a belief, not a control.

06

Stage 6 of 6 · Delivery

Findings Go to a Person. Every Change Is Made by Hand.

The system is read-only and always will be. What it produces is a ranked briefing that goes to the media buyer running your account.

The Briefing

Every finding ranked by severity and then by dollar impact, every prior item explicitly resolved, every figure traceable to the record it came from. It is written for a practitioner, not for a client inbox: it is the working instrument that tells the buyer where to start.

The Buyer Decides

Twenty years of judgment applied to what is real, what is urgent, and what is noise. Some findings are wrong. Some are right and still not worth acting on, and those get filed as considered-and-closed with a review date so they stop being re-raised.

The Change Is Made, and Captured

Changes are made by hand, frequently as a prepared import package reviewed line by line before anything is applied. That night, the system records what changed. The decision becomes part of the permanent record, and the next analysis reasons with it.

This is the loop, and it is the part that compounds. The account improves, the record deepens, and none of that knowledge leaves when a person does.

Beyond the Nightly Run

The Archive Answers Direct Questions Too

The nightly analysis is the scheduled half. The buyer can also query the full archive directly: two years of history, the complete change record, and the account documents, all available in the moment rather than requiring a new export and a new week.

Deep dives return as written briefs with evidence attached, and where the answer amounts to a set of account changes, as a prepared import package ready for review. Those briefs are required to state what the system cannot see before they state a recommendation, so that a confident answer built on a blind spot is caught by the person reading it.

The Short Version

What We Are Claiming

Atlas was built in-house. Not white-labeled, not a reseller agreement, not a subscription to a platform somebody else maintains. When it needs to change, we change it.

Read-only by design. The system has no ability to modify an account. Not a policy. An architectural fact.

Your data is isolated. Each client’s archive is separate. Nothing is pooled, nothing analyzes another account, nothing trains anything.

Every claim cites the record. A finding that cannot point at its evidence does not ship.

The record cannot be quietly edited. Snapshots are immutable, the change history is append-only, and corrections are filed rather than applied.

Assistant, not replacement. Findings go to an expert. Every change is made by a person.

This is the engineering view. The shorter version of the same story is on the main Atlas page.

How Atlas Works, End to End