# Plan: Umsetzung des "B2B Marketing Assistant" Backends

Dieses Dokument beschreibt den Plan zur Umsetzung der Backend-Logik für die React-Anwendung unter `/b2b-marketing-assistant` als robusten, faktenbasierten Python-Service. Das primäre Ziel ist es, die Konsistenz und Zuverlässigkeit der Analyseergebnisse durch "Grounding" (Verankerung in realen Daten) signifikant zu erhöhen.

## 1. Zielsetzung & Architektur

-   **Ziel:** Transformation der reinen Frontend-Anwendung in einen Service mit einem Python-Backend, das vor jeder KI-Analyse eine solide Faktenbasis durch Web-Scraping schafft. Dadurch werden die Ergebnisse reproduzierbar und basieren auf den tatsächlichen Inhalten der Unternehmens-Website.
-   **Architektur:** Wir replizieren den bewährten Aufbau des "Market Intelligence" Tools:
    1.  **React-Frontend:** Die Benutzeroberfläche in `/b2b-marketing-assistant` bleibt bestehen, wird aber von direkten KI-Aufrufen befreit.
    2.  **Node.js API-Brücke (`server.cjs`):** Ein minimaler Express.js-Server, der Anfragen vom Frontend annimmt und an das Python-Backend weiterleitet.
    3.  **Python-Orchestrator (`b2b_marketing_orchestrator.py`):** Das neue Herzstück, das die gesamte Logik kapselt.

## 2. Kernprozess mit "Grounding"

Der 6-stufige Prozess der App wird im Backend abgebildet, wobei die ersten Schritte fundamental geändert werden:

1.  **Schritt 1 (Angebot) & 2 (Zielgruppen):**
    *   **Intelligentes Scraping:** Das Python-Skript crawlt die gegebene URL und sucht aktiv nach Unterseiten wie "Produkte", "Lösungen", "Branchen" etc.
    *   **Text-Extraktion:** Der relevante Inhalt dieser Seiten wird extrahiert und zu einem "Grounding-Dokument" zusammengefasst.
    *   **KI als Extraktions-Engine:** Die KI wird angewiesen, **ausschließlich auf Basis dieses extrahierten Textes** das Angebot und die Zielgruppen zu identifizieren und zu strukturieren. Halluzinationen werden so unterbunden.

2.  **Schritt 3-6 (Personas, Pains, Gains, Messages):**
    *   Diese Schritte bauen auf den validierten, faktenbasierten Ergebnissen aus Schritt 1 & 2 auf. Die gesamte Logikkette wird dadurch stabiler und konsistenter.

3.  **Schritt 7 (Customer Journey & Buying Center):**
    *   **NEU:** Als finaler Schritt wird die hypothetische Kaufentscheidung simuliert.
    *   **Fokus:** Analyse der "Journey" vom ersten Touchpoint bis zum Vertragsabschluss.
    *   **Kernfragen:**
        *   Wie sieht der Entscheidungsprozess aus? (Spontan vs. Gremium)
        *   Welche Stationen durchläuft der Käufer?
        *   Wie sehen typische Verträge aus (Laufzeit, Lock-in)?
        *   Welche spezifischen Fragen stellen sich die unterschiedlichen Entscheider (Buying Center) in den verschiedenen Phasen?
    *   **Ziel:** Tiefe Einblicke in das Käuferverhalten, spezifisch getrimmt auf das ermittelte Produkt (SaaS vs. Hardware), unter Einbeziehung der Pains & Gains.

## 3. Strategische Vision: Integration der Tools

Dieses Projekt ist der erste Schritt zur Schaffung eines einheitlichen "Strategy & Audit"-Workflows.

-   **Phase 1 (Aktuelles Projekt):** Wir bauen den "B2B Marketing Assistant" als eigenständigen Service mit einem modularen Python-Backend.
-   **Phase 2 (Zukünftig):** Die wiederverwendbaren Python-Module (Scraping, API-Handler etc.) werden mit dem `market_intel_orchestrator.py` zu einem einzigen, leistungsfähigen Backend verschmolzen. Der Workflow wäre dann nahtlos:
    1.  **Strategie definieren:** Mit dem B2B Marketing Assistant eine Tiefenanalyse eines Referenzkunden durchführen.
    2.  **Markt auditieren:** Die erstellte Strategie direkt nutzen, um Lookalikes zu finden und zu bewerten.

