移动应用与忠诚度 CRM：为什么应该一起构建

常见的顺序是这样的：零售商先建一个电商网店，之后再委托开发移动应用，再往后又加上忠诚度项目，而且忠诚度项目往往交给另一家完全不同的第三方供应商。每个项目单独来看，都把自己的问题解决得不错。麻烦出在接缝处：顾客的积分余额在应用和网站之间不同步，兑换规则被实现了两遍、慢慢变得不一致，每推出一个新的忠诚度功能，都要为网店做一遍，再为应用做一遍。这些都不是哪一家供应商的错。三个从一开始就没打算共用后端的系统，事后被硬接在一起，结果就是这样。

Guardian Malaysia 没有走这条路，值得仔细看看原因。

一个后端，而不是三个

Guardian 与我们合作 Adobe Commerce 已经超过 8 年。当移动应用和 MyGuardian Rewards 忠诚度项目被提上日程时，它们并没有被规划成两个附加在现有网店上的独立项目。这款应用构建在 Adobe Commerce 的无头架构上，也就是说，网店、应用和忠诚度层都建立在同一个后端和同一份顾客数据之上，而不是三个需要事后持续同步的系统。

事后拼接

网站

各自的顾客数据

移动应用

各自的顾客数据

忠诚度

各自的顾客数据

事后再去同步

一起构建

网站

移动应用

忠诚度

一个后端，一份顾客记录

每个渠道上都是同一个数字

落到实际层面，这意味着会员的积分余额、会员等级和可用奖励，无论在应用里看还是在网站上看，都是同一个数字。因为数字本来就只有一个，而不是两个系统各存一份、定期对账。这也意味着，一个新的忠诚度功能只需要基于共享后端构建一次，就能立即在所有渠道上线，而不是先为应用做一遍，再为网页重做一遍，什么时候上线全看各个团队什么时候排得上。

这种统合在结果上体现为什么

自整合式忠诚度应用上线以来，MyGuardian Rewards 的会员数仅在前 47 天内就增长了近 90%，此后一年内增长超过 250%。这样的增长速度，不只是因为忠诚度机制本身有吸引力，也是因为摩擦很小：顾客无论是在门店、在网站还是在应用里注册，加入的都是同一个项目、用的是同一个账户。他们不需要在两套忠诚度体系之间做选择，也不会事后发现自己在门店的注册并没有同步到应用里。

这种做法所避开的失败模式

我们也做过事后拼接的版本：有些客户在原本各自独立的应用和网站上，后来才加上忠诚度项目。几乎每一次，都会出现两个问题。

跨系统匹配顾客身份是个实实在在的难题，绝不是小细节。 移动应用通常用手机号作为账户标识，因为在手机上，基于 OTP（一次性验证码）的注册是最省事的方式。网站则更多使用电子邮箱。当应用和网站是作为两个独立系统构建的，这两种标识从设计上就没打算互相对应，于是同一个人最终变成了两条不同的顾客记录，中间没有任何可靠的键能把它们关联起来。事后要修复，通常意味着请顾客自己动手合并网页和应用的账户。这多出来的一步，恰恰在你最希望注册毫不费力的地方增加了摩擦，而且相当一部分顾客根本懒得去完成。另一种办法，是用姓名和其他信息做模糊匹配来自动合并记录，但这有可能把两个不同的人合并在一起，或者该合并的两个人没合并上，后果更糟。

只在某个渠道发放的奖励，会悄悄蚕食不发奖励的那个渠道。 如果应用里能赚积分而网站上不能（或者反过来，当忠诚度项目最初是一个只针对应用的计划时，这种情况同样常见），顾客会做出理性的反应：把购买转向真正给他们奖励的那个渠道。这不是假设性的风险，而是可以预见的结果，因为你给了顾客一个偏好某个渠道的金钱理由，而这个理由跟哪个渠道真正更好地服务他们毫无关系。零售商可能在从未做过这个决定的情况下，就不知不觉地把顾客训练成了放弃网站、改用应用，或者正好反过来。

除了这两个问题，同样的事后拼接架构还往往带来同步延迟（在一个渠道赚到的积分要过一段时间才出现在另一个渠道）、兑换规则实现两遍并逐渐走样，以及功能要在两套独立代码库而不是一套上推进，导致上线变慢。但真正改变顾客行为和营收的，是身份匹配问题和渠道蚕食风险这两个，而不只是后端整不整洁的问题。

在委托任何一个项目之前要确认什么

如果您正在规划移动应用和忠诚度项目，哪怕两者不在同一时间进行，在确定供应商或架构之前，有几个问题值得先问清楚：

如果您正在规划移动应用或忠诚度项目，尤其是两者都在规划，欢迎与我们聊聊移动应用开发或忠诚度 CRM。