# ABOT 群运营分析 2.0 推进方案 ## 1. 文档目标 本文档用于明确 ABOT 当前“群运营分析”能力的现状、缺口与下一阶段建议落地方向，帮助后续开发时避免重复建设，也避免一次性把范围做得过重。 本文重点不是从零设计一套全新系统，而是： - 识别当前项目已经具备的群运营分析基础 - 找出哪些数据资产已经落库但尚未产品化使用 - 定义一版“最小但有感知”的群运营分析 2.0 - 给出可直接进入开发的页面、接口与迭代顺序建议 --- ## 2. 当前能力现状 从现有代码与后台页面看，项目已经具备一版“群运营分析 1.0”，并不属于从零起步。 ### 2.1 已有前台能力 当前后台已经有以下页面与展示能力： - 群组统计总览页 - 群活跃度排行 - 群详情弹窗 / 详情面板 - 健康度评分 - 基于规则的运营建议 - 沉默成员排行 - 发言成员排行 - 消息趋势与高峰时段 - 插件调用情况与插件覆盖度 已存在的主要页面： - `admin/dashboard/templates/groups.html` - `admin/dashboard/templates/contacts_management.html` - `admin/dashboard/templates/robot_management.html` ### 2.2 已有后端聚合能力 当前群详情接口已经不是简单查表，而是做了相当多的聚合计算，主要包括： - 群成员概览统计 - 近 24 小时 / 7 天 / 30 天消息统计 - 消息类型占比 - 近 14 天消息趋势 - 近 30 天小时分布与高峰时段 - 插件调用汇总 - 插件成功率 - 群健康度评分 - 基于阈值规则的运营建议 对应核心接口： - `admin/dashboard/blueprints/robot.py` 中的 `/robot/api/group//detail` ### 2.3 已有数据资产 项目中已经沉淀了不少可直接复用的运营分析数据表，这意味着 2.0 更多是“产品化串联”，而不是“重新采集数据”。 #### 1. 消息与活跃度基础数据 - `messages` - `speech_counts` - `t_chatroom_member` - `t_chatrooms` 可支持： - 群消息量趋势 - 发言排行 - 活跃覆盖率 - 沉默成员识别 - 高峰时段识别 #### 2. 机器人使用与插件渗透数据 - `t_group_stats` - `t_group_command_user_stats` - `t_plugin_stats` - `t_user_stats` 可支持： - 插件调用量 - 插件成功率 - 插件覆盖度 - 唯一触发人数 - 功能渗透度判断 #### 3. 总结与画像类数据 - `t_message_summary` - `t_group_profile_snapshot` - `t_member_context` - `t_member_digest` 可支持： - 群定位摘要 - 高频讨论主题 - 群风格判断 - 核心成员画像 - 成员分层总结 #### 4. 关系与互动网络数据 - `t_message_mentions` - `t_social_edges_daily` 可支持： - 谁经常主动互动 - 谁经常被点名 / 被@ - 谁是核心连接点 - 小圈层 / 搭子关系 #### 5. 运营价值分层数据 - `t_value_rank_snapshot` 可支持： - 群内核心成员识别 - 高价值成员榜单 - 待召回边缘成员识别 --- ## 3. 当前缺口判断 虽然当前已经有不少分析能力，但整体上更偏： - 机器人在群里的使用分析 - 群活跃度基础诊断 还没有完全升级成： - 面向运营动作的群运营控制台 当前主要缺口在以下几个方面。 ### 3.1 有统计，但缺少“结论表达” 当前很多页面已经能展示数字、排行与趋势，但管理员仍然需要自己把这些数字转化为判断。 例如： - 这个群到底是闲聊群、工具群还是运营群 - 这个群最近是升温还是降温 - 这个群更适合推签到、排行还是话题互动 这些结论目前还没有被显式产品化。 ### 3.2 有建议，但缺少“可执行动作” 当前已有 `operation_suggestions`，但更多是规则式提示，例如： - 沉默成员较多 - 活跃覆盖率偏低 - 插件渗透率不足 这些建议已经有价值，但还不够“下一步就能做”。例如还缺： - 建议在什么时间发互动 - 建议激活哪些成员 - 建议给这个群重点推什么功能 - 建议减少哪些高失败命令 ### 3.3 有画像数据，但没有统一编排成运营视图 项目已经具备： - 群画像 - 成员画像 - 成员摘要 - 群总结 但这些数据更多还停留在插件内部能力或独立存储层，后台没有统一组装成“运营者一眼能看懂”的页面。 ### 3.4 有关系数据，但没有做成差异化能力 `t_message_mentions` 和 `t_social_edges_daily` 已经是很有价值的数据资产，但当前群运营页面里还没有把它们真正用起来。 如果后续继续做群运营分析，这一块最容易形成差异化。 --- ## 4. 群运营分析 2.0 的目标 建议把“群运营分析 2.0”定义为： > 从“看群数据”升级为“理解群状态，并给出下一步运营动作建议”。 它不应只是增加更多图表，而应该让后台具备以下能力： - 看懂这个群是什么群 - 看懂这个群最近变好了还是变差了 - 看懂谁是核心成员、谁是边缘成员、谁值得激活 - 看懂机器人在这个群里应该推什么、不应该推什么 - 给出下一步可执行的运营动作建议 --- ## 5. 建议产品形态 建议 2.0 不再只围绕“群组统计排行页”，而是把重点放在“单个群的运营分析详情页 / 详情面板”上。 推荐拆成 4 个核心板块。 ### 5.1 板块一：群体检 定位：回答“这个群当前健康不健康，最近趋势如何”。 建议展示： - 群健康分 - 近 7 天 / 30 天消息趋势 - 活跃覆盖率趋势 - 沉默成员占比 - 插件渗透趋势 - 新增活跃成员数 - 最近 30 天消息类型结构 输出价值： - 这个群是在升温还是降温 - 互动是变多还是变少 - 机器人功能是否在被持续使用 ### 5.2 板块二：群画像 定位：回答“这是一个什么群，大家最近在聊什么”。 建议展示： - 群定位摘要 - 群风格标签 - 高频主题 - 最近热点内容 - 活跃时段画像 - 群公告 / 群定位与实际讨论是否一致 优先复用数据： - `t_message_summary` - `t_group_profile_snapshot` - `messages` 输出价值： - 管理员不用翻聊天记录，也能快速理解群状态 - 为后续机器人策略和运营动作提供上下文 ### 5.3 板块三：成员分层与关系 定位：回答“这个群是谁在带动、谁沉默了、谁值得运营”。 建议展示： - 核心成员榜 - 高价值成员榜 - 沉默成员榜 - 边缘活跃成员列表 - 最近被@最多成员 - 最近主动互动最多成员 - 核心关系对 / 搭子关系 优先复用数据： - `t_chatroom_member` - `t_member_context` - `t_member_digest` - `t_message_mentions` - `t_social_edges_daily` - `t_value_rank_snapshot` 输出价值： - 从“谁发言多”升级为“谁值得重点运营” - 为召回、分层激活、群活动设计提供依据 ### 5.4 板块四：运营动作建议 定位：回答“下一步具体该做什么”。 建议展示： - 推荐互动时间 - 推荐激活对象 - 推荐主推插件类型 - 推荐减少 / 优化的高失败指令 - 推荐欢迎语 / 菜单引导策略 - 推荐一条可直接发布的话题引导文案 输出形式建议： - 直接给行动卡片 - 每张卡片包含：问题、原因、建议动作、适用对象 输出价值： - 把群运营分析从“分析报表”变成“决策辅助工具” --- ## 6. 建议先做的最小版本 为了降低改动风险，建议群运营分析 2.0 第一版只做“最有感知、最少侵入”的部分，不要一上来就做复杂关系图谱和大规模新表。 ### 6.1 第一版范围 建议第一版只落以下内容： #### 1. 群画像摘要卡 展示内容： - 群定位摘要 - 最近 7 天热点主题 - 群风格标签 - 推荐运营方向 优先数据源： - `t_group_profile_snapshot` - `t_message_summary` - 若无画像快照，则用现有统计数据兜底输出 #### 2. 群趋势体检卡 展示内容： - 近 7 / 30 天消息变化 - 活跃覆盖率变化 - 沉默成员变化 - 插件调用变化 说明： - 第一版不必做太多新图表，可以先用趋势值 + 小型趋势图 #### 3. 成员分层卡 展示内容： - 核心成员 Top N - 待激活成员 Top N - 沉默成员 Top N 说明： - 第一版先不做关系网络可视化 - 先把“谁值得运营”这件事讲清楚 #### 4. 运营动作建议卡 展示内容： - 建议高峰互动时间 - 建议主推功能 - 建议重点激活成员 - 建议优化命令入口 说明： - 第一版仍然可以以规则引擎为主 - 不需要一开始就上 LLM 动作建议 ### 6.2 第一版暂不处理 为了避免范围膨胀，建议先不做： - 复杂关系网可视化 - 群与群之间横向对标 - 自动生成完整运营周报 / 月报 - 大量新增定时任务 - 全自动策略闭环 - 基于 LLM 的高成本全量分析 --- ## 7. 建议数据复用策略 群运营分析 2.0 尽量优先复用现有数据表，减少对主链路侵入。 ### 7.1 直接复用 - `messages` - `t_chatroom_member` - `t_group_stats` - `t_message_summary` - `t_group_profile_snapshot` - `t_member_context` - `t_member_digest` - `t_message_mentions` - `t_social_edges_daily` - `t_value_rank_snapshot` ### 7.2 能不用新增表就先不用 第一版尽量通过已有聚合查询和轻量接口拼装页面，不要急着新增“群运营宽表”。 原因： - 当前仓库数据层职责已经偏重 - 先验证产品结构是否有效，比先扩表更重要 - 宽表可以放到后续性能优化阶段再做 ### 7.3 需要注意的数据口径 后续实现时要统一口径，避免页面数值互相打架： - 成员统计只基于 `status = 1` 的在群成员 - 活跃覆盖率要区分 7 天和 30 天窗口 - 插件渗透度要明确是“插件种类数”还是“触发人数占比” - 沉默成员口径要统一为“30 天未发言或从未发言” - 趋势对比要说明是“环比上周 / 环比上月” --- ## 8. 推荐接口拆分 建议不要继续把所有逻辑都堆在一个群详情接口里，可以在不破坏兼容性的前提下做轻拆分。 ### 8.1 可保留现有接口 保留： - `/robot/api/group//detail` 用途： - 继续服务现有页面 - 作为兼容入口存在 ### 8.2 建议新增的 2.0 接口 建议新增以下接口： #### 1. 群运营概览接口 - `/robot/api/group//ops_overview` 职责： - 返回健康分 - 趋势摘要 - 活跃覆盖率 - 沉默成员占比 - 插件渗透度 #### 2. 群画像接口 - `/robot/api/group//ops_profile` 职责： - 返回群画像摘要 - 热点主题 - 群风格标签 - 高峰时段建议 #### 3. 成员分层接口 - `/robot/api/group//ops_members` 职责： - 返回核心成员 - 沉默成员 - 待激活成员 - 高价值成员 #### 4. 动作建议接口 - `/robot/api/group//ops_actions` 职责： - 返回可执行的运营建议卡片 这样做的好处： - 降低单接口复杂度 - 页面可按模块懒加载 - 后续更容易单独优化每个板块 --- ## 9. 页面推进建议 推荐优先在现有群详情视图上增强，而不是立即新开一套全新后台模块。 ### 9.1 第一阶段 优先增强现有群详情视图： - `contacts_management.html` 中的群洞察面板 - 或 `groups.html` 的详情弹层 原因： - 改动更小 - 用户路径更短 - 不需要重新设计入口 ### 9.2 第二阶段 如果第一阶段效果好，再考虑独立成真正的“群运营分析详情页”。 页面结构建议： - 群体检 - 群画像 - 成员分层 - 行动建议 --- ## 10. 推荐迭代顺序 建议按以下顺序推进。 ### 第一步：群画像摘要卡 优先级最高。 原因： - 用户感知最强 - 可直接复用已有画像/总结数据 - 风险相对低 ### 第二步：成员分层卡 原因： - 最贴近运营动作 - 能立刻产生“该找谁运营”的价值 ### 第三步：动作建议卡 原因： - 把分析结果转成可执行动作 - 让页面从“报表”变成“工具” ### 第四步：趋势增强 原因： - 趋势图和环比更像锦上添花 - 可以放在前面几项做完后补 ### 第五步：关系网络能力 原因： - 虽然价值高，但实现与展示复杂度也最高 - 适合作为 2.1 或 3.0 增强项 --- ## 11. 最终建议 群运营分析这条线现在不应该再理解为“补一个统计页”，而应该升级为： - 用现有数据资产理解单个群 - 给出可执行的运营动作建议 - 逐步把后台从“管理面板”做成“运营辅助台” 如果只做一个最小且最值得推进的版本，建议直接落： 1. 群画像摘要卡 2. 成员分层卡 3. 运营动作建议卡 这三块最容易体现价值，也最不容易把工程范围做炸。