ロイヤリティカードの作り方を調べると、見つかるのはたいてい2種類の記事です。Apple Walletだけで話が終わるものと、Google Walletだけで話が終わるもの。どちらか一方だけを実行すれば、施策としては半分しか完成しません。日本の顧客のうちAndroidを使う層は、自社が対応していないウォレットを持ち歩いているだけだからです。
本記事は最初から両方をカバーする内容です。顧客がどちらのプラットフォームを使っているかによって、ロイヤリティカードが届くかどうかが左右されるべきではないからです。
デジタル会員証の作り方（2系統を別々に作らずに済む方法）
ネイティブで構築する場合、Apple WalletとGoogle Walletはまったく別の技術経路です。Appleは PassKit を通じて署名済みの .pkpass ファイルを使い、Googleは自社のWallet APIを通じてパスオブジェクトを使います。それぞれ独自の証明書と独自の更新パイプラインで動くため、多くの会社では両対応が「1件」ではなく「2件」のバックログチケットになってしまいます。
ノーコードのパスビルダーを使えば、これを1つのワークフローにまとめられます。ダッシュボード上でカード——項目、色、バーコードなど——を一度デザインすれば、プラットフォーム側がその1つのデザインからApple版とGoogle版の両方を生成・署名します。誰も気づかないうちにズレていく2つのカード定義を維持するのではなく、維持するのは1つだけです。
小規模店舗向けロイヤリティアプリ：そもそも必要か
小規模店舗向けの専用ロイヤリティアプリは一見すると完全な解決策に思えますが、多くの小さなチームはそのコストを見誤りがちです。多くの顧客が完了させないダウンロード、App StoreとPlay Storeの継続的な保守、そしてどちらかのプラットフォームがルールを変えるたびに必要になる改修です。
ウォレットパスは同じ中核機能——ポイント残高、ランク、スキャン用バーコード——を、ダウンロードを一切求めずに実現します。ほとんどの小規模店舗にとって、この比較はいつもウォレットパスに軍配が上がります。アプリが見合うのは、パスでは本当に実現できない機能——アプリ内注文やソーシャルフィードなど——が必要な場合であり、ポイントの記録と再来店の後押しのためだけなら、それは不要な重荷です。
手順:1枚のカードを両ウォレットへ
-
カードを一度だけデザインする
ブランディング、色、ロゴ、そして重要な項目——プライマリー項目としてポイント残高またはスタンプ数、セカンダリー項目として有効期限や会員IDなど——を設定します。POSレジがスキャンするバーコードまたはQRコードの値も追加します。このデザイン工程は、対応するプラットフォームの数にかかわらず一度だけ発生します。
-
AppleとGoogleへ同時に公開する
同じダッシュボードから、Apple WalletとGoogle Wallet両方のバージョンを生成します。署名や形式の違いはプラットフォーム側が処理するため、公開するのは1つのインストールリンクと1つのQRコードだけで、顧客の端末に応じて正しいパス形式へ自動で解決されます。
-
両プラットフォームでインストールリンクをテストする
iPhoneでリンクを開き、カードのプレビューとApple Walletへの追加が正しく行われることを確認したら、Android端末でも同様にGoogle Walletで確認します。バーコードがスキャンできること、ブランディングが想定どおり表示されること、位置情報アラートが範囲内で発火することをチェックします。片方では動くがもう片方では壊れているカードは、両対応で構築する意味そのものを失わせます。
両バージョンを同期させ続ける
Apple用とGoogle用の2つのパスを別々に構築・維持すると、新しいランクの追加、リブランディング、還元しきい値の変更のたびに作業が2倍になります。Pushwoosh Wallet Passesは両方で動く1枚のカードを発行するため、一度行った更新はApple・Google問わず保存済みのすべての端末に届き、2つ目のビルドを維持する必要はありません。
両ウォレットでロイヤルティ施策を展開する
Pushwoosh Wallet Passesは、1つのダッシュボードからApple WalletとGoogle Wallet向けに1枚のカードを構築するため、顧客がどちらの端末を持っていても同じ体験を届けられます。同じ仕組みが飲食店の会員プログラムや、より広い小売業のロイヤリティ施策でどう機能するかもあわせてご覧ください。
