订阅
套餐、MRR、状态——活跃、试用中或已取消——货币和开始日期,直接来自 Stripe。
一条主线,四个面
到底有什么会落在主线上
同一条共享记录,四种读法。点一下就能看到每个账户身上都带着什么——行为、工作、对话和收入,全部挂在同一个身份上。
每一个事件,都在记录上
产品分析和网站分析数据,以第一方方式采集,并关联到它们所属的账户。
- 产品分析和网站分析统一在一个身份上
- 会话、功能、页面和设备——按账户划分
- 打通匿名、注册和付费三种状态
示例数据
反馈和交付,连在一起
- 机会点、洞察和反馈都关联到账户
- 路线图、Sprint 和发布都在同一条记录上
- 每个任务都能追溯到需要它的那个客户
支持和会议,都带着上下文
- 聊天、支持工单和会议纪要都挂在账户上
- 每一段对话旁边,都能看到促成它的那个行为
收入也在主线上
- 从你的账单连接器同步每个账户的 MRR 和 ARR
- 按涉及的收入排优先级,而不是按投票数
- 从功能到代码再到收入,全程可追溯
360
打开一个账户,不用再开一堆标签页。
每个客户公司一页。他们付了多少钱、提过什么要求、都有谁、下次什么时候聊——全部从你的连接器里汇总而来,没有人手动重新输入过。
Insights
打在这个账户上的每一条反馈——需求、缺陷、评价——都带着各自的来源。
会议
通过你的预约链接生成的预约都会落在这里:访客、主持人、活动类型、时间。
联系人
具名的那些人——买家、champion、CTO——都带着邮箱。Stripe 给你公司信息;人要你自己加上去。
数据来源
每个连接器对应一个圆点:实心表示这个客户已经有数据了,空心表示还没有。用不着去猜哪些已经接上了。
外部 ID
Stripe 的 cus_* 和 CRM 的标识符都挂在这条记录上——这样同一个客户永远不会被拆成两条。
360 页面里的 Behaviour、Work 和 Conversation 面板,会随每个连接器逐个上线——底层的关联关系已经写好了;对应的连接器上线,面板就会跟着点亮。
身份匹配
alice@fernwood.co 登录了。Fernwood 的记录就会亮起来。
当事件或 SDK 数据带着用户邮箱到达时,主线会自动把域名匹配到对应的账户上。不用上传 CSV,不用手动合并,不会出现重复客户。
- ✓写入时就把邮箱域名匹配到账户上。每个产品用户都会变成一条挂在其公司名下的终端用户记录。
- ✓外部 ID 也一样会被解析——Stripe 的客户 ID 和 CRM 的标识符,都指向同一条记录。
- ✓每一次匹配都会被记录下来:方法、置信度、状态。是一条你随时能查的审计轨迹——不是黑箱。
信号 alice@fernwood.co
匹配 域名 fernwood.co → Fernwood & Co
方法 email_domain
状态 已确认 · 审计记录已写入
示例数据——真实的审计轨迹存在于每一次匹配上。
主线上的收入
他们付的钱,跟所有东西都挂上钩。
接入 Stripe 之后,你的客户和订阅数据几秒钟内就会自动补全。从那以后,收入就不再是一份你要跑一遍才能看到的报表——它是这条记录上的一列,其他一切都往它上面挂。
- ✓每一份订阅都在这条记录上:套餐、MRR、状态、货币、开始日期。
- ✓有多份订阅?账户会按状态优先级挑一份最有代表性的展示出来。
- ✓流失情况就在你工作的地方就能看到:已取消的状态直接显示在客户记录上——不需要每月去查一张表格。
- ✓按名字、域名或外部 ID 搜索任何客户——按一下键就行,不用来回切换工具。
- ✓按订阅状态筛选,按 MRR 排序。你最大的那些客户,自然就排在列表最前面。
- ✓每一行都带着域名、套餐和收入——这份列表本身就是一份免费的收入视图。
反馈和工作,连在一起
每个任务都知道是谁提出的要求——以及他们付多少钱。
给任意一条 insight 打上账户标签,360 就会把这个客户提过的所有要求都汇总起来。把一个任务分配给某个账户,选择器上就会直接显示这笔钱——Fernwood & Co · 每月 5,000 美元。原因会跟着这项工作一起流转。
- ✓Insight → 账户:反馈、需求和缺陷报告,都会堆积在提出它们的那个客户身上。
- ✓任务 → 账户:下拉列表里每个账户都带着自己的 MRR,所以选一个客户,其实就是在选一份分量。
- ✓打开任务详情,客户、他们的套餐和收入都直接显示在卡片上——不用再开第二个标签页。
目前客户和 MRR 只会显示在任务详情页里;看板和列表里的行,暂时还不会按任务显示 MRR。
主线上的事件
使用数据一到就已经是关联好的。
每一个分析事件在写入时就已经关联好了——账户和终端用户信息就搭在事件那一行上。「这个客户过去 30 天做了什么?」只是一次索引查询,不需要跨身份表做 join。
- ✓关联发生在数据摄入的那一刻,不是靠夜间批处理——事件一落地,就已经知道自己属于哪个账户。
- ✓按账户和按用户查询事件都建了索引——就是为了「给我看看这个客户的使用情况」能快速跑出来。
- ✓等分析连接器上线,360 页面里的 Behaviour 面板就会直接从这个关联关系里读取数据——数据早就已经准备好了。
事件 feature_used · export_csv
用户 alice@fernwood.co
账户 Fernwood & Co · $5,000/mo
已关联 写入时就完成——查询时不需要再做扇出计算
示例数据
360 页面里的 Behaviour、Work 和 Conversation 面板会按连接器逐个开启——底层的关联关系今天就已经存在,面板会随着每个连接器上线而逐一点亮。目前来自代码工具的工作项,是通过功能间接关联到账户的,不是直接关联。这个页面上没提到的东西,产品里目前都还没有。
FAQ
常见问题
产品主线是什么?
每位客户一条记录——Stripe 订阅和 MRR、反馈、会议和联系人,都汇总在同一个 Account 360 里——每个模块都会读取和写入这条记录。它是整个操作系统赖以运行的共享骨架。
记录之间是怎么被拼接到一起的?
通过邮箱域名和外部 ID 完成匹配,并带有审计轨迹——这样同一个客户的付款、反馈和对话,都会汇总成一个 360 视图,而不是散落在各个工具里。
为什么共享数据模型很重要?
这就是「连接」和「整合」的区别。当反馈、工作、收入和沟通都写入同一条主线时,每个决策背后的「为什么」早就已经关联好了——不需要导出数据,也不需要在六个工具之间来回核对。
主线能告诉我,我们上线的东西到底有没有效果吗?
能。因为工作、功能和客户都在同一条记录上,每个上线的任务都自带自己的结论。采用率涨了吗?MRR 变了吗?这些账户留下来了吗?「我们上线的东西是否有效」这个结论,直接从主线上就能读出来——不需要另外做研究,也不需要导出 BI 报表。
我的数据会和其他客户的隔离开吗?
会——AIOProductOS 是多租户架构,按组织做行级隔离,所以每家公司的主线都和其他租户的严格隔开。
分析事件会和账户绑定在一起吗?
会——每个分析事件在生成时就已经预先关联到对应的账户,所以行为数据、收入和反馈,全都挂在同一条客户记录上,而不是活在一个独立的分析数据孤岛里。