Платформы Wallet-карт делятся на 3 класса: отдельные сервисы для карт, платформы лояльности со встроенным Wallet и платформы вовлечения пользователей (CEP) с нативным Wallet. Отдельного сервиса достаточно, когда карта и есть вся программа. Когда карта должна работать вместе с push, email, сегментами и сценариями, обычно выигрывает платформа, в которой уже живёт профиль клиента.
Сначала о путанице в названиях. Apple PassKit — фреймворк Apple для карт Wallet, на нём строит свои продукты каждый поставщик карт. PassKit Inc. — компания, которая продаёт платформу для карт. Когда ищут «альтернатива PassKit», имеют в виду компанию, и именно её касается это сравнение, а заодно и то, где в нём место Pushwoosh Wallet passes.
3 класса инструментов для Wallet-карт
Отдельные сервисы для карт. PassKit, Passcreator, PassSlot и Pass2U сосредоточены на самой карте. PassKit сочетает no-code конструктор с API для Apple Wallet и Google Wallet, PassSlot — нишевый конструктор для Apple Wallet, в основном для ретейла и мероприятий, а Pass2U — no-code конструктор для обеих платформ, рассчитанный на малый бизнес.
Платформы лояльности с Wallet. Поставщики программ лояльности, например Antavo и Yotpo, ведут логику программы (баллы, уровни, награды) и предлагают Wallet как 1 из способов показать карту.
Платформы вовлечения с нативным Wallet. Платформы вовлечения пользователей, например Pushwoosh и Airship, выпускают карты нативно, на том же профиле, что и push, in-app, email и SMS. Другие платформы вовлечения подключают Wallet через партнёров. Braze, например, работает с поставщиками карт вроде PassKit.
Сравнительная таблица
| Критерий | Отдельный сервис карт | Платформа лояльности с Wallet | CEP с Wallet через партнёра | CEP с нативным Wallet |
|---|---|---|---|---|
| Карты Apple и Google | Нативно, некоторые сервисы только Apple | По-разному | Через сервис партнёра | Нативно |
| Визуальный конструктор | Да | По-разному | В сервисе партнёра | Да |
| API | По-разному | Да | 2 API | Да |
| Обновления в реальном времени | Да | Да | Да, через синхронизацию | Да |
| Сегменты по данным клиента | Только данные карты | Данные лояльности | Через синхронизацию | Тот же профиль |
| Кросс-канальные сценарии | Нет | Ограниченно | 2 инструмента | 1 сценарий |
| Push, email, SMS в том же инструменте | Нет | По-разному | Да, Wallet отдельно | Да |
Читайте таблицу по строкам, а не по колонкам. Для retention-команд важнее всего строки про сегменты, сценарии и каналы. Именно там классы и различаются. В выпуске карт они близки.
Если ваша аудитория живёт в нескольких странах, добавьте к таблице 2 своих критерия: одинаково ли хорошо сервис поддерживает Apple Wallet и Google Wallet (на глобальном рынке доли iOS и Android близки) и где он хранит данные клиентов из ЕС.
Как устроены цены у отдельных сервисов
Цены меняются, поэтому перед решением проверьте текущую страницу тарифов каждого поставщика и запишите дату проверки. Уточните, что поставщик считает: выпущенные карты или карты, активные на телефонах. Одна и та же программа может стоить очень по-разному в этих 2 моделях.
Все модели и скрытые расходы разобраны в гайде по ценам.
Читайте также: Сколько стоят Wallet-карты: модели цен и скрытые расходы
Когда достаточно отдельного сервиса
Отдельный сервис для карт хорошо подходит, когда Wallet — это и есть программа, а не 1 из каналов внутри неё. Типичные случаи:
- Организатор мероприятий выпускает билеты, без приложения и без регулярных рассылок.
- Малый бизнес ведёт карту со штампами без другой CRM.
- Разовая кампания: купон, бейдж конференции, сезонная карта.
Здесь конструктора и API поставщика хватает. Полноценная платформа вовлечения была бы избыточной, и мы честно скажем это любому, кто спросит.
Когда нужна платформа вовлечения
Картина меняется, когда карта должна реагировать на данные клиента и работать с другими каналами. Вы переросли отдельный сервис, когда:
- Хотите выпускать карты по событиям в приложении или на сайте, например при регистрации или первом заказе в e-commerce.
- Сегментируете владельцев карт по поведению, данные о котором живут в вашей CDP или платформе вовлечения.
- 1 момент, например баллы, которые скоро сгорят, требует и обновления карты, и push, и email.
- Синхронизируете 2 базы данных и собираете один и тот же сценарий дважды.
В этот момент вопрос звучит так: подключить сервис карт к текущей платформе или перейти на платформу с нативным Wallet.
Где место Pushwoosh
Pushwoosh — омниканальная платформа вовлечения пользователей, которая выпускает карты Apple Wallet и Google Wallet нативно, без партнёра посередине. Карты выпускаются по User ID и живут в той же CDP, сегментах и Customer Journey, что и push, in-app, email, SMS и WhatsApp. В сценариях есть отдельный шаг Issue Wallet Pass (выпуск Wallet-карты).
Вы получаете визуальный конструктор для обеих платформ, REST API и обновления в реальном времени. В Apple Wallet обновления проходят молча, если у поля нет сообщения об изменении, а если оно есть, клиент видит уведомление на экране блокировки. В Google Wallet изменения синхронизируются на все устройства, где сохранена карта. Данные хранятся на собственной инфраструктуре Pushwoosh в Германии и США, платформа соответствует GDPR и сертифицирована по SOC 2 Type 2 и ISO 27001:2022. Для команд с клиентами в ЕС это упрощает проверку поставщика.
Честно об ограничениях: Pushwoosh не предлагает NFC-карты, например проездные с оплатой касанием или ключи от гостиничных номеров. И на любой платформе Apple и Google разрешают только уведомления, связанные с картой.
Подробнее: Что такое wallet pass
Меньше разрозненных инструментов с Pushwoosh
Если Wallet — 1 из каналов в большой программе удержания, Pushwoosh ставит его рядом с push, in-app, email, SMS и WhatsApp на 1 профиле клиента. 1 конструктор, 1 API, 1 сценарий для всех каналов.
Правильная платформа для Wallet — не та, у которой больше всего шаблонов карт. А та, что ближе всего к месту, где уже живут данные ваших клиентов.
FAQ