入口一 · 大R看板

分区域大 R 榜

近 30 天充值 Top5 · 大R＝持有荣耀等级 · 各区币种不同，不可跨区比金额。

⌕
#用户荣耀近30天充值笔数状态

入口一 · 每日大事件

今日有 4 条需要处理

前三个看板的异常汇总 · 没有异常时本页不显示内容 · 数据截至 2026-08-10

业务

8/8 群聊 10 连抽与 Lucky777 同日各涨约 38%，两个独立模块同幅上涨

10 连抽 80.8 万金币 vs 周末基线 58.7 万（+37.8%）；Lucky777 296.99 万 vs 周末基线 214.95 万（+38.2%）。 单个模块波动可以是偶然，两个玩法机制完全不同的模块在同一天涨出几乎相同的幅度，指向全局性事件——活动、推送或版本。
需确认缺口：活动上下线开关未接入，无法直接比对
大R

Witcher（29361701）静默 11 天，规则判高风险 —— 归因追查后下修为中

跑了 5 条查询：对照组排除大盘因素，历史节奏显示他属于「爆发→长静默→再爆发」的脉冲型，上一轮静默 48 天后回归。 本次静默仅 11 天，且 8/6–8/8 已回来消耗 6.6 万金币、8/7 充值 258 万。
中风险SVIP 08-12 到期仍需关注
业务

家族 26470215 只有 74 人，贡献值却是最大家族的 9.9 倍

全平台 2,783 个家族、40,545 名成员。成员数最多的 15556642 有 89 人、贡献 135.9 万； 而 26470215 仅 74 人、贡献 1,342.9 万。家族价值与规模严重脱钩，按人数排家族榜会完全排错。
口径问题
大R

冬（12927899）是印尼近 30 天充值第 2 名，但尚未建档

他是从 Witcher 的礼物往来关系自动辐射进候选池的，近 30 天充值 2,743 万 IDR，荣耀 Lv.2。 关系辐射先于榜单发现了他——这正是「针对一个人、辐射到相关的人」的价值。
待建档
入口三 · 业务看板

抽奖

四个常设模块的持续监控 · 数据窗口 2026-07-12 ~ 08-10

10 连抽 30 天消耗
1,371.7万
参与人数
4,707
单抽 27,907
大R 金币占比
51.7%
人数仅占 7.0%
人均倍差
14.1×
大R vs 普通
10 连抽日消耗
金色＝周末　虚线＝周末／工作日基线
场景大R人数总人数大R金币占比大R人均 / 普通人均
群聊 10 连抽3314,70751.7%21,424 / 1,515 · 14.1×
群聊单抽40727,90720.8%6,020 / 340 · 17.7×
情侣多抽201 人 · 26.4万金币待跑人均 1,313
情侣单抽1,370 人 · 21.4万金币待跑人均 156
10 连抽是大 R 的主场：7% 的人吃掉 51.7% 的消耗。要判断「有钱人是不是不满足现在的抽奖」，该盯的是大R 人均 21,424 这个数的走势，不是整体消耗。
Lucky777 30 天
5,838.8万
金币投注
日均参与
3,553
去重 UV
大R 金币占比
41.4%
人数仅占 1.16%
周末效应
1.16×
抽奖是 1.46×
三款概率游戏日投注
Lucky777 / Lucky Fruit / Lucky Slot · 金色＝周末
概率游戏几乎不分工作日和周末（1.16×），社交型抽奖才有明显周末效应（1.46×）。 这条差异本身就是判据：如果某天概率游戏也跟着抽奖一起涨，那多半不是周末，而是有外部事件。8/8 正是这种情况。
家族总数
2,783
在册成员
40,545
status=1
平均规模
14.6
人 / 家族
50 人以上
51
占 1.8%
规模分布
按成员数分档
Top10 家族 · 按成员数
对比贡献值
家族价值与规模严重脱钩。成员最多的 15556642（89 人）贡献 135.9 万，而 26470215 只有 74 人、贡献 1,342.9 万，是前者的 9.9 倍。 按人数排家族榜会完全排错——「家族生态」这个问题的第一步，是先定义按什么排。
有有效 CP 的用户
13,742
亲密值记录
107,946
按周期累积
情侣抽奖参与
1,571
多抽 201 · 单抽 1,370
情侣抽奖消耗
47.8万
占群聊抽奖 1.9%
案例：CP 亲密值如何领先充值
Witcher（29361701）× Yennefer（28910730）· 对数刻度
亲密值峰值领先充值爆发 2–6 天。4/13 亲密值达 899,422，两天后开始 11 天充值爆发；7/21 回升至 1,156，六天后再次爆发。 若这个领先关系在更大样本上成立，CP 亲密值就是一个可用的充值前置信号 待验证。
下级 · 数据口径

