Jitsu 的 warehouse-first 是什么意思?
warehouse-first 指的是：Jitsu 把你自己的数据仓库当作事件数据的最终落点和唯一可信来源，而不是把数据先交给某个第三方分析 SaaS 平台。事件从网站、App、服务器等来源被采集后，直接流进你选择的数据仓库，后续分析、共享、建模都在你自己的仓库里进行。它适合希望掌握数据归属、避免供应商锁定、并且已经有（或愿意使用）数据仓库的团队；如果你只想开箱即用、不打算维护仓库，这种模式未必是最省事的选择。
warehouse-first 的核心机制
传统分析工具的常见路径是：
用户事件 → 第三方分析平台（SaaS）→ 在平台内看报表
数据存在供应商的服务器上，你能用的分析能力受限于该平台提供的功能，导出和迁移往往有成本。
Jitsu 的路径是：
用户事件 → Jitsu 采集 → 你的数据仓库 → 用你喜欢的工具分析
根据 Jitsu 官网的描述，它把自己定位为“以最快速度把数据送达数据仓库”而专门设计的工具，并强调“让你的数据仓库成为数据的唯一可信来源”“统一数据且无供应商锁定”。
两者的关键差别在于数据归属和灵活性：
| 维度 | 直接写入分析平台 | Jitsu 的 warehouse-first |
|---|---|---|
| 数据存放位置 | 供应商服务器 | 你自己的数据仓库 |
| 供应商锁定 | 较强，迁移有成本 | 较弱，数据在你手里 |
| 分析工具选择 | 受平台功能限制 | 仓库之上可自由接工具 |
| 数据共享 | 依赖平台权限体系 | 由你自主控制 |
| 前期门槛 | 低，注册即用 | 需要有一个数据仓库 |
为什么“仓库为中心”会带来不同
把仓库设为终点，改变的不只是存储位置，还有三件事：
- 自主控制：数据在你自己可管理的基础设施里，访问、备份、删除由你决定。
- 便于共享：官网提到“与任何人共享数据”，因为仓库本身就是一个可以被多种工具读取的公共数据层，而不是锁在某个平台账号里。
- 面向分析的实时性：官网称可以从 App 实时把用户行为数据流到所选仓库，“几分钟而不是几小时”就能用于分析。
采集和写入是怎么完成的
官网把上手概括为三步，前两步是理解 warehouse-first 的关键：
- Capture（采集）：官网称“简单到像加一个 Google Analytics 标签”，从网站、App 以及其他用户触点采集事件。页面示例里给出了 HTML、React 等接入方式。
- Store（存储）：把数据写入数据仓库，以获得最大的自主权和控制权，并在此基础上共享数据。
- （第三步在页面中被截断，未完整给出）
在写入仓库之前，还可以用 Jitsu Functions 修改、过滤或增强事件。官网说明这些函数运行在 JavaScript 运行时环境中，因此可以使用 npm 包、库和键值存储等生态。页面给出的示例函数逻辑是：当事件类型为 identify 时，检查该邮箱是否已注册，若未注册则写入标记并向 Slack 发送新用户通知——这说明“在数据入库前做加工”是 warehouse-first 流程里的一个可编程环节。
谁适合用这种模式
更适合的情况：
- 你已经有数据仓库，或愿意把仓库作为数据分析的中心。
- 你在意数据归属，不希望被单一 SaaS 供应商锁定。
- 你需要把同一份事件数据交给多个分析工具或团队使用。
- 你有开发资源，愿意用 JavaScript 函数做事件加工。
可能不适合的情况：
- 你只想注册一个账号就看报表，不想碰仓库。
- 团队没有维护数据仓库的能力或意愿。
- 你的分析需求完全能被现成 SaaS 平台满足，且不介意数据放在对方那里。
关于价格和上手门槛
官网页面显示“Free for up to 200k events”（每月最多 20 万事件免费）以及“No credit card required”（无需信用卡），并提供了 Pricing 页面链接。是否长期免费、超出额度后的计费方式，需要以官网 Pricing 页面的最新说明为准，这里不做推断。
如果你要判断它是否值得用，可以先回答一个问题：你希望事件数据的最终归属是你自己的仓库，还是某个分析平台的账号？ 答案偏向仓库，warehouse-first 的价值就成立；偏向“开箱即用”，则优先考虑传统 SaaS 分析工具。