Если в вашей платформе вовлечения пользователей нет нативных Wallet-карт, у вас два пути. Подключить отдельный сервис карт и держать две системы синхронизированными или перейти на платформу, которая выпускает карты Apple Wallet и Google Wallet на том же профиле клиента. Первый путь быстрее на старте. Второй проще в работе, когда Wallet становится частью ваших сценариев.
Мы написали этот разбор для команд на платформах вроде Braze, OneSignal или CleverTap, которые хотят Wallet-карты, не ломая всё остальное. Сравнение на уровне поставщиков — на странице Wallet passes.
С чего вы начинаете
Поддержка Wallet сильно отличается от платформы к платформе. Braze подключает Wallet через партнёров, например PassKit. В OneSignal нативных Wallet-карт нет. Перед планированием проверьте актуальную документацию своей платформы, потому что это меняется.
Без нативной поддержки карта живёт в одной системе, а клиент — в другой. Каждый выпуск, обновление или таргетинг карты требует данных из обеих.
Для команд, чья аудитория живёт в нескольких странах, добавьте к этому ещё один вопрос: одинаково ли хорошо ваш текущий стек работает с Apple Wallet и Google Wallet. На глобальном рынке доли iOS и Android близки к 50/50, поэтому половина клиентов не должна получать карту «по остаточному принципу».
Путь A: оставить свою CEP и добавить сервис карт
Вы оставляете текущую платформу для push, email и сегментов и подключаете отдельный сервис для карт Apple Wallet и Google Wallet.
Обычно это выглядит так. Ваша CEP или бэкенд вызывает API сервиса карт, чтобы выпускать карты, часто через вебхуки. Если сервис карт отдаёт события, они возвращаются в CEP, и вы можете сегментировать владельцев карт.
Плюсы реальные. Ничего не переезжает. Команда сохраняет свои инструменты и сценарии, а начать можно с одной задачи, например с карты лояльности.
Минусы накапливаются со временем. Две базы данных для синхронизации, две подписки, две проверки безопасности и GDPR. Каждый сценарий, где обновление карты идёт вместе с сообщением, например «ваши баллы скоро сгорят», собирается в двух инструментах.
Путь B: перейти на платформу с нативным Wallet
Вы переносите коммуникации на платформу, которая выпускает Wallet-карты нативно, на том же профиле, что и push, in-app, email и SMS.
Карты выпускаются по User ID внутри платформы. Сегменты, сценарии и каналы видят владельца карты как одного клиента. Один шаг сценария выпускает карту, а следующий отправляет ссылку.
Вы получаете один профиль, один сценарий и один договор. Обновления карт и сообщения запускаются одним триггером, и нет слоя синхронизации, за которым надо присматривать.
Цена — сама миграция: изменения SDK, импорт данных, пересборка сценариев и шаблонов. Она окупается, когда Wallet — долгосрочный канал, а не разовая кампания.
| Путь A: CEP + сервис карт | Путь B: нативный Wallet | |
|---|---|---|
| Время до первой карты | Быстро | Зависит от миграции |
| Систем в поддержке | 2 плюс слой синхронизации | 1 |
| Сценарии с обновлением карт | Собираются в двух инструментах | Один сценарий |
| Сегментация владельцев карт | Через синхронизированные данные | Тот же профиль |
| Договоры и проверки поставщиков | 2 | 1 |
| Лучше всего подходит | Для одной задачи в Wallet | Для Wallet как канала удержания |
Как принять решение
Ответьте на 4 вопроса.
-
Масштаб
Wallet — это одна кампания или канал, с которым вы будете работать годами? Одна кампания говорит в пользу пути A.
-
Каналы
Сколько сценариев сочетают карту с push, email или SMS? Если много, это аргумент за путь B.
-
Команда
Есть ли у вас разработчики, чтобы построить и поддерживать слой синхронизации? Если нет, путь A со временем становится дорогим.
-
Резидентность данных
Нужны ли вам хостинг в ЕС и меньше обработчиков данных ради GDPR? Каждый дополнительный поставщик — ещё один обработчик на проверку.
Если два или больше ответов звучат как «надолго», «много», «нет разработчиков» или «меньше обработчиков», присмотритесь к пути B. Если ни одного, путь A — вполне хороший выбор, и через год к нему можно вернуться.
Вопрос о резидентности данных особенно важен для распределённых команд: если среди ваших клиентов есть жители ЕС, проверка по GDPR обязательна для каждого поставщика в цепочке, а не только для основной платформы.
Сколько стоят два инструмента
В первый день путь A выглядит дешевле, потому что ничего не переезжает. За год добавьте то, что никогда не попадает в счёт поставщика карт: разработку интеграции, поддержку синхронизации, двойную работу над сценариями и вторую проверку поставщика.
Путь B переносит расходы в начало: сначала работа по миграции, потом одна плата за платформу. Сравнивайте оба варианта на горизонте 12–24 месяцев, а не 1.
Чек-лист миграции
Если вы выбрали путь B, планируйте переезд вокруг клиента, а не вокруг инструмента.
- Проведите аудит рассылок. Составьте список push, email, SMS и in-app кампаний, сценариев и сегментов, которые нужно перенести.
- Сопоставьте данные. User ID, теги, события и записи о согласиях. Именно User ID связывает карту с клиентом.
- Настройте Wallet один раз. Сертификат Apple Pass Type ID (аккаунт Apple Developer, $99 в год) и Google Issuer ID с приглашённым в ваш аккаунт издателя сервисным аккаунтом Pushwoosh.
- Интегрируйте SDK. Замените старый SDK в приложении и протестируйте push до того, как переводить трафик.
- Сначала пересоберите ключевые сценарии. Приветственный, брошенная корзина, реактивация пользователей, затем новые сценарии с Wallet.
- Спланируйте запуск карт. Выпускайте карты из шага сценария и отправляйте ссылку по email, SMS или push.
- Ненадолго запустите обе системы параллельно. Оставьте старую платформу на короткий период перекрытия, затем отключите её.
Во время переезда выпускайте карты из своего бэкенда через API.
Выберите окно для переезда с учётом сезона. Если вы в e-commerce, не переключайте трафик в ноябре: на Black Friday и Cyber Monday приходится пик кампаний, и пересобранные сценарии лучше проверить заранее, например в сентябре или октябре.
Упростите стек с Pushwoosh
Pushwoosh выпускает нативные карты Apple Wallet и Google Wallet на тех же User ID, сегментах и сценариях, что и push, in-app, email, SMS и WhatsApp. Это одна платформа на собственной инфраструктуре в Германии и США, с соответствием GDPR и сертификацией SOC 2 Type 2. Посмотрите, где место Pushwoosh среди вариантов Wallet.
Добавить Wallet не должно означать прикрутить ещё один инструмент. Это должен быть один профиль клиента, с которым работает каждый канал.
FAQ
Похожие статьи
Показать все
