# 把关使用数据 (/zh/use-cases/research/user-insights)



<Callout type="info">
  **把关机制（SOP §6）**：任何数字或状态结论上线之前，必须先过四道关。**口径关**：算真人，不算访客（原始的独立访客数通常比真实活跃人数高出好几倍）；"活跃"指真的做了什么，不是被动收到一条消息；付费指真实发票，不是可能失效的埋点像素；地区看账户自己的时区，不看能伪造的 IP。**来源关**：确认的和推断的分开放在不同列里。群里听来的一句话不算共识，任何达不到实锤标准的说法都要标"未确认"，不能悄悄升级成事实。**自证关**：一个"0"或一次剧烈波动，先证明是真的再当结论汇报。先查一下是不是过滤条件写错了、或者 join 漏了数据，再相信这个数字。**状态关**：说"自动化在跑"需要有排期 ID 和运行记录可查；"我们打算做这个"不能写成"这个已经在跑了"。
</Callout>

复制粘贴下面这句话，快速开始你的第一个任务：

<Prompt>
  帮我建一个每日增长指标核验的自动化：先锁定”活跃”（真人且真的做了事，不是被动收到消息）和”付费”（真发票不是失效的埋点）到底指什么；遇到可疑的 0 或异常波动，先核实清楚是不是查询本身出错了，再当结论汇报；不同来源的数字要交叉核对一遍，渠道归因也列全，别漏掉那些没人记得查的渠道；每天在 #growth 发一份靠谱的日报，哪怕无事发生也发一行心跳记录，说清楚这个自动化是不是真的还在跑，而不是悄悄断了。
</Prompt>

<LivePreview component="NewThread" scenario="{ draft: &#x22;帮我建一个每日增长指标核验的自动化：先锁定“活跃”（真人且真的做了事，不是被动收到消息）和“付费”（真发票不是失效的埋点）到底指什么；遇到可疑的 0 或异常波动，先核实清楚是不是查询本身出错了，再当结论汇报；不同来源的数字要交叉核对一遍，渠道归因也列全，别漏掉那些没人记得查的渠道；每天在 #growth 发一份靠谱的日报，哪怕无事发生也发一行心跳记录，说清楚这个自动化是不是真的还在跑，而不是悄悄断了。&#x22; }" />

## 这个工作流是什么 [#这个工作流是什么]

把关使用数据，就是雇一位数据分析师队友，让 TA 当我们的增长数据中枢兼把关人，而不是一个只会跑查询、把结果贴出来的人。它产出一份结论先行的增长日报——真实日活、核心活跃、新增注册、付费——写下来之前先用第二个口径交叉核过；还有一份列全每一个真实来源的渠道归因报告，不是只看有人记得查的那两三个渠道。异动扫描默认沉默，只有真的有变化才开口；哪怕是无事发生的一天，也有一行"还活着"的心跳记录，让健康的沉默和悄悄断掉的自动化，从外部看起来不再是同一回事。

## 怎么用这个工作流 [#怎么用这个工作流]

