利用中のカスタマーエンゲージメント基盤がウォレットパスにネイティブ対応していない場合、選択肢は2つです。パス作成ツールを接続して2つのシステムを同期し続けるか、Apple WalletとGoogle Walletのパスを同じ顧客プロファイル上で発行できる基盤に乗り換えるかです。前者は早く始められます。後者は、ウォレットがジャーニーの一部になった後の運用がシンプルです。
この記事は、Braze、OneSignal、CleverTapなどの基盤を使っていて、すべてを作り直さずにウォレットパスを導入したいチームに向けたものです。ベンダー単位の比較はWallet passesの比較ページをご覧ください。
現在の出発点を確認する
ウォレットへの対応状況は、エンゲージメント基盤によって大きく異なります。Brazeは、PassKitなどのパートナーを通じてウォレットに対応しています。OneSignalには、ネイティブのウォレットパス機能がありません。状況は変わるため、計画を立てる前に、利用中の基盤の最新ドキュメントを確認してください。
ネイティブ対応がない場合、パスは一方のシステムに、顧客はもう一方のシステムに存在することになります。パスを発行するにも、更新するにも、対象を絞り込むにも、両方のデータが必要です。
日本では、プッシュ通知やメールに加えてLINE公式アカウントも顧客接点として併用しているチームが少なくありません。すでにチャネルごとにツールが分かれている場合、ウォレットのためにもう1つツールを加えると、同期すべきデータの経路がさらに増えます。
ルートA：今のCEPを残し、パス作成ツールを追加する
プッシュ通知、メール、セグメントには今の基盤を使い続け、Apple WalletとGoogle Wallet用に単体のパス作成ツールを接続します。
一般的な仕組みは次のとおりです。CEPまたは自社のバックエンドが、多くの場合Webhook経由でパス作成ツールのAPIを呼び出し、パスを発行します。パス作成ツールがイベントを提供していれば、それをCEPに戻し、パス保有者をセグメント分けできます。
メリットは確かにあります。移行は不要です。チームは今のツールとジャーニーをそのまま使え、ポイントカードのような1つのユースケースから始められます。
デメリットは時間とともに積み上がります。同期すべきデータベースが2つ、契約が2本、セキュリティとGDPRの審査が2回です。「ポイントの失効が近づいています」のように、パスの更新とメッセージを組み合わせるシナリオは、すべて2つのツールにまたがって構築することになります。
日本のエンタープライズ導入では、情報システム部門の審査で第三者認証、データの所在、委託先管理が確認されるのが一般的です。ルートAでは、この審査資料をベンダーごとにそろえる必要があります。
ルートB：ネイティブにウォレット対応した基盤に乗り換える
メッセージ配信を、ウォレットパスをネイティブに発行できる基盤に移します。パスは、プッシュ通知、アプリ内メッセージ、メール、SMSと同じプロファイル上で扱われます。
パスは基盤の中でUser IDに対して発行されます。セグメント、ジャーニー、チャネルのすべてが、パス保有者を1人の顧客として認識します。ジャーニーの1つのステップでパスを発行し、次のステップでリンクを送れます。
プロファイルも、ジャーニーも、契約も1つで済みます。パスの更新とメッセージが同じトリガーから送られ、見張り続けなければならない同期の仕組みもありません。
コストは移行作業そのものです。SDKの変更、データのインポート、ジャーニーとテンプレートの再構築が必要になります。ウォレットを単発のキャンペーンではなく長期的なチャネルとして使う場合に、元が取れます。
| ルートA：CEP＋パス作成ツール | ルートB：ネイティブ対応 | |
|---|---|---|
| 最初のパスまでの期間 | 短い | 移行の規模による |
| 保守するシステム | 2つと同期の仕組み | 1つ |
| パスの更新を含むジャーニー | 2つのツールにまたがって構築 | 1つのジャーニー |
| パス保有者のセグメント分け | 同期したデータ経由 | 同じプロファイル |
| 契約とベンダー審査 | 2件 | 1件 |
| 向いているケース | ウォレットのユースケースが1つだけ | ウォレットをリテンションのチャネルにする |
判断のフレームワーク
4つの質問で自社の状況を採点します。
-
範囲
ウォレットは1回のキャンペーンですか？それとも何年も運用するチャネルですか？1回のキャンペーンならルートAが有力です。
-
チャネル
パスとプッシュ通知、メール、SMSを組み合わせるシナリオはいくつありますか？多いならルートBが有力です。
-
チーム
同期の仕組みを構築し保守できる開発者はいますか？いなければ、ルートAは時間とともに高くつきます。
-
データの所在
GDPRのためにEUでのホスティングや、データ処理者の削減が必要ですか？ベンダーが1社増えるごとに、審査すべき処理者も1社増えます。
答えのうち2つ以上が「長期的」「多い」「開発者がいない」「処理者を減らしたい」なら、ルートBを真剣に検討しましょう。1つも当てはまらなければ、ルートAで十分です。1年後に見直すこともできます。
2つのツールのコストを数える
ルートAは、何も移行しないため、初日は安く見えます。1年単位では、パス作成ツールの請求書には現れない部分を加えてください。連携の構築、同期の保守、重複するジャーニー作業、2回目のベンダー審査です。
ルートBはコストが前倒しになります。まず移行作業、その後は1つの基盤の料金です。両者は1か月ではなく、12〜24か月で比較してください。稟議で導入を説明する場合も、この期間でのROIを示すと、社内の判断材料として伝わりやすくなります。
移行チェックリスト
ルートBを選ぶなら、ツールではなく顧客を軸に移行を計画します。
- 送っている内容を棚卸しする。 移行が必要なプッシュ通知、メール、SMS、アプリ内メッセージのキャンペーン、ジャーニー、セグメントを一覧にします。
- データをマッピングする。 User ID、タグ、イベント、同意の記録です。パスと顧客を結び付けるのはUser IDです。
- ウォレットの設定を一度だけ行う。 AppleのPass Type ID証明書（Apple Developerアカウント、年額99ドル）と、GoogleのIssuer IDが必要です。発行者にはPushwooshのサービスアカウントを招待します。iPhoneの利用率が高い日本市場では、まずAppleの証明書の準備から始めると計画が立てやすくなります。
- SDKを組み込む。 アプリの旧SDKを置き換え、トラフィックを移す前にプッシュ通知をテストします。
- 主要なジャーニーから再構築する。 ウェルカム、カゴ落ち、休眠ユーザーの復帰施策の順に作り、その後で新しいウォレットのシナリオを加えます。
- パスの展開を計画する。 ジャーニーのステップからパスを発行し、メール、SMS、プッシュ通知でリンクを送ります。
- 短期間だけ並行運用する。 旧基盤を短い期間だけ残し、その後で停止します。
移行中は、APIを使って自社のバックエンドからパスを発行できます。
Pushwooshでツール構成をシンプルにする
Pushwooshは、ネイティブのApple WalletパスとGoogle Walletパスを、プッシュ通知、アプリ内メッセージ、メール、SMS、WhatsAppと同じUser ID、セグメント、ジャーニーの上で発行します。1つの基盤で完結し、ドイツと米国にある自社のインフラでホストされ、GDPRに準拠し、SOC 2 Type 2とISO 27001:2022の認証を取得しています。情報システム部門の審査でも、確認すべきベンダーは1社で済みます。詳しくはウォレットの選択肢の中でのPushwooshの位置付けをご覧ください。
ウォレットを導入することは、ツールをもう1つ継ぎ足すことであってはなりません。すべてのチャネルが活用できる、1つの顧客プロファイルを持つことです。
