Marketing

零代码搭一个营销分析师：Airtable + Claude + Slack 三小时搞定

零代码搭一个营销分析师：Airtable + Claude + Slack 三小时搞定
目录

某个周二早上 9:14，一家中型电商公司的增长负责人在频道里敲了 /analyst blended CAC by channel this month。11 秒后，Slack 弹回一条消息：一张小柱状图，外加一句 "付费社媒 $48，Google $62，邮件 $14，综合 $39。邮件最便宜，差 3.4 倍 —— 要不要我看看放量瓶颈在哪？" 她截了图，丢进董事会频道，回去继续喝咖啡。

造出这个答案的系统一个月花 99 美元的工具费，由一个从来没写过一行 Python 的市场经理用一个周末搭出来。在我看来，这是 2025 年一个小型营销团队能搭出的最有用的一套东西 —— 但几乎没人真在搭，因为大家都在等那个一年 4 万美金的 BI 平台，而 BI 平台被数据团队无限期排在后面。

这是它的搭法。三个小时，四个数据源，一条 Slack 命令。搭完你拥有的是一个不用睡觉、不请年假、用普通话回答问题的营销分析师。

架构一段话讲完

Airtable 是数据库。它装四张表 —— 渠道投放、GA4 流量、邮件表现、CRM 归因收入 —— 全部按日期和渠道主键。每天早上，四个自动化（每路数据一个）刷新一次行。Claude 是分析师大脑：它接收用户提问，去对应的 Airtable 表里查数据（走一条轻量的 API 调用），然后产出一段结构化答案，结尾带一个图表规格。Slack 是界面：一条斜杠命令 /analyst <问题> 触发一个 Airtable 自动化，自动化调 Claude，拿到答案，把结果作为一张渲染好的图发回频道。整体活动部件三个。代码量：零，前提是你用 Airtable 自带的脚本能力和 Slack 自带的工作流步骤。

2025 年能搭、2022 年搭不出来的原因，是 Claude 能看懂 "按渠道看本月综合 CAC 是多少" 这类问题，自己判断该查哪张表、用什么过滤、什么图最能回答。在 2022 年你得把每个问题都硬编码进去。现在你写一次表结构，剩下 Claude 来干。

第一个小时：Airtable 基表

第一个小时最重要。数据模型搞错，Claude 会信心十足地用垃圾回答你所有问题。搞对，剩下的搭建就是喝杯咖啡的事。

四张表。 每张表都带 Date 和 Channel 字段，这是下游所有联表的主键。除此之外，表结构故意压得很窄：

  • Channel_Spend（渠道投放）—— 一行 = 一渠道一天。字段：Date、Channel（Meta、Google、TikTok 等）、Spend、Currency。
  • GA4_Sessions（GA4 会话）—— 一行 = 一渠道一天。字段：Date、Channel、Sessions、Engaged_Sessions、Conversions（GA4 关键事件）、Revenue（购买事件，从 GA4 电商模块拉）。
  • Email_Performance（邮件表现）—— 一行 = 一封发送。字段：Send_Date、Campaign_Name、Recipients、Delivered、Opens、Clicks、Conversions、Revenue。
  • CRM_Attributed_Revenue（CRM 归因收入）—— 一行 = 一渠道一周。字段：Week_Start、Channel、New_Customers、Returning_Customers、Net_New_ARR 或 Net_Revenue（看你的模型）。

每张表都按渠道+日期主键的原因是：营销团队问的几乎所有问题，都是这两个维度的一个切片。"CAC by channel this month" 就是 CRM_Attributed_Revenue.New_Customers 除以 Channel_Spend.Spend，按渠道分组，过滤本月。Claude 一旦拿到表结构，几乎能模式匹配到任何问题。

同步方式。 MVP 阶段不要搭实时管道。用 Airtable 的 CSV 导入，或者更好 —— 用 Airtable 自带的 Google Sheets 同步。模式：每个 Google Ads / Meta Ads / Klaviyo / HubSpot 报表配一个每日触发器（Google Sheets 里的 time-based 触发器 30 秒搞定），把数据落进一个 Google Sheet，Airtable 再去同步这个 Sheet。表结构双向同步，数据单向。不好看。但是能用。

GA4 的话，最简单的零代码路径是官方的 GA4 → BigQuery 导出，再写一个 BigQuery → Google Sheets 的定时查询按渠道+日期聚合。如果觉得太重，用 GA4 Reporting API 走 Airbyte 或 Coefficient 这种免费的连接器。这个阶段的目标不是优雅。目标是每天早上 9 点之前拿到昨天的数。

