Daten & Formeln
Welche Berichte wir uns ziehen, welche Kennzahlen daraus entstehen und wie jede Formel rechnet — mit Quelle und Code-Ort. Die Gebühren-Tabellen sind live: was hier steht, rechnet ab sofort. Damit bleibt das Tool nachvollziehbar statt Blackbox.
Berichte — was wir uns von Amazon ziehen
Nur diese Berichte braucht das Tool. Alles andere ist unnötig.
| Bericht | Priorität | Plattform | Wo ziehen | Turnus | Liefert | Im Tool |
|---|---|---|---|---|---|---|
| Business Report (Verkäufe & Traffic) | Pflicht | Seller Central | Seller Central → Berichte → Geschäftsberichte → ‚Verkäufe und Besucherzahlen – Detailseite' (nach Datum) | je Periode — monatlich empfohlen, lückenlos | Umsatz, Bestellungen, Einheiten, Sitzungen, CVR, Einheiten-CVR, Buybox %, AOV | Marke → Berichte |
| Ads-/Kampagnenbericht (Sponsored Products) | Pflicht | Ads-Konsole | Amazon Ads Konsole (advertising.amazon.de) → Berichte → Sponsored Products → Berichtstyp ‚Kampagne' | je Periode — Zeitraum deckungsgleich zum Business Report | Spend, PPC-Umsatz, ACoS, ROAS, CTR, CPC, PPC-CR, Impressionen, Ziel-ACoS (aus Portfolio-Namen) | Marke → Berichte |
| Search-Term-Report (Suchbegriffe) | empfohlen | Ads-Konsole | Amazon Ads Konsole (advertising.amazon.de) → Berichte → Sponsored Products → Berichtstyp ‚Suchbegriff' | monatlich oder quartalsweise | Wasted Spend, Negativ-Kandidaten, N-Gram-Wurzeln, ASIN-Ziele ohne Conversion | Marke → Berichte |
| SQP (Search Query Performance) | empfohlen | Seller Central | Seller Central → Marken → Marken-Analysen → Suchanfragen-Leistung (braucht Markenregistrierung) | monatlich | Eure CTR/CVR vs. Markt, verlorene Käufe, Umsatzpotenzial je Suchanfrage | Marke → Berichte |
| Cerebro-Export (Helium 10) | optional | Helium 10 | Helium 10 → Cerebro → eigene ASIN + Wettbewerber-ASINs → CSV-Export | je Listing-Projekt / bei Bedarf | SOV, Quick-Wins, Umsatzlücken, Opportunity-Matrix, Keyword-Tiering (primary→Titel …) | Produkt-Werkbank → SOV-Report |
| Flat-File-Kategorievorlage | optional | Seller Central | Seller Central → Katalog → Produkte per Upload hinzufügen → Vorlage der Kategorie | bei Amazon-Vorlagen-Änderung (jeweils NEUSTE Vorlage) | keine Kennzahl — Ziel-Format für upload-fertige Flat Files | Marke → Flat Files |
| Amazon-Gebühren-PDF | optional | Amazon (PDF) | Amazon-Ankündigungen/Hilfeseiten (Amazon verschickt Gebühren-Änderungen als PDF — keine öffentliche Tabellen-API) | bei Gebühren-Änderung | Verkaufsgebühr-Sätze, Lager- und Entsorgungs-Tabellen des Margen-Rechners | Einstellungen → Daten & Formeln (diese Seite) |
| Retouren-/Payments-Bericht | geplant | Seller Central | Seller Central → Berichte → Zahlungen bzw. Retouren | — | Retourenquote (steht NICHT im Business Report — deshalb bewusst noch keine Retourenquote im Cockpit, kein Platzhalter) | noch nicht integriert |
Listing-Inhalte, Bilder und Bewertungen brauchen KEINEN Bericht — die holt das Tool per Scrape, die ASIN reicht.
Datenfluss — was mit jedem Datenpunkt passiert
Quelle → Speicher → Analysen (mit Code-Ort) → Verwendung → Anzeige. Testgesichert: jeder Code-Ort existiert, keine Kette unvollständig.
ASIN & Listing-Import
Quelle: Pflichtfeld ASIN beim Anlegen; Import läuft als erste Etappe des Ein-Klick-Laufs (D172) · Speicher: listing_snapshots
| Analyse | Outcome | Code-Ort |
|---|---|---|
| Listing-Scrape | Titel, Bullets, Beschreibung, Attribute, Bilder-URLs, Preis (IST-Zustand) | src/lib/scrape/apifyProduct.ts |
| Fakten-Extraktion | Produkt-Wahrheit (Materialien, Maße, Specs, USPs) | src/lib/analysis/factsFromListing.ts |
| Listing-Kontrolle | Sektions-Scores, Keyword-Abdeckung, Maßnahmen | src/lib/analysis/listingAudit.ts |
| Marken-Ableitung | Eigenmarken-Kandidat aus dem Original-Titel (D149, Fallback) | src/lib/text/marken.ts |
| A+-Bild-Auslese (Upload, optional) | hochgeladene A+-Bilder werden EINMAL per Vision ausgelesen → extrahierter Text nach aplusContent; die Bild-Bytes werden verworfen, nie gespeichert (ephemer, D220) | src/lib/analysis/bildAuslese.ts |
Verwendung: Content-Prompts (Listing-IST: verbessern, nicht kopieren) · Zahlen-Herkunfts-Quellen des Gates (D114) · Conversion-Blocker-Abgleich (Kunden-Thema vs. Listing-Antwort, D167) · aplusContent → Content-Beleg-Quellen + Feature-Ranking (D220)
Wirkung der Analyse auf den Content — Ergebnis für Ergebnis
Jedes Analyse-Ergebnis mit seinem Weg in die Text-Erstellung. Testgesichert: eine deklarierte Wirkung muss im Code wirklich gelesen werden, und „ohne Wirkung“ gilt nur mit Begründung.
| Analyse-Ergebnis | entsteht in | Wirkung auf den Content |
|---|---|---|
| listing_snapshots (Titel, Bullets, Beschreibung, Attribute, Preis) | Listing-Import | ✓ Prompt-InputRecipeInputs.listingIst + facts (Produkt-Wahrheit)gelesen in: app/actions.ts · lib/recipes/listing.ts |
| listing_snapshots.bilderText (eigene Bild-/A+-Auslese) | Bildanalyse (Vision) | ✓ Prompt-InputRecipeInputs.bildBelege — Bild-Aussagen gelten als belegt (D230)gelesen in: app/actions.ts · lib/recipes/listing.ts |
| listing_snapshots.bildBefunde | Bild-Auslese (Rest-Feld) | ohne Wirkung — bewusstSeit D165 sind die Regel-Urteile der Bild-Auslese abgeschafft; das Feld wird mit einer LEEREN Liste beschrieben und trägt keinen Inhalt mehr. Es geht also keine Analyse verloren — das Feld ist ein Schema-Rest und Kandidat zum Entfernen (eigene Migration). |
| review_insights.payload (Pain Points, Kaufauslöser, Kundensprache, Kern-These, Erkenntnis-Karten) | Roh-Analyse + Verdichtung | ✓ Prompt-Input |
QM-Blockier-Log — welche Regel scheitert wie oft?
Jeder harte QM-Block wird hier gezählt. Häufige Wiederholungen derselben Regel sind Bau-Aufträge (neuer Fixer, bessere Regel oder fehlender Input), keine Zufälle.
| Regel | Verstöße | Zuletzt | Letzter Beleg |
|---|---|---|---|
| sprache.produkt-fokus | 1 | 4.8.2026, 07:27:17 | 'Steinbach steht für Material, dem viele Nutzer beim Poolzubehör vertrauen und das sie in ihrem Bekanntenkreis weiterempfehlen.' – Anbieter-/Marken-Standpunkt o… |
Kombinierte Kennzahlen — brauchen mehrere Quellen
Fehlt eine der Quellen, fehlt die Kennzahl — das Tool zeigt dann den Nachlade-Hinweis statt einer Schätzung.
| Kennzahl | Entsteht aus | Formel / Regel |
|---|---|---|
| TACoS | Ads-Bericht + Business Report | Spend (Ads) ÷ Gesamtumsatz (Business) × 100 |
| PPC-Anteil | Ads-Bericht + Business Report | PPC-Orders (Ads) ÷ Bestellungen (Business) × 100 |
| Organisch-Umsatz | Ads-Bericht + Business Report | max(0, Umsatz − PPC-Umsatz) — Näherung, kein Cent-Ledger |
| Organische CR | Ads-Bericht + Business Report | max(0, Bestellungen − PPC-Orders) ÷ Sitzungen × 100 |
| ACoS/TACoS-Ampel | Ads-Bericht + Margen-Kalkulation (oder Hand-Marge) | Schwelle = Account-Marge (Hand) VOR Ø Break-even-ACoS der Produkt-Kalkulationen |
| Perioden-Diagnose | Business + Ads (+ SOV & SQP als Ursachen-Signale) | ln-Zerlegung Umsatz = Sitzungen × CVR × AOV + Quer-Abgleich der Module |
| Handlungs-Hebel (€) | Cerebro + Search-Term + Ads + SQP | je Handlung eigene Quelle: SOV-Korridor, Wasted Spend − ASIN-Anteil, Überspend über Ziel-ACoS, SQP-Potenzial |
KPI- & Formel-Register
Business Report (Verkäufe & Traffic) · 6 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Bestellungen (Orders) | Bestellposten gesamt; FALLBACK bestellte Einheiten, wenn Spalte fehlt | reporting-main (Doppel-Definition im Bestand hier EINMAL festgelegt, D48) | src/lib/reports/business.ts |
| CVR | Orders ÷ Sitzungen × 100Immer aus Roh-Summen, nie aus der Datei übernommen. | reporting-main computeWeeklyRow | src/lib/reports/business.ts |
| Einheiten-CVR | Einheiten ÷ Sitzungen × 100 | reporting-main | src/lib/reports/business.ts |
| Buybox % | Σ(Buybox% × Sitzungen) ÷ Σ Sitzungen (sitzungsgewichtet) | reporting-main Business-Parser-Golden | src/lib/reports/business.ts |
| AOV | Umsatz ÷ Bestellungen | reporting-main | Cockpit (Hero-Kachel) |
| Zahlformat | aus den DATEN erkannt (deutsch 1.234,56 vs. US 1,234.56), nie geraten | reporting-main-Prinzip | src/lib/reports/business.ts (makeNumParser) |
Advertising / PPC (Ads-Bericht) · 11 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| ACoS | Spend ÷ PPC-Umsatz × 100 | reporting-main Ads-Parser-Golden (Raten IMMER aus Rohwerten) | src/lib/reports/ads.ts |
| ROAS | PPC-Umsatz ÷ Spend | reporting-main | src/lib/reports/ads.ts |
| CTR / CPC / PPC-CR | Klicks÷Impr. ×100 · Spend÷Klicks · PPC-Orders÷Klicks ×100 | reporting-main | src/lib/reports/ads.ts |
| Impressionen (abgeleitet) | round(Klicks ÷ CTR) — nur wenn Export keine Impressions-Spalte hat | reporting-main-Golden (DE-Export) | src/lib/reports/ads.ts |
| Ziel-ACoS | aus dem Portfolio-Namen geparst (‚ACoS Ziel 12,5%' → 0,125) | reporting-main parseTargetAcos | src/lib/reports/ads.ts |
| Totals-Raten | aus SUMMEN — nie Mittelwert der Zeilen-ACoS | reporting-main Aggregate-Golden | src/lib/reports/ads.ts |
| TACoS | Spend ÷ Gesamtumsatz (Business Report) × 100 | reporting-main computeWeeklyRow-Golden | src/lib/reports/ads.ts (combineWithBusiness) |
| PPC-Anteil | PPC-Orders ÷ Bestellungen × 100 | reporting-main-Golden (Orders-basiert!) | src/lib/reports/ads.ts |
| Org.-CR | max(0, Orders − PPC-Orders) ÷ Sitzungen × 100 | reporting-main-Golden | src/lib/reports/ads.ts |
| Organisch-Umsatz | max(0, Umsatz − PPC-Umsatz) | reporting-main (‚Näherung, kein Cent-Ledger') | src/lib/reports/ads.ts |
| ACoS/TACoS-Ampel | unter der Schwelle grün, ab der Schwelle rot; ohne Schwelle keine Färbung. Schwelle: Account-Marge (Hand-Eintrag) VOR Ø Break-even-ACoS der Produkt-Kalkulationen | reporting-main acosColor + effectiveMarginPct | Advertising-/Cockpit-Seite |
Search-Term-Report & N-Gram · 4 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Wasted Spend | Σ Spend aller Suchbegriffe mit Spend > 0 und 0 Käufen (inkl. ASIN-Ziele; ASIN-Anteil separat ausgewiesen) | reporting-main SearchTerm-Golden (136,93-€-Fixture) | src/lib/reports/searchterm.ts |
| ASIN-Ziel-Erkennung | Suchbegriff matcht ^B0 + 8 Zeichen [a-z0-9] | reporting-main isAsinTerm | src/lib/reports/searchterm.ts |
| N-Gram-Wurzeln | zusammenhängende 1/2/3-Wort-Folgen; De-Dup je Term; ASINs ausgeschlossen; KEIN Stemming, Stopwörter bleiben (literale Wurzeln für Keyword-Aktionen); Raten aus Summen | reporting-main ngram-Golden | src/lib/reports/searchterm.ts (ngramRoots) |
| Negativ-Kandidaten | Wurzeln mit Spend > 0 und 0 Käufen, sortiert nach Spend | reporting-main | src/lib/reports/searchterm.ts |
Search Query Performance (SQP) · 3 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Eure CTR / CVR vs. Markt | Marken-Klicks÷Marken-Impr. bzw. Marken-Käufe÷Marken-Klicks — Markt analog aus Gesamt-Spalten; Report-Ebene aus SUMMEN | reporting-main SQP-Metrics-Golden | src/lib/reports/sqp.ts |
| Verlorene Käufe | max(0, Markt-CVR × eure Klicks − eure Käufe) | reporting-main-Golden (lostPurchases = 3 bei 25 %×20−2) | src/lib/reports/sqp.ts |
| Umsatzpotenzial | verlorene Käufe × Median-Kaufpreis (Marke, Fallback Markt) | reporting-main-Golden (3×30 € = 90 €) | src/lib/reports/sqp.ts |
SOV-Audit (Cerebro) · 6 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Rank-Gewicht vw(rank) | 1: 1,0 · 2: 0,65 · 3: 0,45 · 4–5: 0,3 · 6–10: 0,15 · 11–20: 0,06 · 21–50: 0,015 · 51–100: 0,005 · >100: 0,001 | temoa-tools-beta script.js:1424 | src/lib/sov/audit.ts |
| Keyword-Sales → monatlich | Cerebro-KS (wöchentlich) × 4,36 | temoa-tools-beta WEEKLY_TO_MONTHLY | src/lib/sov/audit.ts |
| Opportunity-Score | Gap×0,45 + KS×0,25 + SV×0,15 + CPR-Leichtigkeit×0,15; Priorität ≥0,6 High / ≥0,35 Medium | temoa-tools-beta | src/lib/sov/audit.ts |
| Umsatz-Korridor | Lücken-Potenzial × 20 % (low) / 60 % (base) / 95 % (high) — Korridor, keine Garantie | temoa-tools-beta | src/lib/sov/audit.ts |
| Vergleichs-ASINs aus dem Keyword-Export | Wettbewerber = die Rang-Spalten der Cerebro-CSV (Kopfzeile, Muster B+9 Zeichen), ohne die eigene ASIN. Bedingung: mindestens EIN echter Rang > 0 — eine Spalte voller „-“ war nur formal dabei und würde Scrape-Budget für ein Produkt verbrennen, mit dem gar nicht verglichen wurde. Sortiert nach Anzahl gerankter Keywords (breitester Wettbewerber zuerst), bei Gleichstand alphabetisch für stabile Reihenfolge. Der Review-Scrape ergänzt sie automatisch; ausdrücklich eingetragene ASINs gewinnen und werden ergänzt, nicht ersetzt | Nutzer-Vorgabe 31.07. (kein manueller Zwischenschritt), D268 | src/lib/sov/audit.ts (wettbewerberAsinsAusRows) |
| Keyword-Tiering | Rang = Suchvolumen × Cluster-Relevanzgewicht (Tiebreak Opportunity-Score) — BERECHNET, unabhängig von der CSV-Zeilenfolge (Cerebro sortiert nach Competitor Performance Score); Schnitte: 1–3 primary → Titel, 4–13 secondary → Bullets, 14–18 tertiary → Beschreibung, Rest Backend; Brand-Alternatives ausgeschlossen (Fremdmarken-Verbot); Keywords ohne Suchvolumen (SV 0/‚-') bleiben erhalten und sortieren mit Score 0 ans Ende (Backend) | D51/D92 + Backend-Spec (Amazon-Policy) | src/lib/sov/tiering.ts |
Content-Regeln (Validation-Gate) · 11 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Byte-Zählung | TextEncoder (UTF-8): Umlaute = 2 Bytes — zählt wie Amazon | seo-os-Regression | src/lib/text/bytes.ts |
| Ausschöpfungs-Prinzip | Unterausnutzung der Limits = WARNUNG (blockiert nicht), harte Verstöße = FEHLER (blockieren Freigabe) | Nutzer-Vorgabe D41 | src/lib/validation/gate.ts |
| Begründungs-Pflicht | jeder Textbestandteil trägt Herleitung (Teil ← Quelle); Behauptungen werden deterministisch gegen den Text verifiziert (≥50 % Wort-Überlappung = belegt) | D40/D41 | src/lib/recipes/listing.ts |
| USP-Einmal-Verwendung | jede USP genau 1× über alle Bullets (Wortstamm-Dedup, Bindestrich-Komposita gesplittet) | Nutzer-Feedback (Briefing-Wiederholungen) | src/lib/validation/gate.ts |
| Zahlen-Herkunfts-Check | Jede Zahl im generierten Text (inkl. Zahlwörter ‚drei', ‚einem Meter') braucht eine Quelle in Produkt-Wahrheit/Listing-IST/Zusatz-Infos/Keywords; Kontextwort bei ANDERER Zahl in der Quelle = Widerspruchs-FEHLER (3 vs. 4 AA-Batterien), unbelegte Zahl = FEHLER (6500 K); Reviews sind NIE Spec-Quelle; ohne Quellen ehrlich passiv | Nutzer-Befund Northpoint D114 | src/lib/validation/gate.ts (pruefeZahlenTreue) |
| Claim-Stärke gegen Messwert | Intensitäts-Wort darf den belegten Messwert nicht überbieten. dB-Bänder: ‚flüsterleise/lautlos/unhörbar' ≤ 30 · ‚sehr leise' ≤ 40 · ‚leise' ≤ 50 · ‚angenehm leise/geräuscharm' ≤ 55. Verglichen wird mit dem HÖCHSTEN dB-Wert der Quellen (der Claim muss auch laut gelten); ohne Messwert ehrlich passiv. Die spezifischere Stufe gewinnt, damit ‚angenehm leise' nicht in die ‚leise'-Regel fällt | Nutzer-Befund 30.07. (‚flüsterleiser Motor' bei ≤ 55 dB), D265 | src/lib/validation/gate.ts (pruefeClaimStaerke) |
| Sprach-Gates (Lokalisierung) | Content-Sprache je Produkt (unabhängig vom Marktplatz). Gate 1: Sprach-Heuristik über die GESAMTE Keyword-Basis (Signal-Wörter ×2 + Zeichen + Endungen ×0,5 je Sprache; Urteil nur bei Top-Score ≥ 3 UND ≥ 1,5× Zweitplatzierter — sonst ehrlich passiv) — sicherer Widerspruch zur Content-Sprache blockt die Generierung (GEN-04). Gate 2: Review-Scrapes laufen gegen den Marktplatz der Content-Sprache (de→de, en→co.uk, fr→fr, it→it, es→es); ASIN verrät ihren Marktplatz nicht — nicht existente ASINs liefern ehrlich 0; Sprach-Heuristik über gescrapte Texte als zweite Sicherung (Hinweis, kein Block) | Nutzer-Vorgabe 21.07. (lokalisieren statt übersetzen), D128 | src/lib/text/sprache.ts + src/app/actions.ts |
| Fremdmarken-Blacklist | vom Keyword-Relevanz-Filter erkannte Fremdmarken (Grund ‚Marke: XY') fließen als Verbotsliste in Prompt UND Gate — jedes Vorkommen in Titel/Bullets/Backend/Beschreibung = FEHLER (auch bei Handarbeit) | Amazon-Policy (backend-keywords.md) + D87-Erkennung, verdrahtet D97 | src/lib/recipes/listing.ts + src/lib/validation/gate.ts |
| Keyword-Reihenfolge im Prompt | Keywords erreichen die Text-Generierung in Tiering-Reihenfolge (SV × Cluster-Relevanzgewicht) — primary[0] ist damit wirklich das Hauptkeyword, nicht zufällige DB-Reihenfolge | Tiering-Formel D51/D92, verdrahtet D97 | src/app/actions.ts (nachTieringScore) |
| Bullet-Aufbau (Drei-Positionen-Anatomie) | Position 1: Benefit zuerst (Headline + erste 5–8 Wörter, nie Feature-Name) · Position 2: Feature als Beleg + Secondary Keyword natürlich integriert · Position 3: Use Case + konkrete Details (für wen/wann + Material/Maß/Prüfnorm/Garantie); drei Jobs je Bullet: Einwand entkräften + Use Case bestätigen + Keyword unterbringen | Blog/Schaubild 07/2026 (knowledge/sources/blog-bullets-backend-2026-07.md), D98 + Nutzer-Feedback 21.07. | src/lib/recipes/listing.ts (Prompt — semantisch, kein Gate-Check) |
| Backend ohne Satzzeichen | Amazon ignoriert Satzzeichen — jedes ist ein verschwendetes Byte; LLM-Pfad entfernt sie deterministisch, Handarbeit bekommt eine Warnung. Bei >249 Bytes ignoriert Amazon das GESAMTE Feld (nicht abgeschnitten) — deshalb harte wortweise Kappung vor dem Speichern; Priorität: Invisible → Rest-Long-Tails → Synonyme/Abkürzungen → englische Begriffe (mixing bowl) → Kundensprache; KEINE Tippfehler (Amazon-Hilfe: unnötig) | Blog 07/2026 + Amazon-Hilfe, D99 | src/lib/recipes/listing.ts + src/lib/validation/gate.ts |
Marge & Break-even (Workbook-Port) · 7 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Warenbestellung/Stück | Einkauf + Verpackung + Logistik + Zoll + QC; Zoll = (Einkauf+Verpackung+Logistik) × Zollsatz — QC ist NICHT zollpflichtig | Workbook Zelle D22 (via reporting-main) | src/lib/margin/calc.ts |
| Retourenkosten | mit q = Retourenquote × (1 − Entsorgungsanteil): FBA-Versand×q + Verkaufsgebühr×0,2×q + Kostenbasis×0,05×q; Bekleidung zahlt den Rückversand doppelt | Workbook Zelle D29 | src/lib/margin/calc.ts |
| Entsorgungskosten | mit p = Retourenquote × Entsorgungsanteil: Entsorgungsgebühr×p + (Ware+Inbound+Variabel)×p + Umsatz×p − Verkaufsgebühr×0,8×p | Workbook Zelle D30 (80 % Gebühren-Erstattung) | src/lib/margin/calc.ts |
| Marge / Netto | Netto = Brutto ÷ (1+MwSt); Marge = Netto − Ware − Amazon-Gebühren − Variabel − Inbound; Marge% = Marge ÷ Netto | Workbook (1L-Fixture: 18,31906 %) | src/lib/margin/calc.ts |
| ROI | Marge ÷ (Ware + Variabel + Inbound) × 100 | Workbook (1L: 81,065 %) | src/lib/margin/calc.ts |
| Break-even-ACoS | Marge ÷ BRUTTO-VK × 100 — max. Werbekostenanteil am Bruttoumsatz bis ±0 | Workbook (1L: 15,394 %) | src/lib/margin/calc.ts |
| Regressionsanker | 1L-Fixture (Menge 100, 9,90 € VK, 9×9×27 cm, 900 g, 10 % Retouren, 25 % Entsorgung) → Marge 1,524022836 € — jeder Umbau muss diesen Wert reproduzieren | reporting-main calc.test.ts | src/lib/margin/calc.test.ts |
Perioden-Diagnose (Cockpit) · 2 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Umsatz-Zerlegung | Umsatz = Sitzungen × CVR × AOV; das Perioden-Delta wird über ln-Anteile exakt auf die drei Faktoren verteilt (Σ Faktor-Beiträge = Gesamt-Delta, kein Rest); bei Null-Werten keine Zerlegung statt erfundener Zahlen | Eigenentwicklung (D64) — Antwort auf die fehlende Holistik der Bestands-Tools | src/lib/reports/diagnose.ts |
| Ursachen-Abgleich | dominanter Faktor + Quer-Signale: Traffic-Rückgang × offene SOV-Lücken → Sichtbarkeit; CVR-Rückgang × Buybox −2 pp → Buybox vor Listing; CVR-Rückgang × Buybox stabil → Listing/Preis (SQP/Reviews); AOV → Preis/Mix; TACoS ≥ Break-even → unprofitabel erkauft; fehlende Signale werden benannt statt still gelückt | Eigenentwicklung (D64), konservative Regeln — nur belegbare Aussagen | src/lib/reports/diagnose.ts |
Keyword-Relevanz (Cerebro-Import & Hand-Eingabe) · 7 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Marken-Keywords | Keywords mit Marken-/Herstellernamen (fremde UND eigene Marke) werden aussortiert — Kunden suchen dort gezielt eine Marke, keine Kategorie; Erkennung per KI-Klassifikation, der Code übernimmt nur Keywords, die wirklich in der Liste stehen; ohne API-Key bleibt die Regel passiv (nie raten bei Ausschlüssen) | Nutzer-Regel D87 | src/lib/keywords/relevanz.ts (erkenneMarkenKeywords) |
| Abweichende Maße | Keyword-Maße (200x150, 750 ml, 1 l, 80 cm — Paare reihenfolge-unabhängig, Einheiten normiert, 5 % Toleranz) gegen die bekannten Produkt-Maße (Fakten-Feld ‚Maße/Menge' + Titel); Abweichung → aussortiert. Kennt das Tool KEINE Produkt-Maße, filtert die Regel nicht | Nutzer-Regel D87 (Krabbeldecken-Beispiel: 200×150 behält, 140×80 fliegt) | src/lib/keywords/relevanz.ts (pruefeMasseUndAnzahl) |
| Abweichende Anzahl | Stückzahlen im Keyword (10 stück, 20er pack, 3er set) gegen die Produkt-Anzahl; Abweichung → aussortiert (Kabelbinder-Beispiel: 20er behält, ‚10 stück' fliegt) | Nutzer-Regel D87 | src/lib/keywords/relevanz.ts |
| Abweichende Farbe | Farbwörter im Keyword gegen die bekannte Produkt-Farbe — als Farbfamilien (hellgrau/dunkelgrau/anthrazit = grau), nur ganze Wörter; ‚bunt' lässt alles durch; ohne bekannte Produkt-Farbe filtert die Regel nichtAchtung bei Varianten-Familien: die Regel prüft gegen die GESCANNTE ASIN — Farb-Ausschlüsse dort einmal gegenlesen. | Nutzer-Regel D91 | src/lib/keywords/relevanz.ts (extractFarben) |
| Abweichende Form | Formwörter als Gruppen (eckig/rechteckig/quadratisch = eine Gruppe; rund/kreisrund; oval; sechseckig …) gegen die bekannte Produkt-Form — eckige Krabbelmatte behält ‚rechteckig', ‚rund' fliegt; ohne bekannte Form passiv | Nutzer-Regel D91 | src/lib/keywords/relevanz.ts (extractFormen) |
| Tier-Vergabe (primary/secondary/tertiary/backend) | Rangfolge = Suchvolumen × Cluster-Relevanzgewicht (Kern-Kategorie 1,0 · deutsche Kategorie 0,8 · Problem/Anwendung/Longtail 0,6 · Discovery 0,4), Gleichstand entscheidet der Opportunity-Score; Schnitte: Platz 1–3 primary → Titel, 4–13 secondary → Bullets, 14–18 tertiary → Beschreibung, Rest backend. Tiers werden NACH dem Relevanz-Filter vergeben (Aussortierte verbrauchen keine Plätze) und unrankende Keywords sortieren per Score mit ein | temoa-tools-beta-Formelwerk + D91 | src/lib/sov/tiering.ts |
| Kennzeichnen statt löschen | Aussortierte Keywords bleiben gespeichert (mit Grund) und sind in der Werkbank prüfbar/wieder aufnehmbar; manuelle Entscheidungen (Präfix ‚manuell') überschreibt kein Auto-Lauf; ausgeschlossene Keywords fließen NICHT in Tiering, Texte, Backend, Audit oder Briefs | Nutzer-Vorgabe D87 (Transparenz) | src/app/actions.ts (deriveKeywordsFromSov, toggleKeywordRelevanz) |
Bewertungs-Analyse & Tiefen-Audit · 18 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| Review-Scrape je Sterne-Klasse | je ASIN UND je Sterne-Klasse (filterByStar 1★–5★) genau EINE parallele Anfrage — 2 ASINs = 10 Läufe —, je bis zu 100 der AKTUELLSTEN geschriebenen Rezensionen (sortBy recent; Amazons Gesamtzahl zählt auch Bewertungen ohne Text — Stichprobe < Gesamtzahl ist normal); Zeitbudget 40 s je Lauf, damit immer eine Rückmeldung kommt; Teilausfälle und Ausbeute als Notiz je ASIN+Klasse, nie stiller Abbruch | Nutzer-Vorgabe D72/D96 (Actor-JSON) | src/lib/reviews/apify.ts |
| Datenbasis-Anzeige | echte Amazon-Zahlen (Gesamt-Bewertungen, Ø, Verteilung %) NEBEN der Stichprobe; Verhältnis-Balken nur aus der echten Verteilung — die Stichprobe ist je Klasse gedeckelt und bildet kein Verhältnis ab | Ehrlichkeits-Prinzip D74 | src/app/actions.ts (scrapeReviewsAction) |
| Pain Points / Kaufauslöser | aus ALLEN Sterne-Klassen (Sterne-Zahl = Kontext, kein Filter); Häufigkeit + verbatim-Zitate; Konfidenz: ≥60 Reviews high, ≥20 medium, sonst low | temoa-audit review-insights-Schema (SALVAGE §7) + D75 | src/lib/reviews/apify.ts (extractInsights) |
| Insight-Verdichtung (Karten) | Roh-Themen → 4–8 benannte Erkenntnisse (Titel · Beschreibung · Relevanz 1–5 · Quellen · Bild-Ideen · Beleg-Aspekte); Code erzwingt: Beleg-Referenzen nur gegen echte Roh-Themen (Zählwerte aus der Analyse, nie vom LLM), Karte ohne Beleg fliegt GEZÄHLT raus, Dedup über Titel/Beleg-Menge, Quellen-Tags stempelt die Pipeline; Bild-Ideen laufen durch den Wahrheits-Filter (erfundene Experten-Zitate/Siegel ohne Beleg in der Produkt-Wahrheit werden entfernt und ausgewiesen) | Referenz-Tool-Sichtung II, D131–D134/D137/D140 | src/lib/reviews/verdichtung.ts + src/lib/analysis/bildideen.ts |
| Analyse-Konfidenz (Worte statt Prozente) | Stichprobe gescrapt / Amazon-Gesamtzahl: <20 nicht belastbar · 20–59 dünn · ≥60 richtungsweisend · ≥150 UND ≥30 % belastbar; Amazons Gesamtzahl zählt Bewertungen ohne Text mit (~500/ASIN-Deckel, D130) — deshalb Worte mit Herleitung statt eines Fassaden-Prozents je Erkenntnis | D138 (Referenz zeigt ‚Data Reliability 98 %' ohne Formel — bewusst NICHT übernommen) | src/lib/reviews/konfidenz.ts (beurteileAnalyseBasis) |
| Beleg-Angabe je Erkenntnis | Anzahl der verknuepften, verbatim-geprueften Beleg-Aspekte — LLM-geschaetzte Erwaehnungs-/Prozentwerte sind verbannt (D154); Relevanz — seit D266 EINE Formel für Verdichtung, Feature-Ranking UND Conversion-Blocker: 0 Beleg-Aspekte → 1 · 1 → 3 · 2 → 4 · ≥3 → 5. Die Verdichtung übernahm sie vorher aus der LLM-Antwort (nur geklemmt) — zwei Listen, zwei Maßstäbe, nicht vergleichbar. WELCHE Aspekte gezaehlt werden, haengt seit D284 von der Liste ab: Verdichtung und Blocker zaehlen ALLE Beleg-Aspekte, das Feature-Ranking nur die KAUFAUSLOESER — ein Merkmal, das Kunden nur kritisieren, ist kein starkes Kaufargument (vorher machte genau diese Kritik ‚Anschluss Ø 38 mm' zum Merkmal Nr. 1) | D138/D154/D167/D266/D284 | src/lib/analysis/relevanz.ts (belegRelevanz) |
| Zaehlwert je Aspekt (N×) | Anzahl VERSCHIEDENER Reviews mit verbatim-verifizierter Fundstelle — vom Code gezaehlt, nie vom LLM geschaetzt; ein ehrlicher Mindestwert (das LLM liefert bis zu 15 Fundstellen je Aspekt, jede wird gegen die Review-Texte geprueft) | D170 | src/lib/reviews/belegPruefung.ts |
| Signifikanz-Gate | Unter 100 analysierten Reviews kein Gate; ab 100 braucht ein Aspekt ≥2, ab 500 ≥3 verifizierte Fundstellen, um Erkenntnis/Finding zu werden — Uebergangenes wird benannt ausgewiesen und bleibt in der Roh-Liste sichtbar | D170 | src/lib/reviews/verdichtung.ts (filtereEinzelnennungen) |
| Tendenz einer Erkenntnis | Summe der verifizierten Fundstellen je Seite (Kaufausloeser vs. Pain Points) einer Karte — mehr positiv → ueberwiegend positiv, mehr negativ → ueberwiegend negativ, gleich → ausgeglichen; nie von der KI behauptet. Seit D284 traegt JEDE Karte mit Beleg-Aspekten eine Richtung: eine einseitig belegte Karte IST positiv bzw. negativ (vorher blieb sie ohne Vorzeichen — gerade die eindeutigen Faelle standen ohne Urteil neben den uneindeutigen). Fehlt einer vertretenen Seite jeder Zaehlwert, wird KEINE Zahl gezeigt statt ‚0+ / 0−' | D171/D284 | src/lib/reviews/verdichtung.ts (kartenTendenz) |
| Merkmals-Ordnung (Product Features) | Anzeige-Reihenfolge deterministisch aus der Merkmal-Einordnung (D282) des Driver-Laufs: stuetzt Kaufgrund → ohne Einordnung → notwendige Angabe → ohne erkennbaren Zweck; innerhalb der Klasse nach Relevanz, dann nach Kaufausloeser-Fundstellen. Als ‚ergebnis' eingeordnete Eintraege (Zustand beim Kunden, z. B. ‚Spuerbar waermeres Poolwasser') sind KEINE Merkmale — sie werden aus der Liste genommen und gezaehlt ausgewiesen, statt einen Kaufgrund als Merkmal zu doppeln. Ohne Einordnung bleibt die Ranking-Reihenfolge und es wird nichts behauptet (D145) | D284 (Nutzer-Befund 04.08.2026) | src/lib/analysis/featureAnzeige.ts (ordneFeatures) |
| Zuständigkeits-Gate (Seller vs. Amazon) | Vor JEDER Zählung: Versand-/Zustell-/Paketdienst-Themen fallen raus (dafür ist Amazon zuständig, der Seller kann es nicht ändern und muss es im Listing nicht adressieren) · Verpackung/Transportschaden wird Produkt-Feedback (Sache des Sellers, aber nicht über Listing-Text lösbar) · alles andere bleibt Rohstoff. Seller-Vorrang schlägt die Amazon-Stämme, damit ‚Lieferumfang'/‚Aufbauanleitung' nicht am Stamm ‚liefer' mit wegfliegen; Filter bewusst ENG (‚Kundenservice', ‚auf Amazon' bleiben drin — zu breit löscht seller-relevante Themen unbemerkt). Ausgeschlossenes wird gezählt und benannt, nie still. Läuft seit D266 EINMAL beim Speichern der Roh-Analyse statt in jedem Konsumenten — damit arbeiten Verdichtung, Feature-Ranking, Blocker, Driver UND die Listing-Kontrolle automatisch auf bereinigten Aspekten; vorher erzeugte ein Versand-Pain-Point eine Maßnahme, die kein Text lösen kann | Nutzer-Vorgabe 30.07., D265/D266 | src/lib/analysis/zustaendigkeit.ts + src/app/actions.ts (auswertungKern) |
| Conversion-Driver-Score (0–100) | Motiv-Klasse (Kern 40 · Entscheidung 25 · Absicherung 15 · Hygiene 0) + Suchnachfrage (Anteil am relevanten Suchvolumen ×40, max 20 — der einzige GEMESSENE Vorkauf-Datenpunkt) + Wettbewerber-Konsens (n/m der Wettbewerber-Listings ×15) + eigene Bewertungen (Nennungen/Stichprobe ×150, max 15) + übertragbare Wettbewerbs-Bewertungen (×100, max 10) + Erwartungsbrüche (je 5, max 10) + harter Beleg (5). Relevanz 1–5 aus dem Score (≥80/65/50/45). Dieselbe Formel für jedes Produkt — das ist die Bedingung für konstante Qualität; Nennungshäufigkeit allein reicht NICHT, weil Bewertungen post-purchase entstehen und Erlebnis-Auffälligkeit messen, nicht Kaufrelevanz | Nutzer-Vorgabe 30.07. (Driver = Resultat, nicht Feature/USP), D265 | src/lib/analysis/motive.ts (driverScore) |
| Driver-Auswahl (Schwelle statt Quote) | Schwelle 45 Punkte: ein Kernmotiv allein (40) reicht NICHT, es braucht bestätigende Evidenz. Keine Untergrenze im Prompt mehr (eine Quote ist eine Aufforderung zum Auffüllen — aufgefüllt wird mit Features). Mindestens EIN Driver ist Pflicht (gäbe es keinen Kaufgrund, bräuchte es das Produkt nicht) — gilt NUR für den ersten, wird als Pflicht-Driver markiert und trägt seine dünne Evidenz sichtbar. Notbremse bei 8: greift sie, ist die Schwelle zu weich (Bau-Auftrag) | Nutzer-Vorgabe 30.07., D265 | src/lib/analysis/motive.ts (waehleDriver) |
| Abdeckung je Kanal (3 Stufen) | prominent (Titel · Bullet 1 · erste 80 Zeichen eines Bullets) · erwähnt (Bullet-Mitte, Beschreibung, Attribute, Wichtige Informationen, A+) · fehlt · nicht_erfasst. Vorhanden und praktisch unsichtbar ist nicht dasselbe wie prominent; ‚nicht erfasst' erzeugt NIE eine Lücke (wo nicht hingesehen wurde, wird keine behauptet). Gleicher Wort-Abgleich wie die Listing-Kontrolle — kein zweiter Matcher, keine zweite Wahrheit | Nutzer-Befund 30.07. (‚entspannter Beinfreiheit' als Nebensatz), D265 | src/lib/analysis/abdeckung.ts |
| Conversion-Blocker (Fall + Score) | Blocker = Driver-Baustein ohne (ausreichenden) Beweis; Fall aus Text- × Bildstufe: fehlt komplett (1,0) · Nutzen nicht benannt, nur Merkmal (0,9) · nur im Kleingedruckten (0,7) · kein Bildbeweis (0,6) · unzureichender Bildbeweis, Botschafts-Note < 3 (0,4). Titel schreibt der CODE aus dem Template und benennt die fehlende BEWEISART; Blocker-Score = Driver-Score × Fall-Gewicht. Kein Blocker ohne Driver — damit ist Doppelung zwischen den zwei Listen maschinell unmöglich | Nutzer-Vorgabe 30.07. (Blocker ergibt sich aus dem Driver), D265 | src/lib/analysis/blockerFall.ts |
| Insights-Dokument (Kunden-Report) | Reine Projektion, kein LLM: Ampel je Kaufgrund = SCHLECHTESTE Stufe seiner Nutzen-Bausteine (die Ampel darf nie schöner sein als der schwächste Beweis) · Handlungsplan = die Blocker selbst, getrennt in Text- und Bild-Fälle, Bild-Maßnahmen angereichert mit „wie besser“ des betroffenen Slots aus dem Bild-Audit · nicht messbare Dimensionen tragen score null, nie 0 (D70) · harte Obergrenzen 10 Matrix-Zeilen / 6 Text- / 5 Bild-Maßnahmen / 4 Risiken / 8 Grenz-Zeilen, ein Zitat je Zeile. Gate: kein Dokument ohne Datenbasis, ohne Kaufgrund, ohne Beleg-Quelle je Zeile oder mit Maßnahme ohne Kaufgrund-Referenz — bei Verstoß wird NICHTS gespeichert | Nutzer-Vorgabe 30.07. (minimalistisch, keine Redundanz, SOV-Zahlen raus), D267 | src/lib/reports/insightsDokument.ts |
| Bilder-Briefing (Designer) | Ein Konzept je Kaufgrund, der im Bildset nicht bewiesen ist — kein fester Slot-Plan (D209: keine Mindestmengen). Status aus dem Blocker-Fall: „unzureichender Bildbeweis“ → nachschärfen, sonst neu bzw. ersetzen. Findings = Befund + Evidenz-Anteile (Bewertungen, Suchnachfrage), NIE die Motiv-Klasse. Deterministisch erzwungen: keine vorgeschriebenen Bildtexte und keine Szenen-Regie (Licht, Perspektive, Brennweite) — Gate pruefeKonzeptFreiheit, gilt auch für die englische Fassung. Sprachgebunden und deshalb nie übersetzt: Produkt-Wahrheit, Kundenstimmen, ausgelesener Bildinhalt — ein englischer Designer gestaltet ein deutsches Listing | Nutzer-Vorgabe 31.07. (Konzept-Idee + Findings, keine konkreten Bildtexte, keine Szenen), D269 | src/lib/analysis/bildBriefing.ts |
| Tiefen-Audit (8 Dimensionen) | Titel · Bullets · Beschreibung · Backend · Bilder · A+ · Bewertungs-Sockel · Preis, je ‚Aktuell / Probleme / Empfehlung' + Score 0–10; bewertbar ist NUR, wofür Daten vorliegen (erzwingt der Code, nie das LLM); USPs/Zielgruppe/Positionierung werden aus Listing + Kundenstimmen HERGELEITETPflicht-Datenbasis: Listing-Inhalt + Bewertungs-Analyse (optional Wettbewerber). | temoa-audit 8-Dim-Spec (SALVAGE §7) — Struktur portiert, Umsetzung neu (‚LLM generiert, Code erzwingt') | src/lib/analysis/deepAudit.ts |
Handlungen (€-Hebel) · 5 Größen
| Größe | Formel / Regel | Quelle | Rechnet in |
|---|---|---|---|
| SOV-Umsatzlücken | Hebel = Korridor-Obergrenze der Top-Lücken | D45/temoa-tools-beta | src/app/actions.ts (syncBrandActions) |
| Kampagnen ohne Verkäufe | Hebel = voller Spend der No-Sale-Kampagnen | reporting-main ads-no-sale | src/app/actions.ts |
| Über Ziel-ACoS | Hebel = Σ (Spend − PPC-Umsatz × Ziel-ACoS) der Kampagnen über Ziel | reporting-main ads-over-target (40−100×0,2 = 20 €) | src/app/actions.ts |
| Negativ-Keywords | Hebel = Wasted Spend − ASIN-Anteil; ASIN-Ziele als eigene Handlung | reporting-main st-negatives/st-asin-negatives | src/app/actions.ts |
| SQP-Priorität | Hebel = Gesamt-Umsatzpotenzial; größte Einzel-Lücke wird benannt | reporting-main sqp-top-priority | src/app/actions.ts |
Content-Limits (live aus dem Validation-Gate)
Quelle: knowledge/content-Specs → src/lib/validation/rules.ts — dieselben Werte, gegen die das Gate prüft.
| Sektion | Maximum | Ausschöpfungs-Ziel |
|---|---|---|
| Titel | 75 Zeichen | ab 60 |
| Bullets (5 Stück) | 255 Zeichen inkl. Leerzeichen | ab 230 Zeichen |
| Item Highlights | 125 Zeichen | ab 115 |
| Backend-Keywords | 249 Bytes | ab 220 |
| Beschreibung | 1999 Bytes | ab 1700 |
| Q&A (5 Paare) | Frage 110 · Antwort 230 Zeichen | Antwort ab 180 |
Amazon-Gebühren-Tabellen (Margen-Rechner)
Diese Werte rechnen LIVE in jeder Margen-Kalkulation. Aktualisierung: Amazon-Gebühren-PDF hochladen — das Tool extrahiert die Tabellen, prüft sie deterministisch und zeigt die Abweichungen zur Bestätigung. Amazon bietet keine öffentliche Tabellen-API; mit der SP-API-Anbindung (geplant) kommt die Gebühren-Vorschau je ASIN als automatische Gegenprobe.
Verkaufsgebühr je Kategorie (% vom Brutto-VK)
Alles andere8 %
Bekleidung & Schuhe15 %
Elektronik-Zubehör15 %
Computer-Zubehör15 %
Schmuck20 %
Baumarkt13 %