流量红利消退，公域投放前置付费、ROI 不可控，大量实体、电商商家开始转向存量用户裂变。推三返一（行业俗称三三循环）是一类直推阶梯循环奖励营销模型：用户购买指定实物礼包获取分享资格，直推 N 人回本，后续订单奖励档位循环复用，实现老客户驱动新客户增长。
市面上不少 SaaS 分销系统均已实现该模式。但很多开发者只实现表面业务逻辑，忽略算法边界、退款回滚、风控漏洞与合规埋点，上线后出现算账错误、资金漏洞、业务合规风险。
1 业务背景与原始诉求
1.1 商家业务痛点
- 公域广告前置付费，无论有没有成交都需要消耗预算，沉没成本高；
- 传统转介绍依赖人情，缺少标准化激励，很难规模化复制；
- 希望营销成本后置：产生真实新增订单之后才发放营销奖励；
- 希望可灵活调整回本单数、每一档奖励，适配不同毛利产品；
- 部分商家需要团队等级激励，但又担忧多层计酬法律风险。
1.2 核心业务目标
用户购买指定实物礼包获得分享资格，通过直推新用户下单获取阶梯奖励；累计直推达到设定数量后收回自身消费成本；继续推荐新客户，奖励档位从头循环，形成持续裂变。团队等级奖励为可选扩展模块，默认建议关闭。
2 核心业务模型与奖励算法
2.1 基础业务流程
- 用户购买系统标记的指定实物礼包 SKU，才获得循环推荐奖励参与资格；普通商品不触发该模式。
业务约束：用户可以只买礼包，完全不做推广，购买行为不等于强制推广任务。
- 该用户直推新用户完成礼包下单，按照直推订单的时间顺序，依次匹配阶梯奖励档位；
- 直推有效订单累计达到配置的「回本订单数」，完成回本；
- 超过回本订单数之后，新的直推订单重新从第 1 档奖励开始循环；
- 后台可配置参数：回本订单数（3/4/5 可配置）、每一档奖励金额 / 比例、循环奖励总开关。
2.2 奖励计算示例（配置：1000 元礼包，3 单回本）
配置档位：第 1 单 200 元、第 2 单 300 元、第 3 单 500 元，3 单完成回本，第 4 单起循环。
- 用户 A 花费 1000 元购买礼包，获得分享资格；
- A 直推订单 1：奖励 = 第 1 档 200 元；累计奖励 200；
- A 直推订单 2：奖励 = 第 2 档 300 元；累计奖励 500；
- A 直推订单 3：奖励 = 第 3 档 500 元；累计奖励 1000，回本完成；
- A 直推订单 4：重新回到第 1 档，奖励 200 元；
- A 直推订单 5：第 2 档 300 元；
- A 直推订单 6：第 3 档 500 元；
- A 直推订单 7：再次回到第 1 档 200 元，无限循环。
关键点：档位按照直推订单的时间有序队列依次消耗，不是按用户数，是按有效成交订单序列。
2.3 伪代码逻辑（便于后端开发参考）
# 每个消费商维护自己的直推有效订单有序列表 order_list（只包含已完成、未退款订单）
# config: 配置 [{reward:200}, {reward:300}, {reward:500}]，长度即回本需要订单数
def calc_cycle_reward(user, new_order, config):
if not user.has_cycle_qualification():
return 0
if new_order.refund_status:
return 0
order_list = user.get_valid_refer_order()
order_list.append(new_order)
idx = len(order_list) - 1
pos = idx % len(config)
reward = config[pos]["reward"]
return reward边界注意：退款订单需要从
order_list剔除；剔除之后，后续所有订单档位要重新计算，并且已经发放的奖励需要做回滚扣减，这是系统最容易出 BUG 的地方。
2.4 可选扩展：团队等级奖励模块（高风险）
当开启团队奖励开关后，统计会员伞下全部有效业绩，达到业绩门槛自动升级：青铜、白银、黄金、白金、钻石。 每个等级可配置：团队奖励比例、平级奖励比例。
🚨风险提示：团队奖、平级奖极易触碰多层计酬红线。 系统设计层面建议：团队奖励独立总开关，默认关闭；开关关闭状态下，完全不执行团队业绩计算与奖励发放，防止商家误配置上线。
3 系统模块整体架构设计
整体拆分为五大核心模块：循环奖励模块、团队等级模块、会员钱包模块、风控防作弊模块、商城基础支撑模块。
3.1 循环奖励模块（核心必选）
- 循环奖励总开关，一键启停整套推三返一逻辑；
- 阶梯奖励配置：支持多档设置，每档可配置固定金额或比例；
- 回本订单数配置，定义多少单完成一次循环；
- 用户直推订单有序队列存储，记录每一笔有效直推订单；
- 订单状态监听：仅订单完成才计算奖励；退款触发奖励回滚、钱包扣减；
- 奖励入账事件，产生流水日志，完整可追溯。
3.2 团队等级模块（可选扩展，默认关闭）
- 团队奖励全局开关；
- 等级字典配置：等级名称、升级伞下业绩门槛、团队奖比例、平级奖励比例；
- 伞下业绩统计：只统计有效成交，剔除退款、关闭订单；
- 自动升降级逻辑；
- 平级奖励匹配计算逻辑。
3.3 会员与钱包账务模块
- 会员资格标记：只有购买指定礼包 SKU 才获得循环分享资格；
- 奖励钱包：区分冻结余额、可提现余额；
- 完整账务流水：每一笔奖励入账、扣回、提现全部留痕；
- 推广关系链存储，溯源每一笔奖励来自哪一笔源订单。
3.4 风控与防作弊模块（生产环境必备）
裂变系统如果缺少风控，极易被小号批量薅奖励。
- 设备指纹、账号关联识别，拦截批量注册小号；
- 礼包商品白名单：只有指定 SKU 才触发循环奖励；
- 退款订单奖励回滚机制，保证账务平衡；
- 支持设置单人周期奖励上限；
- 异常订单标记、后台人工复核能力。
3.5 商城基础支撑
小程序 / H5 商城、分享海报生成、订单管理、用户关系链维护，完成业务闭环。
4 数据库核心表设计要点（简化版）
仅列出关键表与关键字段，帮助理解存储模型
1. marketing_cycle_config 三三循环主配置表
| 字段 | 说明 |
|---|---|
| id | 主键 |
| switch_cycle | 循环奖励总开关 0 关闭 1 开启 |
| return_order_num | 回本订单数量 |
| create_time | 创建时间 |
2. marketing_cycle_level 循环档位配置表
| 字段 | 说明 |
|---|---|
| id | 主键 |
| config_id | 关联主配置 ID |
| reward_type | 0 固定金额，1 比例 |
| reward_value | 奖励值 |
| sort | 档位顺序 |
3. user_cycle_order 用户直推有效订单队列表
这是算账核心，记录每个用户直推的有效订单顺序，退款需要删除该记录，触发重算奖励 | 字段 | 说明 | | ---- | ---- | |id | 主键 | |user_id | 分享人 ID| |order_id | 被推广的订单 ID| |order_status | 订单状态，退款标记 | |sort_index | 队列序号 |
4. user_wallet_record 钱包流水表
所有奖励发放、扣回、提现都在此留痕，不可物理删除，只能新增反向流水。
5. marketing_team_config 团队等级配置表（可选） 存储各个等级、升级门槛、团队奖、平级奖比例。
重要原则：业务禁止物理删除流水，退款、回滚奖励采用新增反向冲正流水，保证账务可审计。
5 系统层面需要固化的合规约束
很多风险不能只靠运营文档，需要把部分约束埋进系统逻辑和后台提示。
- 奖励资格必须绑定真实商品 SKU 后台配置页面提示警告：禁止配置无实物的资格类虚拟礼包。
- 不强制推广 系统逻辑不限制购买礼包后的用户，不做分享也可以正常使用商品权益。
- 高风险模块强隔离 团队奖励模块独立开关，关闭状态下完全不运算；后台有醒目的红色风险提示。
- 退款链路闭环 一旦订单退款，对应产生的奖励必须支持回滚扣回，防止资金漏洞。
- 系统提示文案 后台配置界面增加风险提示：本模式仅为营销工具，禁止夸大收益宣传，业务上线请咨询法务。
系统无法管控商家对外宣传口径，需要服务商在对接客户时明确告知：禁止宣传躺赚、副业暴富，该模式定位老带新营销活动，不是理财项目。
6 业务适用场景与不建议接入场景
✅适合接入： 实体门店套餐、消费品电商、农产品、新品冷启动；具备真实公允价值实物 / 服务，毛利充足，希望做存量用户老带新裂变。
❌系统不建议承接的需求： 无实物产品、售卖空推广资格礼包、商品定价严重脱离市场行情，此类项目法律风险极高。
7 落地总结与开发踩坑点汇总
推三返一（三三循环）本质：一套带有序队列循环档位的直推奖励系统，附带可选的团队等级扩展。
在实际项目对接中，经常遇到下面几类坑：
- 只处理下单成功，忽略退款之后订单队列变化，造成奖励计算错乱；
- 把用户数当成订单数做循环档位匹配，业务逻辑理解错误；
- 团队奖励没有独立开关，商家上线后无意开启带来合规隐患；
- 缺少账务冲正机制，退款之后奖励无法扣回，出现资金漏洞；
- 缺少风控，被批量小号薅取奖励。
作为技术服务商，不能因为客户有需求就无脑实现全部功能，需要向客户明确提示模式的业务边界与法律风险。系统只是工具，产品、定价、运营、法务才是业务安全的基石。