计算字段。 加几个 Airtable 公式字段，把最常用的指标预计算好：

  • 日汇总视图里的 Blended_CAC = Channel_Spend.Spend ÷ CRM_Attributed_Revenue.New_Customers（每渠道每天）
  • Email_Performance 里的 Email_Revenue_Per_Recipient = Revenue ÷ Recipients
  • Channel_Spend 里的 ROAS = CRM_Attributed_Revenue.Net_Revenue ÷ Spend

这些是 Claude 第一反应会去查的指标。提前做成列，Claude 就不必在提示词里现场算，数学上也不会错。

第一个小时结束你应该有：四张表，每张至少塞 30 天的历史数据，每张配好每日刷新，再加几个公式列。打开 Airtable 的界面设计器，做一个叫"Marketing Snapshot"的视图，把四张表按日期+渠道 join 起来。后面用它肉眼对一下答案。

第二个小时：Claude 提示词

这是整套系统里最核心的一块，所以别跳过迭代。多数团队写一行提示词、收到一次烂答案、然后断定 AI 不好用。第二个小时的任务，是写一条能扛住 50 种不同问题的提示词。

系统提示词。 在 Airtable 里建一张"Prompts"表，只放一条记录，Body 字段是完整的系统提示词。Body 就是你和 Claude 之间的合同 —— 改一次，整个分析师跟着变。从下面这个骨架开始，再去定制：

你是一名营销分析师。你能访问这个 Airtable 基表里的四张表：
- Channel_Spend: {Date, Channel, Spend, Currency}
- GA4_Sessions: {Date, Channel, Sessions, Engaged_Sessions, Conversions, Revenue}
- Email_Performance: {Send_Date, Campaign_Name, Recipients, Delivered, Opens, Clicks, Conversions, Revenue}
- CRM_Attributed_Revenue: {Week_Start, Channel, New_Customers, Returning_Customers, Net_Revenue}

你的工作：用数字 + 图表 + 一句话结论，回答用户的问题。

步骤：
1. 识别问题要的指标（比如 CAC、ROAS、转化率）。
2. 识别需要哪张表、对应什么公式。
3. 识别时间窗口和分组维度。
4. 从 Airtable API 拉相关行。用户没指定窗口时，默认"过去 30 天"。
5. 计算指标。必须估算时，标 "(est.)"。
6. 返回严格按下面这个 shape 的 JSON：
   {
     "answer_short": "<一句话，普通话>",
     "table": [["渠道", "数值", ...], ...],
     "chart_type": "bar" | "line" | "number",
     "chart_title": "",
     "x_label": "",
     "y_label": "",
     "caveat": ""
   }

规则：
- 永远不要编数字。数据缺失时返回 {"answer_short": " 数据缺失"}，table 为空。
- 图表标签必须带单位（$, % 等）。
- 问题有歧义时（比如"营销最近怎么样"），挑最可能的指标（净新增收入，周环比）并说明你的假设。
- 问题跟营销数据无关时，礼貌拒绝。

这条提示词要长，是因为 Claude 的纪律性完全取决于你给它的合同。"永远不要编数字" 是最重要的一行。没这句，Claude 会在数据不全的那几天画出一张漂亮但虚构的图。有这句，Claude 就会说 "TikTok 2025-10-04 数据缺失"，团队也就信任这个系统。

Exemplar 模式。 系统提示词之后，追加 5–8 个 worked example。格式是 Q: ... A: ...，A 是完整的 JSON 返回结构。这是让输出稳定最有效的杠杆。两个 example 比十段说明都有用。覆盖范围：一个 CAC 问题、一个时间趋势问题、一个"这周变了什么"的问题、一个有歧义的问题（让 Claude 看到"先说假设"的行为）、一个系统答不了的问题（让 Claude 看到拒绝模式）。5 个 example 之后，提示词几乎不会再翻车。

Claude 怎么看到数据。 两种走法。第一种：把相关行直接内联在提示词里喂给 Claude。小切片（单渠道 × 30 天 = 30 行）完全够用，远低于 Claude 的上下文上限。第二种：让 Claude 走 tool-use 自己去调 Airtable API。v1 我会选第一种 —— 简单、没 MCP server、没授权折腾。第二种留到你切片超过 200 行再升级。

走第一种的话，处理斜杠命令的那个 Airtable 自动化负责拉数据（一次过滤调用），把行格式化成 markdown 表，附加在系统提示词 + 用户问题之后发给 Claude。总时延：拉数据 2–4 秒，Claude 5–10 秒。整条往返 15 秒以内，足够快，快到大家真的会用。

第二个小时结束你应该能挑那 5 条 exemplar 问题，配上 mock 数据贴给 Claude，拿到正确 shape 的 JSON。做到这一步，提示词就能上线。

第三个小时：Slack 命令和图表

