この位置追跡器を使用した訪問者行動分析のパイロットプロジェクトは、大規模な店舗流量を持つ2つのスーパーマーケットで実装されました。IT部門長がスーパーマーケットを代表し、パイロットプロジェクトのインストールと保守に必要なすべての許可を提供しました。
したがって、私たちはシステムをスーパーマーケットFTPおよびそのサーバーシステムに外部接続する許可を得ました。これらのシステムにはスーパーマーケットのすべてのチェックが記録されており、これらの記録を使用できるようになりました。
アイデア
主なアイデアは、スーパーマーケットの訪問者にターゲット型のプロモーションオファーを送ることでした。これらは長期または短期的なオファーであり、スーパーマーケットが特定の製品を即座に売却する必要があるときに送信されました。
最初の主なタスクは、各購入者のチェックから情報を取得することでした。その後、この情報は数千人の店舗顧客の商品好みの共通データベースを形成しました。
言い換えれば、購入者は商品の範囲を選択し、レジで支払いを行い、30〜40分後にはその購入に関する情報がサービスに届きます。
技術的なアイデアは、小売スペースの入口に直接設備を設置することでした。この意図は、定期的な顧客の入場を追跡することでした。
プロジェクト実装フロー
- 訪問者が店舗に入ります。彼のカードは入口のリーダーでスキャンされますが、残念ながら私たちは彼について何も知りません—情報がありません。しかし、この「クリーン」な訪問者が購入をした後、私たちのクラウドは最大30分以内にその訪問者データで更新され、購入の傾向を感じることができます。
- その後、私たちはこの情報を処理し、共通データベースに保存します。これにより、大規模データを扱うことができるユーザーのプロファイルの大きなグループを作成します。
- 例えば、顧客Xが特定のブランドのミルクを購入し、その後同じメーカーで製造されたヨーグルトを購入した場合、これは乳製品グループの一部と認識されます。この乳製品グループは、さまざまな理由で他の商品グループと互換性を持つことができます（情報は私たちが分析します）。つまり、例えば、Xに煙肉のオファーを送信でき、広範な分析に基づいて、顧客がこの肉を70％の確率で購入すると確信できます。
- 確率は数百万のチェックを検討した後に計算されます。このようにして、購入間の特定の相互関係を特定し、売上を最大化するために重要でした。
- このプロセスの最終段階はオファーそのもの、つまりプロモーションです。数日後、顧客Xが店舗に訪問したとき、すでに彼らに送信するべきオファーを知っています（もちろん、マーケティング部門がそのような提案を準備している場合）。
通知サーバーは、マーケティングプロモーションサーバーからデータを停止せずに受信し、特定のグループの訪問者に表示する必要があるスーパーマーケットの新しいオファーが適切なタイミングで展開されます。
サービスのマーケティング
マーケティング部門は約2000商品のデータを私たちに送信します。通常、マーケティング部門は特定の商品グループを広告する期間を設定します。
例えば、顧客Yが店舗に入り、過去の購入行動の分析に基づいて、彼がワインとチップスが好きであることがわかります。この情報をマーケティングプロモーションサーバーに転送します。その後、マーケティングセンターの専門家は、Y訪問者に広告できる商品オファーがあるかどうかを確認します。センターは広告メッセージのテキストを作成し、通知サーバーにシグナルを送信し、最後にYに広告オファーを含むメッセージを送信します。マーケティングサービスはどのオファーを送信するかを知っています。簡単に言うと、一つのオファーはミルク好き向けに設計され、別のオファーは魚ファン向けに送られます。
マーケティングプロモーションサーバーはNode.jsとMongoDBに基づいて動作しました。また、スーパーマーケットが広告会社について共有したすべての情報を保持しました。
次に頻度アルゴリズムが登場します—どの人にメッセージをより頻繁に表示し、どの人に少ない頻度で表示するのでしょうか？私たちが頻繁にメッセージを送った顧客に迷惑をかけないように、少し遅くして、私たちのメッセージを受け取ったことが少ない人にのみ送信します。
技術的実装
スーパーマーケットのレーン上には高感度リーダーが設置されました。当初はRQ3 RFIDリーダーを使用しました。スーパーマーケットの訪問者は、ユニークなRFIDタグを持つロイヤリティカードを持っています。カード自体は特定の金額で購入するときや、他の商業プログラムに従ってレジで使用されます。
結果として、潜在的な購入者がスーパーマーケットに入ると、すでにその情報を手に入れることができます。
アイデアは、すべての商業店舗のオファーを携帯電話やアプリに即座に転送することでした。しかし、これはそれを使用できる訪問者の数を大幅に減らすことになります。この状況は基準を高めました：高齢者も商業メールを使用できるようにするための最良の解決策を実装する必要がありました。したがって、スーパーマーケットからの課題は、少なくとも60％の立っている顧客をカバーすることでした。
従って、大規模な通信チャネルはSMSまたはUSSD通知に基づくものとしました。
訪問者が店舗に入り、そのカードが特別なリーダーでスキャンされます。その後、私たちのサーバーはシグナルを受け取ります（Node.jsベースのアプリケーションによって、Pythonに置き換えられました）、このケースでプロモーションが役立つかどうかを判断します。顧客にパターンがあるかどうか... オファーがあれば、SMSが送信されます。
すべてのデータはどこに保存されましたか？
データストレージにはCouchDBを使用しました。その後、より利便性のためにシステムをCouchbaseに変更しました。
マイクロサービスの作業はどのように組織化されましたか？データ処理、つまりユーザーに属するプロファイル、テンプレート、パターン—このモジュールは直接データベースと連携し、そのデータも分析しました。ここではロジック+Python+Couchbaseの組み合わせを使用しました。つまり、MTPプロトコルがインストールされており、外部サービスがそれを介して通信し、通常の外部Restfull API（Node.jsベース）がインストールされました。これはArduinoサーバーから届くタグからのすべてのリクエストを受け取りました。RestFull APIのタスクはデータを取得することだけでした。ここではMTPプロトコルを介して情報をストレージに転送しました。
言い換えれば、特定の数のタスクがあり、データベースと連携するサービスがそれらを処理するキュー（que）として受け取りました。すべてのタスクは同期的に処理されました。
通知サーバーはTwilioおよびプッシュ通知サーバーに接続されていました。そのタスクは、携帯電話番号またはモバイルデバイスのUIDを取得し、指定されたテキストを送信することでした。
Pythonサービスとのバックグラウンド接続があり、定期的にFTP Node.jsサーバーに接続し、数十万のレコードと追加のハッシュをアップロードしました。約100万のレコードがCouchbaseにアップロード・保存されました。1時間ごとに一定量のデータを処理し、顧客の明確な好みを持つ特定のユーザーグループを作成しました。
統合とテストの次の段階
第二開発段階では、より多くのリーダーを異なるゾーンに設置してオファーの束を送信する必要がありました。スーパーマーケットが設定した主な目標は、販売空間への広告負荷なしでプロモーターに追加の通信チャネルを提供することでした。
スーパーマーケット管理は、この広告キャンペーンが代替マーケティング手法（例えば、バナー、リーフレットなど）と比較してどれほど効果的であるかを見たいと考えていました。
広告メッセージが購入結果に与える影響を追跡する必要がありました。例えば、「ソーセージを買う」という仮定的なテキストの広告メッセージは、特定の期間に約1万の潜在顧客に送信されました。この期間中に売れたソーセージの数量を前回の結果と比較して計算する必要がありました。得られた結果に基づいて、特定の結論を導き出すことができました。インターネットのオンラインコスト・パー・アクションモデルに類似したものです。クライアントはユーザー/訪問者が特定の行動を実行した場合のみ支払います。
この段階をテストするために、20人のスーパーマーケット訪問者にRFIDタグが与えられ、彼らのタスクは通常のスーパーマーケット訪問者の行動を模倣することでした。
まとめ
このように未来を感じるかもしれませんが、来年にはすべての大規模小売スーパーマーケットで訪問者指向の推奨/プロモーションが現れるでしょう。Amazonはすでに多くの小売プロセスを自動化できることを証明しました。 Amazon Go 店舗。訪問者の注意と忠誠心は、現代企業が今競争している「金のchest」です。