openclaw - 💡(How to fix) Fix Konzept: Contao-Erweiterung Mail-Automation (Drip) [1 participants]

Zielbild

Eine Contao-Erweiterung „Mail-Automation“ (Arbeitstitel: drip), mit der Kontakte regelbasiert in automatisierte E-Mail-Sequenzen geführt werden können.

Das System soll Newsletter-Versand um echte Journey-/Lifecycle-Automation ergänzen (Trigger, Wartezeiten, Bedingungen, Follow-ups).

Warum

• Wiederkehrende Kommunikationsstrecken automatisieren
• Leads/Nutzer entlang definierter Pfade begleiten
• Manuelle Kampagnenarbeit reduzieren
• Bessere Nachverfolgung von Öffnungen/Klicks/Konversionen

Scope

MVP

• Sequenzen anlegen (mehrere E-Mails in Reihenfolge)
• Trigger-basierter Start (z. B. Formular abgeschickt, Tag gesetzt, Import)
• Zeitverzögerungen zwischen Schritten (z. B. +2 Tage)
• Basis-Personalisierung über Tokens/Felder
• Versand-Log pro Kontakt/Schritt
• Stop-/Pause-Mechanismus pro Kontakt

Später (v2+)

• Visueller Flow-Builder
• If/Else-Bedingungen nach Verhalten (Open/Click/No-Click)
• A/B-Tests pro Mail-Schritt
• Scoring / Lead-Qualifizierung
• Webhook-Trigger und externe Event-Quellen
• Multi-Channel (z. B. SMS/Push)

Fachliches Konzept

Kernobjekte

• Contact: Empfänger mit Profilfeldern, Tags, Consent-Status
• Sequence: Automationsserie mit Metadaten (aktiv/inaktiv, Zielgruppe)
• Step: Einzelner Schritt (Wartezeit, Mail, Bedingung)
• Enrollment: Kontakt ist in Sequence eingeschrieben
• ExecutionLog: Historie je Schritt/Aktion/Fehler

Trigger (Startbedingungen)

• Formular-Ereignis in Contao
• Manuelle Einschreibung im Backend
• Tag-/Segment-Änderung
• CSV-Import oder API-Aufruf

Regeln/Logik

• Scheduler/Worker verarbeitet fällige Steps
• Idempotente Verarbeitung (kein Doppelversand)
• Retry-Strategie bei temporären Versandfehlern
• Guardrails für Consent/Double-Opt-in

Technische Architektur (Contao)

Integration

• Eigene Bundle-Struktur (Contao/Symfony-konform)
• DCA-Modelle für Sequences/Steps/Enrollments
• Backend-Module zur Konfiguration und Einsicht
• Hook/Event-Subscriber für Trigger-Ereignisse

Verarbeitung

• Queue/cron-basierte Ausführung für zeitgesteuerte Steps
• Versand über bestehende Mail-Infrastruktur
• Saubere Trennung: Orchestrierung vs. Versandadapter

Nachvollziehbarkeit

• Pro Kontakt: Timeline mit gesendeten/übersprungenen Schritten
• Fehlersicht inkl. letzter Exception + Retry-Zähler
• Exportierbare Logs für Support/Audit

Datenschutz & Compliance

• DSGVO-konforme Verarbeitung und Nachweisbarkeit
• Consent-Prüfung vor jedem Versand
• Unsubscribe-/Abmeldepfade je Sequence respektieren
• Datensparsamkeit + konfigurierbare Aufbewahrung

Offene Fragen

1. Soll MVP ausschließlich E-Mail abdecken oder Architektur direkt kanaloffen sein?
2. Welche Contao-Version(en) sind Zielplattform (5.3/5.4/5.5/5.7)?
3. Welche Trigger sind für MVP zwingend (Formular, Tag, API)?
4. Wie tief muss Reporting im MVP sein (nur Logs vs. KPI-Dashboard)?
5. Welcher Mail-Provider/Transport ist primär?

Umsetzungsphasen

Phase 0 – Discovery

• Anforderungen finalisieren
• Datenmodell und Trigger-Liste fixieren
• technische Risiken bewerten

Phase 1 – MVP Backend + Engine

• Entities/DCA/Backend-UI
• Enrollment + Step-Runner
• Versand + Logging

Phase 2 – Stabilisierung

• Retry/Fehlerhandling
• Performance unter Last
• Tests + Dokumentation

Phase 3 – Erweiterungen

• Bedingungen/Branches
• A/B-Tests
• erweitertes Reporting

Akzeptanzkriterien (MVP)

• Sequence kann im Backend erstellt/aktiviert/deaktiviert werden
• Kontakt kann automatisch und manuell eingeschrieben werden
• Zeitversetzte Mails werden zuverlässig genau einmal versendet
• Versand- und Fehlerlogs sind pro Kontakt einsehbar
• Consent- und Unsubscribe-Regeln werden strikt eingehalten

Nächste konkrete Schritte

• Ziel-Contao-Version festlegen
• Trigger für MVP final priorisieren
• Datenmodell als ER-Skizze ausarbeiten
• Technisches Paketgerüst für Bundle anlegen
• Erste End-to-End-Sequenz als Proof of Concept implementieren