电商实务
Friends & Family 机制为什么能带来推荐式增长
某个忠诚度应用有 60% 的新注册,直接来自 Friends & Family 邀请。这套机制如何在头两个月里跑赢一个运营多年的成熟项目。

Danny Khow,联合创始人兼董事总经理阅读约 4 分钟
大多数忠诚度项目的增长路径都一样:注册、攒积分,也许哪天会员想起来了,会顺口告诉朋友一声。Friends & Family 机制改变的正是这一点,它把邀请本身做成项目运转方式的一部分,而不是事后从营销那边补挂上去的东西。我们想知道这在增长数字上到底会不会体现出来,于是把自己做过的两个忠诚度项目放在一起比较:一个带这套机制,一个不带。
把这套机制说明白
Friends & Family 的分组允许一位会员把其他人邀请进同一个组,一起累积积分。不再是单个账户孤立地攒分,而是一个家庭或一群朋友共同累积进度。这一个设计选择改变了底层的动机:邀请别人不再只是帮个忙,而是让自己的积分余额涨得更快的最快途径。会员被驱动去拉人,而不只是去兑换。
两个真实项目的匿名对比
为了对两位客户都公平,这里不点出任何一个项目的名字;但背后的数据是真实的。
项目 A 是一个运营多年、已经成熟的零售忠诚度项目,不含 Friends & Family 机制。两年间,它以稳定持续的日均注册速度建起了庞大的会员基数,背后是一个早已广为人知、受信任的零售品牌,还有可以直接触达的既有客群。
项目 B 是一个新上线的忠诚度应用,从第一天起就围绕 Friends & Family 机制来设计,没有任何可迁移进来的既有数字会员基数。上线头两个月,它的日均注册速度比项目 A 两年的平均值快了约 15%。
| 项目 A | 项目 B | |
|---|---|---|
| Friends & Family 机制 | 无 | 第一天起就内建 |
| 运营时长 | 两年以上 | 头两个月 |
| 起步基数 | 有既有客群可以触达 | 没有数字会员基数 |
| 上线时的品牌认知 | 已经建立并受信任 | 全新上线 |
| 日均注册速度 | 作为基准线的两年平均值 | 快约 15% |
| 经由邀请进来的注册 | 不适用 | 60% |
并排来看,一个起步基数为零的全新项目,不只是追平了运营多年的成熟项目,而且在日均口径上还略快一些,用的时间却短得多。这不是个小结果。项目 A 拥有全部的结构性优势:既有的客户关系、品牌知名度,以及两年的复利时间。项目 B 一样都没有,却依然跑赢了,靠的主要是一套把每位会员都变成招募者的机制。
项目 A 也不是一个孤立的对照样本。在这一对之外,Bridzia 还为另外 4 家零售商构建过不含 Friends & Family 机制的标准忠诚度项目。我们并没有拿到它们全部的早期增长窗口速度数据,不像项目 A 那样具体,所以我们不会声称这 15% 的差距在每一个项目上都同样成立。它真正说明的是:这个对比并非从一对凑巧合适的样本里挑出来的,它背后还有一批按标准方式构建的项目作为参照。
关于这个对比能证明什么、不能证明什么,我们想说得坦白些。这是两个不同的品牌、两个不同的行业、两份不同的营销预算,所以我们无法以科学意义上的确定性,把 Friends & Family 机制单独切分出来当作唯一原因。我们能说的是:差距的方向和幅度,正是一套推荐机制真正在起作用时会呈现的样子,这也和这套机制在设计上本该如何运转所推导出的预期相吻合。
这一预期还有一个更直接的数字作支撑:项目 B 的新注册里,有 60% 直接来自 Friends & Family 邀请。这不是机制带来的副作用,而是这个项目实际增长路径的大头。上面的速度对比呈现的是结果,这个数字则是产生该结果的机制本身。
它为什么有效
内建在产品本身里的推荐,比起挂在营销活动上的推荐,有两个优势。一是它经由信任度远高于广告的渠道触达用户,来的是朋友的消息,而不是品牌的消息。二是它是持续性的,而非一次性的推动,因为邀请的动机不会随着上线活动结束而消失,它已经成了项目每天如何运转的结构的一部分。
还有一个容易被忽略的留存副效应。身处共享积分组里的会员,判断的并不只是自己要不要继续用这个应用,而是要不要和自己邀请进来的那些人一起继续用下去,这抬高了抽身离开的代价。

