零售超市现在知道访客购买了什么,并能提出定制推荐

这个使用位置追踪器分析访客行为的试点项目在两家大型超市实施,这些超市客流量很大。IT 部门负责人代表超市并提供了安装和维护试点项目的全部权限。

因此我们获得了将我们的系统外部连接到超市 FTP 和其服务器系统的许可,所有超市收据都记录在那里,使我们能够使用这些记录。

这个想法

关键的想法是向超市访客发送有针对性的促销优惠。这些可以是长期或短期的优惠,每当超市需要尽快处理某些选定产品时就会发出。

最初,主要任务是从每个买家的收据中获取信息。后来这些信息形成了数千名商店客户的通用产品偏好数据库。

换句话说,买家会选择一系列商品,在收银台付款后,30-40 分钟内我们就会收到关于他们购买的信息。

技术想法是在零售空间入口处直接安装设备。这里的意图是追踪常客的进入情况。

iBeacon 超市试点背后的想法

项目实施流程

项目实施流程
  1. 访客进入商店。他的卡片被入口处的读卡器扫描,但事实证明,我们对他一无所知——没有任何信息。但关键在于,这个“干净”的访客在购买后,我们的云端系统会在最多半小时内更新该访客数据——我们就能感受到他的购买偏好。
  2. 然后我们处理这些信息并将其保存在通用数据库中。我们正在创建一个大型用户档案组,使我们能够处理大数据。
  3. 例如,如果客户 X 购买了某种品牌的牛奶,然后又购买了同一制造商生产的酸奶,那么这被识别为乳制品组的一部分。反过来,这个乳制品组可以与其他商品组兼容,原因各不相同(这些信息由我们分析)。这意味着我们可以向买家 X 发送烟熏肉的优惠,基于我们广泛的分析,我们可以确信客户会以 70% 的概率购买这种肉。
  4. 在检查了数百万张收据后计算出概率。通过这种方式,我们确定了购买之间的某些联系,这对最大化销售非常重要。
  5. 整个过程的最后阶段是优惠本身,即促销。几天后客户 X 再次光顾商店时,我们已经知道要向他们发送什么优惠(当然,前提是市场部门已准备好了这样的提案)。

通知服务器持续从营销推广服务器接收数据,因此所有需要展示给特定访客群体的超市新优惠都会在正确的时间部署。

项目实施流程,第二阶段

服务背后的营销

市场部门向我们发送大约 2000 件商品的数据。通常,市场部门会为某些商品设定广告时间范围。

例如,买家 Y 进入商店,考虑到我们对其过去购买行为的分析,我们可以得出结论,他们喜欢葡萄酒和薯片。我们将此信息传递给营销推广服务器。然后市场中心的专业人员查看是否有任何产品优惠可供为 Y-访客广告。中心形成广告消息文本,向通知服务器发出信号,最终向 Y 发送带有广告优惠的消息。关键是营销服务知道要发送什么优惠。简单来说,一个优惠可能针对牛奶爱好者,而另一个则可能发送给鱼粉。

营销推广服务器基于 Node.js 和 MongoDB 运行。它还保存了超市分享的所有关于广告公司的信息。

接下来是频率算法发挥作用——我们向谁展示消息更频繁,向谁展示得更少?为了避免对那些经常收到消息的买家造成骚扰,我们稍微放慢节奏,只向很少收到我们消息的人发送。

服务背后的营销

技术实现

在超市通道上方安装了高穿透力读卡器;最初我们使用 RQ3 RFID 读卡器。超市访客拥有带有唯一 RFID 标签的忠诚度卡片。该卡片本身在购买达到一定金额或根据任何其他商业计划时会在收银台应用。

结果,当潜在买家进入超市时,我们已经掌握了他们的信息。

这个想法是立即将所有商业商店优惠转移到手机和应用程序上。然而,这会显著减少能够使用它的访客数量。这种情况提高了门槛:我们需要实施最佳解决方案,使老年人也能使用商业邮件。因此,超市给我们的挑战是至少覆盖商店内 60% 的站立客户。

因此,大规模通信渠道应基于短信或 USSD 通知。

访客进入商店并用特殊读卡器扫描其卡片。我们的服务器随后会收到一个信号(通过基于 Node.js 的应用程序,后来被 Python 替换),提出是否在这种情况下推广有用的问题。客户是否有模式?……如果对买家有优惠,他们将收到一条短信。

所有数据存储在哪里?

我们使用 CouchDB 进行数据存储。后来我们将系统更改为 Couchbase 以更加方便。

微服务的工作方式如何组织?处理数据,即所谓的用户档案、模板和模式——该模块直接与数据库交互并分析其数据。这里我们使用了逻辑 + Python + Couchbase 的组合。也就是说,安装了 MTP 协议——外部服务与之通信,同时安装了一个基于 Node.js 的常规外部 Restfull API。它接收来自 Arduino 服务器的标签请求,这些请求通过 3G 通道传递。RestFull API 的任务只是获取数据,除此之外什么都不做。在这里,它通过 MTP 协议将信息传输到存储。

换句话说,有某些任务,与数据库交互的服务会接收它们作为处理队列(que),所有任务都会同步处理。

通知服务器连接了 Twilio 和推送通知服务器。它的任务是获取手机号码或移动设备的 UID 并发送指定文本。

我们有一个后台连接到 Python 服务,该服务定期连接到 FTP Node.js 服务器,并上传数十万条记录和额外的哈希值。大约一百万条记录被上传并存储在 Couchbase 中。每小时处理一定量的数据以创建具有明确客户偏好的用户组。

所有数据存储在哪里

集成和测试的下一阶段

在第二开发阶段,我们需在不同区域安装更多读卡器以发送优惠包。超市设定的关键目标是为推广者提供额外的通信渠道,而无需在交易空间上增加广告负担。

超市管理层希望看到这种广告活动与替代营销方法(例如横幅、传单等)相比的效果如何。

我们需要跟踪广告信息对购买结果的影响。例如,在某个时间段内向约 10,000 名潜在客户发送了假设文本“买香肠”的广告信息。有必要计算在此期间售出了多少香肠,与之前的结果进行比较。根据获得的结果,我们可以得出某些结论。这里可以应用互联网中的在线按行动付费模型作为类比,即客户只在用户/访客执行特定操作时才支付。

为了测试这一阶段,给 20 名超市访客分配了 RFID 标签,他们的任务是模拟普通超市访客的行为。

总结

虽然这听起来像未来主义,但以访客为导向的推荐/促销将在未来一年出现在所有大型零售超市中。亚马逊已经证明许多零售过程可以通过他们的 Amazon Go 商店自动化。访客的关注和忠诚度是现代公司现在竞争的“金库”。