Gespeicherte Builds

Ein gespeicherter Build ist ein Schnappschuss einer angefangenen Konfiguration im Web-Uploader. Er hält alle Entscheidungen fest, die du bisher getroffen hast, darunter deine Medienauswahl, die Kampagnenstruktur, den Text und eventuelle Anpassungen am Ad-Set-Targeting. Dazu bekommt diese Arbeit eine feste Referenz build_<hash>. Web-Uploader, CLI und MCP nutzen alle dieselbe Referenz.

Ein Build ist keine gestartete Anzeige und kein abgeschlossener Job. Du kannst einen unvollständigen Build speichern, an eine andere Oberfläche übergeben und weiterarbeiten, bevor du irgendetwas erstellst.

Autosave im Web-Uploader

Der Uploader speichert deinen aktuellen Build im Hintergrund, während du arbeitest. Die Build-Referenz erscheint an zwei Stellen:

Unten im Panel Ad Configuration
Im Kopf des Texteditors pro Anzeige und pro Ad Set, neben Reset All

Klick auf das Kopiersymbol neben der Referenz, um sie in die Zwischenablage zu kopieren. Dann kannst du sie in die CLI, eine MCP-Unterhaltung oder deine eigenen Notizen einfügen, ohne die ganze Konfiguration zu kopieren.

Autosave hält eine Arbeitskopie aktuell. Es startet keine Anzeigen und ersetzt nicht die normalen Schritte für Vorschau und Erstellung.

Autosaves und benannte Builds

Ein Autosave ist die aktuelle, unbenannte Arbeitskopie. Ein benannter Build ist ein Autosave, den du bewusst mit einem sinnvollen Namen gespeichert hast, damit du ihn leicht wiederfindest.

Sobald das Konto mindestens einen Build hat, erscheint unter Account Selection neben dem Selektor für das Werbekonto ein Symbol Saved builds (ein Stapel Dateien). Ein Klick darauf öffnet Saved Builds mit allen benannten Builds und deinen neuesten Autosaves für dieses Konto. Dort kannst du:

einen Build fortsetzen (Resume)
die Build-Referenz mit dem Kopiersymbol kopieren
einen Autosave mit Namen speichern (Save)
einen benannten Build mit dem Stiftsymbol umbenennen
einen Build in eine neue Kopie abzweigen (Fork)
einen Build löschen (Delete)

Fenster Saved Builds mit einem benannten Build und einem Autosave, jeweils mit Änderungszeit und den Buttons Resume, Fork und Delete sowie Symbolen zum Kopieren und Umbenennen

Ein Badge Web only bedeutet, dass du den Build im Web-Uploader fertigstellen, aber noch nicht über CLI oder MCP starten kannst. Fahr mit der Maus darüber, um den Grund zu sehen.

Nutze einen benannten Build für Arbeit, zu der du später zurückkehren willst. Wenn du einen Autosave benennst, bleibt er als gespeicherter Build erhalten und landet nicht nur in der wechselnden Liste der letzten Autosaves.

Build fortsetzen

Um in der Web-App weiterzumachen, öffne Saved Builds und klick auf Resume. Der Uploader lädt die gespeicherte Konfiguration zurück in die Bedienelemente, sodass du weiter daran arbeiten kannst.

Resume arbeitet am selben Build weiter, spätere Autosaves aktualisieren ihn also direkt. Nimm Fork, wenn du einen Build als Vorlage nutzen und das Original unverändert lassen willst. Fork erstellt einen neuen, unbenannten Entwurf mit eigener Build-Referenz und öffnet dann die Kopie zum Bearbeiten.

Du kannst einen Build auch direkt über dieses URL-Format öffnen:

https://adsuploader.com/dashboard/uploader?build=build_...

Der Uploader wechselt zu dem Werbekonto, dem der Build gehört, bevor er ihn wiederherstellt. Basiert der Build auf einem API-Preset, wählt der Uploader dieses Preset erneut aus. Basiert er auf einer Meta-Anzeige, lädt der Uploader diese Quellanzeige neu und wendet dann die gespeicherte Konfiguration an.

Die direkte URL ist praktisch, wenn dir ein Agent einen Build zurückgibt oder der ursprüngliche Uploader-Tab geschlossen ist.

Mit einem KI-Agenten arbeiten

Die Texteditoren pro Anzeige und pro Ad Set haben Buttons für Claude und ChatGPT. Jeder Button öffnet eine neue Unterhaltung, in der die aktuelle Build-Referenz und ein MCP-Bearbeitungsprompt schon eingetragen sind. Beschreib die Textänderungen, die du willst, und der Agent kann genau diesen Build über das Ads Uploader MCP abrufen und aktualisieren.

Ist der Build noch im Uploader geöffnet, prüft die Seite auf externe Änderungen, wenn du zum Tab zurückkehrst oder das Fenster fokussierst. Solange die Seite sichtbar ist, prüft sie außerdem regelmäßig. Hat der Server eine neuere Version und du hast keine ungespeicherten lokalen Änderungen, übernimmt der Uploader das Update automatisch.

Klick auf das Aktualisieren-Symbol neben der Build-Referenz, wenn du sofort prüfen willst. Dasselbe Bedienelement findest du in der Fußzeile von Ad Configuration und im Kopf des Texteditors.

