Hat Ihre Customer-Engagement-Plattform keine nativen Wallet Passes, haben Sie zwei Wege. Sie binden ein Pass-Tool an und halten zwei Systeme synchron, oder Sie wechseln zu einer Plattform, die Apple- und Google-Wallet-Passes auf demselben Kundenprofil ausstellt. Der erste Weg ist schneller gestartet. Der zweite ist einfacher im Betrieb, sobald Wallet Teil Ihrer Journeys ist.
Für Unternehmen im DACH-Raum entscheidet dabei oft nicht die Funktionsliste, sondern der Datenschutz. Jedes zusätzliche Tool, das Kundendaten verarbeitet, ist ein weiterer Auftragsverarbeiter mit eigenem Auftragsverarbeitungsvertrag (AVV) und eigener Prüfung durch Datenschutz und IT. Pushwoosh ist DSGVO-konform, nach ISO 27001:2022 und SOC 2 Type 2 zertifiziert und betreibt Rechenzentren in der EU und den USA.
Dieser Leitfaden richtet sich an Teams auf Plattformen wie Braze, OneSignal oder CleverTap, die Wallet Passes nutzen möchten, ohne alles umzubauen. Einen Vergleich auf Anbieterebene finden Sie im Wallet-Passes-Vergleich.
Ihr Ausgangspunkt
Die Wallet-Unterstützung unterscheidet sich zwischen Engagement-Plattformen stark. Braze ergänzt Wallet über Partner wie PassKit. OneSignal hat keine nativen Wallet Passes. Prüfen Sie vor der Planung die aktuelle Dokumentation Ihrer eigenen Plattform, denn das ändert sich.
Ohne native Unterstützung liegt der Pass in einem System und der Kunde in einem anderen. Jeder Pass, den Sie ausstellen, aktualisieren oder gezielt ausspielen, braucht Daten aus beiden.
Weg A: CEP behalten und ein Pass-Tool ergänzen
Sie behalten Ihre bisherige Plattform für Push, E-Mail und Segmente und binden ein eigenständiges Pass-Tool für Apple und Google Wallet an.
So läuft das meist ab. Ihre CEP oder Ihr Backend ruft die API des Pass-Tools auf, um Passes auszustellen, oft über Webhooks. Stellt das Pass-Tool Events bereit, fließen sie zurück in Ihre CEP, damit Sie Pass-Inhaber segmentieren können.
Der Vorteil ist real. Nichts wird migriert. Ihr Team behält seine Tools und Journeys, und Sie können mit einem Anwendungsfall starten, etwa einer Kundenkarte.
Der Nachteil wächst mit der Zeit. Zwei Datenbanken zum Synchronisieren, zwei Abonnements, zwei Sicherheits- und DSGVO-Prüfungen. Jedes Szenario, das ein Pass-Update mit einer Nachricht verbindet, etwa „Ihre Punkte verfallen bald“, wird über zwei Tools hinweg gebaut.
Weg B: zu einer Plattform mit nativem Wallet wechseln
Sie verlagern Ihre Kommunikation auf eine Plattform, die Wallet Passes nativ ausstellt, auf demselben Profil wie Push, In-App, E-Mail und SMS.
Passes werden innerhalb der Plattform pro User ID ausgestellt. Segmente, Journeys und Kanäle sehen den Pass-Inhaber als einen Kunden. Ein Journey-Schritt stellt den Pass aus, der nächste versendet den Link.
Sie erhalten ein Profil, eine Journey und einen Vertrag. Pass-Updates und Nachrichten kommen aus demselben Auslöser, und es gibt keine Synchronisierungsschicht, die ständig betreut werden muss.
Der Preis ist die Migration selbst: SDK-Änderungen, Datenimport, Nachbau von Journeys und Vorlagen. Sie lohnt sich, wenn Wallet ein langfristiger Kanal ist und keine einmalige Kampagne.
| Weg A: CEP + Pass-Tool | Weg B: natives Wallet | |
|---|---|---|
| Zeit bis zum ersten Pass | Kurz | Hängt von der Migration ab |
| Zu pflegende Systeme | 2 plus Synchronisierungsschicht | 1 |
| Journeys mit Pass-Updates | Über 2 Tools gebaut | 1 Journey |
| Pass-Inhaber segmentieren | Über synchronisierte Daten | Dasselbe Profil |
| Verträge und Anbieterprüfungen | 2 | 1 |
| Passt gut für | Einen einzelnen Wallet-Anwendungsfall | Wallet als Kanal für Kundenbindung |
Entscheidungsrahmen
Bewerten Sie Ihre Situation anhand von 4 Fragen.
-
Umfang
Ist Wallet eine einzelne Kampagne oder ein Kanal, den Sie über Jahre betreiben? Eine einzelne Kampagne spricht für Weg A.
-
Kanäle
Wie viele Szenarien verbinden einen Pass mit Push, E-Mail oder SMS? Viele sprechen für Weg B.
-
Team
Haben Sie Entwickler, die eine Synchronisierungsschicht bauen und pflegen? Wenn nicht, wird Weg A mit der Zeit teuer.
-
Datenresidenz
Brauchen Sie Hosting in der EU und weniger Auftragsverarbeiter für die DSGVO? Jeder zusätzliche Anbieter ist ein weiterer Auftragsverarbeiter, den Sie prüfen müssen.
Im DACH-Raum ist die letzte Frage selten offen. Für viele CTOs und IT-Leiter ist EU-Datenresidenz eine Pflichtanforderung, kein Zusatz. Stellen Sie die Datenschutzprüfung deshalb an den Anfang der Entscheidung, nicht ans Ende des Projekts.
Lauten zwei oder mehr Ihrer Antworten „langfristig“, „viele“, „keine Entwickler“ oder „weniger Auftragsverarbeiter“, sehen Sie sich Weg B genau an. Trifft keine davon zu, ist Weg A eine gute Wahl, und Sie können die Entscheidung in einem Jahr neu prüfen.
Die Kosten von zwei Tools durchrechnen
Weg A wirkt am ersten Tag günstiger, weil sich nichts bewegt. Über ein Jahr kommen die Posten hinzu, die nie auf der Rechnung des Pass-Anbieters stehen: der Bau der Integration, die Pflege der Synchronisierung, doppelte Arbeit an Journeys und eine zweite Anbieterprüfung.
Bei Weg B fallen die Kosten am Anfang an: erst die Migration, dann eine einzige Plattformgebühr. Vergleichen Sie beide über 12 bis 24 Monate, nicht über 1.
Checkliste für die Migration
Wenn Sie sich für Weg B entscheiden, planen Sie den Wechsel rund um den Kunden, nicht rund um das Tool.
- Erfassen Sie, was Sie versenden. Listen Sie die Push-, E-Mail-, SMS- und In-App-Kampagnen, Journeys und Segmente auf, die umziehen müssen.
- Bilden Sie Ihre Daten ab. User IDs, Tags, Events und Einwilligungsnachweise. Die User ID verbindet einen Pass mit einem Kunden.
- Richten Sie Wallet einmal ein. Ein Pass-Type-ID-Zertifikat von Apple (Apple-Developer-Konto, 99 US-Dollar pro Jahr) und eine Issuer ID von Google, zu deren Issuer das Service-Konto von Pushwoosh eingeladen ist.
- Integrieren Sie das SDK. Ersetzen Sie das alte SDK in Ihrer App und testen Sie Push, bevor Sie Traffic umleiten.
- Bauen Sie zuerst die wichtigsten Journeys nach. Willkommensstrecke, Warenkorbabbrecher, Rückgewinnung, danach die neuen Wallet-Szenarien.
- Planen Sie den Start der Passes. Stellen Sie Passes aus einem Journey-Schritt aus und senden Sie den Link per E-Mail, SMS oder Push.
- Betreiben Sie beide Systeme kurz parallel. Behalten Sie die alte Plattform für eine kurze Überlappung, dann schalten Sie sie ab.
Wählen Sie auch das Zeitfenster bewusst. Im DACH-E-Commerce fallen in den November und Dezember Black Friday, Cyber Monday und das Weihnachtsgeschäft, ein Plattformwechsel mitten in dieser Saison ist ein unnötiges Risiko. Das erste Quartal eignet sich besser. Und weil iOS in Deutschland einen leicht höheren Anteil hat als im globalen Durchschnitt, testen Sie Apple- und Google-Passes mit gleichem Gewicht.
Nutzen Sie während des Wechsels die API, um Passes aus Ihrem eigenen Backend auszustellen.
Ihren Stack vereinfachen mit Pushwoosh
Pushwoosh stellt native Apple- und Google-Wallet-Passes auf denselben User IDs, Segmenten und Journeys aus wie Push, In-App, E-Mail, SMS und WhatsApp. Es ist eine einzige Plattform, betrieben auf eigener Infrastruktur in Deutschland und den USA, DSGVO-konform und mit SOC 2 Type 2. Sehen Sie, wo Pushwoosh unter den Wallet-Optionen steht.
Wallet zu ergänzen sollte nicht bedeuten, ein weiteres Tool anzuschrauben. Es sollte ein einziges Kundenprofil bedeuten, mit dem jeder Kanal arbeiten kann.
FAQ
Verwandte Artikel
Alle anzeigen
