Vol.3 schließt an vol.1 und vol.2 an und bringt zwei größere Integrationen sowie gezielte Verbesserungen für den Journey-Alltag.
Hinweis zur Datenverarbeitung: Alle in diesem Update beschriebenen Features verarbeiten Ihre Audience-Daten ausschließlich auf der Pushwoosh-Plattform mit EU-Datenresidenz (Rechenzentren in Deutschland und der EU), ISO 27001:2022-Zertifizierung und SOC 2 Type I. Pushwoosh agiert dabei als Auftragsverarbeiter im Sinne von Art. 28 DSGVO. Ein aktueller Auftragsverarbeitungsvertrag (AVV) steht in Ihrem Account-Bereich bereit.
Und das ändert sich konkret 👇
Journey-Zielgruppen mit Meta Ads synchronisieren 🎯
Das Audience-Sync-Element im Customer Journey Builder ist jetzt mit Meta Ads verbunden. Fügen Sie es an beliebiger Stelle in eine Journey ein, wählen Sie das Ad-Konto und die Custom Audience — und Nutzer werden als fester Bestandteil des Flows hinzugefügt oder entfernt.
Was sich ändert: Verhaltenskohorten, die Sie in Pushwoosh aufbauen, steuern ab sofort automatisch Retargeting- und Ausschlusslisten in Meta. Kein CSV-Export, kein manueller Abgleich, kein Warten auf ein Data-Team als Brücke zwischen den Systemen. Der Sync läuft als Journey-Schritt und bleibt aktuell, während Nutzer ein- und austreten.
Meta ist die erste Ad-Plattform, die über Audience Sync in Pushwoosh unterstützt wird. Google, Pinterest und weitere folgen — alle über dasselbe Journey-Element.
DSGVO-Hinweis: Die Synchronisation mit Meta Custom Audiences setzt voraus, dass Ihre Nutzer einer entsprechenden Verarbeitung zu Werbezwecken zugestimmt haben (Art. 6 Abs. 1 lit. a DSGVO). Pushwoosh leitet Daten erst dann an Meta weiter, wenn der Audience-Sync-Schritt im Journey-Flow ausgelöst wird — keine Hintergrundübertragungen. Pushwoosh agiert hierbei als Auftragsverarbeiter; Meta verarbeitet die übermittelten Identifikatoren nach eigenem Auftragsverarbeiterverhältnis. Prüfen Sie, ob Ihre bestehende Einwilligungs-Dokumentation diesen Use Case abdeckt, bevor Sie den Sync aktivieren.
Mehr zum Audience-Sync-Element im Customer Journey →
Journeys aus externen Diensten per Inbound Webhook auslösen 🔌
Inbound Webhooks ermöglichen es Drittsystemen, Pushwoosh-Events direkt auszulösen. Ihr CRM schließt einen Deal, Ihr Shopsystem registriert eine Zahlung, Ihr Analytics-Tool erreicht einen Meilenstein — jedes System sendet einen HTTP-POST an Pushwoosh, und ein zugeordnetes Event wird auf dem passenden Nutzerprofil ausgelöst.
Was sich ändert: Bisher erforderte die Umwandlung eines Dritt-Webhooks in ein Pushwoosh-Event einen eigenen Integrationsserver: Webhook empfangen, Payload parsen, Pushwoosh-API aufrufen, Retries verwalten. Das übernimmt jetzt Pushwoosh. Sie fügen einen Beispiel-Payload ein (z. B. aus Stripe oder einem deutschen ERP-System wie Sage oder DATEV), mappen Felder auf Event-Attribute, wählen die Nutzeridentifikation (User-ID, E-Mail, Telefon oder HWID) — fertig.
Anwendungsfall für den DACH-E-Commerce — Shopware oder Shopify → Post-Purchase-Journey: Eine erfolgreiche Zahlung in Ihrem Shopsystem landet als Purchase-Event in Pushwoosh und löst eine Dankes-Sequenz oder Upsell-Journey aus. Gleiches gilt für Buchungsbestätigungen aus Reservierungssystemen oder Vertragsabschlüsse aus CRM-Lösungen.
DSGVO-Hinweis: Die Payload-Verarbeitung findet vollständig auf der Pushwoosh-Plattform mit EU-Datenresidenz statt. Personenbezogene Daten aus dem übermittelten Payload verlassen den DSGVO-konformen Rahmen nicht. Pushwoosh speichert keine Roh-Payloads dauerhaft — nur die auf Event-Attribute gemappten Werte werden dem Nutzerprofil zugeordnet. Achten Sie darauf, in Ihrem Payload ausschließlich Attribute zu übermitteln, deren Verarbeitung durch Ihre Datenschutzerklärung und ggf. AVV abgedeckt ist.
Präzisere Zustellsteuerung ⚙️
Zwei kleinere Updates, die im Journey-Alltag regelmäßig gefragt sind.
⏱️ Push-TTL pro Kampagne festlegen
Push-TTL — die Zeitspanne, in der das System versucht, eine Benachrichtigung zuzustellen, wenn das Gerät offline ist — lässt sich jetzt auf Ebene der einzelnen Kampagne setzen, sowohl in Customer-Journey-Push-Schritten als auch bei einmaligen Pushes. Bisher war der TTL am Preset verankert, sodass alle Kampagnen mit diesem Preset denselben Ablaufzeitraum geerbt haben.
Warum das relevant ist: Zeitkritische Nachrichten — Flash-Sales im E-Commerce, OTPs im FinTech, Breaking-News-Benachrichtigungen oder Live-Event-Erinnerungen — sollten einen Nutzer nicht drei Tage später erreichen, wenn sein Gerät wieder online geht. Mit einem kurzen TTL werden abgelaufene Benachrichtigungen automatisch verworfen. Für alle anderen Fälle gilt weiterhin der Standard-TTL aus dem Preset.
Für Automotive- und FinTech-Szenarien im DACH-Raum: OTPs und sicherheitskritische Aktions-Benachrichtigungen sollten grundsätzlich mit minimalem TTL konfiguriert werden, um zu verhindern, dass sensible Hinweise auf einem verzögert verbundenen Gerät erscheinen, nachdem das Zeitfenster für die Aktion bereits abgelaufen ist.
🗓️ Nutzer nach bevorstehenden Datums-Events segmentieren mit daysahead
Der neue Operator daysahead erlaubt es, Nutzer nach Datum-Tags oder Event-Attributen vorausschauend zu segmentieren. Er ist das Gegenstück zu daysago.
Nutzen Sie ihn, um Segmente wie diese zu bauen:
- Abonnements, die in den nächsten 7 Tagen ablaufen,
- Geburtstage in den nächsten 3 Tagen,
- Testphasen, die in 14 Tagen enden,
- Buchungen, Reservierungen oder geplante Termine in der kommenden Woche.
Der Operator berechnet sich immer vom aktuellen Zeitpunkt aus, sodass das Segment ohne manuelles Update oder geplanten Aktualisierungsjob aktuell bleibt. Kombinieren Sie ihn mit einer Journey, um Verlängerungs-Erinnerungen, Geburtstagsangebote oder Ablaufhinweise zum richtigen Zeitpunkt auszuspielen.
DACH-Praxisbeispiel: Kfz-Versicherungen oder Wartungsverträge laufen häufig zu festen Jahrestagen aus. Mit daysahead lassen sich diese Vertragsverlängerungssegmente vollautomatisch und ohne tägliche manuelle Pflege aufbauen — eine Anforderung, die im deutschen Direktmarketing durch den hohen Stellenwert vertraglicher Kommunikation besonders relevant ist.
E-Mail-Preference-Center: flexibleres Kategorien-Management 💌
Im Q1-2026-Produkt-Update haben wir das E-Mail-Subscription-Preference-Center eingeführt — Abonnenten wählen selbst, welche E-Mail-Kategorien sie erhalten möchten (Newsletter, Aktionen, Produkt-Updates), statt pauschal abzumelden.
Was sich seitdem geändert hat: Das Verwalten dieser Kategorien ist jetzt deutlich flexibler.
Beim Anlegen einer Kategorie entscheiden Sie direkt, ob Sie:
- neue Nutzer automatisch abonnieren möchten, sobald sie sich registrieren, und/oder
- alle bestehenden Nutzer abonnieren möchten, sobald Sie speichern.
Außerdem lassen sich Subscription-Kategorien per CSV-Massenimport importieren. Das ist besonders nützlich, wenn Sie eine bestehende Audience migrieren oder Präferenzen aus einem anderen System synchronisieren.
DSGVO-Hinweis: Beide Schalter — Auto-subscribe und Subscribe existing users — setzen eine gültige und dokumentierte Marketingeinwilligung der betroffenen Nutzer voraus (Art. 6 Abs. 1 lit. a DSGVO). Das Aktivieren eines Schalters ersetzt keinen Opt-in. Prüfen Sie vor dem Einsatz, ob Ihre bestehende Einwilligungs-Dokumentation die neue Kategorie inhaltlich abdeckt. Für CSV-Importe gilt dasselbe: Importieren Sie nur Präferenzdaten, für die eine belegbare Einwilligung vorliegt. Da die CSV-Verarbeitung vollständig auf der Pushwoosh-Plattform mit EU-Datenresidenz stattfindet, verlassen die Preference-Daten Ihrer Abonnenten den DSGVO-konformen Rahmen nicht. Alle Änderungen werden im Audit-Log Ihres Accounts dokumentiert.
Updates selbst ausprobieren
Alle oben genannten Features sind live und in Ihrem Konto sofort einsatzbereit.
Die vollständige Übersicht aller zuletzt ausgelieferten Änderungen finden Sie in den Release Notes.
Verwandte Artikel
Alle anzeigen
