PostHog 收入分析侦察技能实战基于 signals-scout-revenue-analytics 的上游守门指南【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog收入分析Revenue Analytics是 PostHog 中典型的派生产品——它没有独立的事件流而是把团队配置的收入事件与Stripe 等支付平台经数据仓库管道同步的数据两条上游路径标准化进revenue_analytics_*托管视图charge、customer、mrr、product、revenue_item、subscription后供仪表盘消费。本文以仓库中 signals-scout-revenue-analytics/SKILL.md 为骨架讲解 PostHog Signals 侦察代理scout如何扮演上游守门犬当 Stripe 同步停滞或收入事件停止上报时仪表盘会无声地展示错误数字、财务基于过期数据做决策——这正是本技能的最高价值场景。读完本文你将掌握该侦察技能的完整运行协议、8 类高价值侦察模式、记忆管理与报告决策规则以及这些规则背后的视图构建源码依据。为什么收入分析侦察的核心是上游守门犬收入分析没有自己的事件流它只是把上游数据标准化成托管视图。因此对侦察代理而言上游健康 指标波动事件源团队通过RevenueAnalyticsConfig配置的收入事件如purchase_completed携带 revenue / currency / subscription 等属性数据仓库源Stripe当前唯一受支持的支付平台源见 orchestrator.py 中SUPPORTED_SOURCES [ExternalDataSourceType.STRIPE]及其他支付平台经数据仓库管道同步。当 Stripe 同步停滞或收入事件停止触发仪表盘静默失真——这类问题没有错误界面暴露给用户却是财务依据。MRR / churn / ARR 本身的变动反而是次要的因为团队通常已经在盯这些数字。收入数据具有高恐慌半径误报比任何其他领域更快侵蚀信任。文档给出的总原则是拿不准时写 scratchpad 记忆而不是发报告。快速收尾先判断收入分析是否激活每次运行的第一个动作不是深挖而是低成本判断该团队是否真的在用收入分析。检查两个信号external_data_sources中没有任何支付平台top_events中没有收入事件。两者皆空即判定收入分析未激活写一条 scratchpad 后空手收尾keynot-in-use:revenue_analytics:team{team_id}content简短说明如 checked at {timestamp}, no payment platform, no revenue events同一 key 重复运行会幂等地刷新时间戳条目保留到收入分析真正激活为止——届时下一次运行会重写或删除它。后续收入运行冷启动时读到此条目即可快速短路。一次运行的完整工作流每次运行在定位 → 探索 → 记忆 → 决策 → 收尾之间循环跳过不适用的环节。冷启动定位三个廉价读取scout-scratchpad-searchtextrevenue或textstripe——读取持久化的团队导向信息pattern:、noise:、addressed:、dedupe:前缀的条目以及团队已知的收入事件名、Stripe 源标签、货币构成、目标scout-runs-list近 7 天——此前收入运行发现了什么、排除了什么scout-project-profile-get——external_data_sourcesStripe 状态、top_events配置的收入事件触达量、popular_insights/recent_dashboards收入图表是否承载业务、product_intents卡住的 onboarding。画像形状今天什么在响画像特征通常含义Stripe 形态的external_data_sources行status failed或卡在running收入仪表盘静默过期——高影响上游守门场景配置的收入事件从top_events消失或急剧下滑捕获回归——MRR / 毛收入人为下降popular_insights包含收入图表且其数据源不健康已确认的下游影响——高置信发现product_intents列出收入分析但无 Stripe 源、无事件配置卡住的 onboarding——写记忆不发报告已知收入变动后近期仪表盘浏览量不变团队没在看——仪表盘存在但不承载业务八类高价值侦察模式以下模式是探索的起点而非清单每条都包含检测方法、验证手段与处理分级。1. 上游同步停滞仪表盘读数错误最高影响Stripe 或其他支付平台源 failed / stuck / cancelled/revenue仪表盘把昨天的 MRR 渲染成今天的。财务指标无声读错用户侧毫无错误表面。验证链external-data-sources-retrieve查 Stripe 源——status、last_run_at、错误字符串external-data-sync-logs判断失败模式是一次性还是周期性用execute-sql对system.insights查询爆炸半径哪些收入洞察/图表依赖该源SELECT * FROM system.insights WHERE name ILIKE %revenue% OR query::text ILIKE %revenue_analytics%用inbox-reports-list交叉检查是否已有开放的仓库源报告——若已有用append_note追加收入特有角度哪些财务指标错了而不是为同一仓库故障另写并行报告。关键认知仓库故障是恢复动作收入角度是业务影响散文——哪些仪表盘、谁在读、错多少。2. 收入事件捕获回归团队配置了purchase_completed或类似事件作为收入事件今天它从top_events消失或 24h 计数低于此前基线的 30%。事件源客户的 MRR 将人为偏低毛收入图表呈阶梯式骤降。廉价验证对事件跑query-trends14 天窗口确认下降真实且不是周末模式。配合read-data-schema event_properties检查收入属性本身是否停止流动事件仍触发但 revenue 为null——上游原因不同下游症状相同。满足以下条件即构成高置信发现14 天趋势呈清晰拐点而非正常周周期事件仍定义在RevenueAnalyticsConfig中团队没有故意改名近期部署 / SDK 升级时间与拐点吻合提示而非证据。3. 订阅属性缺失 → MRR 为空订阅制业务配置了事件源但RevenueAnalyticsConfig.events[].subscriptionProperty为null。PostHog 无法判断哪些 charge 属于同一订阅MRR 视图为空——仪表盘能渲染但只有毛收入有意义。检测特征事件配置了 revenue currency 但无订阅属性毛收入图表有数据而 MRR 图表为空。对刚上线的团队记 scratchpad 即可对上线已久、本应发现的团队值得发报告。4. 货币构成意外Currency mix surprise对托管视图revenue_analytics.all.revenue_analytics_charge执行聚合查询SELECT original_currency, count(), sum(original_amount) FROM revenue_analytics.all.revenue_analytics_charge WHERE timestamp now() - INTERVAL 30 DAY GROUP BY 1 ORDER BY 2 DESC从未出现过的货币、或份额突然跳升通常有两种解释(a) 团队在开拓新市场——写 scratchpad不发报告(b) 货币属性配置错误收入被错误标记——表现为非美元团队却出现单一主导货币反之亦然。用RevenueAnalyticsEventItem.currencyProperty交叉引用以区分二者。从源码看货币换算正是 schemas/_definitions.py 中BASE_CURRENCY_FIELDS的设计意图original_currency/original_amount保留原始值currency_aware_divider/currency_aware_amount处理零小数货币JPY、KRW 等并换算为团队基准货币最终产出currency/amount两个真正被消费的字段。5. Stripe 客户 ↔ PostHog 人关联断裂Stripe 客户应携带posthog_person_distinct_id元数据PostHog 才能把收入挂到人档案上。若新创建客户停止携带该元数据结账流程部署后回归聚合视图仍正常但人级收入分组分析、客户旅程会变暗。该元数据键定义在 sources/constants.pyPOSTHOG_PERSON_DISTINCT_ID_METADATA_KEY posthog_person_distinct_id。检测查customer视图比较近 30 天与之前 30 天非空posthog_person_distinct_id的客户数。团队未使用人级收入功能则记 scratchpad正在使用检查popular_insights中是否有人维度收入图表则值得报告。6. 递延收入未递延Deferred revenue not deferringStripe 源健康但发票行项目缺少period属性。仪表盘会把年度订阅一次性落入单月呈现月度收入 lumpy而非按服务期分摊。检测查revenue_item视图找is_recurring true且period_start/period_end为null的行。当超过约 20% 的周期性行缺少 period 信息时发报告——财务报表以微妙方式出错。7. 目标未达但无升级Goal miss without escalationRevenueAnalyticsConfig.goals携带due_dategoalmrr_or_gross。若某目标的due_date距今不足 14 天且当前 MRR或毛收入趋势低于目标团队本应已在行动若近期仪表盘浏览量没有上升说明没人看。暴露差距由团队决定。排除条件due_date已过期且团队未更新的目标——那是配置债务而非活跃目标记 scratchpad 即可。源码注记在 team_revenue_analytics_config.py 中_goals字段已标注DEPRECATEDrevenue analytics goals were removed with the dashboard; column retained; do not read or write。SKILL.md 仍保留了目标监控模式作为侦察协议的一部分实际运行时若发现该字段已被移除应降级为 scratchpad 记忆而非报告。8. 测试账户污染RevenueAnalyticsConfig.filter_test_accounts false且项目配置了基于person.properties.email的测试账户过滤。内部 QA 计费被计为真实收入。源码层面该开关对应 team_revenue_analytics_config.py 中的filter_test_accounts models.BooleanField(defaultFalse)——默认关闭需要主动开启。通常记 scratchpad 即可若 scratchpad 显示团队历史上问过收入一夜暴增且原因就是 QA 流量则值得报告。记忆管理把观察沉淀为可检索的条目记忆是持续活动。每当观察到未来收入运行应知道的信息就写 scratchpad 条目并用 key 前缀编码类别使未来运行单次text搜索即可命中pattern:revenue_analytics:event-config— 收入事件为purchase_completedrevenue 属性为revenue分、currency 属性为currency、订阅属性为subscription_id。pattern:revenue_analytics:stripe_prod— Stripe 源stripe_prod是团队主源stripe_test是沙箱其失败属预期。pattern:revenue_analytics:currency-mix— 报告货币为 USDoriginal_currency常规包含 EUR / GBP / CAD——多货币构成对该团队是常态。pattern:revenue_analytics:q3-arr-goal— 团队已配置收入目标Q3 ARR 目标为 $Xdue_date 2026-09-30——每月复查进度。pattern:revenue_analytics:dashboard-staleness— /revenue仪表盘最后查看于 2026-04-22团队未积极关注——以更高置信阈值发报告。addressed:revenue_analytics:test-accounts— filter_test_accounts关闭example.com账户的 QA 计费进入收入——已提出团队已知晓。report:revenue_analytics:stripe_prod— 2026-06-30 为停滞的stripe_prod同步撰写了报告0193…MRR 毛收入仪表盘读数过期下次运行若源仍失败编辑它。reviewer:revenue_analytics:billing— 计费 / 收入界面负责人为octocat——收入源报告路由到此处。到第 5 次运行时scratchpad 已掌握团队的收入配置、货币构成、哪些仪表盘承载业务、财务是否在积极关注——当回归发生时发现自带正确上下文落地。决策规则编辑、新建、记忆还是跳过撰写报告前先确认该源 / 指标是否已有报告。report:revenue_analytics:entity指针是最可靠路径——它持有report_id可直接inbox-reports-retrieve。无指针时退回inbox-reports-list搜索ordering-updated_at按源标签 / 指标 / 仪表盘 id。对每个候选编辑Edit当收件箱已覆盖该源或指标用scout-edit-report编辑现有报告。收入问题很少全新——Stripe 源仍失败、收入事件仍低迷用append_evidence追加最新状态与收入特有影响哪些指标错了、错多少或重写你撰写的报告标题/摘要。先检查匹配报告的状态edit-report无法改状态向resolved/suppressed/failed报告追加会埋没真实复发——先前报告不再活跃时应撰写新报告并将report:revenue_analytics:entity指向新 id。若数据仓库侦察或管道已提交仓库源故障报告用append_note追加收入角度而非为同一上游故障另写并行报告。新建Author收件箱无活跃覆盖时用scout-emit-report新建。强发现标准置信度 ≥ 0.85evidence含具体仪表盘 id、源标签、视图名与量化影响哪个财务指标错、错多少、谁在读。若发现是指标变动MRR 阶梯、收入悬崖而非配置缺口通过charts附上受影响的序列使拐点与起始时间可见。收入发现几乎总是调查任务而非一行代码修复——失败源的恢复动作在仓库而非代码 PR——因此设actionabilityrequires_human_input不设priority/repository。务必设置suggested_reviewers用scout-members-list解析负责人每个成员携带已解析的github_login缓存在reviewer:revenue_analytics:areakey 下或证据已点名负责人时传{user_uuid}。这是报告触达人类的唯一途径留空则无人认领、大概率被错过。撰写后写report:revenue_analytics:entityscratchpad 条目记录report_id让下次运行编辑它而非重复创建。记忆Remember低于报告门槛但值得带往前或记录你排除了什么及原因用scout-scratchpad-remember。跳过Skip若noise:/addressed:/dedupe:前缀的 scratchpad 条目或现有收件箱报告已覆盖跳过并留一行说明。报告通道契约字段 schema、safety × actionability 状态映射、审阅者路由、非幂等性警告、编辑规则由 harness 提示词完整携带本节只补充收入特有的框架。鉴于收入的高恐慌半径保持高撰写门槛更少、更好、路由正确的报告。收尾总结本次运行——一段话看了什么、撰写或编辑了哪些报告、记住了什么、排除了什么。harness 会把这段总结写入运行记录作为可检索文本未来运行通过scout-runs-list读取。不要另写运行元数据 scratchpad 条目——运行总结已承担该职责。排除条件跳过这些报告货币刚变更——所有图表呈现明显阶梯变化并非回归。先前运行的pattern:条目通常会标记此情况。团队套餐中收入分析处于 beta——部分团队仅作预览使用。scratchpad 应记录无记录则写一条并跳过。沙箱 / 测试 Stripe 源——test_或sandbox_前缀意味着团队在接入联调这里的失败不是生产信号。团队重命名了收入事件——RevenueAnalyticsConfig.events[].eventName近期更新过事件缺失其实是旧名称。标记前先交叉检查配置的时效性。目标过期且无跟进——配置债务而非活跃目标记 scratchpad 后跳过。拿不准时写记忆条目而不是发报告。MCP 工具清单直接调用只读external-data-sources-list/external-data-sources-retrieve——Stripe 源健康度source_type过滤支付平台external-data-sync-logs——失败历史区分一次性与周期性上游问题read-data-schema events/read-data-schema event_properties——确认收入事件与属性仍在流动query-trends——用 14 天窗口和同比验证事件量下滑execute-sql对revenue_analytics.all.revenue_analytics_charge|customer|mrr|revenue_item|subscription——托管视图是事实来源。按源也存有视图source.prefix.revenue_analytics_view_type数据仓库与revenue_analytics.events.event_name.revenue_analytics_view_type事件——命名规则见 core.py 的view_prefix_for_event事件名非字母数字字符替换为下划线与view_prefix_for_sourcesource_type.lower().[prefix]execute-sql对system.insights/system.dashboards——找出依赖失败源爆炸半径的收入洞察与仪表盘dashboards-get-all/dashboard-get——内置收入仪表盘与自定义收入仪表盘data-warehouse-data-health-issues-retrieve——平台检测到的仓库源问题收入是最高优先级的下游消费者之一。Harness 级scout-project-profile-get/scout-scratchpad-search/scout-runs-list/scout-runs-retrieve——定位 去重inbox-reports-list/inbox-reports-retrieve——撰写前查找既有报告scout-emit-report/scout-edit-report——撰写 / 编辑报告报告通道契约在 harness 提示词中scout-members-list——项目成员及其解析后的github_login用于suggested_reviewers路由scout-scratchpad-remember——跨运行持久记忆。深入调查时沙箱镜像内置了posthog:auditing-warehouse-source-health在收入分析上游捕获 Stripe 源失败与posthog:diagnosing-failed-warehouse-syncs失败同步的恢复动作。停止条件无支付平台 无收入事件 → 写not-in-use:条目后空手收尾画像 scratchpad 显示稳定图景 → 空手收尾候选匹配noise:/addressed:/dedupe:前缀的 scratchpad 条目 → 跳过已验证部分假设、撰写或编辑了确定的内容 → 收尾即使还有可查的。更少、更好的报告——尤其在恐慌半径高的领域。看了但没发现有意义的东西也是一种真实结果。源码佐证派生视图是如何构建出来的SKILL.md 中反复引用的revenue_analytics_*托管视图并非手工维护而是由 views/README.md 描述的构建器模式自动生成┌─────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌───────────────┐ │ Sources │───▶│ Builders │───▶│ Orchestrator │───▶│ View Objects │ │ Events/Stripe│ │ Transform │ │ Coordinates │ │ HogQL Query │ └─────────────┘ └──────────────┘ └─────────────────┘ └───────────────┘Sources定义如何从不同系统提取数据sources/events/转换 PostHog 事件、sources/stripe/转换 Stripe 表Schemas定义 6 类视图Charge、Customer、MRR、Product、Revenue Item、Subscription的标准化输出格式如 mrr.py 定义 MRR 视图字段source_label/customer_id/subscription_id/mrr始终是当前时间的 MRROrchestrator在 orchestrator.py 中遍历每个配置的收入事件 每个启用的 Stripe 源生成SourceHandle对每个 handle 按 view kind 跑注册的 builder产出带 schema 字段的视图实例Views是注册进 HogQL 数据库 schema 的最终查询视图名为{source_type}.{prefix}.{view_suffix}如stripe.prod.charge_revenue_view。侦察代理用execute-sql直查的revenue_analytics.all.revenue_analytics_charge等聚合视图正是这套构建链路的产物。理解这条链路就能理解侦察模式背后的机制Stripe 源 failed 会中断视图刷新模式 1事件属性停滞会污染事件源视图模式 2订阅属性缺失会让mrr字段无值可算模式 3货币换算字段依赖original_currency正确标记模式 4。最后值得强调SKILL.md 中RevenueAnalyticsConfig是 Django 层 team_revenue_analytics_config.py 的TeamRevenueAnalyticsConfig模型filter_test_accounts、eventsJSON 字段含subscriptionProperty/productProperty/couponProperty与收入分析相关的配置、测试账户过滤逻辑都可在此模型及products/revenue_analytics/backend/views/目录下找到实现。侦察技能文档、前端配置界面revenueAnalyticsSettingsLogic.ts与后端构建链路共同构成了 PostHog 收入分析从配置到观测的完整闭环。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考