我们用了哪些数据

Matrix 每日跑批的完整 SQL 设计 · 12 条分三层，每层职责不同 · 全部只读，不写数仓

一

静态画像

每天 1 次 · _ad 表 · 全量快照
#数据内容表说明
SQL-1基础信息 + SVIP 等级 + 荣耀等级dw_user_basic_info_ad JOIN ods_user_level_ad JOIN ods_com_wealth_level_ad性别 / 年龄 / 城市 / 等级一次拿完
SQL-2当前 CP 关系（cp_uid、CP 时长、亲密值）ods_com_couple_value_stat_record_ad判断 CP 是否变化
SQL-3当前家族归属（家族 id、角色、加入时间）ods_com_family_member_ad判断家族是否变化
SQL-4概率游戏等级ods_com_lucky_game_level_user_ad等级判断风险
二

行为统计

近 7 日 · _sd 表 · 支撑当前画像 ＋ 时间线
#数据内容表说明
SQL-5充值记录（金额 / 次数 / 时间）ods_com_cash_order_adstatus=1，充值 Timeline
SQL-6礼物流转（送礼给谁 / 收礼来自谁 / 金额）ods_com_gift_receive_bill_ad关系分析核心，知道他在养谁、被谁养
SQL-7金币消费场景分布（按 scene_id / commodity_name）ods_com_coin_bill_ad type=0消费驱动力分析
SQL-8群聊房间行为（进房时长 + Top 房间 + 上麦次数）ods_flw_log_message_sd（JOIN_ROOM / EXIT_ROOM / OPEN_MICRO）JOIN ods_soc_chat_room_ad知道他主要泡在哪些房间、房主是谁
SQL-9私聊关系统计（Top 对话对象、消息深度、新建对话框）dm_soc_chat_session_msg_v1_sd谁是他最亲密的私聊对象
三

内容分析

近 1 日 · 供 AI 阅读原文

这层是 AI 真正「读懂这个人今天在做什么」的核心 —— 不统计数字，直接读消息内容。

#数据内容表说明
SQL-10今日群聊发言内容（原文）rt.rt_log_message_sd CHAT_ROOM_MESSAGEAI 读原文 → 发现骂产品 / 暴露情绪 / 特殊事件
SQL-11今日私聊消息内容（原文，双向）ods.ods_soc_chat_msg_v1_sdAI 读原文 → 发现线下约 / 转账 / 出轨 / 流失预警
SQL-12今日活跃房间详情（房间名 / 类型 / 房主昵称）ods_soc_chat_room_ad补全 SQL-8 的上下文，知道房间叫什么
＊

关键设计决策

限量读原文
每人近 200 条群聊 ＋ 100 条私聊，控制 token；AI 一次综合阅读，输出关键事件／情绪状态／风险信号
批量不循环
每条 SQL 都 uid IN (watchlist) 一次查完所有人
预计耗时
12 条 SQL、几百个用户，约 15–20 分钟/天
日报怎么来
统计层对比（SQL5–9 对比昨日）＋ 内容层 AI 阅读（SQL10–11），不需要额外查询
!

实测速度

2026-08-11
范围实测耗时状态
SQL-1~4 静态画像< 2 秒可用
SQL-5 / 7 充值与金币流水< 2 秒可用
SQL-9 私聊关系统计3.9 秒可用
全量分档聚合（1,038 人）2.4 秒可用
分区域 Top 榜（三表 join）2.1 秒可用
SQL-8 房间行为 / SQL-10–11 原文—超时，待宽表
会上说「SQL-5 起全部超时」，实测证伪了一半。真正跑不动的只有行为埋点类（房间进出、上麦、消息原文）。流水与统计类完全可用 —— 这也是本站所有真实数字的来源。
只读铁律：Matrix 对数仓只发 SELECT / SHOW / DESCRIBE，不建表不写表。需要落表的一律出 SQL 交研发执行。
入口二 · 个人档案

①

今日简报

2026-08-10
②

当前画像

钱去哪了
投注与赢回
投注流水 ≠ 消费
充值节奏
CP 亲密值
③

时间线

④

历史快照

入口四 · 活动看板

