Building Ads Command Centers

Was macht Building Ads Command Centers?

Ziel

Ein zuverlässiges Werbe-Cockpit für Google Ads und Meta Ads bauen. Die Herkunft der Zahlen, die Unterschiede zwischen den Plattformen, die Isolation der Organisationen und die Sicherheit der an die Werbeplattformen gesendeten Aktionen wahren.

Das Produkt vor dem Bau klassifizieren

• Reporting: Verbindung, Synchronisation und schreibgeschützter Zugriff.
• Assistierte Steuerung: Empfehlungen, Vorschau, dann menschliche Validierung von Budgets, Pausen und Wiederaufnahmen.
• SaaS-Self-Service: Multi-User-OAuth, Kontoauswahl, Rechteverwaltung, Abrechnung, Compliance und Support.

Versprich nicht die dritte Stufe, wenn nur eine Admin-Verbindung und simulierte Tests existieren.

Mit dem tatsächlichen Kontext beginnen

Das vorhandene Repository und die Infrastruktur inspizieren, bevor ein Stack gewählt wird. Die Zielnutzer, die Anzahl der Konten, die Aktualisierungshäufigkeit, der erwartete Verlauf, die Quelle der Wahrheit für Conversions, Währungen, Zeitzonen, das Hosting und die Compliance-Anforderungen erfassen.

Die Lösung auf die gewählte Stufe dimensionieren. Für ein internes, schreibgeschütztes Einzelorganisations-Tool reichen eine einzelne Organisation, einfache Rollen und ein Monolith aus. Erzwinge kein OAuth-Self-Service, keine Microservices, keine Abrechnung oder keinen Genehmigungsworkflow ohne entsprechenden Bedarf.

Nützliche Referenzen laden

• Immer architecture-data-sync.md lesen.
• Für Google Ads google-ads.md lesen.
• Für Meta Ads meta-ads.md lesen.
• Vor jedem externen Schreibzugriff oder Produktionsgang production-safety.md lesen.
• Bevor das System als fertig erklärt wird, die relevanten Abschnitte von acceptance-checklist.md anwenden.

API-Versionen, Berechtigungen, Überprüfungsverfahren und Kontingente ändern sich. Zum Zeitpunkt der Implementierung die offiziellen Dokumentationen überprüfen.

Workflow

1. Eine Fähigkeitsmatrix erstellen: Plattform, Lesen/Schreiben, Quelle, nachgewiesener Status und Grenzen.
2. Organisationen, Mitglieder, Rollen, Verbindungen, Werbekonten und Prüfprotokoll entwerfen.
3. Zuerst die Nur-Lese-Connectoren implementieren und die rohe Herkunft bewahren.
4. Durch idempotente Aufgaben in eine normalisierte Datenbank synchronisieren. Aktualität, Fehler, Abdeckung und Attributionskontext anzeigen.
5. Eine Stichprobe über einen abgeschlossenen Zeitraum mit den nativen Google- und Meta-Oberflächen abgleichen.
6. Empfehlungen durch deterministische Regeln und Berechnungen erstellen. Ein LLM nur zur Erklärung oder Neuformulierung verwenden.
7. Jeden Schreibzugriff separat mit Vorschau, Autorisierung, Grenzen, Idempotenz, Prüfung, Remote-Auslese und Rollback-Verfahren hinzufügen.
8. Die Isolation zwischen Organisationen, den OAuth-Ablauf, Kontingente, Aufgabenwiederholungen und fehlende Metriken testen.

Invarianten

• Keine Geheimnisse im Repository, Browser, in Logs, Screenshots, Exporten oder Prompts.
• Google- und Meta-Conversions niemals naiv addieren: Plattform, Aktion, Fenster und Attributionsmodell beibehalten.
• Eine geplante Synchronisation ist keine Echtzeit.
• Niemals eine Mutation auf einem Produktionskonto ohne ausdrückliche Genehmigung und genauen Umfang testen.
• Jede Fähigkeit qualifizieren: implementiert, in Sandbox getestet, in Produktion validiert oder partiell.

Erwartetes Lieferobjekt

Die Architektur und ihre Annahmen, das Datenschema, die Google- und Meta-Verbindungsabläufe, die Synchronisationsstrategie, die Berechtigungsmatrix, die Schreibschutzmaßnahmen, die Abgleichtests und das Betriebsrunbook bereitstellen. Klar trennen, was umgesetzt ist und was noch zu validieren bleibt.