Google Ads Governance: Änderungen kontrolliert freigeben

Die fünf Schritte der Kurzantwort sind Grenzen, die Automatisierung nicht unsichtbar überspringen darf – unabhängig davon, wie das ausführende System vermarktet wird. Ein typischer Fall ist unspektakulär: Jemand senkt von Hand ein Gebotsziel, und drei Monate später weiss niemand mehr, warum. maitiq beantwortet ihn strukturell – mit einem gespeicherten Entscheid und einer protokollierten Umsetzung je vorgeschlagener Änderung.

Warum reicht der Google-Änderungsverlauf nicht?

Der Änderungsverlauf listet Änderungen an Konto, Kampagnen und Anzeigengruppen der vergangenen zwei Jahre. Er zeigt Zeitpunkt, Änderungstyp und die auslösende Identität – Person, Google Ads API, Google Ads Editor, automatisierte Regel oder eines der internen Systeme von Google. Er lässt sich nach Kampagne, Anzeigengruppe, Änderungstyp, Nutzer, Tool und geänderter Position filtern und mit Leistungsdaten verknüpfen. Passwortänderungen erfasst er aus Sicherheitsgründen nicht. Google hält ausserdem fest, dass nicht immer alle Änderungen an Einstellungen auf Kontoebene oder Änderungen, die Google-Mitarbeitende während einer Beratung vornehmen, aufgeführt werden.

Er beantwortet damit vor allem eine Frage: Was wurde im Konto verändert? Er beantwortet nicht:

• welches Geschäftsziel galt;
• welche Evidenz den Vorschlag stützte;
• wer fachlich genehmigte und mit welcher Befugnis;
• welche Risiken bewusst akzeptiert wurden;
• welcher Rollback vorbereitet war;
• ob die Änderung später den erwarteten Zustand erzeugt hat.

Dazu kommt eine Auslesegrenze, die viele Teams erst beim Aufbau eines eigenen Archivs bemerken: Die Zwei-Jahres-Ansicht der Oberfläche ist kein maschinell abrufbarer Verlauf. Über die Google Ads API liefert die Ressource change_event bei Aktualisierungen alte und neue Feldwerte (bei Neuanlagen den neuen Wert), dazu den Client-Typ und, sofern im Web-Änderungsverlauf sichtbar, den Nutzer; verlangt ist ein Abfragezeitraum innerhalb der letzten 30 Tage und höchstens 10’000 Zeilen pro Abfrage; Google hält fest, dass dabei nicht jede Zeile des Verlaufs enthalten sein muss. Die Ressource change_status reicht 90 Tage zurück, gibt pro Ressource jedoch nur die jüngste Änderung und keine Feldwerte zurück. Diese 30- und 90-Tage-Grenzen gelten für diese beiden Ressourcen, nicht für alle über die API verfügbaren Daten. Wer eine belastbare Spur über Quartale braucht, muss sie selbst laufend speichern. Eine interne Spur ersetzt die Plattformhistorie nicht: Sie dokumentiert die eigenen Entscheide und Aktionen von maitiq, nicht die Begründung jeder manuellen Änderung im gesamten Google-Konto.

Welche fünf Schritte braucht eine Änderung?

1. Evidenz. Die Quelle wird unverändert beschrieben: Zeitraum, Konto, Kampagne, betroffene Entität, Kennzahlen, Datenverfügbarkeit und Grenzen. Fehlende Daten bleiben fehlend.

2. Vorschlag. Der Vorschlag nennt die genaue Handlung: alter und neuer Wert, wo ein solcher Wertevergleich sinnvoll ist – ein Anlegen hat keinen früheren Zahlenwert –, dazu Ziel, Begründung, erwartete kontrollierbare Beobachtung und mögliche Nebenwirkungen. Eine Analyse ist noch keine Handlung.

3. Entscheid. Eine berechtigte Person nimmt an, lehnt ab oder lässt offen; ist der begrenzte Autopilot ausdrücklich aktiviert, kann er innerhalb der von Ihnen gesetzten Grenzen annehmen. Identität und Zeitpunkt werden gespeichert, ein Grund, wo einer erfasst wird. Eine Annahme ist nicht die technische Umsetzung.

4. Separat autorisierte Umsetzung. Nur eine eigens autorisierte Identität führt exakt die genehmigte Änderung aus. Eine eigene Autorisierung bedeutet dabei nicht zwingend einen zweiten Freigabeklick: Beim Ausschluss eines Wettbewerber-Keywords ist der ausdrückliche Entscheid selbst die Autorisierung für genau diese eine Operation, und die Ausführung wird unabhängig davon gegen Entscheid, Umfang und Ziel geprüft. Anfrage und Rückmeldung von Google werden protokolliert, ein Vorher-/Nachher-Nachweis dort, wo die Operation ein unabhängiges Rücklesen liefert.