Hast du lokale Änderungen, wenn ein externes Update eintrifft, überschreibt der Uploader sie nicht. Stattdessen zeigt er ein Banner „This build was updated externally." mit Load changes und Keep mine:

Load changes übernimmt den neueren gespeicherten Build.
Keep mine behält deine aktuelle lokale Arbeit und verwirft dieses Update.

Ist dein Uploader-Tab geschlossen, frag den Agenten nach der Build-URL. Nach dem Aktualisieren eines Builds, der bereits geöffnet ist, muss er die URL nicht teilen.

Arbeit zwischen Web, CLI und MCP übergeben

Gespeicherte Builds sind die Brücke zwischen den drei Oberflächen. Du kannst in der Web-App mit hochgeladenen Medien und einer Quellkonfiguration starten, die Referenz build_... für eine bestimmte Änderung an einen CLI- oder MCP-Agenten übergeben und das Ergebnis dann im selben Uploader-Tab oder über eine angeforderte URL prüfen.

Die Referenz bezeichnet weiterhin denselben Build, während er zwischen den Oberflächen wandert. Du musst Preset, Quellanzeige, Medienauswahl oder Textkonfiguration nicht bei jeder Übergabe neu anlegen.

Unvollständige Builds und Startfähigkeit

Ein Build kann nützlich sein, bevor er startklar ist. Einen unvollständigen Build kannst du im Web-Uploader fortsetzen und fertigstellen, auch wenn CLI oder MCP ihn als web-only markieren.

Für einen Launch über CLI oder MCP braucht der gespeicherte Build eine nutzbare Quellkonfiguration, zum Beispiel ein API-Preset oder eine Quellanzeige, auflösbare Medien für sein Werbekonto und eine vollständige Konfiguration, die der Headless-Workflow unterstützt. Fehlt davon etwas, meldet der Build, warum er nicht startfähig ist. Dann kannst du im Web-Uploader weitermachen und ihn fertigstellen.

Schau dir immer zuerst die Vorschau an, bevor du Anzeigen erstellst. Für den Web-Workflow siehe Anzeigen konfigurieren und Anzeigen starten, für den Kommandozeilen-Workflow CLI-Konfiguration.

IDs für Videomedien

Bei Videos muss mediaItems[].mediaId die numerische Facebook-Video-ID sein: Nutze die videoId aus der Upload-Antwort, nicht deren interne id. videoId wird als Alias akzeptiert, und für linkedAssets[] gilt dieselbe Regel. Interne Upload-IDs werden beim Speichern nur aufgelöst, wenn sie zum angemeldeten Nutzer und zum ausgewählten Konto gehören. Ohne numerische ID oder Batch-Verknüpfung macht ein nicht aufgelöstes Video den Build nicht startfähig.

Ein kanonisches Video-Element mit einer primären 4x5-Datei und einer verknüpften 9x16-Variante:

{
  "mediaName": "X__H01.mp4",
  "mediaType": "video",
  "mediaId": "1805649190475379",
  "thumbnailHash": "PRIMARY_THUMBNAIL_HASH",
  "placementType": "portrait",
  "isGroupPrimary": true,
  "assetGroupId": "ag_1",
  "linkedAssets": [
    {
      "mediaName": "X__H01-9x16.mp4",
      "mediaType": "video",
      "mediaId": "1234567890",
      "thumbnailHash": "STORY_THUMBNAIL_HASH",
      "placementType": "story"
    }
  ]
}

Partnership-Builds

Gespeicherte Builds behalten auch Partnership-Einstellungen: Referenzen auf importierte Beiträge, Creator- und Sponsor-Identitäten, Header-Modus, Text, Enhancements und Veröffentlichungseinstellungen. Rohe Ad-Codes werden nie in einem Build gespeichert oder in einer Ausgabe angezeigt. Ein verifizierter Code kann für dieselbe Marke und denselben Beitrag wiederverwendet werden. Beim Launch brauchst du aber eventuell trotzdem eine erneuerte Berechtigung oder einen neuen Code.

Vollständige Builds mit bestehenden Instagram-Beiträgen und Partnership-Builds mit hochgeladenen Medien (inklusive Partnern pro Zeile und No Partner) kannst du im Web, in der CLI und im MCP als Vorschau ansehen und starten. Ältere Builds mit Facebook-Beiträgen bleiben web-only. Importierte Beiträge lassen sich nicht mit hochgeladenen Medien mischen. Hat ein importierter Build Einstellungen, die der Web-Editor nicht anzeigen kann, überschreibt der Web-Uploader ihn nicht. Bearbeite ihn dann weiter über CLI oder MCP. Die Spec-Felder für Partnerships findest du in der CLI-Referenz.

Hinweise zu Konto und Zugriff

Gespeicherte Builds gehören zu dem Werbekonto, in dem sie erstellt wurden, und lassen sich nicht in ein anderes Konto übertragen. Ein direkter Link kann den Uploader zum richtigen verbundenen Konto wechseln lassen, ändert aber nicht, wem der Build gehört.

Der Zugriff auf CLI und MCP ist zahlenden Nutzern vorbehalten und im Testzeitraum nicht verfügbar. MCP nutzt dieselben Zugriffsregeln wie die CLI. Wenn du den CLI-Zugriff deaktivierst, ist also auch der MCP-Zugriff deaktiviert. Anleitungen zu Verbindung und Authentifizierung findest du unter MCP-Konfiguration.

Dokumentation