23 KiB
Konzept: Selbstlernende KI-Video-Ads für Kosmetik-Brands
Arbeitstitel: BrandLoop (Platzhalter) Stand: Juli 2026 · Entwurf v1
1. Elevator Pitch
Kosmetik-Brands geben einen Prompt ein und erhalten drei KI-generierte Werbevideos – jedes von einem anderen Top-Modell. Die Brand wählt das beste, die Ad läuft, und jedes Ergebnis fließt zurück in eine wachsende Brand Knowledge Base. Jedes weitere Video startet mit allem, was bisher funktioniert hat.
Der Pitch-Satz: „Deine Ads lernen aus jedem ausgegebenen Euro. Generische Tools erstellen Videos – wir bauen ein Ad-Gedächtnis für deine Brand."
2. Problem
- Kosmetik-Brands brauchen konstant frischen Video-Content (TikTok, Reels, Shorts), Produktion ist teuer und langsam.
- KI-Video-Tools (Creatify, Arcads & Co.) generieren zwar schnell, aber ohne Gedächtnis: Jedes Video startet bei null, Markenkonsistenz (Gesicht, Produkt, Ton) fehlt.
- Brands wissen nicht, warum eine Ad funktioniert hat – das Wissen steckt in Köpfen, nicht im System.
3. Zielgruppe
Primär: kleine bis mittlere Kosmetik-Brands (D2C), die selbst Ads schalten und keine große Agentur haben. Später erweiterbar auf andere D2C-Branchen – die Mechanik ist branchenunabhängig.
4. Der Produkt-Loop
Runde 1 (Kaltstart)
- Prompt: Brand Owner beschreibt die Idee („Frau hält roten Lippenstift in die Kamera").
- Generierung: 3 Videos parallel, jedes von einem anderen State-of-the-Art-Modell (z. B. Veo, Kling, Runway – Auswahl regelmäßig aktualisieren, da sich der Markt schnell bewegt).
- Auswahl: Brand Owner wählt das beste Video und lädt es hoch.
- Vote: Die Wahl ist das erste Trainingssignal.
Runde 2+ (der Loop greift)
- Neuer Prompt (andere Location, anderes Produkt).
- Vor der Generierung wird der Prompt automatisch mit dem Brand-Wissen angereichert (siehe Kap. 5) – die Videos starten nicht bei null.
- Nach jeder Runde: Vote + (sobald angebunden) echte Ad-Performance → Knowledge Base wird aktualisiert.
Ergebnis: Plug and Play, das mit jedem Durchlauf besser wird.
5. Brand Knowledge Base (das „Fine-Tuning-System")
Wichtig zur Einordnung: Wir trainieren kein Modell neu. Wir bauen pro Brand eine strukturierte Wissensdatenbank, die bei jeder Generierung als Kontext mitgegeben wird. Das ist billiger, sofort wirksam und funktioniert mit jedem Video-Modell – auch mit denen, die nächstes Jahr erscheinen.
Zwei Ebenen: Regeln vs. Attribute
- Brand-Regeln (kein Score, gelten immer): feste Prompts, die in jede Generierung injiziert werden – z. B. „neutraler/cleaner Hintergrund", „nur zeigen, was verlangt ist – nicht mehr, nicht weniger", Logo-Vorgaben, No-Gos. Regeln nehmen nicht am Scoring teil und können nicht „absteigen".
- Attribute (mit Score, konkurrieren): Locations, Farben, Voices, Handlungen etc. – alles, was pro Video variieren darf und woraus das System lernt.
Struktur
brand-knowledge/
├── _meta/
│ ├── brand-profil.md (aus Onboarding: Label, Produkte, Zielgruppe,
│ │ 3 Brand-Worte, am Markt seit)
│ ├── elo-parameter.md (Dev-Modus: K-Faktoren, Gewichtungen)
│ └── kategorie-index.md (alle Kategorien + Ø-Score → Startwerte neuer Einträge)
│
├── regeln/ (kein Score, gelten immer – nur Dev-Modus)
│ ├── hintergrund-clean.md
│ ├── nur-verlangtes-zeigen.md
│ ├── logo-schutz.md
│ └── referenzen-nie-kopieren.md
│
├── assets/ (versioniert, Release-Prinzip)
│ ├── gesicht-mara/
│ │ ├── asset.md (freigegeben: v4 · Versionskette v1→v4 mit Gründen)
│ │ ├── v1.md … v4.md (je: Beschreibung, Merkmale, Referenz-IDs, Votes)
│ │ └── referenzen/ (Bild-IDs aus Uploads & Generierungen)
│ └── produkt-rouge-no5/
│ ├── asset.md (freigegeben: v2)
│ └── referenzen/
│
├── attribute/ (Elo-Score, konkurrieren)
│ ├── location/
│ │ ├── kaiserslautern.md (5240 · aktiv)
│ │ ├── kaiserslautern--stadion.md (5560 · Unter-Attribut)
│ │ └── koeln.md (4980 · archiviert)
│ ├── licht/
│ │ ├── warm-abendlicht.md (6350)
│ │ ├── tageslicht.md (5210)
│ │ └── studio.md (4870 · archiviert)
│ ├── farben/
│ │ ├── warm-rot.md (6100)
│ │ └── pastell.md (5320)
│ ├── kamera/
│ │ ├── close-up.md (6280)
│ │ ├── langsamer-schwenk.md (5450)
│ │ └── makro-produkt.md (5720)
│ ├── voice/
│ │ ├── warm-weiblich.md (5890)
│ │ └── text-overlay-statt-voice.md (5100)
│ ├── geraeusche/
│ │ ├── asmr-oeffnen.md (5640)
│ │ └── upbeat-musik.md (5230)
│ ├── texte-hooks/
│ │ └── dein-rot-dein-statement.md (6020)
│ └── handlungen/
│ ├── produkt-in-kamera-halten.md (6150)
│ └── auf-kamera-zulaufen.md (5380)
│
├── videos/ (ein Eintrag pro generiertem Video)
│ ├── video-0031.md (Prompt, Script, Tags, Asset-Versionen,
│ │ Vote-Ergebnis, Performance-Daten)
│ └── …
│
└── logs/
├── 2026-06.md (chronologisch: jeder Vote, jede Analyse,
└── 2026-07.md jedes Elo-Update mit Grund)
Aufbau einer Attribut-Datei
# Kaiserslautern
Kategorie: location
Status: aktiv
Score: 5240
K-Faktor: 8 (etabliert, 12+ Vergleiche)
Startwert: 5000 (erster Eintrag der Kategorie, 2026-05-02)
Verwendet in: 12 Videos · Gewonnen: 8 · Verloren: 4
Letzte Verwendung: 2026-07-18 (video-0031)
Unter-Attribute: kaiserslautern--stadion (5560)
Tags: urban, nahbar, stadion, abendlicht
## Beschreibung
Mittelgroße Stadt in der Pfalz, Südwestdeutschland. Für die Brand liefert
sie einen urban-nahbaren Look ohne Großstadt-Anonymität: echte Straßen,
Sandstein-Altstadt, das Stadion als markanter Wiedererkennungspunkt und
der Pfälzer Wald als grüner Rahmen. Wirkt authentisch statt gestellt –
passt zu „mutig, clean, luxuriös" über den Kontrast: edles Produkt,
bodenständige Umgebung.
## Was diese Location ausmacht
- Urban, aber nahbar; Stadion als Wiedererkennungspunkt
- Warmes Abendlicht funktioniert besser als Tageslicht
- Beste Kombination bisher: + close-up + warm-rot (3 Siege gemeinsam)
## Details
### Erkennungspunkte / Drehorte
- Fritz-Walter-Stadion (Betzenberg): rote Sitzreihen, erhöhte Lage
über der Stadt → als Unschärfe-Hintergrund am stärksten (siehe
Unter-Attribut kaiserslautern--stadion)
- Altstadt / Marktplatz: roter Sandstein, enge Gassen, warme Töne
- Stadtpark & Waldrand: grüner Kontrast für Natur-Kosmetik-Claims
### Licht & Tageszeit
- Golden Hour (Sommer ca. 19:30–20:45): warmes Licht auf Sandstein –
bester gemessener Look (Thumbstop 41 %)
- Mittagslicht vermeiden: harte Schatten, kühle Wirkung (verlor
2× gegen Abendlicht)
### Farbwelt & Sound
- Dominanz warmer Rot-/Sandtöne → harmoniert mit Produktfarbe
warm-rot (6100) und Rouge No. 5
- Geräuschkulisse: ruhige Straße, Vogelstimmen im Park – kompatibel
mit ASMR-Attribut, ungeeignet für Upbeat-Schnitte
### Prompt-Bausteine (gehen in die Generierung)
- "mid-size German city, warm sandstone old town, golden hour"
- "red stadium seats soft-focus in background, elevated view"
- negativ: "no crowds, no traffic, no gray overcast sky"
## Gelernt aus Vergleichen
- vs. Köln (2026-07-12, Vote): Stadion-Hintergrund war der Unterschied
→ Unter-Attribut kaiserslautern--stadion angelegt (Start: Ø 5480)
- vs. Studio (2026-06-28, Ad-Performance): Outdoor schlug Studio
bei Thumbstop-Rate (41 % vs. 24 %)
## Score-Verlauf
| Datum | Ereignis | Gegner | Δ | Neu |
|------------|-----------------------------------|---------|------|------|
| 2026-05-02 | Angelegt (Kategorie leer) | – | – | 5000 |
| 2026-06-14 | Vote video-0018 (Favorit bestätigt ×0,3) | koeln | +6 | 5006 |
| 2026-06-28 | Ad-Performance video-0022 (×2) | studio | +44 | 5050 |
| 2026-07-12 | Gezielte Frage „welche Stadt?" | koeln | +10 | 5060 |
| 2026-07-15 | Vote video-0029 (Abweichung, voll)| studio | +28 | 5088 |
| 2026-07-18 | Ad-Performance video-0031 (×2) | koeln | +152 | 5240 |
Aufbau einer Video-Datei
# video-0031
Szene: „Roter Lippenstift – Close-up"
Erstellt: 2026-07-18 · KI-Modell: Modell A
Script: bestätigt mit 1 Nutzer-Änderung („Schwenk langsamer" → Lernsignal an kamera/)
## Verwendete Bausteine
Regeln: alle aktiven (4)
Assets: gesicht-mara v3 · produkt-rouge-no5 v2
Attribute: kaiserslautern (5240) · warm-abendlicht (6350) · close-up (6280)
· warm-rot (6100) · warm-weiblich (5890) · dein-rot-dein-statement (6020)
## Ergebnis
Vote: gewonnen gegen video-0032/-0033/-0034 (System-Favorit bestätigt → ×0,3)
Veröffentlicht: TikTok + Instagram (2026-07-18)
Performance (Stand 19.07.): CTR 2,4 % · Thumbstop 41 % · ROAS 3,1× · +218 Follower
→ Elo-Updates siehe logs/2026-07.md
Mechanik
- Jedes Video wird beim Erstellen automatisch getaggt (Location, Farben, Voice, Geräusche, Texte, Handlungen, Personen).
- Neuer Eintrag startet beim Durchschnitts-Score seiner Kategorie (neue Location = Durchschnitt aller Locations). Grund: Elo ist relativ – stünde ein neuer Eintrag fix bei 5000, während die Kategorie längst bei 6500 liegt, gälte er als „schlechter als alles Bisherige", obwohl er nur ungetestet ist, und würde nie vorgeschlagen. Nur der allererste Eintrag einer Kategorie startet bei 5000 (Skala 0–10.000). Die Unsicherheit neuer Einträge steckt nicht im Startwert, sondern im K-Faktor (siehe Kap. 6).
- Attribute können Unter-Attribute bilden (Kaiserslautern → Stadion), wenn Vergleiche zeigen, dass ein Detail den Unterschied macht.
- Neben dem Score zählt der Inhalt: Bei Vergleichen wird per LLM analysiert, was das Gewinner-Attribut besser gemacht hat, und als Text in der .md festgehalten.
- Jede Attribut-Datei hat drei Text-Ebenen: Beschreibung (allgemein, was ist das), Was es ausmacht (die gelernte Essenz) und Details (präzise Fakten: Drehorte, Licht/Tageszeit, Farbwelt, Sound, fertige Prompt-Bausteine inkl. Negativ-Prompts). Die Details schreibt das System selbst – aus Analysen, Vergleichen und Performance-Daten; der Nutzer sieht davon nichts.
Logs & Historie
- Jeder Vote erzeugt einen Log-Eintrag pro betroffenem Attribut: Datum, Vergleichspartner, Punktänderung, Grund (Vote / Performance / gezielte Frage).
- Damit ist jederzeit ablesbar, was besser oder schlechter geworden ist – und warum das System etwas empfiehlt.
- Archivieren statt löschen: Absteigende Attribute werden auf „archiviert" gesetzt, ihre Historie bleibt. Ein schlechter Score ist auch Wissen – kommt die Brand später auf das Attribut zurück, startet sie nicht wieder bei null.
6. Scoring-System
Problem: Zuordnung (Attribution)
Gewinnt Video A (Kaiserslautern) gegen Video B (Köln), kann der Grund auch das Modell, das Licht oder die Stimme sein. Fixe +10 auf „Kaiserslautern" lernt das Falsche.
Lösung: Elo + verteilte Punkte
- Elo-Prinzip: Punktegewinn hängt vom Score des Gegners ab. Sieg gegen ein hoch bewertetes Attribut bringt mehr als gegen ein schwaches. Startwert = Kategorie-Durchschnitt (siehe Kap. 5). K-Faktor trägt die Unsicherheit: neue Einträge machen anfangs große Punktsprünge (schnelles Einpendeln), etablierte kleine (Stabilität).
- Verteilung: Bei einem Sieg bekommen alle Tags des Gewinner-Videos anteilig Punkte, alle Tags des Verlierers verlieren anteilig. Über viele Runden kristallisiert sich heraus, welcher Tag wirklich den Unterschied macht.
- Gezielte Fragen: Zusätzlich kann das System dem Brand Owner isolierte Fragen stellen („Welche Stadt war besser?") – die Antwort wirkt dann nur auf dieses eine Attribut. Das ist das schnellste Signal gegen das Zuordnungsproblem.
- System-Favorit mit Anchoring-Schutz: Bei der Auswahl markiert das System seinen vorhergesagten Favoriten dezent (Umrandung). Da Menschen markierte Vorschläge überproportional bestätigen, werden Votes gewichtet: Bestätigung des Favoriten = wenig Punkte, Abweichung = volle Punkte (Abweichen ist das stärkere Signal). Die Übereinstimmungsrate zwischen Vorhersage und Owner-Wahl wird getrackt – sie ist die zentrale Qualitätsmetrik der Knowledge Base.
- Inhaltsvergleich: Nach jedem Vote vergleicht ein LLM die .md-Inhalte der konkurrierenden Attribute und schreibt die Erkenntnis („Stadion war der Unterschied") in beide Dateien. Bei Bedarf entsteht ein neues Unter-Attribut mit eigenem Score.
Zwei Signalquellen
| Signal | Quelle | Stärke |
|---|---|---|
| Vote des Brand Owners | Auswahl aus 3 Videos + gezielte Fragen | schnell, subjektiv |
| Ad-Performance | Meta/TikTok Ads API: CTR, Thumbstop-Rate, ROAS, neue Follower | langsam, objektiv – das ist der Moat |
Performance-Daten werden höher gewichtet als Votes und brauchen keine Bestätigung durch den Owner – der Markt hat bereits entschieden. Damit bewertet am Ende der Markt, nicht das Bauchgefühl.
7. Konsistenz: Gesicht, Produkt, Handlung
Der einzige Punkt, an dem echtes Modell-Anpassen nötig ist. Die Referenz-Assets dafür (Gesicht, Produkt) werden im Tab „Verbessern" erstellt und gepflegt (siehe Kap. 8):
- Gesicht/Person: Character-Reference-Features der Video-Modelle bzw. LoRA-Training auf Referenzbildern – so bleibt das Brand-Gesicht (oder der Brand Owner selbst) in jedem Video identisch.
- Produkt: Referenzbilder des Produkts (Lippenstift) in die Generierung einspeisen – kritisch, denn das Produkt muss 1:1 stimmen, sonst ist die Ad unbrauchbar.
- Handlungen: Als Attribut-Dateien in der Knowledge Base beschrieben („Produkt in Kamera halten: Nahaufnahme, 2 Sek., dann Schwenk") und in jeden Prompt injiziert.
8. Funktionen & UI
Vom Homescreen aus: Erstellen (Szene oder Modell) – und Verbessern ist jederzeit auf jedes Asset anwendbar, kein getrennter Silo. Lebenszyklus: erstellen → jederzeit verbessern.
Erstellen → Szene (Video)
Nutzer gibt den Prompt ein → System überarbeitet ihn automatisch und baut die Brand Knowledge ein (Regeln + Top-Attribute + freigegebene Assets) → Script wird angezeigt: Nutzer liest, kann bearbeiten und bestätigt → erst dann werden die Videos generiert (Kosten entstehen erst nach Bestätigung; Script-Änderungen sind zusätzliches Lernsignal).
Videoanzahl einstellbar (3–6): Größere Brands zahlen gern für mehr Varianten pro Runde – Preis pro Video. Deckel bei 6, weil (a) es nur eine Handvoll Top-Modelle gibt und (b) bei zu vielen Videos die Auswahlqualität des Owners sinkt und das Trainingssignal verrauscht.
Erstellen → Modell (Person, Produkt, Asset)
- Person/Produkt beschreiben + Referenzbilder hochladen → Asset wird erstellt und direkt angezeigt.
- Gefällt es nicht („die Person sieht nicht gut aus") → sofort Verbessern, beliebig oft.
Beim Onboarding (tutorial-artig: Fullscreen-Intros + kurze Formularseiten, 5 Pflichtfragen inkl. „Wie lange am Markt?") entsteht die initiale Brand Knowledge: Logo, Produktbilder, bestehende Top-Ads (optional, empfohlen). Direkt danach wird ein erstes Ergebnis gezeigt, damit der Nutzer sofort sieht, was seine Knowledge Base bewirkt.
Developer-Modus (versteckt, nur intern)
Fünfter Navigations-Bereich, für Nutzer unsichtbar – das Feintuning und Betriebsgeheimnis der App. Enthält: die festen Regeln (Prompt-Injection, vom Nutzer weder sichtbar noch verwaltbar), den Prompt-Einblick (der fertige angereicherte Prompt, der wirklich ans Videomodell geht) und die Elo-Parameter (K-Faktoren, Gewichtung Performance vs. Vote, Startwert-Logik).
Verbessern (jederzeit, Fine-Tuning der Brand Knowledge)
Verbessert die Brand-Assets selbst – Gesicht, Produkt, weitere. Die hier erzeugten Referenzen sorgen für die 1:1-Konsistenz in jedem generierten Video.
- Asset wählen (z. B. das Brand-Gesicht oder das Produkt).
- Änderung beschreiben – auf zwei Wegen:
- Text-Feedback: „Haare dunkler, Ausstrahlung natürlicher."
- Referenz hochladen – dabei Pflichtfeld: Was soll aus der Referenz übernommen werden (Frisur, Hautton, Verpackungsdetail …)? Ohne Beschreibung rät das System und kopiert das Falsche. Nebeneffekt: Die Beschreibung liefert saubere neue Merkmale für die Asset-Datei.
- Mehrere neue Versionen (z. B. 3–5) werden generiert – jede zieht andere Vorlieben aus der Knowledge Base – angezeigt als Vorher/Nachher-Bild.
- Owner wählt die beste → neue Version des Assets. Beliebig wiederholbar – so wird das Produkt Schritt für Schritt personalisiert.
Scoring beim Verbessern: Die Merkmale der Gewinner-Version steigen in der Elo gegenüber den Merkmalen der ersetzten Version. Wichtig: Nur Merkmale, in denen sich die Versionen unterschieden, bekommen Punkte – was alle Versionen gemeinsam hatten, hat nicht konkurriert und trägt kein Signal.
Versionen einfrieren (Release-Prinzip): Assets entwickeln sich in Versionen (v1 → v2 → v3, Versionskette im Log mit Änderungsgrund und Gewinner). Videos nutzen immer eine freigegebene Version – ein neues Gesicht ist ein bewusster Release, kein schleichender Drift. Jedes Video loggt, welche Asset-Version es verwendet hat; so bleibt messbar, welche Version performt, und die Brand behält Wiedererkennung.
Rechte (Regeln, fest):
- Referenzen fremder Inhalte: Merkmale beschreiben und lernen, nie 1:1 kopieren (Urheberrecht).
- Gesichter echter Personen nur mit dokumentierter Einwilligung – auch beim Brand Owner selbst. Rein KI-generierte Gesichter sind der rechtlich sichere Standard.
9. Differenzierung (Moat)
- Ad-Gedächtnis pro Brand: Konkurrenz generiert, wir lernen. Je länger eine Brand dabei ist, desto besser die Ergebnisse – und desto höher die Wechselkosten. Die Knowledge Base gehört zur Brand, ist aber nur in unserem System nutzbar.
- Modellunabhängigkeit: Wir hängen an keinem Video-Modell. Erscheint ein besseres, tauschen wir es ein – die Knowledge Base bleibt.
- Performance-Loop: Anbindung an echte Ad-Daten macht aus „schöne Videos" → „Videos, die nachweislich verkaufen". Das ist das Argument gegenüber der Kosmetik-Industrie.
10. Ressourcen & Tech-Stack (Stand: Juli 2026)
Architektur
Cloud-basiert (V1). Alles läuft auf gemieteter Infrastruktur in Deutschland – kein eigenes Blech, DSGVO-konform. Später (V2+): eigener MCP-Server, über den Brands ihre Knowledge Base auch in eigene Tools (z. B. Claude, interne Systeme) einbinden können – ein zusätzliches Verkaufsargument Richtung Industrie.
App: Web + native parallel (ein Codebase, z. B. Flutter oder React Native). Achtung: In-App-Abos kosten 15–30 % App-Store-Abgabe – Zahlung deshalb wo möglich über die Web-App via Stripe abwickeln.
Stack
| Baustein | Wahl | Warum | Kosten/Monat (realistisch) |
|---|---|---|---|
| Hosting | Hetzner Cloud | DSGVO, Rechenzentrum in Deutschland, bestes Preis-Leistungs-Verhältnis | MVP: CX32 (4 vCPU/8 GB) ~ €7 · ab ~25 Brands: CX42 (8 vCPU/16 GB) ~ €16–17 |
| Video-Speicher | Hetzner Object Storage (S3-kompatibel) | Videos sind zu groß für die Server-Disk; inkl. 1 TB | ~ €6 Basis, wächst mit Datenmenge |
| Backend/DB | Appwrite (self-hosted) | Supabase-ähnlich (Auth, DB, Functions, Realtime), aber ohne Lizenzkosten – läuft auf dem Hetzner-Server | €0 |
| KI-Gateway | OpenRouter | Eine API + eine Abrechnung für LLM und Video – deckt unser Multi-Modell-Versprechen ab | nutzungsbasiert (s. u.) |
| LLM | Claude (via OpenRouter) | Prompt-Überarbeitung, Script, Tagging, LLM-Vergleiche, Details-Texte | ~ €30–50 bei 250 Szenen |
| Videomodelle | Seedance 2.0 + Veo 3.1 + Sora 2/Wan (via OpenRouter) | 3–6 Videos, jedes von einem anderen Top-Modell – hält das Konzeptversprechen | ~ €0,70–1,90 pro Video (5 s, 720p–1080p) |
| Payment | Stripe | Abos + nutzungsbasierte Abrechnung (Preis pro Video), EU-fähig | ~ 1,5–3 % + €0,25 pro Transaktion |
| Resend o. Brevo | Verifizierung, Rechnungen, Benachrichtigungen | €0–20 | |
| Domain | – | – | ~ €15/Jahr |
| Monitoring/Backups | Uptime Kuma (self-hosted) + Sentry Free + Hetzner-Snapshots | Ausfälle & Fehler sehen, DB + Knowledge Bases täglich sichern | ~ €1–10 |
Beispielrechnung: 25 Brands (~250 Szenen ⇒ ~1.000 Videos/Monat)
| Posten | ca./Monat |
|---|---|
| Videogenerierung (1.000 × Ø €1,20) | € 1.200 |
| LLM (Claude: Scripts, Tagging, Vergleiche) | € 40 |
| Server (CX42) + Object Storage | € 25 |
| E-Mail, Monitoring, Sonstiges | € 25 |
| Gesamt Infrastruktur + KI | ~ € 1.300 |
→ Über 90 % der Kosten sind Videogenerierung. Genau deshalb funktioniert das Preismodell „Preis pro Video" (Kap. 8): Die variablen Kosten trägt der Kunde direkt mit. Bei 25 Brands ≈ €52 Kosten/Brand/Monat – ein Abo ab ~€150–300/Brand lässt gesunde Marge. Video-API-Preise fallen zudem tendenziell weiter.
Rechtliches (nicht vergessen)
- AVV (Auftragsverarbeitungsvertrag) mit Hetzner abschließen – Standard, kostenlos
- EU AI Act: KI-generierte Werbevideos müssen als KI-generiert gekennzeichnet werden
- Einwilligungen für echte Gesichter dokumentieren (siehe Kap. 8), Impressum/AGB/Datenschutzerklärung
- Meta/TikTok Ads API (V3): Entwickler-Zugänge und App-Reviews der Plattformen früh beantragen – die Freigabeprozesse dauern
11. Risiken & offene Punkte
- Kosten pro Runde: Durch einstellbare Videoanzahl (3–6) mit Preis pro Video trägt der Kunde die Mehrkosten selbst – aus dem Risiko wird ein Umsatzhebel.
- Kaltstart: Ohne Historie ist Runde 1 generisch. Abgefedert durch das Onboarding im Erstellen-Tab (Logo, Produktbilder, Top-Ads → initiale Knowledge Base).
- Anchoring durch Favoriten-Markierung: Wird über die Vote-Gewichtung (Bestätigung < Abweichung) und das Tracking der Übereinstimmungsrate kontrolliert. Falls die Bestätigungsrate verdächtig hoch wird (>90 %), Markierung testweise ausblenden.
- Wenig Datenpunkte: Elo braucht viele Vergleiche. Der LLM-Inhaltsvergleich gleicht das aus, weil er schon aus einem einzigen Vergleich Erkenntnisse zieht.
- Rechte: KI-Gesichter und Kennzeichnungspflicht für KI-generierte Ads (EU AI Act) klären.
- Plattform-Anbindung: Meta/TikTok-API-Zugänge und Attributionsfenster technisch prüfen.
12. Grobe Roadmap
- MVP: Prompt → 3 Videos (3 Modelle via API) → Auswahl → einfache Knowledge Base (Tags + Elo) → Prompt-Anreicherung in Runde 2.
- V2: Gezielte Vergleichsfragen, LLM-Inhaltsvergleich, Unter-Attribute, Produkt-/Gesichts-Referenzen.
- V3: Meta/TikTok-Ads-Anbindung, Performance-gewichtetes Scoring, Reporting-Dashboard für die Brand.