## 4. Fortschritts-Log

### Phase 1: Initialisierung & Planung

- [x] Anforderungsanalyse und Zieldefinition (Grounding, Konsistenz).

- [x] Architektur nach Vorbild `market-intel-backend` festgelegt.

- [x] Diesen Schlachtplan in `b2b_marketing_assistant_plan.md` erstellt.

- [x] Aufbau der Grundstruktur: Erstellen der `b2b_marketing_orchestrator.py`, der `server.cjs` in `/b2b-marketing-assistant` und des `Dockerfile`.

- [x] Erstellung von `package.json` und `requirements.txt`.

- [x] Anpassung des Frontends (`App.tsx`) für die Kommunikation mit dem neuen Backend.

- [x] Entfernen von Frontend-Dateien und -Inhalten, die nicht mehr benötigt werden (`parser.ts`, Prompts aus `constants.ts`).

- [x] Implementierung der `start_generation`-Logik im Python-Backend (Scraping, Grounding, initialer Gemini-Aufruf für Schritt 1).

- [x] Implementierung der `next_step`-Logik im Python-Backend (mehrstufige Gemini-Aufrufe für Schritte 2-6, Kontext-Management).

- [x] Fehlerbehebung: Alle Python-Syntaxfehler (Encoding, Strings) behoben.

- [x] Validierung: Das Tool lädt das Frontend und führt das Web-Scraping erfolgreich durch.

- [x] **API-Fix:** Umstellung auf Gemini v1 API und Modell `gemini-2.5-flash` (1M Token Context).



### Phase 2: Validierung & Optimierung (Abgeschlossen)

- [x] Docker-Container gebaut und gestartet.

- [x] Zugriff auf die UI über Port 3004 erfolgreich.

- [x] **Grounding Upgrade:** Umstellung von Plain-Text auf "Sanitized HTML" (H1-H6, Links erhalten) für präzise Produkterkennung.

- [x] **Kontext-Erweiterung:** Entfernung des 30.000 Zeichen Limits für vollständige Website-Analyse.

- [x] **Robustheit:** Implementierung von Retry-Logik (Exponential Backoff) und Timeout-Erhöhung (600s) für komplexe Analysen.

- [x] **Frontend Fixes:**

    - [x] Robuster "Copy Table" Button (Fallback für Non-HTTPS).

    - [x] PDF-Export optimiert (Landscape, keine Scrollbalken).

    - [x] "Schritt 6 Wiederholen"-Funktion eingebaut.

- [x] **Prozess-Optimierung:** Schritt 6 fokussiert nun automatisch auf die Top-Branche, um Token-Limits und Lesezeit zu optimieren.

- [x] **Logging:** Detailliertes File-Logging (`Log_from_docker`) für Prompts und Antworten implementiert.



## 5. Deployment & Betrieb (Konsolidierte Architektur)

Die Anwendung ist nun vollständig in die zentrale Docker-Compose-Architektur des Projekts integriert. Das separate Bauen und Starten einzelner Container ist nicht mehr notwendig.

### Zentraler Start via Docker Compose

Der gesamte Anwendungs-Stack (Proxy, Dashboard, B2B Assistant, Market Intelligence) wird über die `docker-compose.yml`-Datei im Hauptverzeichnis des Projekts verwaltet und gestartet.

1.  **Navigieren Sie in das Projekt-Hauptverzeichnis.**
2.  **Starten Sie alle Dienste:**
    ```bash
    docker-compose up -d --build
    ```
    Der `--build`-Parameter sorgt dafür, dass alle Docker-Images neu erstellt werden. Dies ist bei Änderungen am Frontend (`App.tsx`), an den `Dockerfile`n oder den `requirements.txt`/`package.json` notwendig.

