Google Ads governance: approving changes in a controlled way

The five steps in the short answer are boundaries that automation must not skip over invisibly – regardless of how the executing system is marketed. A common example: someone lowers a bid target by hand, and three months later nobody knows why. maitiq keeps the decision and implementation record together for every change it proposes – with a stored decision and a logged implementation.

Why is the Google Ads change history not enough?

The change history lists changes to the account, campaigns and ad groups from the past two years. It shows the time, the type of change and the identity that triggered it – a person, the Google Ads API, Google Ads Editor, an automated rule or one of Google’s internal systems. You can filter it by campaign, ad group, change type, user, tool and the item changed, and link it to performance data. For security reasons, it does not record password changes. Google also notes that not all account-level settings changes, or changes made by Google representatives during consultations, are listed in the change history.

It therefore answers one question above all: what was changed in the account? It does not answer:

• which business objective the change served;
• which evidence supported the proposal;
• who approved it on the merits and with what authority;
• which risks were deliberately accepted;
• which rollback was prepared;
• whether the change later produced the expected state.

There is also a retrieval limit that many teams only notice when they build their own archive: the two-year view in the interface is not a machine-readable history. Through the Google Ads API, the change_event resource returns the new field values for creations and both old and new values for updates, together with the client type and, if visible in the web client’s Change History, the user who made the change, but requires a date window within the last 30 days and at most 10,000 rows per query; Google notes that this need not include every row of the history. The change_status resource reaches back 90 days, but returns only the most recent change per resource and no field values. These 30-day and 90-day limits apply to these two resources, not to all data available through the API. Anyone who needs a reliable record across quarters has to store it themselves on an ongoing basis. An internal record does not replace the platform history: it documents maitiq’s own decisions and actions, not the rationale for every manual change in the whole Google account.

Which five steps does a change need?

1. Evidence. The source is described without alteration: period, account, campaign, affected entity, metrics, data availability and limits. Missing data stays missing.

2. Proposal. The proposal states the exact action: old and new value where such a comparison is meaningful – a create has no prior numeric value –, plus the goal, the rationale, the expected observation you can verify and possible side effects. An analysis is not yet an action.

3. Decision. An authorised person approves, rejects or leaves it open; when the bounded autopilot is explicitly enabled, it can approve within the limits you set. Identity and time are stored, and a reason where one is recorded. An approval is not the technical implementation.

4. Separately authorised implementation. Only a separately authorised identity carries out exactly the approved change. A separate authorisation does not necessarily mean a second approval click: when a competitor keyword is excluded, the explicit decision is itself the authorisation for that one operation, and the execution is checked independently against the decision, scope and goal. The request and Google’s response are logged, together with before/after evidence where the operation supports an independent read-back.

5. Verification. Technical checking establishes the state as far as it can be evidenced: it reports the available evidence – such as the API response and the audit – and, where the operation supports an independent read-back, the before/after evidence. Missing verification stays open instead of counting as confirmed; no immediate independent confirmation is promised for every write. The later impact observation follows after a defined observation window and assesses how the relevant state has developed. Correlation is not reported as impact.

Every step needs an error outcome. If relevant evidence is missing, the decision may stay blocked; recommended status values are “insufficient evidence to decide”, “new approval required” for an expired decision, “not executed” for a blocked pre-check, “unresolved” for an unknown remote result and “not closed” for an open verification. A justified N/A does not automatically become “insufficient evidence to decide”. These status values are a recommendation for your register, not five built-in product statuses: not every operation has an independently read-back before/after state, an expiry status or a stored free-text reason. A failed attempt must appear neither as a successful change nor as “no change needed”.

Who decides what? The RACI basis

Separate roles, not just people: business responsibility (goal, budget, risk), paid search responsibility (professional review), measurement responsibility (conversion and attribution limits), implementation (execution), review (independent verification), data protection and security (access, consent, click IDs) and finance (media budget and authorisation limits).

Exactly one role is accountable per row, never software. In smaller teams, one person holds several roles; the events stay separate – first the decision, then the execution within the valid permission. Add a deputy and an escalation path for each row, otherwise an absence blocks the process. The matrix is a copyable template for your own role register, not an editable field on this page. This is how maitiq fits in: the workflow is not accountable in any row – it supplies evidence and a proposal; a named person from your team decides, or the explicitly enabled, bounded autopilot decides within the limits you set; responsibility for granting that policy remains with the named person. In the managed service a Client Success Manager supports the work, and the implementation takes place within the authorisation granted for it as a logged step.

How maitiq provides governance as part of the workflow

The workflow run gathers evidence and produces proposals with the action, the rationale and the data behind them – old and new value where such a value comparison exists. Proposal generation itself changes nothing in the account. An authorised person approves, rejects or leaves it open; when the bounded autopilot is explicitly enabled, it can approve proposals within the limits you set and invoke a separate, separately checked apply execution in the same workflow run. The decision is stored with identity and time; the implementation remains tied to the separately checked execution rights and is logged. Anything outside those limits is not approved automatically.

Which changes are material?

Materiality depends on the account. There are no universal Google categories for it and no generally valid CHF or percentage thresholds. The matrix is a copyable template for your own materiality register, not an editable field on this page. Calibrate it with your own values:

