能开进账单的 归因。
Ignition 承载私域游戏化增长——大转盘、兑换码、裂变——并把每一次奖励缝回到一个可确定、可审计的转化。转盘负责吸引注意力，归因路径与只追加账本负责赢得信任。
确定性计费 · 复式记账账本 · 租户级隔离
- 100%
- 确定性计费基准
- 只追加
- 复式记账账本
- 有版本
- 对外公开的归因政策
定位
不是游戏化工具箱,而是一台归因机器。
大转盘只是获客的舞台效果。归因路径与账本才是产品本身,所有工程优先级都服从这个判断——因为营收正确性不是可以事后再补的功能。
- 概率型转化可以出现在看板上——但永远不会进入账单。
- 靠平台费而非虚高数字的分成,让激励保持诚实。
- 每一笔可计费事件都冻结了产生它的政策版本与证据。
核心能力
让账单永远不是一次猜测
从第一次点击到落到账本,这六件事让归因始终经得起追问。
只做确定性归因
计费只依赖可确认的事件——兑换码核销,而非概率型设备匹配。我们自己无法验证的,就绝不计费。
只追加的复式记账账本
退款与拒付通过冲销分录记账,原始记录永不被改写。不平衡的交易在类型层面就无法被表示。
有版本、对外公开的政策
归因规则对客户与 KOL 公开。每条记录都冻结了当时的政策版本与证据快照——从设计上就能应对申诉。
游戏化获客
Telegram Mini App 内的服务端权威大转盘:加权抽奖、原子库存、幂等抽奖。客户端只负责把结果演出来。
租户级隔离
行级安全把每一次查询都限定在其租户内;密钥以信封加密静态存储。默认失败即关闭。
封顶但不停服
超出封顶的转化仍会归因、仍会为 KOL 计入——只是被标记为免费。体验更好,也是自然的升级动因。
运作方式
一条路径,端到端
从 Mini App 里的一次点击,到复式账本上的一行——每一跳都是我们可以复现的事实。
- 01
抽奖
用户打开 Telegram Mini App 并转动转盘。服务端抽出结果,并签发唯一的一个兑换码。
- 02
核销
兑换码在客户自己的 App 内核销。Telegram 身份与 App 身份在此绑定——在一个加锁事务里完成,是整条路径唯一的缝合点。
- 03
归因
确定性归因与其可计费事件一起写入,并盖上政策版本与证据快照。
- 04
结算
月末,未结算事件在租户封顶范围内出具账单,并向支付网关推送草稿。
- 05
记账与审计
每一笔计费都以平衡的复式分录入账;每日审计重新校验不变量,一旦偏移即告警。
为什么这个数字可信
四条我们绝不妥协的约束
系统的大部分设计,只有对着这四条才讲得通。它们正是账单立得住的原因。
计费建立在确定性归因之上
概率型匹配可以出现在看板上,却绝不出现在账单上。一处穷尽式判断强制执行——遗漏无法悄悄计费。
没有利益冲突
平台费意味着我们不会因为把数字做大而多赚。规则有版本、对外公开;每条记录都保留其证据。
账本只追加
退款与欺诈判定写入冲销分录;已出具账单的计费基准始终冻结。数据库本身已收回更新与删除权限。
能力由数据驱动
没有散落各处的套餐判断。权限来自数据,于是“Discord 暂时免费”这样的承诺是被记录下来的,而非写死在代码里。
定价
按已确认的转化计费
平台费让激励保持一致;绩效计费永远只统计我们能验证的事件。
入门版
平台费
适合第一场私域活动
- 游戏化 Mini App 转盘
- 确定性归因
- 对外公开的归因政策
- 包含月度封顶
成长版
平台费 + 绩效
适合按结果与 KOL 结算的团队
- 包含入门版全部能力
- 按核销进行绩效计费
- 复式记账账本与每日审计
- 租户级隔离与加密密钥
- 归因查询 API
企业版
面议
适合受监管的多品牌增长
- 包含成长版全部能力
- 云 KMS 与 Stripe 适配
- 申诉通道与证据导出
- 专属上线与 SLA
常见问题
把疑问讲清楚
准备好让归因达到账单级别了吗?
在你自己的活动上,看看完整路径——抽奖、核销、归因、结算、记账——真实跑起来。