最后一个小时写代码最少，但用户体验收益最大。一个团队能按的按钮，价值抵得过十个他们得记着去打开的仪表盘。

Slack 斜杠命令。 在你的 Slack workspace 里建一条自定义斜杠命令 /analyst，指向一个 Airtable 自动化 webhook。斜杠命令的 body 就是问题文本。自动化收到后：

  1. 解析问题，猜该用哪张表（关键词匹配："CAC" → CRM + Spend，"open rate" → Email，"sessions" 或 "traffic" → GA4）。问题模糊时，默认一个"summary"调用，返回过去 30 天四张表的合计。
  2. 从 Airtable 拉相关行。
  3. 拼提示词：系统提示词 + 数据表 + 用户问题。
  4. 调 Claude API（Anthropic 的 messages.create 端点，模型 claude-sonnet-4-5）。
  5. 解析 JSON 响应。
  6. 渲染图表。柱状图最快的上线方式是 QuickChart.io 的 image API —— 把 Chart.js config 当 URL 传过去，拿到一张 PNG。数字类直接 post answer_short。折线图同样的 QuickChart 套路。
  7. 把图 + 一句话结论 post 回频道，Slack step 用 respond。

响应结构。 每条答案都是一条 Slack 消息，三部分：一句话回答、一张图、一个 footer 标数据时间戳（比如"数据截至 2025-10-12，06:00 UTC 刷新"）。这个时间戳不能省 —— 它是团队一眼能看出"我看的是昨天的数还是上周二的数"的唯一办法。没它，每条答案都会跟一句 "这是最新的吗？" 的追问，工具价值打对折。

聊天快捷模式。 大多数人其实不想每次都敲 /analyst。上线最快被采纳的模式是做一个 Slack Workflow，触发词是频道里的 "@analyst"。机器人读出 @ 后面的内容当作问题，在 thread 里 post 答案。这就是我那个客户电商版在用的模式。斜杠命令兜底用，@ mention 是日常驱动接口。两种都搭，多花 20 分钟。

第三个小时结束你应该能在测试频道敲 /analyst what's our blended CAC by channel this month，15 秒内拿到一张柱状图。能做到这一步，搭建就完成了。

四个大坑

这四件事不提前知道，会把你周末吃掉。

坑 1：渠道命名漂移。 Meta 把 "Facebook" 改成 "Meta" 的那天，你的投放表里写 Meta，CRM 里还写 Facebook，Claude 拼出来的表静默丢掉一半数据。修法是一张 Channel 映射表 —— 一行 = 一个逻辑渠道，配每个数据源里出现的名字。入库时花 20 分钟把名字归一化，一劳永逸。每个季度审一次。

坑 2：货币混用。 欧洲电商团队最爱的 bug。投放表是 EUR，CRM 收入是 USD，综合 CAC 算成错币种。两种解法：(a) 入库时按日汇率换算；(b) 每个数值字段带一个 Currency 字段，让 Claude 算之前先换。建议 (a)，入库时就换，不要丢给提示词处理。

坑 3：跑题幻觉。 第一次有同事敲 /analyst 伦敦天气怎么样 的时候，Claude 会真的答它。团队信任会瞬间蒸发。修法是系统提示词加两行："如果问题跟这四张表的数据无关，返回 {"answer_short": "我只能回答跟营销数据相关的问题"}。" 单独写个测试用例。再在 exemplar 块里加一条拒绝模式的例子。

坑 4：大问题的上下文窗口。 哪天有人敲 /analyst 把过去 12 个月每个渠道的周度 ROAS 都拉出来对比一下，你会撞上下文上限。修法是在 Airtable 里预聚合：建一张 Weekly_Channel_Summary 表，把日数据卷积上去。长窗口走 Summary 表，短窗口走日表。Airtable 脚本根据问题里的时间跨度挑表。30 分钟的活，但要在董事会会议上有人问之前先做好。

这套东西给你的真正价值

零代码分析师的重点不是那张图。图是最容易的部分。重点是团队和数据的关系会变。当 "CAC by channel 是多少" 的回答时间从 20 分钟（找仪表盘、找对标签、过滤、截图）压到 11 秒，问题的形态就会变。大家开始问更好的问题，因为提问成本变成零。

另一件会变的是谁在问。零代码分析师对用户的职衔没有任何意见。CEO、实习生、客户成功负责人、财务伙伴 —— 11 秒内拿到一样的答案。大多数小型营销团队的数据瓶颈不是数据，是分析师的日程表。这套系统在频道里铺了一层薄薄的分析师。

一年 4 位数美金的 BI 工具，14 周后给你同样的答案。3 小时的搭建，周一就给你 80% 的价值。先把 80% 搭起来。剩下那 20% —— 等你真用了一个月，你会知道它该长成什么样。