那些不真撞上就没人会想的治理问题
Friends & Family 机制在提案文档里看起来很简单:邀请人、合并积分,完事。真正决定它在生产环境里成败的,是一系列和奖励逻辑毫无关系的边界情况,全都关乎真实的人按真实的人性行事时会发生什么。这几条规则,我们已经都构建好了。
必须先定下来的事不定会出什么问题
组管理员
谁握有权限
一个没有指定归属人的组,既没有明确的权限去添加或移除成员,也没有权限代表这个组做决定。每个组从创建的那一刻起就需要有一位确定的管理员,而不是等争执逼出这个问题之后才补上。
强制移除
争执如何收场
朋友之间会闹掰,家人之间也会。系统需要的不只是把人请进来的方式,还得有让管理员强制移除成员的方式,否则这套机制会悄悄从「自己选择加入的东西」变成「感觉被困住的东西」。
离开时的积分
什么会跟着一起走
既然积分是合并的,成员离开(无论主动还是被移除)就会立刻带出一个问题:他赚到的积分留在组里,还是有一部分要跟着他走?把这一条悬着不定,您就会以最难受的方式,也就是从一张工单里,知道会员原本期待的是哪个答案。
管理员交接
归属人退出后怎么办
如果管理员离开了应用或注销了账户,这个组需要一条明确的交接路径:是自动把另一位成员升为管理员,是要求组内推举接任者,还是走一套清晰的解散流程。无论哪种,都不能让它停在一个无人归属的损坏状态里。

这些都不是奖励逻辑的问题,而是产品治理的问题。它们恰恰属于那种在规划会议上看着像细枝末节、一旦没有事先定好,上线几周内就会变成实打实的客服负担的东西。
如果您正在设计一个忠诚度项目
有几件实务上的事,值得在上线之前就做对,而不是上线之后再补。
- 定好积分怎么共享。 全组共享积分、只给发出邀请的那个人奖励,或者两者的折中,各自带来的动机都不一样,这个选择应当贴合您的产品实际被使用的方式。
- 设一个合理的分组人数上限。 不封顶等于招来滥用;上限太小,又会在机制跑起来之前就限制住它的扩散范围。
- 从一开始就把反欺诈做进去,尤其是当积分可以折算成真实金钱价值时,因为推荐机制同样是最显眼的可钻空子之处。
- 让邀请流程本身足够顺畅。 再有效的机制,如果邀请一个人要点上好几下,照样发挥不出应有的效果。
- 在上线前解决上面这四个治理问题,别等第一张工单逼着您做决定。
如果您正在构建或重新梳理一个忠诚度项目,并且希望有一套真正按能跑通的方式搭起来的推荐机制,欢迎与我们聊聊忠诚度 CRM。
继续阅读
相关文章
更多关于平台、集成,以及买家如何发现品牌的内容。

电商实务
AI 发现商品的起点是您自己的网站,而不是 ChatGPT
74% 的马来西亚消费者购物时已在使用 AI。我们在 4 个 Adobe Commerce 项目中上线 Live Search 与 AI 商品推荐,实际带来了什么变化。
阅读全文
电商实务
升级到 Adobe Commerce 2.4.8:真正会坏掉的是什么
4 次 Adobe Commerce 2.4.8 升级下来,已安装扩展里每 10 个就有 9 个需要打补丁,Firebear 与 Amasty 也不例外。这里是需要提前规划的部分。
阅读全文
电商实务
如何在马来西亚更快上线一家 Adobe Commerce 店铺
真正压缩 Adobe Commerce 上线周期的是什么——范围纪律、尽早敲定的本地化,以及先验证集成——同时不留下事后后悔的余地。
阅读全文
