忠诚度计划运作机制图解

1全景：赚 → 领 → 花

整条链路只有三步，但中间有两道会让积分消失的闸门——这是最容易被忽略、也最容易引发客诉的地方。

用户完成任务不等于拿到积分。必须主动点一次「领取」，积分才进钱包；进了钱包也还有有效期。两道闸门的天数都由运营按活动设定。

这是两个互相独立的开关。同一批用户，可以「都看得到」但「只有一部分拿得到」。一期就是这么设计的。

「展示」和「参与」分开控制，是一期能小范围试水的关键。提需求时这两个词必须分开说——混着说，开发一定会做成「看得到的人都能拿」。

为什么要这么设计

全量展示能拉动认知和讨论，限定参与能把成本和风险控制在可承受范围。等玩法验证稳定，只需要改一个开关就能逐步放开人群，不用重新开发。

四道校验，任何一道不过就拿不到分。前端需要针对每种情况给出不同的提示文案，否则用户只会看到一个灰按钮。

四道校验的顺序是固定的，前一道不过就不往下走。右边这个红框是产品要重点打磨的部分——四种「签不了」的原因，用户看到的文案应该完全不同。

同一笔积分会经历三个状态，中途有三个岔路会让它消失或回来。两个倒计时的起点不一样，这是最容易算错的地方。

只有「已进钱包」的积分才算公司的负债。待领取阶段作废的那部分，财务上不产生成本；这也是为什么领取率是个需要盯的指标。
注意：「已使用」是终点，没有回头路——积分退回只发生在 Tada 下单失败这一种情况，兑换一旦成功就不可逆（详见第 7 节）。

两步换算：先算用户拿到多少分，再算这些分折合多少钱——后者就是财务要计提的成本。

每一笔积分在发放的瞬间就把当时的规则和汇率冻结下来了。运营之后改配置、改汇率，都只影响新产生的积分，不会把历史账算乱——这是财务能对账的前提。

三种任务共用同一套「赚 → 领 → 花」的底座，区别只在于什么动作会触发发分。

触发：用户每天手动点一次签到

按「连续第几天」发分，天数越多给得越多。可以配置漏签是否清零重来。
目的：培养打开 App 的习惯

触发：达到设定的交易量

按累计交易量阶梯发分。
目的：直接拉动核心业务指标

触发：完成某个一次性动作

一期的限制

签到目前只支持用户手动点，系统自动签到的能力还没开发。这意味着前端的提醒和引导会直接决定领取率。

Tada 负责商城和履约，积分余额始终由 HSB 保管，扣不扣分也由 HSB 裁决。下面这条链路已按 Tada 最新确认的接口口径整理。

只有「订单创建失败」这一条岔路会把积分退回用户。订单一旦创建成功、奖励已经生成，这笔兑换就是终态——Tada 明确表示不能取消、不能退货。所以真正的风控点在第 ⑤ 步：扣分由 HSB 判断，Tada 拿到的只是一个只读余额。

这条要划重点：兑换成功后不可逆

Tada 的原话是——客户成功兑换、奖励已生成给 HSB 之后，该笔兑换不能再取消，也不能退回。这意味着：前端必须在用户点「确认兑换」之前做足二次确认；客服口径也要统一成「兑换后无法撤销」，不能给用户留任何余地。

接口	谁提供	必须 / 可选	用途与说明
商城登录 Catalog Webview Login	Tada	必须	HSB 带着用户 ID 和当前积分余额调用，换回一个商城网页地址，在 App 内嵌打开。余额在这一步就传过去了，所以商城页面能直接显示。
身份校验 / 取令牌 Authentication / Get Token	HSB	可选	Tada 在调用 HSB 接口前先取一个令牌。做不做由我们的安全要求决定。
查询积分余额 Get Member Points	HSB	可选	Tada 明确说这个接口在他们那边是可选的——他们只需要余额能被传过去并显示在商城页上，而余额在「商城登录」时已经给了。一期可以不做。
扣减积分 Redemption / Deduct Point	HSB	必须	用户下单时由 Tada 回调，HSB 校验余额后扣分。没有这个接口就无法上线兑换——这是整个商城功能的前置条件。
作废 / 退回积分 Add Void & Retry Void	HSB	必须	仅在 Tada 订单创建失败时调用，把已扣的积分退回给用户。Tada 会自动重试一次；两次都失败则发邮件给 HSB 人工处理。

兑换历史由 HSB 自己维护

哪个用户、什么时候、换了什么、当前什么状态——这套「会员 ↔ 兑换记录」的对应关系由 HSB 侧保存和展示，Tada 不负责这层映射。Tada 的历史详情里可以查到物流 / 发放的追踪信息，客服需要时从那里取。

从上到下依次配置。上线一个新玩法，通常不需要开发介入——除非是全新的任务类型。

换奖励力度、改参与人群、延长活动时间，都在第 3 层改配置就行。只有新增一种「赚分的方式」（比如做一个邀请好友任务）才需要开发排期。