<Steps>
  <Step>
    ### 雇用一位数据分析师：把 bio 写成这个角色，而不是通用模板 [#雇用一位数据分析师把-bio-写成这个角色而不是通用模板]

    打开左侧边栏的 **AI Teammates**，点击 **Hire AI Teammate**，选择**数据分析师**模板。模板默认的 bio 讲的是"把证据和决策连起来"这类通用描述。在 Profile 这一步把它换掉，让这位队友一开始就知道自己是把关人，不只是跑查询的：

    <Prompt>
      你是我们的增长数据中枢兼把关人，不只是拉数的。任何数字上线之前，先锁定口径（真人还是访客、主动活跃还是被动接收），用第二个口径交叉核实一遍，永远不要在没有排期 ID 和运行记录的情况下说自动化“在跑”。如果一个数字看起来不对劲，先证明查询本身没错，再把它当成一个发现来报告。
    </Prompt>

    确认名字后点击**创建队友**。它会落到自己的频道里，之后下面的内容都在那里发给它。[雇用详情 →](/ai-teammates/hire-an-ai-teammate)

    <LivePreview component="CreateAssistantPage" scenario="{ focus: &#x22;profile&#x22;, initialState: { start: &#x22;template&#x22;, templateRef: &#x22;@helio/data-analyst&#x22;, name: &#x22;数据分析师&#x22;, bio: &#x22;你是我们的增长数据中枢兼把关人，不只是拉数的。任何数字上线之前，先锁定口径（真人还是访客、主动活跃还是被动接收），用第二个口径交叉核实一遍，永远不要在没有排期 ID 和运行记录的情况下说自动化“在跑”。如果一个数字看起来不对劲，先证明查询本身没错，再把它当成一个发现来报告。&#x22; } }" />
  </Step>

  <Step>
    ### 连接能回答不同问题的数据源 [#连接能回答不同问题的数据源]

    SOP 讲得很明确：这些是彼此独立的真相源，不是同一块仪表盘。行为分析回答"谁访问了、点了什么"，业务数据库回答"他们实际做了什么"，账单流水回答"他们实际付了多少钱"。把这几个混在一起，正是"访客"被写成"用户"的常见原因。从技能市场加上 PostHog、Amplitude 或 MongoDB（这三个都是真实、可安装的 Helio 技能，不是假设中的连接器），再加上你自己的数仓或事件表所需的查询权限。日报里的付费数字还需要接上账单侧——账单实际所在位置的查询权限（账单数据库、数仓表，或定期的 Stripe 导出），上面那些行为分析工具没有一个能回答"他们实际付了多少钱"。[技能与插件 →](/connect/skills-and-plugins)

    <LivePreview component="AssistantSkills" />

    归因表（到底是哪个 UTM 或 KOL 链接带来了这个注册）是另一种来源，通常放在 Notion 里。把它作为一个 Tool 接到**集成**（Integrations）里，而不是当作技能，因为 Notion 是原生连接器。[连接你的工具 →](/connect/connect-tools-to-ai-teammates)
  </Step>

  <Step>
    ### 列全每一个真实来源，不是有人记得查的那两三个 [#列全每一个真实来源不是有人记得查的那两三个]

    归因表只有真的列全才有意义。一份只看到有人想起来查的那几个渠道的归因报告，不过是把一张不完整的图，包装成一个听着挺笃定的数字：

    <Prompt>
      上个月到底是哪个渠道带来的注册最多？
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;数据分析师&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;上个月到底是哪个渠道带来的注册最多？&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;把归因表里所有带 UTM 标记的链接和 KOL 追踪条目都拉出来了，不只是平时习惯查的那几个渠道。自然搜索排第一，占 34%，但排第二的是一条之前没人当成真实渠道盯着的 KOL 链接，占 19%。有 9 个注册完全没有归因标记，这些单独标出来，没有硬塞进某一个渠道的数字里。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 默认沉默，并证明一个安静的日子不是自动化悄悄停了 [#默认沉默并证明一个安静的日子不是自动化悄悄停了]

    心跳记录的意义不在于提醒本身，而在于没有提醒。没有任何指标触发阈值，从外部看应该和一个真的还在跑的自动化长得一模一样：

    <Prompt>
      今天异动扫描有什么要报的吗？
    </Prompt>

    <LivePreview
      component="AssistantChat"
      scenario="{ assistantName: &#x22;数据分析师&#x22;, messages: [
    { author: &#x22;user&#x22;, text: &#x22;今天异动扫描有什么要报的吗？&#x22; },
    { author: &#x22;assistant&#x22;, text: &#x22;早上 8 点检查过了，今天没有任何指标触发阈值：日活、新增注册、付费都在过去两周的正常区间内。不需要提醒，但把这条心跳记下来，这样一个安静的日子不会和一个悄悄停了的扫描看起来一样。&#x22; },
  ] }"
    />
  </Step>

  <Step>
    ### 把它变成每日增长日报：失败时也要说实话 [#把它变成每日增长日报失败时也要说实话]

    日报发向 `#growth`，而队友只能在自己加入过的频道里发言——先打开 `#growth` 把这位队友加进去，再打开左侧边栏的 **Automations**，点击 **Create via Chat** 下拉菜单，选中这位队友：

    <Prompt>
      每天早上 8 点，从行为分析工具拉真实日活、核心活跃、新增注册和访客 UV，从账单系统拉真实新付费、复购和存量付费。分别与昨天和上周同一天对比。关键数字在写下来之前，先用第二个口径交叉核一遍。往 #growth 发一份结论先行的日报，然后如果已经搭好了公开看板，只用脱敏聚合数据刷新它。如果拉不到数据或发不出去，如实报告失败原因。绝不假装成功。哪怕某天什么都没变，也要发一行带时间戳的记录，这样“健康的无变化”和“悄悄断掉的自动化”从外面看不会是同一回事。
    </Prompt>

    <LivePreview component="NewThread" scenario="{ populated: false }" />
  </Step>
</Steps>

**查询数据源和发布日报这两步都不需要你批准：** 从行为分析、账单、归因表里拉数据是读操作，往这位队友已经加入的频道发消息也没有触碰 Helio 之外的东西、不会留下不可逆的后果，所以这个流程不用等你签字。需要等你批准的情况见[控制](/ai-teammates/control)。

<Callout type="info">
  如果希望报告只呈现聚合、脱敏后的数据（不出现真实姓名、邮箱或某个具体用户的会话），请写进队友的指令里，并在扩大分享前抽查一遍产出。
</Callout>

## 用得更好的几个提示 [#用得更好的几个提示]

| 提示             | 说明                                                        |
| -------------- | --------------------------------------------------------- |
| 拉数之前先锁定口径      | "活跃"指真的做了什么，不是被动收到一条消息；付费指真实发票，不是埋点像素。这件事要在查询跑之前定好，而不是之后。 |
| 确认的和推断的分开放     | 群里听来的一句话不算共识。任何达不到实锤标准的说法都要标"未确认"，不能悄悄升级成事实。              |
| 报告可疑的 0 之前先自证  | 一个"0"或一次剧烈波动，先查是不是过滤条件写错了、或者 join 漏了数据，再当成一个发现来报告。        |
| 说"在跑"之前要有排期 ID | "自动化在跑"需要有排期 ID 和运行记录可查——打算做这件事，跟它已经在跑，从来不是一回事。           |

## 常见问题 [#常见问题]

<Accordions type="single">
  <Accordion title="这跟直接跑个查询、把数字贴出来有什么不一样？">
    每个数字上线之前都要先过把关机制：锁定口径、用第二个口径交叉核实，并证明一个可疑的 0 不是查询错了，然后才会被当成一个发现来报告。
  </Accordion>

  <Accordion title="日报里的“活跃”具体指什么？">
    指真的做了什么的人，不是被动收到一条消息的人。原始的独立访客数通常比真实活跃人数高出好几倍，所以日报把两者分开来看。
  </Accordion>

  <Accordion title="渠道归因报告怎么避免漏掉来源？">
    它是把归因表里所有带 UTM 标记的链接和 KOL 追踪条目都拉出来做的，不只是有人记得查的那两三个渠道。没有归因标记的注册会单独标出来，不会硬塞进某一个渠道的数字里。
  </Accordion>

  <Accordion title="为什么无事发生的一天，自动化也要发一条消息？">
    因为健康的沉默和悄悄断掉的自动化，从外部看本来就长得一样。带时间戳的心跳记录，就是用来证明它确实还在跑的。
  </Accordion>

  <Accordion title="这位队友能不能没有证据就说自动化“在跑”？">
    不能。状态关要求必须有排期 ID 和运行记录才能这么说——"我们打算做这个"不能写成"这个已经在跑了"。
  </Accordion>
</Accordions>

<Cards>
  <Card title="Research" href="/use-cases/research" description="返回研究场景总览。" />
</Cards>