A small amount can be critical if it touches the primary conversion data flow or account-wide rights; a large, immediately reversible budget change can have medium materiality. Define the approval level, implementation window, monitoring and rollback for each level. Critical changes do not start during unattended periods.

What belongs in a change proposal?

Free text alone makes deduplication, review and reporting harder. Use stable entity references and structured status values; the field list below is a template for your proposal format, not a product input:

What does a complete standing approval look like?

A standing approval replaces the individual decision for recurring, low-risk changes. “Optimise according to best practice” is not a clearly defined authorisation. As an organisational template it is complete only with nine items – a copyable template for your authorisation register, not nine product settings:

Any deviation leads back to an individual decision. At the expiry date, actively check whether the approval is extended; silent continuation is not a decision. maitiq’s limited autopilot follows its own, different set of configurable limits: per change an amount and a percentage, plus a cap on the sum of the budget values after the change at the chosen grouping level. These are fewer or different configurable limits than a full organisational policy – not a stronger level of protection. Frequency limits, expiry date and the named responsible person are fields of your register, not product settings; without an enabled policy the function stays off.

How are auto-apply recommendations approved?

Auto-apply is an explicit opt-in. The risk is not a missing consent but an undocumented or forgotten authority that can outlive the awareness of the staff who granted it. Google allows selected recommendation types to be applied automatically – exclusively at account level. The auto-apply settings keep their own history; for each type it shows when it was first enabled, how often it was applied in the past week and when it was last applied. The opting user ID can be confirmed in the change history. Exactly these fields belong in your own authorisation register, supplemented by business purpose, protected conversion actions, review cadence, expiry date and stop rule.

Document individual types, not bundle names: reach and risk differ greatly. The available types change: Google continually adjusts the catalogue of recommendations that can be applied automatically; check the list again at every review. Every review ends with an explicit status per type; recommended values are “keep”, “disable”, “time-limited test”, “insufficient evidence to decide” or “escalation”. The optimisation score is not a business KPI: a recommendation can fit the platform logic and still contradict your business framework.

The distinction matters: disabling stops future automatic applications. It does not revert changes that have already been applied. That requires the separate route through the change history – where the operation supports that undo. If it does not, a separately authorised manual reversal may be required, or a reversal may be impossible. How to keep auto-apply, Smart Bidding and external tools in one register, review them and stop them is described in the guide controlling automation with guardrails.

What does a rollback record look like?

A rollback is not a spontaneous reversal but a prepared, logged procedure. Google provides a time window for it: most change types from the last 30 days can be undone directly in the row of the change history, including a recommendation applied by mistake – where the operation supports that undo. If it does not, a separately authorised manual reversal may be required, or a reversal may be impossible. If an associated element has since been removed, or someone else has already reverted it, the interface reports that the change cannot be undone. A recommendation that was only partially applied cannot be undone with that recommendation’s undo function; this does not prove that every resulting underlying change is impossible to reverse manually. So never rely on this function alone – note the old value before the change.

Record the following for every material change: stop signal, reference to the proposal and proof of implementation, old target value with supporting evidence, authorised person, valid authorisation for the reversal, the chosen route (reversal in the history, separately authorised manual reversal or not possible), time, technical evidence afterwards, remaining cost and data impact, and open items. A pause reduces exposure but does not guarantee that no costs already incurred or reported late will follow. For tracking errors, the rollback also includes stopping a faulty import and reconciling the data.

How do you describe a system by permission rather than by label?

A label such as “AI-powered” says nothing about the control architecture. One question is decisive: can the system trigger a consequential change without a stored, authorised decision? For each layer – Google’s auction system, Google account settings such as auto-apply, and external tools – check the permitted entities, maximum change, proposal or direct mode, human approval, provider identity, audit trail and stop route.

For maitiq, the answer is: proposal generation itself does not change Google Ads. A change arises only from a stored decision and a separately authorised, logged apply execution; when the bounded autopilot is explicitly enabled, the engine can approve proposals within the policy and invoke that separate apply execution in the same overall workflow run. Calculations are deterministic; AI is advisory only and checked against a defined output format, and may neither merge proposals nor approve, reject or numerically rewrite them. An audit never applies changes.

How are verification and impact kept apart?

Technical verification establishes the state as far as it can be evidenced: it reports the available evidence and leaves missing verification open. Impact observation asks later how defined metrics have developed. The two must not merge: a technically correct change can be economically unsuitable, and a favourable movement afterwards proves no causality. Store implementation status, available technical evidence, observation window, data maturity, parallel changes and remaining uncertainty separately. The metric and attribution definitions clarify which metric, window and attribution model the later observation can use.

How do you prevent bureaucracy?

Governance should speed up decisions: pre-approved limits for reversible, low-risk changes, standardised proposal fields, roles based on materiality, bundled review windows, automatic evidence collection and an emergency exception with a documentation obligation within a deadline you set yourself and keep in writing. Every organisation sets that deadline itself; statutory, contractual and incident-related obligations remain unaffected.

Frequently asked questions

Sources and how to read them

The sources are Google documentation: the Help pages describe change history, auto-apply settings and recommendations; the API reference describes what can be retrieved programmatically. Information about how maitiq works is available at maitiq.com.

Have maitiq review your specific case.