Erfahren Sie, wie Sie eine Web‑App für Marketingagenturen planen und bauen, um Kampagnen, Assets und Kundenfreigaben mit Rollen, Workflows und prüfbarer Historie zu verwalten.
Bevor Sie Bildschirme skizzieren oder einen Tech‑Stack wählen, klären Sie das Kernproblem: Kampagnen und Freigaben sind über E‑Mail, Chat und gemeinsame Laufwerke verstreut. Eine Kampagnen‑Web‑App sollte Briefings, Assets, Feedback und Sign‑offs an einem Ort bündeln, sodass alle sehen können, was als Nächstes ansteht — ohne Threads hinterherlaufen zu müssen.
Die meisten Agentur‑Freigabe‑Workflows involvieren vier Gruppen mit unterschiedlichen Bedürfnissen:
E‑Mail‑basierte Freigaben erzeugen vorhersehbare Probleme: verpasste Deadlines, weil niemand die neueste Anfrage sieht; unklare Rückmeldungen wie „mach’s auffälliger“ ohne Details; mehrere Versionen, die herumfliegen; und Nacharbeiten durch späte oder widersprüchliche Eingaben.
Definieren Sie messbare Ergebnisse, damit Sie beurteilen können, ob das Produkt funktioniert:
Konzentrieren Sie sich für v1 auf das kleinste Set, das Kampagnen und Freigaben zusammenhält:
Schöne Extras für später: erweiterte Reports, tiefe Integrationen, Automatisierungsregeln und individuelle Freigabepfade.
Bevor Sie über Bildschirme oder Technik nachdenken, schreiben Sie auf, wie Arbeit tatsächlich durch Ihre Agentur fließt. Ein klarer Workflow verwandelt „Wo steht das?“ in eine vorhersehbare Abfolge von Schritten, die Ihre App durchsetzen, automatisieren und berichten kann.
Die meisten Kampagnen‑Freigabe‑Apps lassen sich mit einer kleinen Menge Bausteine beschreiben:
Dokumentieren Sie die Beziehungen: Eine Kampagne enthält Projekte; Projekte enthalten Aufgaben; Aufgaben erzeugen Assets; Assets durchlaufen Freigaben.
Ein einfacher, agenturfreundlicher Ablauf ist:
Draft → Internal review → Client review → Approved
Geben Sie jedem Status eine operative Bedeutung. „Internal review“ könnte z. B. die Unterschrift des Creative Leads und des Account Managers erfordern, bevor ein Kunde etwas sieht.
Entscheiden Sie, wie Feedback in Ihrem Produkt aussieht:
Wichtig ist, Feedback an eine Asset‑Version zu binden, damit nicht über unterschiedliche Dateien gestritten wird.
Häufige Verzögerungen: Warten auf Reviewer, unklare nächste Schritte und wiederholte Einrichtung. Hilfreiche Automatisierungen sind z. B.:
Echte Freigaben sind selten sauber. Planen Sie für:
Wenn Sie diese Regeln in klarer Sprache beschreiben können, sind Sie bereit, sie in Screens und Datenmodelle zu überführen.
Großartige UX für eine Kampagnen‑App beginnt mit einer einfachen Informationshierarchie, die widerspiegelt, wie Agenturen bereits denken: Kunde → Kampagne → Deliverables (Assets). Wenn Nutzer immer beantworten können „Wo bin ich?“ und „Was passiert als Nächstes?“, laufen Freigaben schneller und weniger geht verloren.
Nutzen Sie den Kunden als oberste Ebene, zeigen Sie dann Kampagnen und schließlich die Deliverables (Ads, E‑Mails, Landingpages, Social‑Posts). Halten Sie die Struktur in Navigation, Breadcrumbs und Suche gleich, damit Nutzer die App nicht auf jeder Seite neu lernen müssen.
Eine praktische Regel: Jedes Deliverable sollte stets auf einen Blick Kunde, Kampagne, Fälligkeitsdatum, Status und Verantwortlichen anzeigen.
Dashboard: Die Agentur‑Startseite. Fokus auf das, was heute Aufmerksamkeit braucht: anstehende Fälligkeiten, Items in interner Review und Items, die auf Kundenfreigabe warten.
Kampagnen‑Timeline: Kalender‑ oder phasenbasierte Ansicht, die Abhängigkeiten sichtbar macht (z. B. „Copy freigegeben“ bevor „Design final“). Lesbar halten — Fortschritt sollte in Sekunden verständlich sein.
Asset‑Review‑Ansicht: Hier gewinnt oder verliert man Zeit. Vorschau groß darstellen, Kommentare leicht auffindbar, nächste Aktion deutlich.
Inbox: Ein Ort für „Dinge, auf die ich reagieren muss“ (neues Feedback, Freigabeanfragen, Erwähnungen). Das reduziert Ping‑Pong über E‑Mail und Chat.
Schnellfilter sollten häufige Agenturfragen beantworten:
Der primäre Call‑to‑Action sollte offensichtlich sein: Freigeben / Änderungen anfordern. Halten Sie ihn im Review‑View fixiert (sticky footer/header), damit Kunden nach dem Scrollen nicht danach suchen.
Kunden prüfen oft zwischen Meetings. Priorisieren Sie mobile Lesbarkeit: saubere Vorschau, große Buttons und kurze Feedback‑Formulare. Wenn ein Tap die Asset‑Ansicht öffnet und ein weiterer Tap freigibt, sehen Sie schnellere Durchlaufzeiten.
Eine Kampagnen‑Freigabe‑App steht oder fällt mit Vertrauen: Kunden müssen sicher sein, nur das zu sehen, was sie dürfen; Ihr Team braucht klare Grenzen, damit Arbeit nicht versehentlich überschrieben oder vom falschen Nutzer freigegeben wird.
Die meisten Agenturen kommen mit fünf Rollen weit:
Statt nur globale Berechtigungen zu haben, definieren Sie Aktionen pro Objekttyp (Kampagne, Deliverable, Asset, Kommentar). Typische Aktionen sind view, comment, upload, approve, edit und delete.
Eine pragmatische Voreinstellung ist „least privilege“: Contributors können eigene Assets hochladen und bearbeiten, das Löschen oder Ändern von Kampagneneinstellungen ist Admins/Account Managern vorbehalten.
Kunden sollten nur ihre Kampagnen, Assets und Diskussionen sehen. Vermeiden Sie geteilte „Kundenordner“, die versehentlich andere Accounts offenbaren. Am einfachsten ist das, wenn jede Kampagne an ein Kundenkonto gebunden ist und Zugriffskontrollen konsistent über Seiten, Downloads und Benachrichtigungen durchgesetzt werden.
Unterstützen Sie zwei Freigabemodi pro Deliverable:
Bieten Sie Share‑Links an, aber standardmäßig privat: zeitlich begrenzte Tokens, optionales Passwort und die Möglichkeit, Links zu widerrufen.
Eine gute Regel: Teilen darf die Kunden‑Grenze nie umgehen — es darf nur Zugriff auf Items gewähren, die der Nutzer ohnehin sehen dürfte.
Eine Kundenfreigabe‑Funktion lebt oder stirbt mit Klarheit. Wenn Ihr Team und Ihre Kunden nicht erkennen können, wer worauf wartet, stocken Freigaben und „freigegeben“ wird diskutierbar.
Starten Sie mit wenigen, allgemein verständlichen Zuständen:
Vermeiden Sie für jeden Randfall einen neuen Status. Bei Bedarf nutzen Sie Tags (z. B. „Legal Review“) statt den Workflow aufzublähen.
Behandeln Sie jeden Upload als neue, unveränderliche Version. Ersetzen Sie Dateien nicht an derselben Stelle — erstellen Sie v1, v2, v3… für dasselbe Asset.
Das unterstützt klare Gespräche („Bitte aktualisiere v3“) und verhindert Datenverlust. Machen Sie die aktuelle Version in der UI deutlich sichtbar und erlauben Sie dennoch, ältere Versionen zum Vergleich zu öffnen.
Freie Kommentare allein sind chaotisch. Ergänzen Sie Struktur:
Unterstützen Sie Zeitcodes (Video) oder Seiten-/Regionspins (PDF/Bilder), damit Feedback sehr konkret wird.
Wenn jemand freigibt, protokollieren Sie:
Nach der Freigabe definieren Sie Regeln: üblicherweise Sperrung der freigegebenen Version, aber die Möglichkeit, eine kleine Revision als neue Version zu erzeugen (setzt Status zurück auf In Review). So bleiben Freigaben verteidigbar, ohne legitime Last‑Minute‑Änderungen zu blockieren.
Kreative Freigaben stehen und fallen damit, wie leicht die richtigen Dateien zur richtigen Zeit zugänglich sind. Asset‑Management ist der Bereich, in dem viele Kampagnen‑Apps heimlich frustrierend werden — langsame Downloads, verwirrende Dateinamen und endlose „Welche Version ist final?“‑Schleifen.
Ein sauberes Muster ist: Objektspeicher für die Binärdateien (schnell, skalierbar, günstig) und eine Datenbank für Metadaten (durchsuchbar, strukturiert).
Ihre DB sollte Asset‑Name, Typ, Kampagne, aktuelle Version, wer hochgeladen hat, Zeitstempel, Freigabestatus und Vorschau‑URLs nachverfolgen. Die Storage‑Ebene hält die Binärdatei und optional abgeleitete Items wie Thumbnails.
Zielen Sie auf eine kleine Menge, die die meisten Workflows abdeckt:
Seien Sie in der UI klar darüber, was hochgeladen werden kann und was nur per Link funktioniert. Das reduziert Fehl‑Uploads und Support‑Tickets.
Vorschauen beschleunigen Reviews und sind kundenschonend. Generieren Sie:
So können Stakeholder Dashboards mit Deliverables überfliegen, ohne hohe Auflösungsdateien zu laden.
Definieren Sie Dateigrößen‑Limits früh (Max‑Größe, Max‑Anzahl pro Kampagne, unterstützte Extensions). Validieren Sie sowohl Dateityp als auch Inhalt (verlieren Sie sich nicht in der Dateiendung). Bei Enterprise‑Kunden oder großen Dateien sollten Sie Malware‑/Virenscans in der Upload‑Pipeline erwägen.
Freigaben brauchen oft Nachvollziehbarkeit. Entscheiden Sie, was „Löschen“ bedeutet:
Kombinieren Sie das mit Aufbewahrungsrichtlinien (z. B. Assets 12–24 Monate nach Kampagnenende behalten), damit Speicherkosten planbar bleiben.
Eine Kampagnen‑App mit Kundenfreigaben braucht keine exotische Infrastruktur. Sie braucht klare Grenzen: eine benutzerfreundliche Oberfläche, eine API, die Regeln durchsetzt, Storage für Dateien und Daten sowie Hintergrundarbeiter für zeitbasierte Aufgaben wie Erinnerungen.
Starten Sie mit dem, was Ihr Team bauen und betreiben kann. Wenn Sie bereits React + Node, Rails oder Django kennen, ist das meist die richtige Wahl für v1. Beim Hosting zählt, dass das Deployment, Logs, Skalierung und Secrets einfach sind.
Wenn Sie schneller iterieren möchten, ohne sich an einen kompletten Eigenbau zu binden, kann eine vibe‑coding Plattform wie Koder.ai helfen, Workflows (Kampagnen, Assets, Freigaben, Rollen) per Chat‑gesteuerter Oberfläche zu prototypen — und später den Quellcode zu exportieren, wenn Sie die Kontrolle übernehmen wollen.
Frontend (Web‑App): Dashboards, Kampagnen‑Timelines, Review‑Screens. Kommuniziert mit der API und handhabt Echtzeit‑UX (Ladezustände, Upload‑Fortschritt, Kommentarthreads).
Backend‑API: Quelle der Wahrheit für Geschäftsregeln — wer darf freigeben, wann ist ein Asset gesperrt, welche Statusübergänge sind erlaubt. Halten Sie sie vorhersehbar und unaufgeregt.
Datenbank: Speichert Kampagnen, Aufgaben, Freigaben, Kommentare und Audit‑Events.
Dateispeicher + Vorschau‑Erzeugung: Legen Sie Uploads in Objektspeicher (z. B. S3‑kompatibel) ab und erzeugen Sie Thumbnails/Vorschauen.
Hintergrundjobs: Alles, was den Nutzer nicht blockieren sollte: E‑Mails, Vorschau‑Generierung, geplante Erinnerungen.
Für die meisten Agenturen ist ein modularer Monolith ideal: eine Backend‑Codebasis mit gut separierten Modulen (Assets, Freigaben, Notifications). Sie können später Services hinzufügen, wo sie wirklich helfen, ohne von Anfang an viele Deploys zu verwalten.
Behandeln Sie Benachrichtigungen als Feature‑Erstklasse: In‑App + E‑Mail, mit Opt‑outs und klarer Thread‑Logik. Eine Job‑Queue (BullMQ, Sidekiq, Celery etc.) lässt Sie Erinnerungen zuverlässig senden, Fehler wiederholen und Uploads/Freigaben nicht blockieren.
Planen Sie ab Start drei Umgebungen:
Wenn Sie tiefer in die Datenebene einsteigen wollen, lesen Sie /blog/data-model-and-database-design.
Ein sauberes Datenmodell sorgt dafür, dass Ihre Kampagnen‑App einfach bleibt, auch wenn sie wächst. Ziel: die häufigen Screens (Kampagnenlisten, Asset‑Queues, Freigabe‑Seiten) schnell und vorhersehbar halten und gleichzeitig die Historie erfassen.
Starten Sie mit einer kleinen Menge Tabellen, die widerspiegeln, wie Agenturen arbeiten:
Halten Sie IDs konsistent (UUIDs oder numerische IDs). Wichtig ist, dass jedes Kind‑Objekt (clients, campaigns, assets) eine organization_id trägt, damit Datenisolation durchsetzbar ist.
Status allein erklären nicht, was passiert ist. Ergänzen Sie Tabellen wie:
Das macht Audit‑Trails und Verantwortlichkeit einfach, ohne die Kerntabellen aufzublähen.
Die meisten Screens filtern nach Kunde, Status und Fälligkeitsdatum. Legen Sie Indizes an wie:
Denken Sie auch an zusammengesetzte Indizes für „was braucht jetzt Review“, z. B. (organization_id, status, updated_at).
Behandeln Sie Ihr Schema wie Produktcode: verwenden Sie Migrationen für jede Änderung. Seed‑einige Kampagnen‑Templates (Standard‑Phasen, Sample‑Status, Standard‑Freigabeschritte), damit neue Agenturen schnell starten und Testumgebungen realistische Daten haben.
Eine Kundenfreigabe‑App steht oder fällt mit Vertrauen: Kunden brauchen eine einfache Anmeldung, Ihr Team muss sicher sein, dass nur die richtigen Personen Zugriff haben. Beginnen Sie mit dem kleinsten Satz Auth‑Features, die agenturfähig sind, und erweitern Sie dann.
Wenn Ihre Nutzer hauptsächlich gelegentliche Kunden sind, ist E‑Mail + Passwort meist am reibungslosesten. Für größere Organisationen (Enterprise) sollten Sie SSO (Google/Microsoft) anbieten, damit sie bestehende Firmenkonten nutzen können. Support für beides ist möglich — machen Sie SSO nicht zur Pflicht, solange Ihre Zielgruppe es nicht erwartet.
Einladungen sollten schnell, rollenbasiert und nachsichtig sein:
Ein gutes Muster sind Magic Links zum Setzen eines Passworts, damit neue Nutzer sich nicht sofort Zugangsdaten merken müssen.
Nutzen Sie sichere Session‑Handhabung (kurzlebige Access‑Tokens, rotierende Refresh‑Tokens, httpOnly‑Cookies wo möglich). Fügen Sie einen Standard‑Passwort‑Reset‑Flow mit ablaufenden, Einmal‑Tokens und klaren Bestätigungsbildschirmen hinzu.
Authentifizierung beantwortet „Wer sind Sie?“, Autorisierung beantwortet „Was dürfen Sie tun?“. Schützen Sie jeden Endpunkt mit Berechtigungsprüfungen — besonders für Kampagnen‑Assets, Kommentare und Freigaben. Verlassen Sie sich nicht nur auf versteckte UI‑Elemente.
Führen Sie auditfreundliche Logs (Login‑Versuche, Einladung angenommen, Rollenänderungen, verdächtige Aktivitäten), aber speichern Sie keine Geheimnisse. Loggen Sie IDs, Zeitstempel, IP/Device‑Hinweise und Ergebnisse — niemals rohe Passwörter, vollständige Datei‑Inhalte oder private Kundennotizen.
Benachrichtigungen entscheiden, ob Ihre App hilfreich oder nervig wirkt. Ziel: Arbeit am Laufen halten, ohne jeden Kommentar zum Postfach‑Feuer zu machen.
Starten Sie mit einer kleinen, signalstarken Menge von Triggern und halten Sie sie über E‑Mail und In‑App konsistent:
Jede Benachrichtigung sollte das „Was“ und die nächste Aktion enthalten mit einem direkten Link zur richtigen Ansicht (z. B. Asset‑Review‑Seite oder Kunden‑Inbox).
Unterschiedliche Rollen wollen unterschiedliche Detailgrade. Geben Sie auf Nutzer‑Ebene Kontrolle:
Setzen Sie smarte Defaults: Kunden wollen typischerweise weniger E‑Mails als interne Teams und interessieren sich oft nur für Items, die ihre Entscheidung erfordern.
Fassen Sie ähnliche Updates zusammen (z. B. „3 neue Kommentare am Homepage‑Banner“) statt eine E‑Mail pro Kommentar zu senden. Schützen Sie vor unnötigen Benachrichtigungen:
Eine dedizierte Approval Inbox Seite reduziert Hin‑und‑Her, indem sie nur zeigt, was der Kunde jetzt tun muss: Items „Warten auf Sie“, Fälligkeitsdaten und ein One‑Click‑Pfad zur richtigen Review‑Ansicht. Verlinken Sie diese Seite aus jeder Review‑Mail (z. B. /approvals).
E‑Mail ist nicht garantiert. Speichern Sie Zustandsinfos (sent, bounced, failed) und wiederholen Sie intelligent. Wenn eine E‑Mail fehlschlägt, zeigen Sie das Admins in einer Activity‑Ansicht und fallen Sie auf In‑App‑Benachrichtigungen zurück, damit Workflows nicht stillschweigend stehen bleiben.
Wenn Kunden Creative freigeben, drücken sie damit Verantwortung aus. Ihre App sollte diese Entscheidungshistorie leicht auffindbar, leicht verständlich und später schwer anfechtbar machen.
Implementieren Sie einen Activity‑Feed auf zwei Ebenen:
Gestalten Sie Einträge lesbar für nicht‑technische Nutzer mit konsistentem Format: Wer hat was, wann und wo. Beispiel: „Jordan (Agentur) hat Homepage Hero v3 hochgeladen — 12. Dez, 14:14“ oder „Sam (Kunde) hat Homepage Hero v3 freigegeben — 13. Dez, 09:03.“
Für Verantwortlichkeit sollten Sie audit‑fähige Einträge für Folgendes speichern:
Praktische Regel: Wenn ein Ereignis Lieferumfang, Timing oder Kunden‑Signoff beeinflusst, gehört es in den Audit‑Trail.
Audit‑Events sollten in der Regel unveränderlich sein. Wenn etwas korrigiert werden muss, protokollieren Sie ein neues Ereignis (z. B. „Freigabe vom Agency re‑opened“) statt die Historie zu überschreiben. Anzeigen‑Felder (z. B. Tippfehler im Asset‑Titel) dürfen editierbar sein, aber auch diese Änderungen sollten protokolliert werden.
Bieten Sie eine Export‑Funktion (PDF oder CSV) für die Übergabe: final freigegebene Versionen, Freigabe‑Zeitstempel, Schlüsselfeedback und Links zu Assets. Besonders nützlich beim Projektabschluss oder bei Teamwechseln auf Kundenseite.
Richtig umgesetzt reduziert das Verwirrung, schützt beide Parteien und macht Ihre Software vertrauenswürdig statt kompliziert.
Reporting und Integrationen können schnell den Umfang einer Kampagnen‑App sprengen. Der Trick: liefern Sie das kleinste Set, das Teams im Alltag hilft, und bauen Sie nach realer Nutzung aus.
Beginnen Sie mit einfachen Reporting‑Views bzw. Dashboard‑Widgets für wöchentliche Statuschecks und tägliche Triage:
Fügen Sie einfache Kampagnen‑Health‑Indikatoren hinzu:
Diese Signale brauchen keine perfekte Vorhersage — nur klare Regeln und zuverlässige Hinweise.
Integrationen sollen manuellen Nachverfolgungsaufwand reduzieren, nicht neue Fehlerquellen schaffen. Priorisieren Sie nach den täglichen Gewohnheiten Ihrer Nutzer:
Auch wenn Sie keine öffentliche API sofort ausliefern, definieren Sie eine Erweiterungsstrategie:
Phase 1: Kern‑Dashboards + Listen für ausstehende/überfällige Items.
Phase 2: Health‑Indikatoren + Cycle‑Time‑Trends.
Phase 3: 1–2 wirkungsvolle Integrationen (meist E‑Mail + Slack).
Phase 4: Webhooks und eine partner‑fähige API.
Wenn Sie kostenpflichtige Stufen für Reporting und Integrationen planen, halten Sie sie einfach und transparent (siehe /pricing). Wenn Sie einen schnelleren Weg zu einem MVP wollen, kann Koder.ai helfen: Workflow in der Planungsphase iterieren, gehostete Builds für Feedback deployen und Snapshots nutzen, um Rollbacks durchzuführen, während Sie Anforderungen verfeinern.
Für tiefere Workflow‑Muster verweisen Sie auf verwandte Artikel unter /blog.
Beginnen Sie damit, das Kernproblem zu definieren: Freigaben und Feedback sind über E‑Mail, Chat und Laufwerke verstreut. Ihre v1 sollte Briefings, Assets, Feedback und Sign-offs zentral zusammenführen, damit alle Beteiligten schnell beantworten können:
Nutzen Sie messbare Ergebnisse wie Durchlaufzeit für Freigaben und Anzahl der Revisionszyklen, um den Umfang realistisch zu halten.
Gestalten Sie die Lösung für vier typische Gruppen:
Wenn Sie nur für interne Nutzer optimieren, leidet meist die Kundenakzeptanz und die Geschwindigkeit der Freigaben.
Wählen Sie eine kleine Menge Metriken, die echten Workflow-Schmerz messen:
Instrumentieren Sie diese früh, um Verbesserungen nach dem Launch von v1 zu validieren.
Eine pragmatische v1 beinhaltet:
Verschieben Sie erweiterte Berichte, tiefe Integrationen, Automatisierungsregeln und benutzerdefinierte Freigabepfade auf später, bis die Nutzung stabil ist.
Modellieren Sie den Workflow mit einigen Kernobjekten:
Definieren Sie dann einen Freigabe-Lebenszyklus (z. B. Draft → Internal review → Client review → Approved), wobei jeder Zustand eine operative Bedeutung hat (wer ihn verschieben kann, was erfüllt sein muss, was als Nächstes passiert).
Verknüpfen Sie Feedback immer mit einer Asset-Version, damit keine Diskussionen über die geprüfte Datei entstehen. Gute Optionen sind:
Struktur macht Feedback umsetzbar und reduziert Nacharbeit.
Halten Sie die Navigation um eine einfache Hierarchie herum konsistent: Kunde → Kampagne → Deliverables (Assets). Wichtige „Daily-Driver“-Screens sind:
Fügen Sie Filter hinzu, die reale Fragen beantworten: Kunde, Fälligkeitsdatum, Status, Verantwortlicher.
Beginnen Sie einfach mit Rollen, die die meisten Agenturen brauchen:
Definieren Sie Berechtigungen pro Objekt (Kampagne, Asset, Kommentar, Freigabe) wie view/comment/upload/approve/edit/delete. Folgen Sie dem Prinzip „least privilege“ und prüfen Sie Berechtigungen im Backend, nicht nur durch UI-Verstecken.
Behandeln Sie jeden Upload als neue, unveränderliche Version (v1, v2, v3…). Dateien nicht inplace überschreiben.\n\nSpeichern Sie Freigabemeta:
Üblicherweise wird die freigegebene Version gesperrt, aber es ist möglich, eine neue Version zu erstellen (setzt den Status wieder auf In Review), wenn Änderungen nötig sind.
Eine pragmatische Architektur besteht aus:
Für v1 ist ein modularer Monolith mit einem Job-Worker meist einfacher bereitzustellen und zu betreiben als viele Services.