5. Verifikation. Die technische Prüfung stellt den Zustand fest, soweit er belegbar ist: Sie meldet die verfügbare Evidenz – etwa die API-Antwort und das Audit – und dort, wo die Operation ein unabhängiges Rücklesen unterstützt, den Vorher-/Nachher-Nachweis. Fehlende Verifikation bleibt offen, statt als bestätigt zu gelten; für jeden Schreibvorgang wird keine sofortige unabhängige Bestätigung versprochen. Die spätere Wirkungsbeobachtung folgt nach einem definierten Beobachtungsfenster und beurteilt, wie sich der relevante Zustand entwickelt hat. Korrelation wird nicht als Wirkung ausgegeben.

Jeder Schritt braucht einen Fehlerausgang. Fehlt relevante Evidenz, kann der Entscheid blockiert bleiben; empfohlene Statuswerte sind «nicht entscheidbar», «erneute Freigabe nötig» bei abgelaufenem Entscheid, «nicht ausgeführt» bei blockierter Vorabprüfung, «ungeklärt» bei unbekanntem Remote-Ergebnis und «unaufgelöst» bei offener Verifikation. Eine begründete Nichtanwendbarkeit führt dagegen nicht automatisch zum Status «nicht entscheidbar». Diese Statuswerte sind eine Empfehlung für Ihr Register, keine fest eingebauten Produktstatus: Nicht jede Operation hat einen unabhängig rückgelesenen Vorher-/Nachher-Zustand, einen Ablaufstatus oder einen gespeicherten Freitextgrund. Ein fehlgeschlagener Versuch darf weder als erfolgreiche Änderung noch als «keine Änderung nötig» erscheinen.

Wer entscheidet was? Die RACI-Grundlage

Trennen Sie Rollen, nicht nur Personen: Geschäftsverantwortung (Ziel, Budget, Risiko), SEA-Verantwortung (fachliche Prüfung), Messverantwortung (Conversion- und Attributionsgrenzen), Umsetzung (Ausführung), Prüfung (unabhängige Nachprüfung), Datenschutz und Sicherheit (Zugriff, Consent, Klick-IDs) sowie Finanzen (Mediabudget und Autorisierungsgrenzen).

Pro Zeile ist genau eine Rolle Accountable, Software nie. In kleineren Teams trägt eine Person mehrere Rollen; die Ereignisse bleiben getrennt – zuerst der Entscheid, danach die Ausführung innerhalb der gültigen Berechtigung. Ergänzen Sie je Zeile Stellvertretung und Eskalationsweg, sonst blockiert eine Abwesenheit den Prozess. Die Matrix ist eine kopierbare Vorlage für Ihr Rollenregister, kein editierbares Feld dieser Seite. So ist maitiq eingebunden: Der Workflow ist in keiner Zeile Accountable – er liefert Evidenz und Vorschlag; eine benannte Person aus Ihrem Team entscheidet, oder der ausdrücklich aktivierte, begrenzte Autopilot entscheidet innerhalb der von Ihnen gesetzten Grenzen; die Verantwortung für das Erteilen dieser Richtlinie bleibt bei der benannten Person. Im Managed Service begleitet ein Client Success Manager (Ihr fester Ansprechpartner); die Umsetzung erfolgt innerhalb der dafür erteilten Autorisierung als protokollierter Schritt.

Wie maitiq Governance mitliefert

Der Workflow-Lauf sammelt Evidenz und erzeugt Vorschläge mit Massnahme, Begründung und Datenbasis – alter und neuer Wert, wo ein solcher Wertevergleich existiert. Die Vorschlagserzeugung selbst verändert nichts im Konto. Eine berechtigte Person nimmt an, lehnt ab oder lässt offen; ist der begrenzte Autopilot ausdrücklich aktiviert, kann er Vorschläge innerhalb der von Ihnen gesetzten Grenzen selbst annehmen und im selben Workflow-Lauf eine separate, eigens geprüfte Ausführung anstossen. Der Entscheid wird mit Identität und Zeitpunkt gespeichert; die Umsetzung bleibt an die separat geprüften Ausführungsrechte gebunden und wird protokolliert. Was ausserhalb dieser Grenzen liegt, wird nicht automatisch angenommen.

Welche Änderungen sind materiell?

Materialität hängt vom Konto ab. Es gibt dafür keine universellen Google-Kategorien und keine allgemeingültigen CHF- oder Prozentschwellen. Die Matrix ist eine kopierbare Vorlage für Ihr Materialitätsregister, kein editierbares Feld dieser Seite. Kalibrieren Sie sie mit eigenen Werten:

