mailingwork für TYPO3

mailingwork ist die DSGVO-native Newsletter-Alternative zu Mailchimp für TYPO3-Projekte

Unternehmen, die einen professionellen Newsletter versenden, aber keine Daten in die USA übertragen wollen, landen fast zwangsläufig bei einem deutschen Anbieter. mailingwork gehört zu den etablierten deutschen E-Mail-Marketing-Plattformen mit Servern in Deutschland, deutscher Rechtsform und einem Support-Team, das DSGVO-Fragen auf Deutsch beantworten kann. Die TYPO3-Extension synchronisiert Subscriber-Listen, steuert Double-Opt-In und überträgt Segmentierungsdaten zwischen CMS und Newsletter-System. Für TYPO3-Projekte, die eine rechtlich unkomplizierte Newsletter-Lösung brauchen, ist die Kombination aus mailingwork und TYPO3 eine der wartungsärmsten Optionen im deutschsprachigen Markt.

Der Vergleich mit Mailchimp zeigt den Unterschied: Kein AVV mit einem US-Unternehmen nötig, kein Transfer-Mechanismus zu dokumentieren, kein Risiko bei Änderungen der transatlantischen Datenschutzabkommen. Die Kehrseite: mailingwork hat einen kleineren Feature-Set als Mailchimp und kein vergleichbares Ökosystem an Third-Party-Integrationen. Wer fortgeschrittene Marketing-Automation (Behavioral Trigger, Lead Scoring, Customer Journey Mapping) benötigt, stösst bei mailingwork eher an Grenzen als bei Mailchimp oder HubSpot.

Typische Einsatzszenarien sind Unternehmens-Newsletter, Mitglieder-Kommunikation und Lead-Nurturing

Das Standardszenario ist der monatliche Unternehmens-Newsletter für 5.000 bis 50.000 Empfänger. Die Redaktion pflegt Inhalte in TYPO3, erstellt den Newsletter in mailingwork und verschickt ihn an segmentierte Listen. Die TYPO3-Extension sorgt dafür, dass neue Website-Anmeldungen automatisch in mailingwork landen und dass Abmeldungen in beide Richtungen synchronisiert werden.

Zweites Szenario: Mitglieder-Kommunikation bei Verbänden und Vereinen. Ein Berufsverband mit 10.000 Mitgliedern verschickt Rundschreiben, Einladungen und Jahresberichte. Die Mitglieder-Daten liegen in TYPO3 (über fe_users oder eine Custom-Tabelle), und mailingwork übernimmt den Versand. Die Segmentierung nach Mitgliedsart, Region oder Fachgruppe wird über Tags gesteuert, die die Extension aus TYPO3-Kategorien generiert.

Drittes Szenario: Lead-Nurturing für B2B-Unternehmen. Ein Maschinenbauer sammelt Leads über Whitepaper-Downloads und Kontaktformulare auf der TYPO3-Website. Die Extension überträgt die Leads mit Quell-Information (welches Formular, welche Seite) an mailingwork, das eine automatisierte E-Mail-Strecke startet: Welcome-Mail nach 1 Tag, Case-Study nach 7 Tagen, Angebots-Einladung nach 14 Tagen.

Technische Architektur verbindet TYPO3-Formulare über die mailingwork-REST-API

Die Extension nutzt die mailingwork-REST-API für den Datenaustausch. Die Konfiguration im TYPO3-Extension-Manager umfasst API-Endpoint, API-Key und die Zuordnung von TYPO3-Feldern zu mailingwork-Kontaktfeldern. Der Sync läuft über Scheduler-Tasks in konfigurierbaren Intervallen.

Der Subscriber-Import folgt einem klaren Ablauf: Ein Besucher füllt ein Anmeldeformular auf der Website aus. TYPO3 speichert die Daten lokal und überträgt sie per API-Call an mailingwork. mailingwork verschickt die Double-Opt-In-Mail. Erst nach Bestätigung wird der Subscriber in der aktiven Liste geführt. Die Extension protokolliert jeden Schritt in einer Log-Tabelle, was für DSGVO-Audits relevant ist.

Die Segmentierung funktioniert über Tags und Custom Fields. Die Extension kann TYPO3-Kategorien (Sys-Categories) automatisch als Tags an mailingwork übergeben. So lassen sich Website-spezifische Segmente (z.B. “Interessiert an Produkt X”) direkt für den Newsletter-Versand nutzen.

Die Templates in mailingwork werden unabhängig von TYPO3 gepflegt. Wer Content aus TYPO3 automatisch in Newsletter-Templates übernehmen will, muss das über die mailingwork-API und Custom-Code lösen, da die Standard-Extension diese Funktion nicht abdeckt.

Häufige Probleme betreffen Feld-Mapping, Double-Opt-In-Timing und Fehler-Handling

Problem eins: Fehlerhaftes Feld-Mapping. Die Felder in TYPO3-Formularen stimmen selten 1:1 mit den Kontaktfeldern in mailingwork überein. Ein Formular hat “Firma”, mailingwork erwartet “company”. Ohne korrektes Mapping landen Daten in falschen Feldern oder gehen verloren. Die Lösung: Vor der Integration ein Feld-Mapping-Dokument erstellen, das alle TYPO3-Felder den mailingwork-Feldern zuordnet, und die Zuordnung in der Extension-Konfiguration hinterlegen.

Problem zwei: Timing des Double-Opt-In. Zwischen der Anmeldung auf der Website und dem Klick auf den Bestätigungslink vergehen oft Stunden oder Tage. Wenn der Sync-Job in der Zwischenzeit läuft und den noch nicht bestätigten Subscriber als “aktiv” an TYPO3 zurückmeldet, entstehen Inkonsistenzen. Die Lösung: Den Subscriber-Status in TYPO3 erst auf “aktiv” setzen, wenn mailingwork den Status “confirmed” zurückgibt.

Problem drei: Fehler-Handling bei API-Ausfällen. Wenn die mailingwork-API nicht erreichbar ist, muss die Extension die Anmeldung puffern und beim nächsten Sync-Lauf erneut versuchen. Ohne diese Retry-Logik gehen Anmeldungen verloren. Die Extension bietet eine Queue-Funktion, die fehlgeschlagene API-Calls speichert und automatisch wiederholt.

Ein viertes Problem, das bei grösseren Installationen auftaucht: Reporting-Granularität. mailingwork liefert Kampagnen-Statistiken auf Empfänger-Ebene, aber die TYPO3-Extension bildet nicht alle Metriken im Backend ab. Für detaillierte Analysen (Klick-Heatmaps, Öffnungszeitpunkte, Device-Verteilung) muss man ins mailingwork-Dashboard wechseln. Gosign empfiehlt, das TYPO3-Backend-Modul für Übersichtsdaten zu nutzen und für tiefe Analysen direkt in mailingwork zu arbeiten.

mailingwork pflegt die TYPO3-Extension aktiv, v12 wird unterstützt

mailingwork als kommerzieller Anbieter hat ein geschäftliches Interesse daran, die TYPO3-Integration aktuell zu halten, weil der TYPO3-Markt ein relevanter Vertriebskanal ist. Die aktuelle Extension unterstützt TYPO3 v11 und v12. Für v13 ist die Kompatibilität zu erwarten, aber noch nicht offiziell bestätigt. Beim Upgrade von v10 auf v12 betreffen Änderungen vor allem die Scheduler-Task-Registrierung und die Extension-Konfiguration, die von ExtensionManager-Settings auf SiteSet-Konfiguration umgestellt werden sollte. Der Subscriber-Sync und die API-Kommunikation bleiben stabil.