# 得到用飞书多维表格做直播复盘：截图自动录数据

> 得到如何用飞书多维表格复盘直播与线下活动？拆解「直播数据复盘大屏」的真实结构：手动录入 55 项指标的代价、上传抖音罗盘截图由 AI 识别自动建档、活动报名与满意度问卷回收、NPS 与嘉宾评分计算，含表设计与指标口径。

分类：企业落地案例　
发布：2026-06-30　
原文：https://apibobo.com/content/posts/dedao-live-data-review-feishu/

---

做知识付费的团队，直播是主战场，线下大会是主阵地。得到把这两件事的复盘统一收进了一个飞书多维表格 Base——「得到同款直播数据复盘大屏」。9 张表，一块「🚀 内容数据大屏」仪表盘。

这套系统真正值得研究的地方不在于它有多复杂，而在于它把同一件事**做了两遍**：一遍手动，一遍自动。对照着看，能非常清楚地看到「AI 到底替掉了什么」。

## 一、痛点：一场直播 55 个指标，谁来填

先看那张手动版的表——「🔉 手动录入直播数据」。它有 55 个字段，密度惊人：

**流量结构**：曝光人数、点击人数、观看人数、观看次数、公域流量、私域流量、自然流量、加热流量、广告流量，以及各自的占比。公域再细分「直播推荐 / 搜索 / 短视频引流 / 关注开播通知」，私域再细分「分享 / 短视频引流 / 预约开播通知 / 公众号」。

**转化漏斗**：曝光率 → 点击率 → 下单人数 / 下单率 → 付款人数 / 付款率 → 订单数 → 成交金额 → 转化率，中间还有一个「曝光-付款」的跨段指标。

**互动与留存**：平均在线、最高在线、平均观看时长（分）、点赞数 / 点赞率、评论数 / 评论率、分享人数 / 分享数 / 分享率 / 人均分享次数、新增关注 / 关注率。

**预约链路**：预约人数、预约到看人数、预约到看率、预约通知占比。

**满意度**：填写问卷人数、问卷回收率、满意度、净推荐值。

这套字段设计本身是专业的——它把「流量从哪来 → 有没有留下来 → 有没有转化 → 满不满意」四段完整串了起来。问题在于成本：每播一场，运营就得对着抖音罗盘的后台大屏，把 50 多个数字一个个抄进表里。抄一场半小时，抄错一个数，整场复盘的结论就歪了。

所以这张表只有 6 条记录。**不是不想复盘，是复盘的门槛太高。**

## 二、方案：把「抄数」换成「截图」

「📊 自动录入直播数据」这张表就是答案。它的字段只剩 13 个，核心流程是：

1. **上传截图**：运营在直播结束后，把抖音电商罗盘·经营直播大屏的截图直接丢进「直播大屏截图」附件字段；
2. **AI 识别**：多模态模型读图，把整屏内容结构化输出，写进「大屏数据识别」字段；
3. **字段落位**：从识别结果里抽出关键指标，回填到独立的数字字段。

「大屏数据识别」字段里存的是完整的结构化解析结果，真实样本长这样：

> ###一、页面基础信息【所属产品】：抖音电商罗盘·经营直播大屏专业版【开播时间】：2025/02/25 19:04【累计开播时长】：共 4 小时 39 分钟
> ###二、核心直播数据【直播间成交金额】：¥430,114【千次观看成交金额】：¥6,096.16【成交人数】：2,007【成交件数】：6,350【观看-成交率(人数)】：6.14%【商品点击-成交率(人数)】：33.45%【平均在线人数】：1,006【曝光-观看率(次数)】：29.3%【人均观看时长】：6 分钟 35 秒【观看-互动率(人数)】：5.28%【新增粉丝数】：308

对应这条记录落到字段上就是：累计成交金额 430,114、成交人数 2,007、成交件数 6,350、平均在线人数 1,006、新增粉丝数 308、观看-互动率 5.28%、千次观看成交金额 6,096.16、人均观看时长 395 秒。

有两个细节做得很讲究：

- **人均观看时长统一成秒**。原始大屏显示的是「6 分钟 35 秒」这种人类可读格式，直接存文本就没法排序和求平均。系统把它归一化成 395（秒），另一条小场次是 9（秒）。**单位统一是能不能做横向对比的前提。**
- **连异常信息也一并留下**。上面那条记录的识别结果里还带着一句系统提示：「本场直播含有不符合平台要求的内容，无法进入复盘模式」。这种平台侧的告警如果靠人抄数，第一个被忽略；靠截图识别，它自然就进了档案。