Ein kleiner Betrag kann kritisch sein, wenn er den primären Conversion-Datenfluss oder kontoweite Rechte berührt; eine grosse, sofort reversible Budgetänderung kann mittlere Materialität haben. Legen Sie pro Stufe Freigabestufe, Umsetzungsfenster, Monitoring und Rollback fest. Kritische Änderungen starten nicht in unbesetzten Zeiten.

Was gehört in einen Änderungsvorschlag?

Freitext allein erschwert Deduplizierung, Prüfung und Reporting. Verwenden Sie stabile Entitätsreferenzen und strukturierte Statuswerte; die folgende Feldliste ist eine Vorlage für Ihr Vorschlagsformat, keine Produkteingabe:

Wie sieht eine vollständige vorab erteilte Dauerfreigabe aus?

Eine vorab erteilte Dauerfreigabe ersetzt den Einzelentscheid für wiederkehrende, risikoarme Änderungen. «Optimieren nach Best Practice» ist keine kontrollierbare Erlaubnis. Als organisatorische Vorlage ist sie erst mit neun Angaben vollständig – eine kopierbare Vorlage für Ihr Berechtigungsregister, keine neun Produkteinstellungen:

Jede Abweichung führt zurück zum Einzelentscheid. Prüfen Sie am Ablauftermin aktiv, ob verlängert wird; stilles Weiterlaufen ist kein Entscheid. Der begrenzte Autopilot von maitiq folgt einem eigenen Satz abweichender, konfigurierbarer Grenzen: pro Änderung ein Betrag und ein Prozentsatz sowie eine Obergrenze für die Summe der Budgetwerte nach der Änderung auf der gewählten Gruppierungsebene. Das sind weniger oder anders konfigurierbare Grenzen als eine vollständige organisatorische Richtlinie – keine strengere Schutzstufe. Häufigkeitsgrenzen, Ablaufdatum und benannte verantwortliche Person sind Felder Ihres Registers, keine Produkteinstellungen; ohne eingeschaltete Richtlinie bleibt die Funktion aus.

Wie werden Auto-Apply-Empfehlungen freigegeben?

Auto-Apply ist eine ausdrückliche Opt-in-Entscheidung. Das Risiko ist keine fehlende Zustimmung, sondern eine undokumentierte oder vergessene Autorisierung, die die Wahrnehmung der Belegschaft überdauern kann. Google erlaubt es, ausgewählte Empfehlungstypen automatisch anzuwenden – ausschliesslich auf Kontoebene. Die Auto-Apply-Einstellungen führen einen eigenen Verlauf; er zeigt pro Typ, wann er zuerst aktiviert wurde, wie oft er in der vergangenen Woche angewendet wurde und wann zuletzt. Die zustimmende Nutzer-ID lässt sich im Änderungsverlauf nachvollziehen. Genau diese Felder gehören in Ihr eigenes Berechtigungsregister, ergänzt um Geschäftszweck, geschützte Conversion-Aktionen, Prüfrhythmus, Ablauftermin und Stoppregel.

Dokumentieren Sie einzelne Typen, nicht Bundle-Namen: Reichweite und Risiko unterscheiden sich stark. Die verfügbaren Typen ändern sich: Google passt den Katalog der automatisch anwendbaren Empfehlungen laufend an; prüfen Sie die Liste bei jeder Prüfung neu. Jede Prüfung endet mit einem expliziten Status pro Typ; empfohlene Werte sind «beibehalten», «deaktivieren», «zeitlich begrenzter Test», «nicht entscheidbar» oder «Eskalation». Der Optimierungsfaktor ist dabei kein Unternehmens-KPI: Eine Empfehlung kann zur Plattformlogik passen und dem Geschäftsrahmen trotzdem widersprechen.

Wichtig ist die Unterscheidung: Deaktivieren stoppt künftige automatische Anwendungen. Es setzt bereits angewendete Änderungen nicht zurück. Dafür gibt es den separaten Weg über den Änderungsverlauf – sofern die jeweilige Operation diese Rücknahme unterstützt. Ist sie nicht verfügbar, kann eine separat autorisierte manuelle Rückänderung nötig sein oder eine Umkehr unmöglich bleiben. Wie Sie Auto-Apply, Smart Bidding und externe Werkzeuge in einem Register führen, prüfen und stoppen, beschreibt der Leitfaden Automatisierung mit Leitplanken kontrollieren.

Wie sieht ein Rollback-Protokoll aus?