线上活动 · 疑似窗口 08-07 ~ 08-09

周期内表现 · 与历史对比 · 活动分析 · 上下线开关尚未接入，窗口由数据反推

当前没有活动上下线数据，这个窗口是「反推」出来的。 接入服务端开关与后台配置后，这一页应由活动列表驱动，而不是靠异常反查。
1

跨模块同步：这是活动最强的信号

模块08-08 实际同周期基线超出周末效应
群聊 10 连抽80.8万58.7万+37.8%强 1.46×
Lucky777296.99万214.95万+38.2%弱 1.16×
印尼荣耀日充值4,275万近期高点——
关键推理：这两个模块的周末效应强度完全不同（1.46× vs 1.16×），却在同一天涨出几乎相同的幅度（+37.8% / +38.2%）。 如果只是周末，弱周末效应的 Lucky777 不该跟着涨这么多。同幅上涨指向一个跨模块的外部事件——活动、推送或版本。
2

活动分析该跑哪些数

少羽现有口径
维度取数方式状态
参与人数 / 消耗金币消耗 source、金币收入 source现在就能跑
资源收支资源收入 / 消耗 key现在就能跑
大R 参与占比join 荣耀等级表现在就能跑
渗透率多少人看到、多少人打开活动页完全缺失
活动起止时间服务端开关 / 后台配置未接入
玩法与功能点无结构化来源未接入
3

活动历史复盘报告

结束后自动生成
报告结构（草案）
一 · 活动概况起止时间 / 玩法 / 目标人群 / 触达量
二 · 周期内表现参与人数、消耗、资源收支，逐日
三 · 与历史对比同类活动横比 + 扣掉周末与大盘基线后的净增
四 · 人群结构大R vs 普通用户的参与与消耗分布
五 · 归因涨跌的假设 → 逐条验证 → 概率，同个人档案那套
⇒ 结论这个活动值不值得再做，以及下次改什么
目标是替代人工复盘。活动结束自动出报告，复盘时直接截图引用，不必再手工拉数、也不必靠运营的主观反馈。
入口三 · 问题线程

问题线程

开放式问题在这里被收敛成可执行的口径。下次不是重新问，是回到线程继续问。

⌕
问题提出时间轮次口径状态
我们产品内有没有军火商？08-05 3 轮v2 · 待修订已出大盘
房间里有没有人劝别人不要送礼？08-11 0 轮未定义阻塞 · 需聊天原文
群聊家族生态是怎么样的？08-08 1 轮未定义澄清中
GCC & 伊拉克新用户付费表现？08-11 ——不走 Matrix
Q

我们产品内有没有军火商？

收敛过程
1澄清笼统问题先反问，不直接开跑
「军火商」在产品内无对应类目。先确认你指的是哪一种：
A · 供给型充值高、自己不消费，把币集中送给少数低充值账号已选
B · 中介型收币来源分散、流出集中，二道贩子
C · 代充型充值频次高、金额规律，受益账号不断变化
已选 A，补充说明：「把金币集中送给少数几个几乎不充值的账号，相当于给别人供弹药。」
2大盘结构性数据可以跑全量
近 14 天消费 > 1 万金币的用户共 1,038 人，按送礼占总支出的比例分档 · 实际耗时 7.1 秒
分档人数占比送礼金币占送礼额
0.67% 的人贡献了 29.6% 的送礼额，比占人数 87.9% 的那一档加起来还多 41%。送礼行为高度集中，方向 A 的假设成立。
3举例行为数据只能抽样，不能全量
A 档全部 7 人 · 点 UID 可建档
用户送礼金币送礼占比累计充值 IDR疑点
4口径落库这一轮的收获，下次默认带上
当前口径 · v2
① 送礼支出 / 总支出 > 70%　② 总支出 > 10,000 金币
③ Top5 受赠方占送礼额 > 70%　④ 受赠方自身充值额 ≈ 0 （③④ 待宽表）
本轮暴露三个漏洞，v2 的结论还不能用：
· 命中第一名 Mr06 的 10.99 万金币送给了自己——判据没排除 target_user_id = user_id
· 7 人里 5 个昵称形如 Mr02 / Ms09 / Man02，area 归属异常，疑似官方或运营账号
· Miliking 无任何充值记录却送出 1.2 万金币，币来源存疑
待确认 · v3
⑤ 排除自送自收　⑥ 排除官方 / 运营账号白名单　⑦ 币来源须为充值而非平台发放