### Zugriff

-   Das zentrale Dashboard ist unter `http://<Server-IP>:8090` erreichbar.
-   Der **B2B Marketing Assistant** ist direkt über das Unterverzeichnis `http://<Server-IP>:8090/b2b/` zugänglich.
-   Der Zugang ist durch Basic Authentication geschützt (Benutzer: `admin`, Passwort: `gemini`).

### Entwicklung (Sideloading)

Für eine schnelle Entwicklung ist "Sideloading" für die Python-Logik aktiviert. Das bedeutet, die `b2b_marketing_orchestrator.py` wird als Volume in den Container gemountet.

-   **Nach Änderungen am Python-Skript:** Ein einfacher Neustart des Containers genügt, um die Änderungen zu übernehmen. Ein kompletter Rebuild ist nicht erforderlich.
    ```bash
    docker-compose restart b2b-app
    ```






---







## 6. Roadmap: Nächste Erweiterungen















### Priorität 1: Integration der SQLite-Datenbank (Portierung) [ABGESCHLOSSEN]































*   **Status:** Erfolgreich implementiert. Der B2B Assistant nutzt nun die gleiche robuste Persistenzschicht wie das Market Intelligence Tool.















*   **Backend:** Die Datenbankintegration erfolgt über das Modul `market_db_manager.py`, das für die Verwaltung der SQLite-Datenbank `b2b_projects.db` zuständig ist. Der Datenbankpfad wird über `DB_PATH` isoliert.















*   **API:** Die entsprechenden Datenbank-Routen sind in `server.cjs` aktiviert, um die Kommunikation zwischen Frontend und Backend zu ermöglichen.















*   **Frontend:** Auto-Save-Funktionen und ein History-Modal wurden in `App.tsx` integriert, um die Persistenz der Projektdaten zu gewährleisten und den Zugriff auf frühere Versionen zu ermöglichen.































### Priorität 2: Customer Journey (Schritt 7) [ABGESCHLOSSEN]

*   **Status:** Erfolgreich implementiert.
*   **Funktion:** Tiefe Analyse der Kaufentscheidung mit Fokus auf Buying Center Dynamik.
*   **Mehrwert:** Liefert konkrete "Deal-Breaker" und definiert benötigte Assets (Munition) für jede Phase.
*   **UI:** Tabellarische Darstellung mit neuer "Schritt neu starten"-Funktion für iterative Optimierung.

### Priorität 3: Asset Factory (Schritt 8)

*   **UI:** Neuer Bereich "Assets generieren" nach Abschluss von Schritt 7.
*   **Funktion:** Auswahl einer Persona und eines Formats (z.B. "LinkedIn Vernetzungsanfrage", "Cold Mail Sequenz").
*   **Input:** Nutzt die in Schritt 7 definierten "Benötigten Assets" als Blaupause.
*   **Output:** Generierung von Copy-Paste-fertigen Texten basierend auf den Painpoints/Gains der Analyse.
*   **Export:** Als separater "Marketing Kit" Download oder Anhang im Markdown.

### Priorität 4: Erweiterung des Finalen Reports [ABGESCHLOSSEN]

*   **Status:** Vollständig in den Workflow integriert.
*   **Search Strategy Beschreibung ICP:** Detaillierte Profile werden generiert.
*   **Digital Signals:** Konkrete Signale (Technographic, Growth, Strategy) identifiziert.
*   **Target Pages:** Relevante URLs für die Akquise im Report gelistet.















### Status: Produktionsbereit (Version 2.2)















Das System ist nun hochgradig robust und bietet volle Transparenz sowie Persistenz.















- [x] Grounding (HTML-Parsing) & Gemini 2.5 Flash / Pro







- [x] Robustheit (Nginx Timeouts 600s, Scraping Fallback "Digital Footprint Mode")







- [x] Persistenz (SQLite DB für alle Projekte)







- [x] UI-Optimierung (History Modal, On-Demand Outreach Generation)







- [x] Logging (Detailliertes Trace-Logging im Container)