Ein Rollback ist keine spontane Gegenänderung, sondern ein vorbereiteter, protokollierter Vorgang. Google bietet dafür ein Zeitfenster: Die meisten Änderungstypen der letzten 30 Tage lassen sich direkt in der Zeile des Änderungsverlaufs rückgängig machen, auch eine irrtümlich angewendete Empfehlung – sofern die Operation diese Rücknahme unterstützt. Ist sie nicht verfügbar, kann eine separat autorisierte manuelle Rückänderung nötig sein oder eine Umkehr unmöglich bleiben. Wurde ein zugehöriges Element seither entfernt oder hat jemand anderes bereits zurückgesetzt, meldet die Oberfläche, dass die Änderung nicht rückgängig gemacht werden kann. Eine nur teilweise angewendete Empfehlung lässt sich über die Rücknahmefunktion der Empfehlung nicht zurücknehmen; das belegt aber nicht, dass jede daraus entstandene zugrunde liegende Änderung manuell unumkehrbar wäre. Verlassen Sie sich deshalb nie allein auf diese Funktion – notieren Sie den alten Wert vor der Änderung.

Halten Sie pro materieller Änderung fest: Stoppsignal, Referenz auf Vorschlag und Umsetzungsnachweis, alten Zielwert mit Beleg, berechtigte Person, gültige Autorisierung für die Rückänderung, gewählter Weg (Rücknahme im Verlauf, separat autorisierte manuelle Rückänderung oder nicht möglich), Zeitpunkt, technischen Nachweis danach, verbleibende Kosten- und Datenwirkung sowie offene Punkte. Eine Pause reduziert Exposition, garantiert aber nicht, dass keine bereits entstandenen oder verzögert gemeldeten Kosten mehr folgen. Bei Trackingfehlern gehört zum Rollback zusätzlich, einen fehlerhaften Import zu stoppen und die Daten abzugleichen.

Wie beschreibt man ein System nach Berechtigung statt nach Label?

Ein Label wie «AI-powered» sagt nichts über die Kontrollarchitektur. Entscheidend ist eine einzige Frage: Kann das System ohne gespeicherten, berechtigten Entscheid eine folgenreiche Änderung auslösen? Prüfen Sie pro Ebene – Googles Auktionssystem, Google-Kontoeinstellungen wie Auto-Apply und externe Werkzeuge – erlaubte Entitäten, maximale Veränderung, Vorschlags- oder Direktmodus, menschliche Freigabe, Anbieteridentität, Auditspur und Stoppweg.

Für maitiq lautet die Antwort: Die Vorschlagserzeugung allein verändert Google Ads nicht. Eine Änderung entsteht erst aus einem gespeicherten Entscheid und einem separat autorisierten, protokollierten Ausführungsschritt; ist der begrenzte Autopilot ausdrücklich aktiviert, kann die Engine Vorschläge innerhalb der Richtlinie selbst annehmen und im selben Workflow-Lauf diese separate Ausführung anstossen. Berechnungen sind deterministisch; KI wirkt nur beratend und gegen ein festes Schema geprüft und darf Vorschläge weder zusammenführen noch genehmigen, ablehnen oder numerisch umschreiben. Ein Audit wendet nie Änderungen an.

Wie wird Verifikation von Wirkung getrennt?

Technische Verifikation stellt den Zustand fest, soweit er belegbar ist: Sie meldet die verfügbaren Nachweise und lässt fehlende Verifikation offen. Wirkungsbeobachtung fragt später, wie sich definierte Kennzahlen entwickelt haben. Beides darf nicht verschmelzen: Eine technisch korrekte Änderung kann wirtschaftlich ungeeignet sein, und eine günstige Bewegung danach beweist keine Kausalität. Speichern Sie Implementierungsstatus, verfügbaren technischen Nachweis, Beobachtungsfenster, Datenreife, parallele Änderungen und verbleibende Unsicherheit getrennt. Welche Kennzahl, welches Fenster und welches Attributionsmodell die spätere Beobachtung zulässt, klären die Kennzahlen- und Attributionsdefinitionen.

Wie verhindert man Bürokratie?

Governance soll Entscheidungen beschleunigen: vorab genehmigte Grenzen für reversible, risikoarme Änderungen, standardisierte Vorschlagsfelder, Rollen nach Materialität, gebündelte Prüfintervalle, automatische Evidenzsammlung und eine Notfallausnahme mit Dokumentationspflicht innerhalb einer selbst festgelegten, schriftlich gehaltenen Frist. Die Frist legt jede Organisation selbst fest; gesetzliche, vertragliche und incidentbezogene Pflichten bleiben davon unberührt.

Häufige Fragen

Quellen und Einordnung

Die Quellen sind Google-Dokumentation: Die Hilfe-Seiten beschreiben den Änderungsverlauf, die Auto-Apply-Einstellungen und den Umgang mit Empfehlungen; die API-Referenz beschreibt, was sich programmatisch abrufen lässt. Angaben zur Arbeitsweise von maitiq finden Sie auf maitiq.com.

Lassen Sie Ihren konkreten Fall von maitiq prüfen.