ウォレットパスについて多くの人が誤解している点があります。「更新を送る」のではありません。パスを編集すれば、スマートフォン側から自動で取りに来るのです。
ポイント残高、ランク、有効期限、バーコード——何を変えるにしても、こちら側で一度書き換えるだけです。顧客のApple WalletやGoogle Walletにすでに保存されているカードは、静かに新しい情報へと描き直されます。誰も再インストールせず、誰もカードをダウンロードし直さず、多くの場合は誰にも通知すら届きません。これがすべての仕掛けであり、何かを組み立てる前に、その裏側の仕組みを理解しておく価値があります。
すべての更新を支えるサイレントプッシュの仕組み
ウォレットパスは静止画像ではありません。パス自身にホームサーバーのアドレスが埋め込まれた小さなデータパッケージで、常に「最新版をどこで確認すればよいか」を知っています。
パスを編集すると、次の順序で処理が進みます。まず、パス配信プラットフォームがAppleまたはGoogleのサーバーへサイレントプッシュを送ります。「サイレント」とは文字通りの意味で、バナーも音も、顧客の目に触れる通知も一切ありません。プッシュは端末上のウォレットを起こし、「保持しているパスの1つが変わった」という事実だけを伝えます。
続いてスマートフォンがパスのホームサーバーへ接続しに行き、更新されたファイルを取得して差し替えます。顧客は後からウォレットを開いたとき、カードが何事もなかったように正しい状態になっているのを目にするだけです。裏側でやり取りされたハンドシェイクを、顧客が意識することはありません。
AppleとGoogleでは配管部分の実装が異なりますが、全体の形は同じです。Appleは PassKit Webサービスと APNs によるサイレントプッシュを使い、GoogleはWallet APIでオブジェクトをサーバー側で更新し、それを端末へ伝播させます。いずれの場合も、こちら側は1件のレコードを触るだけで、そのパスを保持するすべての端末へ更新が行き渡ります。
顧客の端末で更新が発火する条件
すべての変更がボタンを押した瞬間に始まるわけではありません。データを起点にするものもあれば、状況を起点にするものもあります。代表的な例は次のとおりです。
ポイント・ランクの変更
顧客がポイントを獲得し、しきい値を超え、シルバーからゴールドへとランクが上がったとき。ロイヤリティのロジック側がその記録を更新すると、パスには新しい残高やランクが反映され、サイレントプッシュがそれを顧客の端末に届けます。「ゴールドランクおめでとうございます」といったメールを必ず送る必要はありませんが、その瞬間を演出したい場合は別途送ることもできます。
位置情報による表示
これはデータの書き換えとはまったく別のものです。パスには位置情報を持たせることができ、顧客がその場所の近くにいることをスマートフォンが検知すると、端末側が自動でロック画面にパスを表示します。店舗の近くを通りかかると、コーヒーのカードが浮かび上がる、という具合です。場所の設定はパス発行時に一度行うだけで、あとはスマートフォン側がすべて処理し、こちら側からのプッシュは発生しません。
有効期限切れとグレーアウト
クーポンの期限が切れる。チケットの日付が過ぎる。そうしたときにパスを「失効」とマークする更新を送ると、ウォレットはそれをグレーアウト表示にし、静かに壊れているのではなく、明らかに終了したものとして見せます。バーコードがなぜスキャンできないのか顧客が悩むことがなくなるため、サポート対応の手間を1件減らせる小さな工夫です。
顧客がオフラインだった場合
ここからが正直に伝えるべき部分です。過大な期待を持たせると、あとでトラブルの原因になります。
更新をプッシュした瞬間に顧客のスマートフォンがオフラインだった場合、その更新はその時点では届きません。魔法のような仕組みはなく、サイレントプッシュは接続できない端末を起こすことはできません。
救いになるのは、パスが自分のホームサーバーの所在地を知っているという点です。次にスマートフォンがオンラインに戻ってウォレットが確認を行うとき、あるいは次に顧客がパスを開いたとき、端末は最新版を取得して追いつきます。つまり更新が失われるのではなく、端末が受け取れるタイミングまで先送りされるだけです。
実務上のルールとして、ウォレット更新は信頼性が高いものの、機内モードの端末に対する「即時保証」ではありません。「いずれ正しくなる」設計を前提にし、「常に即時」を前提にしないことが大切です。1時間で終わるフラッシュセールのように時間的制約が厳しい施策では、サイレント更新だけに頼らず、配信完了を確認できるチャネルと組み合わせてください。
マーケティング担当者にとって重要な理由(開発者だけの話ではない)
裏側の仕組みを取り除くと、残るのはこういうことです。顧客のポケットにあるカードは、発行した瞬間から古くなっていく印刷物ではなく、こちら側がコントロールできる生きた接点だということです。
それが何をなくすかを考えてみてください。価格改定のたびにカードを再発行するキャンペーンは不要になります。「古いクーポンを削除して新しいものをダウンロードしてください」という、リストの半分が無視するメールも不要です。ポイントが少し動くたびに通知を送る必要もなく、それはまさに顧客に「ミュートする」ことを覚えさせてしまう類のノイズです。ソースを編集すれば、顧客のポケットの中身が更新される——それでいて顧客の忍耐を1秒も消費しません。
これがウォレットパスと静的な素材との違いです。一方はチャネルであり、もう一方はただのPDFです。
すべてのカード保有者に価格やポイントの変更を手作業で知らせるのはスケールしません。Pushwooshはアプリ不要、通知疲れも起こさず、静かに更新を届けます。Wallet Passesの仕組みをぜひご覧ください。
よくある質問
いいえ。パスの内容更新は既定でサイレントに行われるため、ポイント残高や有効期限が変わっても、顧客の画面には何も表示されません。カード裏面に新しいオファーが載るときなど、任意で目に見えるメッセージを添えることもできますが、通常のデータ更新が顧客の手を止めることはありません。
更新は待機します。パスは自分のサーバーアドレスを保持しているため、端末がオンラインに戻ったとき、または次に顧客がパスを開いたときに、ウォレットが最新版を取得して同期します。変更が消えることはなく、端末がサーバーに届く状態になったタイミングで反映されるだけです。PassKit Webサービスのエンドポイントや APNs の設定、Google Wallet APIのオブジェクトといった開発者向けの詳細は、
Pushwooshのドキュメントにまとまっています。