v1.0 的增长系统设计原则只有一句:
把关系记下来,把规则放到后续开放。
邀请关系 / 代理标签 / VIP 等级表都做完, 但
所有派钱动作(代理佣金 + 推荐返佣 + VIP 返现)都不发,
等运营把规则定好再一起接上。
v1.0's growth system follows one principle: build the foundation, defer the rules. Invite relationships, agent flags, VIP tier tables — all shipped. But none of the payouts (agent commission, referral 1%, VIP cashback) are wired up yet. They all light up together when ops finalizes the rules later.
所有口径来自 PRD-V1.0.md 第 11-13 节。
任何用户(普通用户或代理)分享自己的邀请链接, 新用户首次注册时邀请关系永久写入数据库。
触发时机是 用户首次注册的那一瞬间 —— 通过 Telegram start_param=ref_{uid} 或 web URL ?ref={uid} 命中。一旦写入, 永久不可改。这条规则把所有后续代理 / 推荐 / 分佣功能的"地基"先打好。
如果用户自然进来(无 ref 参数), 邀请人字段为空, 不影响玩。如果以后这个人开始邀请别人, 他自己仍然没有上级 —— 关系不可回溯补建。
start_param 或 URL ?ref=xxx 命中关系建立了, 但 v1.0 不派发任何佣金 —— 所以邀请页只展示关系和计数, 没有钱的数字。
v1.0 邀请页能看到的:专属邀请链接 + 二维码 + 一键 TG 分享 + 我邀请了多少人 + 谁邀请了我。不显示「累计返佣 / 今日返佣 / 下线下注量 / Top N」这些 —— 因为还不派钱, 显示了反而误导。
这些数字在后端其实已经可以算出来(因为关系完整 + 下注数据全有), 等运营把分佣规则定好, UI 一键上线展示就行。
t.me/onebot?start=ref_{uid}
运营在后台把 is_agent 字段从 false 改成 true(或反之),仅此而已。这个 flag 在 v1.0 不触发任何分佣行为。
它是一个语义标签: "这个用户是代理"。等运营把完整需求 —— 分级几档 / 佣金多少 / 上溯几层 / 反刷多严 ——回答清楚, 才把 flag 跟逻辑挂上钩。
改这个 flag 要走运营 admin 后台 + 二次确认 + 完整审计日志。降级也允许 (从代理改回普通), 但要写原因记录。
后续开放 · 等运营提需求的 9 项 / 9 items deferred
等级表 + 返现比例 v1.0 已锁。 v1.0 VIP 中心展示等级 + 进度 + 目标权益, 但不发返现 —— 派发逻辑跟代理 / 推荐一起在后续开放。
邀请关系必须在用户注册的瞬间写下, 过了那一刻就没机会再加。所以 v1.0 必须把邀请关系绑定这件事做对、做扎实。这是 v1.0 不能拖到后续开放的唯一刚需。
Invite relationships must be written at registration time; the moment passes and you can't retro-add. So v1.0 must do this right.
只要关系记录完整 + 下注数据完整, 等运营定好规则后, 跑一次回填脚本就能把历史数据补齐。所以分佣规则可以放到后续开放, 不影响最终发放。
As long as relationship + bet records are complete, a backfill job after ops finalizes rules will recover the history.
目标市场 (VN / PH / ID / TH) 的分佣习惯还在摸索, 提前把
3% / 5% / 8%
写死在代码里, 后期改起来比从零做还麻烦。先做最小可改的设计 (yes/no flag + 关系绑定), 等市场数据回来再加 width。
Commission norms in target markets are still being explored; hard-coding early creates more rework than greenfield.