モバイルアプリとロイヤルティCRM：なぜ一緒に構築すべきなのか

よくある順序はこうです。小売企業がまずEコマースストアを構築し、その後にモバイルアプリを発注し、さらにその後でロイヤルティプログラムを追加する。しかもロイヤルティは、まったく別の3社目のベンダーに任せることも少なくありません。それぞれのプロジェクトは、単体で見れば自分の課題を十分に解決しています。問題が表れるのは継ぎ目です。顧客のポイント残高がアプリとウェブサイトの間でずれる。特典交換のルールが二重に実装され、次第に食い違っていく。ロイヤルティの新機能を出すたびに、ストアフロント向けに一度、アプリ向けにもう一度と、2回作らなければならない。どれも特定のベンダーの落ち度ではありません。そもそもバックエンドを共有するよう設計されていなかった3つのシステムを、後からつなぎ合わせると、こうなるのです。

Guardian Malaysiaはその道を選びませんでした。なぜそうしたのかを順に見ていく価値があります。

バックエンドは3つではなく1つ

Guardianは8年以上にわたり、当社がAdobe Commerceのパートナーを務めているお客様です。モバイルアプリとロイヤルティプログラム「MyGuardian Rewards」の構想が持ち上がったとき、これらは既存のストアに後付けする別々の取り組みとしては計画されませんでした。アプリはAdobe Commerceのヘッドレスアーキテクチャ上に構築されています。つまり、ストアフロント、アプリ、ロイヤルティのレイヤーがすべて同じバックエンドと同じ顧客データの上に載っており、後から同期を取り続けなければならない3つのシステムにはなっていない、ということです。

後付けで連携

ウェブサイト

個別の顧客データ

モバイルアプリ

個別の顧客データ

ロイヤルティ

個別の顧客データ

後から同期を取り続ける

最初から一体で構築

ウェブサイト

モバイルアプリ

ロイヤルティ

1つのバックエンド、1つの顧客レコード

どのチャネルでも同じ数字

実務上それが意味するのは、会員のポイント残高、ランク、利用できる特典が、アプリで見てもウェブサイトで見ても同じ数字になるということです。2つのシステムがそれぞれ自分のコピーを持って定期的に突き合わせているのではなく、数字がそもそも1つしかないからです。また、ロイヤルティの新機能は共有バックエンドに対して一度作れば、すぐにすべてのチャネルで使えるようになります。アプリ向けに作り、次にウェブ向けに作り直し、それぞれのチームの手が空いたときに対応する、という形にはなりません。

その一体化が成果にどう表れたか

統合型のロイヤルティアプリをリリースして以降、MyGuardian Rewardsの会員数は最初の47日間だけで約90%増加し、その後の1年間で250%以上増加しました。このペースの成長は、ロイヤルティの仕組みそのものに魅力があるからだけではありません。摩擦が小さいことの結果でもあります。店頭で登録しても、ウェブサイトで登録しても、アプリで登録しても、顧客は同じアカウントで同じプログラムに参加しています。2つのロイヤルティシステムのどちらかを選ばされることも、店頭での登録がアプリに引き継がれていないと後から気づくこともありません。

この構成が避けている失敗パターン

当社は後付け型も構築してきました。別々に作られた既存のアプリとウェブサイトに、後からロイヤルティプログラムを追加したお客様の案件です。そこでは、ほぼ毎回2つの問題が表れます。

システムをまたいだ顧客IDの照合は、些細な事柄ではなく本当に厄介な問題です。 モバイルアプリでは、電話番号をアカウントの識別子にするのが一般的です。スマートフォンではOTP（ワンタイムパスワード）による登録が最も手間の少ない方法だからです。一方、ウェブサイトではメールアドレスを使うことの方が多くなります。アプリとウェブサイトが別々のシステムとして作られている場合、この2つの識別子は突き合わせることを前提に設計されていません。その結果、同じ1人の人間が、確実に結び付けるキーを持たない2つの別々の顧客レコードになってしまいます。これを後から直すとなると、たいていは顧客自身にウェブとアプリのアカウントを手作業で統合してもらうことになります。登録を最も手軽にしたいまさにその場面で手間を増やす追加の一手間であり、一定の割合の顧客はわざわざ完了させようとしません。もう1つの方法、つまり氏名やその他の情報のあいまい一致でレコードを自動照合しようとすると、別人の2人を統合してしまったり、統合すべき2人を統合し損ねたりするリスクがあり、こちらの方がもっと悪い結果になります。

特定のチャネルだけの特典は、特典のないチャネルを静かに侵食します。 アプリではポイントが付くのにウェブサイトでは付かない場合（あるいはその逆の場合。ロイヤルティプログラムがもともとアプリ専用の施策として始まったときには、同じくらいの頻度で起きます）、顧客は合理的に反応します。実際に特典をくれる方のチャネルへ、購入を移していくのです。これは仮定のリスクではなく、予測できる結果です。どちらのチャネルが本当に自分の役に立つかとは無関係に、一方のチャネルを選ぶ金銭的な理由を顧客に与えているのですから。小売企業は、そう望むと決めたことなど一度もないまま、気づけば顧客にウェブサイトを捨ててアプリへ移るよう、あるいはその逆をするよう、意図せずしつけてしまっていることがあります。

この2つのほかにも、同じ後付け型の構成では、同期の遅れ（あるチャネルで貯めたポイントが別のチャネルに反映されるまで時間がかかる）、特典交換のルールの二重実装とその食い違い、そして1つではなく2つの別々のコードベースにまたがることによる機能展開の遅れも起きがちです。それでも、顧客IDの照合の問題とチャネル間の侵食のリスクの2つこそが、バックエンドの整理整頓にとどまらず、顧客の行動と売上を実際に変えてしまうものです。

どちらかのプロジェクトを発注する前に確認すべきこと

モバイルアプリとロイヤルティプログラムを計画しているなら、たとえ時期がまったく同じでなくても、ベンダーやアーキテクチャを決める前に問うておく価値のある質問がいくつかあります。

モバイルアプリかロイヤルティプログラムのどちらかを計画しているなら、そして特に両方を計画しているなら、モバイルアプリ開発またはロイヤルティCRMについて、ぜひご相談ください。