1. 为什么我会把Amplitude交给AI助手一个增长分析师的工作流改造1.1 传统用户行为分析的三个痛点先自报家门。我做增长数据分析有几年了Amplitude 一直是我日常离不开的产品分析工具看漏斗、拉留存、拆事件属性、查用户路径基本都在上面完成。以前每次接到分析需求我的工作流都是固定的登录 Amplitude 控制台在图表编辑器里拖组件、选条件、写 AMPQL等查询结果出来再复制到文档里整理成结论。这套流程能用但有几个痛点随着团队变大越来越明显。第一个痛点是事件命名漂移。公司早期埋点规范不够严同一个功能在不同版本可能叫sign_up_submit、signup_submit甚至还有中文事件名混在里面。每次做漏斗或留存我都要先去事件字典里校对口径、去数据明细里抽样验证不然出来的数字没人敢拍板。这个校对过程极其消耗精力而且又枯燥偏偏不能出错。第二个痛点是跨团队取数效率低。运营、产品、客服隔三差五来问“最近7天新用户次周留存是多少”“购物车页面转化率环比变化怎么样”。每个问题背后几乎都要先确认口径新用户是看首次打开还是首次注册次周留存包不包含当天平台要不要区分App 版本呢一次两次还好天天这么搞分析师就成了人肉查询机器真正需要投入脑力的归因分析和策略建议反而没时间做。第三个痛点是工具门槛。Amplitude 的 AMPQL 和 SQL 查询能力很强但团队里不是每个人都愿意去学那套语法。数据明明就在系统里但要从系统里取出一个“有效结论”中间还隔着一层专业技能。这层技能本来应该是增长分析师的价值所在但也把非专业同学挡在了自助探索的门外人人都想看数最后全挤到一个人身上。1.2 MCP把数据能力接到 AI 助手的“手”上后来 MCPModel Context Protocol开始流行我最大的感受是AI 终于能“动手”了。MCP 是一个标准化的上下文协议它定义了 AI 助手怎么发现外部工具、怎么调用外部工具、外部工具的结果怎么回传。打个比方你可以把它理解成一个 USB-C 接口只要是支持 MCP 的客户端插上符合协议的服务器就能让大模型调用一系列真实能力而不再只是基于静态知识库聊天。Amplitude 官方也提供了对应的 MCP Server。这意味着支持 MCP 的 AI 客户端——比如 Claude Desktop、Claude Code、Cursor以及一些支持远程 MCP 的 IDE——可以直接调用 Amplitude 的数据查询能力。你用自然语言说“分析一下最近7天注册漏斗的转化”AI 会自己去查事件、跑漏斗、拉取结果再按你的要求整理成表格或结论。这等于给团队配了一个“永不睡觉的初级数据分析师”。它不会完全取代资深分析师但能把大量取数、核对口径、产出图表的过程接走让真正做判断的人把时间留给策略。对增长黑客这个角色来说尤其值得因为增长工作本身就是高频假设验证提出假设、拆指标、看数据、调整策略。这套循环如果每个环节都靠人手去跑迭代速度根本跟不上市场变化。2. Amplitude MCP Server 的能力拆解不只是“跑查询”2.1 常用分析工具事件分段、漏斗和用户路径打开 Amplitude MCP Server 的能力清单你会发现它把产品分析的核心模块几乎都暴露成了工具调用。官方版本一直在迭代我没必要把 API 名一个一个写死但能力底座基本可以分成这几类。事件分段Event Segmentation按时间范围、事件类型、筛选条件、分组维度、统计口径事件次数、去重人数、人均次数、平均值去查数据。比如“按平台分组看近两周purchase_complete事件的发生人数和人均次数”。这是日常取数最常用的能力几乎每个增长分析都要用到。漏斗分析Funnel Analysis给出一串事件序列和转化窗口返回每一步的用户数、转化率和流失率。经典用法是“把view_home到view_product到add_to_cart再到purchase_success拉成漏斗按周对比”。漏斗结果自带每一步的转化数据不用你再一个个去拼。用户路径User Paths把一批用户在一段时间内的行为序列聚合起来找出典型路径。对首页改版、新手引导流程优化特别有用能回答“大多数新用户去了哪里”“卡在哪个环节”这类问题。留存分析Retention定义初始事件和回访事件按日、按周、按月看留存曲线。增长团队关注的次周留存、月留存都能直接拿。用户回放 / 用户时间线User Activity查询单个用户的完整事件流水。用户调研、客服申诉、异常行为排查这些场景会用到MCP 能把时间线原样带回来。看板与已存查询Dashboards Queries部分版本支持列出已保存的 Dashboard 和查询让 AI 直接拉已有的图表数据而不是每次重新写一套分析逻辑。2.2 更底层的 AMPQL/SQL 直接执行除了封装好的分析工具Amplitude MCP Server 还提供直接执行 AMPQL 或 SQL 的能力。这意味着如果你知道自己要什么可以跳过预制图表让 AI 现场生成语法并执行。举个例子我想看每日活跃用户数SELECT DATE_TRUNC(day, event_time) AS day, COUNT(DISTINCT user_id) AS active_users FROM events WHERE event_type app_open AND event_time 2025-01-01 GROUP BY 1 ORDER BY 1如果你是第一次接触这个可能不觉得这有什么特别。但请留意一个关键差异MCP 的价值不只是“会写 SQL”而是“写完 SQL 能拿真实数据”。以前用 ChatGPT 写 AMPQL得到的只是文本语法复制回 Amplitude 还可能要改版本、调参数现在 AI 直接关联你的项目环境执行返回真实结果集报错之后还能自己修语法再跑一次。这个差别对工作流的影响是颠覆性的——分析闭环被真正缩短了从“人写查询、人跑数”变成了“AI 写查询、AI 跑数”。2.3 多维下钻按渠道、版本、实验组切片真实业务分析和 Demo 最大的区别在于指标总要被切成很多维度。幸运的是Amplitude MCP 的工具普遍支持分组维度和全局筛选按平台、地区、营销渠道、App 版本、实验组来切。比如“按渠道和操作系统分组统计最近30天新手引导完成率”这种多维下钻在自然语言对话里可以直接表达。不过这里也要提醒一句并不是所有产品分析工具的 MCP 都有这种深度。市面上有些刚出的 MCP Server 只能查报表标题和元数据连事件字段都拿不到。所以技术选型时一定先去读官方 MCP 的 README确认支持哪些参数、返回哪些字段不要看到“官方提供”四个字就想当然。字段越细后面能做的分析才越深。3. 从零配置 Amplitude MCP Server认证、配置和连通性排查3.1 认证方式怎么选API 密钥还是 OAuthAmplitude MCP Server 支持两种认证方式选哪种取决于你的使用场景。第一种是项目级的 API Key 和 Secret Key在 Amplitude 控制台的 Project 设置页面可以找到。这种适合个人本机开发或固定项目使用配置简单把两个密钥写进环境变量就能跑。我建议为 MCP 单独创建一个专用密钥而不是直接复制当前项目在用的主要密钥这样以后要回收权限也方便。第二种是 OAuth2 认证。适合公司统一管理权限的场景团队成员用自己的 Amplitude 账号授权管理员可以在后台做细粒度的访问控制。对团队协作者来说OAuth 更安全密钥不用散落在每个人的配置文件里成员离职后权限也能随账号一起回收不需要挨个去替换密钥。我个人的建议是个人电脑上试用或做个人原型API Key 最快团队共享、多人协作、上生产环境优先用 OAuth 集中式授权实在不行也要用只读角色密钥并且把密钥放在环境变量或系统密钥管理器里不要直接贴到聊天对话框。3.2 配置步骤以 Claude Desktop 为例拿 Claude Desktop 举例你需要在配置文件claude_desktop_config.json的mcpServers字段里新增一条。配置好之后重启客户端就能生效。{ mcpServers: { amplitude: { command: npx, args: [-y, amplitude/mcp-server], env: { AMPLITUDE_API_KEY: 你的_API_Key, AMPLITUDE_SECRET_KEY: 你的_Secret_Key } } } }这里有几个细节值得注意。命令不要乱改。npx -y是确保运行时不卡在安装确认步骤的关键有些人改成npx amplitude/mcp-server后客户端静默失败就是因为安装确认没法自动通过。如果公司内部走 npm 私有镜像源先在本地命令行跑一次npx amplitude/mcp-server确认它能不能正常启动再写进客户端的配置文件。否则客户端的日志里只会留下一行莫名其妙的退出记录排查起来很费劲。如果你的 Amplitude 项目在欧盟或特定数据驻留区域环境变量里要额外加上对应的 API 地址否则所有请求都会返回 404。这个细节在官方文档里写得很清楚但很容易被跳过。一些支持远程 MCP 的客户端可以直接配置远程服务器地址不走本地进程。这种方式团队统一管理更方便但要先确认你的账号有权限访问远程 MCP 网关。我见过最荒唐的配置错误是把 API Key 和 Secret Key 填反了。这两个字段长得像但权限完全不对填反之后接口一样会返回错误。遇到这种情况先检查密钥位置再检查环境变量里有没有多余的空格或换行然后再去看日志。3.3 连通以后先做什么检查配置完不要急着问复杂问题先用最基础的方式验证链路。发一个“读取当前项目信息”或“列出可用工具”的指令如果 AI 能返回项目基本信息和工具清单说明连接已经打通了。如果报错排查顺序一般是密钥是否正确位置是否填反环境变量里有没有多余字符npx 进程是否能正常启动本地网络能不能正常拉取 npm 包客户端日志里的 MCP 进程 stdout/stderr 输出信息比报错弹窗全得多。Claude Desktop 的日志目录在 macOS 和 Windows 上位置不同但本质上思路一样去看 MCP 进程自己打印了什么。很多时候问题不在 Amplitude而在 npm 环境或者系统 PATH 配置上。4. 增长黑客实战自然语言调用 Amplitude 的完整套路4.1 一个完整的分析会话长什么样假设运营同学跑过来问“上周 iOS 新用户的购买转化率为什么下降了”过去我要人工拆成好多步骤去查现在我可以直接在 AI 客户端里说“用漏斗分析查一下最近14天 iOS 平台新用户里view_product到add_to_cart再到purchase_success的转化率按周拆分。如果最近7天相比前7天下降超过5%再补一个用户路径分析看看流失用户的典型行为是什么。”AI 收到指令后会做这样几件事先调漏斗分析接口拿两段窗口的转化数据再对比数字发现下降集中在add_to_cart到purchase_success这一步然后调用户路径接口看单品页、购物车页、结算页的流转最后返回一份带关键结论的简短报告。你会发现在这个过程中人的角色变成了检查和追问AI 才是执行。检查者不需要会写 AMPQL但必须把业务口径描述清楚。所谓的“描述清楚”就是事件名、时间范围、平台、用户群、对比方式都讲明白。AI 再聪明也不应该去猜你的口径否则返回的结果可能和你心里想要的东西根本不是一回事。4.2 我沉淀下来的高频提示词模板在实际工作里我攒了几套高频场景的提示词模板可以直接套用新用户激活分析“统计最近30天新用户的激活事件first_complete或first_order耗时分布按渠道分组列出激活率最低的5个渠道。”留存分析“按周统计最近8周的新用户以首次激活时间为准看他们在后续第1周、第2周、第4周的留存率。”流失预警“查找最近7天内有login_failed事件且没有purchase_success事件的用户数量按地区分组。”实验分析“对比实验组和对照组的checkout_start到checkout_success转化率计算提升幅度和样本量。”我在每个模板后面都会固定补一句“如果某个事件名不存在请告诉我不要自己猜测替换成别的名字。”这句话能有效减少一次最典型的 AI 幻觉。事件名猜错后面整个分析结果都会歪而且歪得毫无察觉比报错还可怕。还有一点非常重要AI 返回的数字再快首次使用时也要抽几个口径跟人工跑出来的结果交叉验证。因为接口返回的指标定义可能和你预期的不完全一致。比如活跃用户是“发生过任意事件的用户”还是“发生过指定事件的用户”系统定义和你脑子里默认的定义可能差出几个百分比这种差异只能靠人工校对来发现。4.3 把 Amplitude MCP 放进更大的 AI Agent 工作流单独一个 Amplitude MCP 已经够好用但它更大的价值在跟其他 MCP 组合成流水线。打个比方单一 MCP 是一个工具多个 MCP 联合起来才是一条生产线。比如你可以同时连接数据库 MCP、团队文档 MCP 和消息通知 MCP。增长周会前AI 自动从 Amplitude 拿最近一周的核心指标从数仓拿 CRM 侧数据从文档知识库拿上次会议结论然后汇总生成一份周报草稿。这套流程在不少成熟团队里已经跑起来了。核心并不是某一个 MCP 有多强而是数据孤岛被打通了。增长分析最终要落到行动行动要追进度进度又要回到数据验证MCP 能把这几个环节焊接在一起减少大量来回搬运的琐碎工作。5. 必须重视的数据口径、API 限额和权限安全5.1 数据口径AI 不会替你做业务判断这是我在实践里感受最深的一点。Amplitude MCP 返回的“活跃用户”“新用户”“留存”这类指标系统里当然有默认定义但你自己业务里的定义不一定和它一致。举一个最常见的例子在 Amplitude 里“新用户”通常指首次上传该用户事件的用户可产品同学口里的“新用户”往往是完成注册的用户。这两个口径算出来的结果能差出不少。所以在提示词里要把口径写死事件名、用户群定义、时间窗口、平台、版本、对比基准。宁可多敲几个字也别让 AI 猜。一旦发现 AI 返回的口径不对马上纠正它然后明确要求它在后续所有分析里沿用同一套口径。这是使用所有数据分析类 MCP 的底层纪律不是 Amplitude 独有的问题。5.2 API 限额和大数据量查询的应对方式Amplitude 作为 SaaS 服务接口当然有配额限制。MCP Server 帮你连续调用多个接口后很可能触发限流表现就是查着查着突然收到 429 或者请求超时。大型项目、高事件量项目尤其容易出现。我的经验是别一口气问一个超大的时间范围。需要覆盖90天的数据就拆成三段30天来跑需要看全量用户路径就明确要求只取代表性抽样用户。还有一个实用做法是让 AI“先探索、后深挖”先看聚合值确认某个方向有异常再往下钻明细。这样既减少 API 消耗也避免生成大量无意义的结果。响应超时是另一个常见现象。你可以明确告诉 AI“返回结果控制在100行以内”或“只列出 Top 10”这能有效防止工具结果被截断。不要把所有明细都倒出来MCP 传输的数据量是有边界的我们要的是能支撑决策的洞察不是一坨无法消化的原始日志。5.3 权限与安全别把全家桶钥匙放在一台电脑上最后聊安全虽然不性感和直接但必须讲。Amplitude MCP 相当于给你电脑上的 AI 客户端发了一把能读取用户行为数据的钥匙。如果这把钥匙被配置在共享环境里等于把大量用户隐私数据暴露给所有能接触到这台机器的人。我建议至少做到下面几项创建只读角色的专用 API 密钥给 MCP不要用管理员密钥密钥放在本机环境变量或系统级密钥管理器里不要写进聊天记录不要提交到 Git 仓库团队场景统一走 OAuth 或集中式 MCP 网关避免每个成员各自复制一份密钥定期轮换密钥员工离职时及时回收权限。不要因为步骤繁琐就跳过。增长数据是公司最敏感的数据之一一旦泄露轻则违反数据合规要求重则直接影响用户信任。我一直觉得MCP 就像给你配了一辆好车但再好的车出发前也得先系好安全带。6. 再分享一个让我少踩两次坑的小习惯前面讲的都是框架和流程最后说两个我自己用着很顺手的细节。第一个是在跟 AI 对话时养成“把口径写进上下文”的习惯。比如问“新用户激活率”我不会只甩给 AI 一句“激活率是多少”而是会写成“激活事件完成首次核心行为新用户注册后7天内时间窗口最近30天平台全部”。这样看起来啰嗦但换来的是 AI 每次查数据都基于同一套定义不会这次按注册算、下次按首次启动算。数据团队也好个人复盘也好最怕的就是口径漂移。第二个是定期让 AI 把曾经执行过的成功查询整理成文档沉淀成团队模板。MCP 好用但历史会话会丢失重新问一遍同样的问题AI 可能要重新摸索。我每隔两周会把跑通过的、结论清晰的自然语言查询指令整理成一篇笔记下次同类需求直接复用。时间长了这套模板就是团队的增长分析资产比任何一份培训 PPT 都实用。Amplitude MCP Server 不是银弹它不会让一个没数据意识的人突然变成增长黑客但它能把“取数—验证—洞察—行动”这条链路中的重复劳动压缩到极低。真正有产品判断力的人会把省下来的时间花在业务假设和实验设计上这才是增长黑客应该做的事。