从 55 个字段手填到 1 张截图，这个改动带来的不是省了半小时，而是**复盘从「重要但做不动」变成了「顺手就做了」**——自动表已经有 8 条记录，超过了手动表。

## 三、线下活动：从报名到回访的完整闭环

Base 的另一半是线下大会（表里称「增长大会」）的运营链路：

**报名端**——「🎡 活动报名数据」（19 条）：会员名称、预约场次，通过 lookup 带出跟进人员。它和「📊 会员底表」（121 条）联动，底表里存会员 ID、会员姓名、跟进销售、排长名称和 SourceID。**报名不是一条孤立信息，而是直接挂到了具体销售和具体会员身上。**

**反馈端**——「🌟 线下活动反馈表（满意度）」（264 条）：这是活动后问卷的原始回收表，题目编号保留在字段名里，能直接看出问卷设计：

1. 对本次活动是否满意（单选）
2. 你对本次活动中最满意的服务是什么？
3. 你对本次活动嘉宾分享内容的满意度评分（满分 5 分）
4. 你对本次活动中最不满意的服务是什么？
5. 不及预期的人不满意细节
6. 请选择本次活动中令你超出预期的部分
7. 你觉得我们还有哪些【需要提升】或者【可以保持】的？
8. 你还想听什么类型的主题分享
9. 你有多大可能把增长大会活动推荐给朋友呢？（0–10 分）

再加两个运营字段：活动场次、是否愿意接受回访。

这份问卷的结构值得抄：**满意与不满意分开问**（第 2 题 vs 第 4 题），**超预期与不及预期分开问**（第 5 题 vs 第 6 题）。合成一道「你觉得怎么样」，得到的永远是「挺好的」；拆成正反两问，才能拿到可执行的细节。第 9 题是标准的 NPS 量表，表里还配了一个 formula 字段做分档换算。

**汇总端**——「💯 线下反馈情况」（6 条，按场次汇总）：报名人数、填写问卷人数、问卷回收率、满意度、净推荐值、推荐指数。一场活动一行，横向就能比出哪场办得好。

**回访端**——「🎯 活动回访记录」（15 条）：微伴昵称、回访人、满意情况、回访记录。前面问卷里勾了「愿意接受回访」的人流到这里，由具体的人跟进。**问卷不是收完就归档，而是筛出了一批可以继续对话的对象。**

**嘉宾端**——「🏅 嘉宾评分计算」：嘉宾名称 + 一个 lookup 过来的「对老师打分」，把问卷第 3 题的评分聚合到人。请谁不请谁，下次有数据可依。

## 四、这套系统的三个可复用设计

**其一，先手动跑通口径，再自动化。** 那张 55 字段的手动表看似被淘汰了，实际上它定义了「什么指标重要、怎么分层、怎么算比率」。自动表能只留 13 个字段，是因为口径已经想清楚了。**顺序反过来——先上 AI 再想指标——通常会得到一堆没人看的数字。**

**其二，用截图当数据接口。** 很多平台的数据后台不开放 API，或者开放了但申请流程漫长。直播大屏、广告后台、电商罗盘这类界面，截图本身就是最通用的「接口」。多模态模型把这层壁垒直接抹平了，代价只是一次上传。

**其三，原始解析结果要留档。** 系统没有只存最终的几个数字，而是把 AI 的完整结构化输出保留在「大屏数据识别」字段里。这样一来，事后发现某个字段抽错了，不用重新截图；将来想多提取两个指标，历史记录里也还有原文。

## 效果

对得到这类同时跑「线上直播 + 线下大会」的团队来说，这套 Base 把两条业务线的复盘统一到了一个数据底座上：直播看流量结构与转化漏斗，线下看满意度与 NPS，会员底表把两边的人打通，最后汇进「🚀 内容数据大屏」。目前系统里已沉淀 264 份活动问卷、121 位会员档案、多场直播与线下活动的完整指标。

如果要复刻其中的截图识别环节，关键是选一个视觉理解足够稳的模型——大屏截图信息密度高、数字多、还有百分号和货币符号，识别错一位数就白做。可以用波波 API（[apibobo.com](https://apibobo.com)）这类 OpenAI 兼容的聚合网关，在飞书自动化的 HTTP 节点里直接调多模态模型，效果不理想时换一个模型只改参数，不用重接一遍鉴权。