ウォレットパス作成ツールは、3つのタイプに分かれます。単体のパス作成ツール、ウォレット機能を備えたロイヤリティ基盤、そしてウォレットにネイティブ対応したカスタマーエンゲージメント基盤です。パスそのものが施策のすべてなら、単体ツールで十分です。パスをプッシュ通知、メール、セグメント、ジャーニーと連動させる必要があるなら、すでに顧客プロファイルを持っている基盤が有利になるのが一般的です。
最初に、名前の紛らわしさを整理しておきます。Apple PassKitは、Walletパスを扱うためのAppleのフレームワークで、どのパスベンダーもこれを土台にしています。一方、PassKit Inc.はパス作成プラットフォームを販売している企業です。「PassKit 代替」と検索する人が探しているのは企業のほうで、この比較で扱うのもそちらです。あわせて、Pushwoosh Wallet passesがどこに位置するかも説明します。
ウォレットパス作成ツールの3つのタイプ
単体のパス作成ツール。 PassKit、Passcreator、PassSlot、Pass2Uは、パスそのものに特化しています。PassKitはノーコードのビルダーとApple WalletおよびGoogle Wallet向けのAPIを組み合わせています。PassSlotはApple Wallet向けのニッチなビルダーで、主に小売とイベントで使われます。Pass2Uは両プラットフォームに対応したノーコードのビルダーで、小規模事業者向けです。
ウォレット機能を備えたロイヤリティ基盤。 AntavoやYotpoなどのロイヤリティベンダーは、ポイント、会員ランク、特典といったプログラムのロジックを担い、カードを表示する手段の1つとしてウォレットを提供しています。
ウォレットにネイティブ対応したエンゲージメント基盤。 PushwooshやAirshipなどのカスタマーエンゲージメント基盤は、プッシュ通知、アプリ内メッセージ、メール、SMSと同じプロファイル上で、パスをネイティブに発行します。ほかのエンゲージメント基盤は、パートナー経由でウォレットに対応しています。たとえばBrazeは、PassKitなどのパスベンダーと連携しています。
比較表
| 比較項目 | 単体のパス作成ツール | ウォレット対応のロイヤリティ基盤 | パートナー経由でウォレット対応のCEP | ウォレットにネイティブ対応のCEP |
|---|---|---|---|---|
| AppleとGoogleのパス | ネイティブ対応。一部はAppleのみ | 製品による | パートナーのツール経由 | ネイティブ対応 |
| ビジュアルビルダー | あり | 製品による | パートナーのツール内 | あり |
| API | 製品による | あり | 2つのAPI | あり |
| リアルタイム更新 | あり | あり | あり（同期経由） | あり |
| 顧客データに基づくセグメント | パスのデータに限られる | ロイヤリティデータ | 同期経由 | 同じプロファイル |
| チャネル横断のジャーニー | なし | 限定的 | 2つのツール | 1つのジャーニー |
| 同じツールでのプッシュ通知、メール、SMS | なし | 製品による | あり（ウォレットは別） | あり |
この表は列ではなく行で読んでください。リテンション担当のチームにとって最も重要なのは、セグメント、ジャーニー、チャネルの行です。タイプによる違いが出るのはそこで、パスの発行そのものについては大差がありません。
単体ツールの料金体系
料金は変わるため、決定する前に各ベンダーの最新の料金ページを確認し、確認した日付を記録しておきましょう。稟議資料に料金を載せる場合も、この日付があると社内説明がしやすくなります。また、ベンダーが課金対象として数えるのが発行済みのパスか、スマートフォン上で有効なパスかを確認してください。同じプログラムでも、2つのモデルで費用が大きく変わることがあります。
料金モデルと見落としがちなコストの全体像は、料金ガイドをご覧ください。
単体ツールで十分なケース
単体のパス作成ツールが向いているのは、ウォレットが施策の中の1チャネルではなく、施策そのものである場合です。典型的なケースは次のとおりです。
- アプリを持たず、継続的なメッセージ配信もしないイベント主催者がチケットを発行する。
- ほかにCRMを持たない小規模店舗がスタンプカードを運用する。
- クーポン、カンファレンスの入場証、季節限定のパスなど、単発のキャンペーン。
こうしたケースでは、ベンダーのデザイナーとAPIで十分に対応できます。本格的なエンゲージメント基盤を導入するのは過剰であり、私たちも相談を受ければそうお伝えします。
エンゲージメント基盤が必要なケース
パスが顧客データに反応し、ほかのチャネルと連動する必要が出てくると、状況は変わります。次のような状態なら、単体ツールの限界を超えています。
- 会員登録や初回注文など、アプリやWebサイトのイベントをきっかけにパスを発行したい。
- CDPやエンゲージメント基盤にある行動データで、パス保有者をセグメント分けしている。
- ポイントの失効が近いといった1つの瞬間に、パスの更新とプッシュ通知とメールが必要になる。
- 2つのデータベースを同期し、同じジャーニーを2回作っている。
日本のECアプリ、小売アプリ、ゲームアプリのように、セール告知やイベント告知をプッシュ通知で日常的に送っているチームは、早い段階でこの状態に当てはまります。そこからの論点は、パス作成ツールを今の基盤に接続するか、ネイティブにウォレット対応した基盤に移行するかです。
Pushwooshの位置付け
Pushwooshは、Apple WalletとGoogle Walletのパスをパートナーを介さずネイティブに発行できる、オムニチャネル型のカスタマーエンゲージメント基盤です。パスはUser IDに対して発行され、プッシュ通知、アプリ内メッセージ、メール、SMS、WhatsAppと同じCDP、セグメント、カスタマージャーニーの中で管理されます。ジャーニーには専用のIssue Wallet Pass（ウォレットパスの発行）ステップがあります。
両プラットフォーム向けのビジュアルビルダー、REST API、リアルタイム更新を利用できます。Appleでは、フィールドに変更メッセージがない限り更新は通知なしで行われ、変更メッセージがある場合は顧客のロック画面に通知が表示されます。Googleでは、変更が保存済みのすべての端末に同期されます。データはドイツと米国にあるPushwoosh自社のインフラでホストされ、GDPRに準拠し、SOC 2 Type 2の認証を取得しています。ISO 27001:2022の認証も含め、情報システム部門の審査で問われる第三者認証とデータの所在を明確に示せます。
制約もはっきりさせておきます。Pushwooshは、タッチで乗車する交通系のパスやホテルのルームキーのようなNFCパスには対応していません。また、どの基盤であっても、AppleとGoogleが許可しているのはパスに関連する通知だけです。
Pushwooshでツールの乱立を防ぐ
ウォレットがより大きなリテンション施策の中の1チャネルであれば、Pushwooshはそれをプッシュ通知、アプリ内メッセージ、メール、SMS、WhatsAppと並べて、1つの顧客プロファイルで扱います。すべてのチャネルに、ビルダーもAPIもジャーニーも1つずつです。LINE公式アカウントを併用している場合も、配信設計を1つのジャーニーにまとめやすくなります。
最適なウォレット基盤とは、パスのテンプレートが最も多いものではありません。顧客データがすでにある場所に、最も近いものです。
