Цей пілотний проект з використанням трекерів місцезнаходження для аналізу поведінки відвідувачів був реалізований у двох супермаркетах із великою кількістю потоку покупців. Голова IT-відділу представляв супермаркет і надав усі дозволи для встановлення та підтримки пілотного проекту.
Тому ми мали дозвіл на зовнішнє підключення нашої системи до FTP супермаркету та їхніх серверних систем, де записувалися всі чеки супермаркету, що дозволяло нам використовувати ці записи.
Ідея
Основна ідея полягала у надсиланні цільових рекламних пропозицій відвідувачам супермаркету. Ці можуть бути довгостроковими або короткостроковими пропозиціями, надсиланими у будь-який час, коли супермаркету потрібно швидко реалізувати певні товари.
Спочатку головною задачею було отримання інформації з кожного чека покупця. Потім ця інформація формувала загальну базу даних уподобань продуктів для тисяч клієнтів магазину.
Іншими словами, покупець обирав набір товарів, оплачував їх на касі, і через 30-40 хвилин ми отримували інформацію про їхні покупки у нашому сервісі.
Технічна ідея полягала в установці обладнання безпосередньо на вході до роздрібного простору. Мета полягала у відстеженні входів регулярних клієнтів.
Потік реалізації проекту
- Відвідувач заходить до магазину. Його картку сканують на вході, але, як виявляється, ми нічого про нього не знаємо – немає інформації. Але саме ця «чиста» відвідувачка здійснює покупку, наш хмара оновлюється протягом півгодини з цими даними про відвідувача – і ми отримуємо відчуття його покупельних уподобань.
- Потім ми обробляємо цю інформацію та зберігаємо її в загальній базі даних. Ми створюємо велику групу профілів користувачів, що дозволяє нам працювати з великими обсягами даних.
- Наприклад, якщо клієнт 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 – зовнішні сервіси спілкувалися з ним, а також був встановлений регулярний RESTful API на основі Node.js. Він отримував усі запити від тегів, що надходили з наших серверів Arduino, які проходили через 3G-канали. Завдання RESTful API полягала просто в отриманні даних і нічого більше. Тут він передав інформацію через протокол MTP до сховища.
Іншими словами, було певне число завдань, і сервіс, що працював з базою даних, отримував їх як чергу для обробки (que), де всі завдання оброблялися синхронно.
Сервер сповіщень був підключений до Twilio, а також до сервера push-сповіщень. Його завдання полягала у отриманні номера мобільного телефону або UID мобільного пристрою та надсиланні визначеного тексту.
У нас було підключення до фонової служби Python, яка періодично з’єднувалася з FTP-серверами Node.js і завантажувала сотні тисяч записів та додаткових хешів. Близько мільйона записів було завантажено та збережено в Couchbase. Раз на годину він обробляв певну кількість даних, щоб створити певну групу користувачів із чіткими уподобаннями клієнтів.
Наступний етап інтеграції та тестування
На другому етапі розробки ми повинні були встановити більше читачів у різних зонах, щоб надсилати набір пропозицій. Основна мета, яку поставила супермаркет, полягала у наданні промо-партнерам додаткових каналів зв'язку без навантаження реклами на торговий простір.
Керівництво супермаркету хотіло побачити, наскільки ефективно ця рекламна кампанія буде порівняно з альтернативними методами маркетингу (наприклад, банери, листівки тощо).
Нам потрібно було відстежувати, як рекламне повідомлення впливає на результат покупки. Наприклад, рекламні повідомлення з умовним текстом «купити салямі» були надіслані приблизно 10 тисячам потенційних клієнтів протягом певного періоду. Було необхідно розрахувати, скільки салямі було продано під час цього періоду порівняно з попередніми результатами. Залежно від отриманих результатів ми могли зробити певні висновки. Аналогом онлайн-моделі Cost-Per-Action в інтернеті можна було застосувати тут, де клієнт платить лише за конкретні дії, які виконані користувачами/відвідувачами.
Для тестування цього етапу 20 відвідувачів супермаркету було наділено RFID-тегами, і їхнє завдання полягала у моделюванні поведінки звичайних відвідувачів супермаркету.
Підсумок
Хоча це може здаватися футуристичним, рекомендації/промо-акції, орієнтовані на відвідувачів, з’являться у кожному великому роздрібному супермаркеті в наступному році. Amazon вже довели, що багато процесів у роздрібній торгівлі можна автоматизувати за допомогою їхніх Amazon Go магазинів. Увага та лояльність відвідувачів — це «золотий скарб», за яким сьогодні конкурують сучасні компанії.