InfiniSynapse
Product analytics: the quick answerProduct Analytics 产品分析：快速回答
Product analytics is the practice of collecting and analyzing user-level behavior data to understand how people reach value, where they struggle, what brings them back, and which product changes improve outcomes. It connects named events and stable identities to methods such as funnels, paths, cohorts, retention and feature adoption. A useful analysis ends with a decision, a testable expectation and a check that the data and result are trustworthy.
Product Analytics 产品分析，是收集并分析用户级行为数据，用来理解用户如何获得价值、在哪里受阻、为什么回来，以及哪些产品改动真正改善结果的实践。它把有明确名称的事件与稳定身份连接到漏斗、路径、分群、留存和功能采用等方法。有效分析最终必须落到一个决策、一个可检验预期，以及对数据与结果可信度的检查。
Product analytics becomes useful when dashboards show that a metric moved but not which behavior changed. The discipline fits digital products with repeatable actions—sign up, invite a teammate, run a report, save a project, renew—when a team needs to relate those actions to activation, engagement, retention or revenue. It is less useful when the core experience cannot be observed through digital events, when identities cannot be handled responsibly, or when the decision depends mainly on qualitative motives. Interviews, usability studies, support conversations and market research remain necessary companions.
当仪表盘只能告诉团队“指标变了”，却不能说明“哪种行为发生了变化”时，人们就会搜索产品分析。只要数字产品会产生可重复动作——注册、邀请同事、运行报告、保存项目、续费——团队就能把这些动作与激活、参与、留存或收入联系起来。若核心体验无法通过数字事件观察、身份数据不能被负责任地处理，或决策主要依赖用户动机，产品分析的作用就会降低。访谈、可用性测试、客服对话和市场研究仍是必要补充。
What is product analytics, and what is it not?什么是产品分析，它不是什么？
Product analytics studies behavior inside a product at the level needed to support product decisions. The basic record is usually an event: a user or account performed an action at a time, with properties that describe context. Analysts transform those records into a sequence, funnel, cohort, retention curve, segment or metric. The goal is not merely to report activity. It is to connect observed behavior to a decision such as simplifying onboarding, improving discovery, changing a default, fixing a failure, or prioritizing an experiment.
产品分析在足以支持产品决策的粒度上研究产品内行为。基础记录通常是事件：某个用户或账户在某个时间执行了某个动作，并带有描述上下文的属性。分析者把这些记录转换成序列、漏斗、分群、留存曲线、细分或指标。目标不只是报告活动量，而是把观察到的行为连接到具体决策，例如简化新手流程、改善功能发现、修改默认值、修复失败点或确定实验优先级。
| Discipline领域 | Primary question核心问题 | Typical data常见数据 | Best use最适用途 |
|---|---|---|---|
| Product analytics产品分析 | What do users do after they enter the product?用户进入产品后做了什么？ | Events, identity, properties, cohorts, accounts事件、身份、属性、分群与账户 | Activation, journeys, adoption, retention激活、旅程、采用与留存 |
| Web analytics网站分析 | How did traffic arrive and behave on pages?流量如何到达并浏览页面？ | Sessions, page views, referrers, campaigns会话、页面浏览、来源与活动 | Acquisition and content performance获客与内容表现 |
| Business intelligence商业智能 | What is happening across the business?整个业务正在发生什么？ | Governed warehouse facts across domains跨业务域的治理后仓库事实 | Repeatable reporting and shared metrics可重复报告与共享指标 |
| User research用户研究 | Why do people think, feel or struggle?用户为什么这样想、感受或受阻？ | Interviews, observation, surveys, usability访谈、观察、问卷与可用性测试 | Motives, unmet needs and explanations动机、未满足需求与解释 |
These categories overlap. A product team may use web analytics for acquisition, a product analytics tool for behavior, a warehouse and BI layer for governed metrics, and research to explain motives. The important boundary is the question, not the vendor label. Physical-product quality analysis, portfolio analysis and product-market sizing address different problems and are outside this guide.
这些类别会重叠。产品团队可能用网站分析处理获客，用产品分析工具研究行为，用数据仓库与 BI 管理可信指标，再用用户研究解释动机。真正的边界是问题，而不是供应商标签。实体产品质量分析、产品组合分析和市场规模测算属于不同意图，不在本指南范围内。
The most useful distinction is the unit of evidence. Web analytics usually begins with a visit, page or acquisition channel. BI usually begins with governed business facts and recurring reporting. Product analytics begins with the actor and the sequence of product actions that may lead to value. It therefore supports questions such as whether invited teammates activate faster, whether a new workflow changes time to value, or whether a feature is used again after discovery. This focus overlaps with behavioral analytics, while the narrower user behavior analytics guide goes deeper into observing and interpreting individual and segmented product behavior.
最实用的区分方式是看证据单位。Web Analytics 通常从访问、页面或获客渠道开始；BI 通常从治理后的业务事实和周期报告开始；产品分析则从行动主体以及可能通向价值的一连串产品动作开始。因此它适合回答：受邀成员是否更快激活、新工作流是否改变价值实现时间、功能被发现后是否会再次使用等问题。这一重点与行为分析重叠；更聚焦的用户行为分析指南将进一步讲解如何观察并解释个人与细分群体的产品行为。
Use product analytics when the decision depends on what happened inside a digital product and can be represented with defensible behavioral evidence. Do not use it alone when the question is why a person felt confused, whether a market need exists, or whether a change caused an outcome. Interviews and usability studies explain motives and comprehension; market research tests demand; experiments or appropriate causal methods test effects. A strong product decision combines these forms of evidence instead of forcing event data to answer every question.
当决策取决于数字产品内部发生了什么，并且能够用可辩护的行为证据表示时，适合使用产品分析。如果问题是用户为什么感到困惑、市场需求是否存在，或某项改动是否造成结果，就不能只依赖产品分析。访谈与可用性研究解释动机和理解，市场研究检验需求，实验或合适的因果方法检验影响。稳健的产品决策应组合多种证据，而不是强迫事件数据回答所有问题。
The data foundation: events, identity, sessions and accounts数据基础：事件、身份、会话与账户
Analysis quality begins before a chart exists. A tracking plan should start from a decision and work backward to a metric, behavior and event. An event name describes an action; event properties describe its immediate context; user or account properties describe the actor at an appropriate point in time. The Amplitude data-planning documentation similarly treats taxonomy as the definition of events, properties and naming conventions. The principle applies regardless of tool.
分析质量在图表出现之前就已决定。追踪计划应从决策出发，反向推导到指标、行为和事件。事件名称描述动作，事件属性描述当时上下文，用户或账户属性描述行动主体在相应时间点的特征。Amplitude 数据规划文档也把 taxonomy 定义为事件、属性与命名规范的体系；这一原则与具体工具无关。
A meaningful action such as Project Created or Report Exported. Prefer stable business language over UI details such as Button Blue Clicked.
有业务意义的动作，例如“创建项目”或“导出报告”。应优先使用稳定业务语言，而不是“点击蓝色按钮”这类界面细节。
A consistent user or account key. Define anonymous-to-known merges, shared devices, bots, deleted users and cross-device behavior explicitly.
一致的用户或账户键。匿名到已登录的合并、共享设备、机器人、已删除用户与跨设备行为都要明确处理。
Context such as plan, feature version, platform, source or workspace size. Record whether a property reflects event time or the current profile.
套餐、功能版本、平台、来源或工作区规模等上下文。必须说明属性反映事件发生时状态，还是当前档案状态。
Choose time zone, session rule, deduplication key and late-arrival policy. A user-level metric and an account-level metric are not interchangeable.
确定时区、会话规则、去重键与迟到事件策略。用户级指标和账户级指标不能互换。
Before implementation, create a small event dictionary containing owner, purpose, trigger, required properties, prohibited sensitive fields, identity unit, example payload and validation query. Avoid tracking every click. Too little data leaves questions unanswered; indiscriminate tracking creates noise, cost and privacy risk. For a practical companion on event collection and tracking-plan quality, see the clickstream analytics guide.
实施前应建立精简事件字典，至少记录负责人、目的、触发条件、必需属性、禁止采集的敏感字段、身份单位、示例载荷和验证查询。不要采集每一次点击。数据太少会留下问题，盲目采集则增加噪声、成本与隐私风险。关于事件采集与追踪计划质量，可继续阅读点击流分析指南。
Model the entities before the events. A user is usually a person, a session is a bounded period of interaction, and an account is the organization, workspace or household that receives value collectively. These are analytical choices, not universal facts. A session can be inactivity-based, task-based or app-lifecycle-based. An account membership can change over time. Store membership and plan history with effective timestamps when historical segmentation matters; otherwise today's account property can rewrite the apparent past.
先建模实体，再建模事件。User 通常是个人，Session 是有边界的一段互动，Account 是共同获得价值的组织、工作区或家庭。这些都是分析选择，并非普遍事实。Session 可以按无活动时间、任务或应用生命周期划分；账户成员关系也会随时间变化。如果历史细分重要，应使用生效时间保存成员关系和套餐历史，否则今天的账户属性可能会改写过去。
Treat event properties as part of the contract. A Report Exported event may require report_id, export_format, workspace_id, client_timestamp, server_timestamp and result. Optional properties should still have documented types and null meaning. Prefer controlled values over free text for fields used in grouping. Never place passwords, tokens, message bodies or unnecessary personal data in analytics payloads. Define deletion and retention behavior with privacy and security owners before collection begins.
把事件属性视为契约的一部分。“Report Exported”事件可能要求 report_id、export_format、workspace_id、client_timestamp、server_timestamp 与 result。可选属性也要记录类型和空值含义。用于分组的字段优先使用受控值，而不是自由文本。不得把密码、令牌、消息正文或不必要的个人数据放进分析载荷；采集开始前应与隐私和安全负责人确定删除与保留规则。
Naming should remain stable when the interface changes. Use an object-action pattern such as Workspace Created, Data Source Connected and Report Shared; document tense and capitalization once; version semantics only when meaning changes. Avoid creating a new event for every button, screen or experiment variant. Raw ordered event streams can later support clickstream analytics, but trustworthy paths still depend on identity, ordering, duplicate handling and noise rules defined here.
界面变化时，事件命名应保持稳定。可采用“对象 + 动作”模式，例如 Workspace Created、Data Source Connected 与 Report Shared；统一时态和大小写；只有语义改变时才做版本化。不要为每个按钮、页面或实验变体创建新事件。原始有序事件流之后可以支持点击流分析，但可信路径仍依赖这里定义的身份、排序、去重和噪声规则。
Core product analytics methods and the questions they answer核心产品分析方法及其回答的问题
A method is useful only when it matches the decision. Event counts reveal scale but hide sequence. Funnels impose an expected route. Path analysis explores routes without fixing all steps in advance. Cohorts align users by a shared start or behavior. Retention asks whether value repeats. Segmentation compares meaningful groups. Adoption measures whether a feature reaches, activates and continues serving the intended audience.
只有方法与决策匹配时才有价值。事件计数显示规模，却隐藏顺序；漏斗设定预期路线；路径分析在不预先固定全部步骤的情况下探索路线；分群按共同起点或行为对齐用户；留存判断价值是否重复；细分比较有意义群体；采用分析衡量功能是否触达、激活并持续服务目标用户。
| Question问题 | Method方法 | Required care关键注意 |
|---|---|---|
| Where does an expected flow lose users?预期流程在哪里流失用户？ | Funnel analysis漏斗分析 | Order, eligibility and conversion window顺序、可进入人群与转化窗口 |
| What do users do before or after an event?某事件前后用户做了什么？ | Path analysis路径分析 | Noise filtering, loops and event taxonomy噪声过滤、循环与事件体系 |
| Do users return and repeat value?用户是否回来并重复获得价值？ | Cohort retention分群留存 | Start event, return event and interval起始事件、回访事件与周期 |
| Who adopts a feature and keeps using it?谁采用功能并持续使用？ | Feature adoption功能采用 | Eligible denominator and meaningful use合格分母与有意义使用 |
| Which behavior is associated with an outcome?哪种行为与结果相关？ | Segmentation and comparison细分与对比 | Selection bias; association is not causation选择偏差；相关不等于因果 |
User journeys and path analysis without false certainty用户旅程与路径分析：避免虚假的确定性
A customer journey is a conceptual model from acquisition through activation, engagement, retention and possibly revenue. A path is an observed sequence of events. Do not confuse the planned journey with what actually happened. Start from a decision event—activation, successful export, upgrade, cancellation—and inspect a limited number of steps before or after it. Remove heartbeat events, background refreshes and repetitive technical noise, while preserving failures and state changes that explain friction.
客户旅程是从获客到激活、参与、留存乃至收入的概念模型；路径则是实际观察到的事件序列。不要把计划中的旅程当作真实发生的行为。应从一个决策事件开始，例如激活、成功导出、升级或取消，检查其前后有限步数。过滤心跳、后台刷新和重复技术噪声，但保留能够解释摩擦的失败与状态变化。
Path frequency alone does not identify the best route. Popular paths may reflect defaults, repeated errors or a large low-value segment. Compare paths for users who reached a defined outcome with paths for eligible users who did not, then examine differences by platform, acquisition source, role or account type. Treat the result as a hypothesis generator. To claim that a path caused retention, use a suitable experiment or stronger causal design.
路径频率本身不能识别“最佳路线”。热门路径可能只是默认设置、重复错误或一个规模很大但价值较低的群体。应对比达到明确结果的用户与有资格但未达到结果的用户，再按平台、获客来源、角色或账户类型检查差异。路径结果用于生成假设；若要声称某条路径造成留存，需要合适实验或更强的因果设计。
Map the journey in two layers. The first is a lifecycle model—acquisition, activation, engagement, retention and revenue—that gives teams a shared vocabulary. The second is observable evidence: entry source, first value event, repeated value, collaboration or upgrade behavior, and exit signals. Each lifecycle stage can contain many paths, and a user can move backward, pause or use several devices. A customer journey analytics guide should connect these stages across channels; dedicated path analysis methods focus on the ordered behavior inside those stages.
旅程可以分两层绘制。第一层是生命周期模型——获客、激活、参与、留存与收入——为团队提供共同语言；第二层是可观察证据：进入来源、首次价值事件、重复价值、协作或升级行为，以及退出信号。每个生命周期阶段都可能包含多条路径，用户也可能后退、暂停或跨设备使用。客户旅程分析指南用于跨渠道连接这些阶段；专门的路径分析方法则聚焦阶段内部的有序行为。
Set a time boundary and an analysis unit before comparing routes. A five-minute sequence may explain interface friction, while a thirty-day account journey may explain collaborative activation. Collapse repeated events only when repetition adds no meaning; a sequence of failed imports can be more informative than a single failure flag. When paths fragment into thousands of variants, group stable event categories, anchor on a meaningful start or end, and show both path share and the underlying number of eligible users.
比较路线前应设置时间边界与分析单位。五分钟序列可能解释界面摩擦，三十天账户旅程则可能解释协作激活。只有当重复不增加含义时才合并重复事件；连续多次导入失败可能比单个失败标记更有信息。当路径分裂为数千种变体时，应按稳定事件类别聚合，以有意义的起点或终点锚定，并同时展示路径占比和合格用户基数。
Funnel analysis: define eligibility before drop-off漏斗分析：先定义资格，再讨论流失
A funnel measures the share of eligible users or accounts that complete ordered steps within a window. A useful funnel definition specifies the population, first step, step order, allowed repetition, conversion window, counting unit and completion event. “Signup conversion” is ambiguous until those choices are written down.
漏斗衡量合格用户或账户在规定时间窗口内完成有序步骤的比例。一个可用漏斗必须明确人群、第一步、步骤顺序、是否允许重复、转化窗口、计数单位与完成事件。在这些选择写清楚之前，“注册转化率”只是模糊名称。
- State the decision. Example: decide whether to simplify workspace invitation during onboarding.写明决策。例如：决定是否简化新手流程中的工作区邀请步骤。
- Define eligible users. Exclude returning administrators, bots, internal testers and users who never saw the flow.定义合格用户。排除回访管理员、机器人、内部测试者以及从未看到该流程的用户。
- Choose steps and a window. Separate required value steps from optional navigation and set a period that reflects the task.选择步骤与窗口。区分必要价值步骤和可选导航，并设置符合任务周期的时间范围。
- Segment the loss. Compare absolute lost users and step conversion by platform, version, source and account type.细分流失。按平台、版本、来源和账户类型比较绝对流失人数与步骤转化。
- Inspect evidence. Join errors, latency, support tickets or research notes before choosing a fix.检查证据。在选择修复方案前，关联错误、延迟、客服工单或研究记录。
The largest percentage drop is not automatically the best opportunity. Consider absolute users lost, downstream value, effort, risk and whether the step is intentionally selective. A payment verification step may lose many users while protecting fraud controls. A small drop at a high-value enterprise setup step may matter more.
百分比流失最大的位置不一定是最佳机会。还要考虑绝对流失人数、下游价值、投入、风险，以及该步骤是否有意进行筛选。支付验证可能损失大量用户，却保护了反欺诈控制；企业高价值设置步骤即使流失比例较小，也可能更重要。
Report both overall conversion and step conversion. Overall conversion divides completers by eligible starters; step conversion divides each step by the preceding eligible step. Also report the absolute drop, because a modest percentage loss near the top can involve more people than a dramatic percentage loss near the bottom. For unordered workflows, use a milestone or any-order funnel instead of silently forcing an order. For repeated transactions, decide whether the first attempt, best attempt or every attempt is counted.
应同时报告整体转化与步骤转化。整体转化用完成人数除以合格起始人数；步骤转化用每一步除以前一步的合格人数。还要报告绝对流失，因为漏斗顶部不大的百分比流失可能涉及更多用户。对于无固定顺序的工作流，应使用里程碑或任意顺序漏斗，而不是暗中强加顺序；对于重复交易，则要决定计算首次尝试、最佳尝试还是每次尝试。
Segmentation is most useful when chosen before inspecting the chart: new versus returning, web versus mobile, plan, role, acquisition source, release version or account maturity. Avoid slicing until a tiny group produces an exciting number. Minimum sample rules and uncertainty intervals help prevent overreaction. The deeper funnel analysis guide covers construction and diagnosis; funnel optimization focuses on prioritizing interventions and verifying that a change improves the intended outcome without harming guardrails.
预先选择的细分最有用，例如新用户与回访用户、Web 与移动端、套餐、角色、获客来源、发布版本或账户成熟度。不要不断切片直到某个极小群体出现“令人兴奋”的数字。最小样本规则和不确定性区间有助于避免过度反应。深入的漏斗分析指南讲解构建与诊断；漏斗优化则聚焦干预优先级，以及如何验证改动在不损害护栏的情况下改善目标结果。
Cohort analysis and retention: measure repeated value分群与留存分析：衡量重复价值
A cohort is a group that shares a start time or behavior. Acquisition cohorts group users by when they signed up. Behavioral cohorts group users by what they did, such as using collaboration within the first week. Retention then asks whether a defined unit returns to a defined value event in later intervals. Calendar retention, rolling retention and unbounded retention answer different questions, so label the method.
分群是一组拥有共同起始时间或行为的对象。获客 cohort 按注册时间分组；行为 cohort 按执行过的动作分组，例如第一周使用协作。留存随后判断某个定义单位是否在后续周期回到某个价值事件。日历留存、滚动留存与无界留存回答不同问题，因此必须标明方法。
Choose a return event that represents value, not mere presence. “App Opened” may be suitable for a daily consumer app but weak for a monthly accounting workflow. A B2B product may need account-level retention because several teammates jointly receive value. Compare cohorts at the same age: week-4 retention for one cohort against week-4 retention for another. Do not compare a mature 12-month cohort with a new cohort that has had only four weeks to return.
回访事件应代表价值，而不只是出现。“打开应用”可能适合每日消费应用，却不适合月度会计工作流。B2B 产品可能需要账户级留存，因为多名团队成员共同获得价值。比较时必须对齐 cohort 年龄，例如用一个 cohort 的第 4 周留存对比另一个 cohort 的第 4 周留存，不能拿成熟 12 个月 cohort 与只有 4 周观察期的新 cohort 直接比较。
Interpretation caution: users who adopt a feature and users who retain may differ before adoption. A retention gap is an association, not proof that the feature caused retention. Check eligibility, exposure timing and pre-existing behavior, then use an experiment or defensible quasi-experimental design when causality matters.
解释注意：采用某功能的用户与最终留存的用户，在采用之前可能已经不同。留存差距只是相关，并不能证明该功能造成留存。应检查资格、暴露时间与既有行为；若因果结论重要，应使用实验或可辩护的准实验设计。
A cohort table places the cohort start period in rows and age since start in columns. Read across a row to see how one cohort changes, and down a column to compare different cohorts at the same age. A retention curve presents the same concept visually and makes early decay, later stabilization and segment gaps easier to inspect. Always show cohort size, because a smooth percentage based on a small denominator can look more reliable than it is.
Cohort 表通常把 cohort 起始周期放在行，把距起点的年龄放在列。横向阅读一行可以查看同一 cohort 的变化，纵向阅读一列可以比较不同 cohort 在相同年龄的表现。留存曲线用图形表达相同概念，更容易观察早期衰减、后期稳定和细分差异。必须展示 cohort 规模，因为小分母形成的平滑百分比可能显得比实际更可靠。
Select daily, weekly or monthly intervals from the product's natural cadence and the decision horizon. Daily retention fits frequent communication or habit products; weekly retention can fit team workflows; monthly or quarterly retention may fit finance and planning products. Avoid changing intervals merely to make the curve look better. Document whether a user must return in the exact interval, on or after the interval, or at any later time. For calculation patterns and interpretation, continue to cohort analysis, retention analysis and the lifecycle-focused user retention guide.
应根据产品自然节奏与决策周期选择日、周或月区间。高频沟通或习惯型产品适合日留存，团队工作流可能适合周留存，财务与规划产品可能适合月度或季度留存。不要为了让曲线更好看而改变周期。还要记录用户必须在精确周期回访、在该周期或之后回访，还是未来任意时间回访。关于计算与解释，可继续阅读分群分析、留存分析和聚焦生命周期的用户留存指南。
Product analytics metrics that lead to decisions能够推动决策的产品分析指标
Do not start with a universal metric list. Start with the product's value exchange and current decision. Define a small metric system: one outcome or north-star-style value measure, input metrics that teams can influence, diagnostic metrics that explain movement, and guardrails that protect user or system health. Every metric needs a unit, numerator, denominator, eligibility rule, time window, time zone, data source, owner and known exclusions.
不要从通用指标清单开始，而要从产品的价值交换和当前决策开始。建立精简指标体系：一个结果或北极星式价值指标、一组团队可影响的输入指标、解释变化的诊断指标，以及保护用户或系统健康的护栏指标。每项指标都需要单位、分子、分母、资格规则、时间窗口、时区、数据源、负责人和已知排除项。
| Metric指标 | Example definition示例定义 | Common failure常见错误 |
|---|---|---|
| Activation rate激活率 | Eligible new accounts reaching a defined value event within 7 days / eligible new accounts7 天内达到定义价值事件的合格新账户 / 合格新账户 | Using signup completion as a proxy for value把完成注册误当成获得价值 |
| Time to value价值实现时间 | Time from eligible start to first value event从合格起点到首次价值事件的时间 | Ignoring censored users who never convert忽略从未转化的删失用户 |
| Feature adoption功能采用率 | Eligible active accounts with meaningful feature use / eligible active accounts有意义使用功能的合格活跃账户 / 合格活跃账户 | Counting exposure or one accidental click把曝光或一次误触算作采用 |
| Week-4 retention第 4 周留存 | Cohort units repeating the value event in week 4 / eligible cohort units第 4 周重复价值事件的 cohort 单位 / 合格 cohort 单位 | Mixing users, accounts or different cohort ages混用用户、账户或不同 cohort 年龄 |
DAU/MAU can be a useful stickiness ratio only when “active” represents meaningful use and the product is expected to be used monthly and daily. It is misleading for seasonal, episodic or low-frequency workflows. Metric definitions should follow product cadence rather than imitate another company's dashboard. The InfiniSynapse product management metrics framework adds metric-selection and decision context.
只有当“活跃”代表有意义使用，且产品同时具有月度与日度使用预期时，DAU/MAU 才可能是有效粘性比率。对于季节性、偶发或低频工作流，它会误导。指标定义应服从产品节奏，而不是模仿其他公司的仪表盘。InfiniSynapse 的产品管理指标框架进一步补充了指标选择与决策语境。
Engagement is not a single formula. Frequency, depth and breadth answer different questions: how often a user returns, how much meaningful work occurs in a period, and how many relevant capabilities or collaborators participate. A high event count can represent value, confusion or automation. Define an engaged user with a behavior connected to the product's promise, then test whether the definition predicts a useful downstream outcome without excluding legitimate low-frequency customers. The user engagement metrics guide separates these dimensions and their formulas.
参与度不是单一公式。频率、深度与广度分别回答用户多久回来一次、一个周期内完成多少有意义工作，以及使用了多少相关能力或有多少协作者参与。高事件量可能代表价值、困惑或自动化。应以与产品承诺相连的行为定义“参与用户”，再检验该定义能否预测有用的下游结果，同时不会排除合理的低频客户。用户参与指标指南将拆解这些维度和公式。
Churn must use the same analytical unit and cadence as retention. User churn, account churn and revenue churn can move in different directions; a B2B account may retain while individual members change. Distinguish voluntary cancellation, failed payment, inactivity and contraction when the action differs. Pair lagging outcomes with controllable leading indicators, but review those relationships periodically. A metric that predicted retention last year may stop doing so after the product, audience or pricing changes. A broader product management metrics framework connects product health to prioritization and operating decisions.
流失必须使用与留存一致的分析单位和节奏。用户流失、账户流失与收入流失可能方向不同；B2B 账户可能仍然留存，但内部成员已经变化。如果对应行动不同，就要区分主动取消、付款失败、不活跃与收缩。应把滞后结果与可控制的领先指标配对，并定期复核两者关系。产品、受众或定价改变后，去年能预测留存的指标可能不再有效。更完整的产品管理指标框架将产品健康连接到优先级与运营决策。
Product and feature adoption: from discovery to repeated use产品与功能采用：从发现到重复使用
Adoption has stages: exposure, discovery, first meaningful use, repeated use and breadth or depth of use. Keep the denominator eligible. A feature available only to administrators should not be divided by all users. For a multi-seat account, decide whether adoption means one champion used the feature, a share of seats used it, or the account embedded it in a recurring workflow.
采用存在多个阶段：曝光、发现、首次有意义使用、重复使用，以及使用广度或深度。分母必须是合格人群。只向管理员开放的功能不能除以全部用户。对多席位账户，还要决定采用意味着一个负责人用过、一定比例席位用过，还是账户把功能嵌入了重复工作流。
Activation and adoption are related but not interchangeable. Activation is the first credible evidence that a new user or account received the product's core value. Product adoption describes broader and sustained incorporation of that value into real work. Feature adoption concerns a specific capability and should begin only after the audience is eligible and the feature is available. For example, viewing a collaboration tooltip is exposure, opening the invitation dialog is discovery, sending an invitation is first use, and multiple teammates contributing across several weeks is repeated account-level adoption.
激活与采用相关，但不能互换。激活是新用户或账户首次获得产品核心价值的可信证据；产品采用描述把这种价值更广泛、持续地嵌入真实工作；功能采用则针对特定能力，并且只有在受众合格且功能可用之后才开始计算。例如，看到协作提示属于曝光，打开邀请对话框属于发现，发送邀请属于首次使用，多名成员连续数周共同贡献才是账户级重复采用。
Diagnose adoption as a chain rather than one percentage. Low discovery suggests information architecture, targeting or communication problems. High discovery but low first use can indicate unclear value, setup cost or permission barriers. Strong first use but weak repeat use can indicate a narrow use case, poor reliability or no durable benefit. Compare eligible non-adopters, new adopters and sustained adopters on prior behavior before drawing conclusions. Continue with the lifecycle-oriented product adoption guide or the narrower feature adoption measurement guide.
应把采用诊断为一条链，而不是一个百分比。发现率低可能意味着信息架构、目标人群或沟通存在问题；发现高但首次使用低，可能是价值不清、设置成本或权限障碍；首次使用强但重复使用弱，则可能是场景过窄、可靠性不足或缺少持续收益。得出结论前，应比较合格未采用者、新采用者和持续采用者此前的行为。可以继续阅读面向生命周期的产品采用指南或更聚焦的功能采用衡量指南。
Mobile app analytics: versions, devices, crashes and funnels移动应用分析：版本、设备、崩溃与漏斗
Mobile app analytics adds version, operating system, device, offline buffering, app lifecycle and store-release context. Events can arrive late or out of order after a device reconnects. Crashes and performance may explain a funnel drop but often live in specialized observability systems. Join those signals carefully by version and time rather than pretending the product event stream alone explains the experience. Privacy, consent and platform policies must shape collection; this page is not legal advice.
移动应用分析还要处理版本、操作系统、设备、离线缓存、应用生命周期和商店发布上下文。设备重新联网后，事件可能迟到或乱序。崩溃与性能可以解释漏斗下降，却往往存在专门可观测系统中；应按版本和时间谨慎关联，而不是假设产品事件流能够单独解释体验。隐私、同意和平台政策必须影响采集设计；本页不构成法律意见。
Instrument app lifecycle events only when they support a decision. App installed, first opened, foregrounded, backgrounded, updated and uninstalled or inferred removal each have different reliability. Server-confirmed business events are often stronger completion signals than client taps. Store both client and server time when offline use matters, establish an ordering policy, and identify the SDK and app version that produced each event. Release annotations help distinguish a product change from seasonality or acquisition-mix shifts.
只有当应用生命周期事件支持决策时才采集。安装、首次打开、进入前台、进入后台、更新以及卸载或推断移除的可靠性各不相同。服务器确认的业务事件通常比客户端点击更适合作为完成信号。离线使用重要时应同时保存客户端与服务器时间，制定排序策略，并记录产生事件的 SDK 和应用版本；发布注释有助于区分产品改动、季节性与获客组合变化。
Build mobile funnels by platform and supported version, then pair conversion with crash-free sessions, request failures and latency guardrails. A lower conversion rate on one device family may reflect performance rather than intent. Avoid comparing a newly released version with the entire historical population; align exposure dates and eligibility. The dedicated mobile app analytics guide covers lifecycle instrumentation, release cohorts and mobile-specific validation in more depth.
移动漏斗应按平台和受支持版本构建，并把转化与无崩溃会话、请求失败和延迟护栏配对。某个设备系列转化较低，可能反映性能问题而不是意图差异。不要把刚发布的版本与全部历史人群直接比较；应对齐暴露日期与资格。专门的移动应用分析指南将更深入讲解生命周期埋点、版本 cohort 和移动端验证。
How to implement product analytics step by step如何逐步实施产品分析
- Write the decision and hypothesis. Name the owner, decision date, behavior you expect to change and the evidence that would reverse your view.写出决策与假设。明确负责人、决策日期、预期改变的行为，以及什么证据会推翻当前观点。
- Define the metric system. Specify outcome, inputs, diagnostics and guardrails, including units, eligibility, windows and sources.定义指标体系。写清结果、输入、诊断与护栏指标，包括单位、资格、窗口与来源。
- Design the tracking plan. Choose only events and properties needed for the decisions; document naming, identity, privacy restrictions and owners.设计追踪计划。只选择决策需要的事件与属性，并记录命名、身份、隐私限制与负责人。
- Instrument and test. Use development and staging accounts to trigger known flows. Confirm payloads, timestamps, required properties, duplicates and anonymous-to-known merges.埋点并测试。用开发和预发布账户触发已知流程，确认载荷、时间戳、必需属性、重复事件和匿名到实名合并。
- Reconcile before interpretation. Compare counts with application logs, billing or another trusted source. Document expected differences rather than forcing false equality.解释前对账。把计数与应用日志、计费或另一可信来源比较，记录合理差异，而不是强行追求虚假一致。
- Analyze the smallest useful question. Select a funnel, path, cohort, retention or adoption view and define comparison segments before browsing results.分析最小可用问题。选择漏斗、路径、分群、留存或采用视图，并在浏览结果前定义比较细分。
- Triangulate and decide. Join quantitative patterns with errors, research or support evidence. Record uncertainty, alternatives and the action chosen.三角验证并决策。把量化模式与错误、研究或客服证据关联，记录不确定性、替代解释和最终行动。
- Verify the outcome. After release, check the primary metric, guardrails, affected segments and data health over a preselected window. Reopen the analysis if results disagree.验证结果。发布后在预先选择的窗口内检查主指标、护栏、受影响细分和数据健康；若结果不一致，重新开启分析。
This workflow is deliberately tool-agnostic. Teams can implement it in a dedicated product analytics platform, a warehouse with SQL, a BI system, an AI analysis agent, or a combination. The key artifacts—decision record, metric definition, tracking plan, validation evidence, analysis query and follow-up result—should remain reviewable when dashboards change.
该工作流刻意与工具无关。团队可以在专用产品分析平台、数据仓库与 SQL、BI、AI 分析 agent 或组合架构中实施。无论仪表盘如何变化，决策记录、指标定义、追踪计划、验证证据、分析查询和后续结果这些关键资产都应可复核。
A worked product analytics example: onboarding activation产品分析完整示例：新手激活
Hypothetical example: a B2B reporting product believes new workspaces receive value when they connect a data source, create a report and share it with a teammate within seven days. The numbers below are illustrative, not InfiniSynapse customer data or a benchmark.
假设示例：某 B2B 报告产品认为，新工作区若在 7 天内连接数据源、创建报告并分享给同事，就获得了价值。以下数字仅用于说明，不是 InfiniSynapse 客户数据，也不是行业基准。
The team defines eligible new workspaces as non-internal accounts created during the analysis month with at least one verified administrator. The funnel is Workspace Created → Data Source Connected → Report Created → Report Shared, with account-level counting and a seven-day window. In the illustrative result, 1,000 eligible workspaces start, 720 connect data, 500 create a report and 240 share. The largest absolute loss is 280 at connection; the lowest step conversion is sharing, at 48% of report creators.
团队把合格新工作区定义为分析月内创建、至少有一个已验证管理员且非内部账户的工作区。漏斗为“创建工作区 → 连接数据源 → 创建报告 → 分享报告”，按账户计数，窗口为 7 天。假设结果中，1,000 个合格工作区开始，720 个连接数据，500 个创建报告，240 个完成分享。连接步骤绝对流失最大，为 280；分享步骤的 step conversion 最低，占报告创建者的 48%。
A segment comparison shows that small workspaces and large workspaces connect data at similar rates, but small workspaces share less often. Path analysis shows many small workspaces export a report before inviting anyone. Support notes suggest solo evaluation is intentional for part of the segment. The team therefore rejects a blanket conclusion that invitation friction causes all loss. It proposes a contextual share prompt only after a successful export, with guardrails for dismissals, errors and report completion. A preplanned experiment tests the prompt, while week-4 account retention checks whether any adoption lift persists.
细分比较显示，小型和大型工作区连接数据的比例相近，但小型工作区分享更少。路径分析发现，许多小型工作区会在邀请任何人之前先导出报告；客服记录又表明，其中一部分本来就在进行单人评估。因此团队否定“邀请摩擦解释全部流失”的笼统结论，改为只在成功导出后展示情境化分享提示，并设置关闭提示、错误与报告完成的护栏指标。预先规划的实验检验该提示，同时用第 4 周账户留存判断采用提升是否持续。
Why this example is defensible: it distinguishes observed counts, a qualitative explanation, an inference, a proposed intervention and a future verification. It does not turn a funnel correlation into a causal claim.
为什么该示例可辩护：它区分了观察计数、定性解释、推断、拟议干预和未来验证，没有把漏斗相关性写成因果结论。
How to choose product analytics tools and architecture如何选择产品分析工具与数据架构
Product analytics tools fall into several jobs. Event collection SDKs capture behavior. Dedicated platforms provide interactive funnels, paths, retention and cohorts. Warehouses centralize events with billing, CRM, support and operational data. Transformation or semantic layers standardize definitions. BI tools publish repeatable reporting. Experimentation systems manage assignment and statistical decisions. Session replay and observability explain experience details. AI analysis agents can accelerate cross-source exploration and draft queries, but their output still needs source and definition checks.
产品分析工具承担不同工作。事件采集 SDK 捕获行为；专用平台提供交互式漏斗、路径、留存与 cohort；数据仓库把事件与计费、CRM、客服和运营数据集中；转换或语义层统一定义；BI 发布可重复报告；实验系统管理分流与统计决策；session replay 与可观测工具解释体验细节；AI 分析 agent 能加速跨源探索和生成查询，但输出仍需核对来源与定义。
| Need需求 | Best-fit category适合类别 | Evaluate评估重点 |
|---|---|---|
| Fast self-serve behavior analysis快速自助行为分析 | Dedicated product analytics platform专用产品分析平台 | Funnel flexibility, identity, governance, latency, cost漏斗灵活度、身份、治理、延迟与成本 |
| Cross-source source-of-truth analysis跨源可信分析 | Warehouse + transformation/semantic layer仓库 + 转换/语义层 | Grain, lineage, freshness, reproducibility, access粒度、血缘、新鲜度、可复现性与权限 |
| Explain individual friction解释个体摩擦 | Research, support, replay, observability研究、客服、回放与可观测 | Consent, sampling, masking, retention, context同意、抽样、脱敏、保留与上下文 |
| Ad-hoc questions across event and business tables跨事件与业务表的临时问题 | SQL or AI-assisted data analysisSQL 或 AI 辅助数据分析 | Read-only access, query visibility, verification, limits只读访问、查询可见性、验证与限制 |
A small team may begin with a dedicated platform and a tracking plan. A warehouse-centered team may prefer warehouse-native analysis and governed SQL. Mature teams often use both: fast behavioral exploration plus warehouse reconciliation. Before procurement, test real tasks with representative data, document mandatory identity and privacy requirements, estimate event-volume cost, and verify exports so the organization is not trapped in an unreviewable metric layer. The product analytics tools comparison framework explains how to evaluate collection, identity, analysis, governance and portability.
小团队可以从专用平台和追踪计划起步；以仓库为中心的团队可能更适合 warehouse-native 分析与治理后的 SQL；成熟团队往往同时使用两者：快速探索行为，再用仓库对账。采购前应使用代表性数据测试真实任务，记录身份与隐私硬性要求，估算事件量成本，并验证导出能力，避免组织被锁定在无法复核的指标层。可参考产品分析工具对比框架，从采集、身份、分析、治理与可迁移性评估选项。
Warehouse-native product analytics keeps behavioral logic close to governed source data and can simplify joins with subscription, account, support and operational tables. Its tradeoffs are the need for reliable modeling, compute management and interfaces that non-SQL users can operate safely. A dedicated platform often offers faster interactive paths and funnels, but teams must inspect identity resolution, export completeness and whether definitions can be reproduced outside the interface. Neither architecture removes the need for a tracking plan or validation.
Warehouse-native 产品分析让行为逻辑靠近治理后的源数据，也更容易连接订阅、账户、客服和运营表；代价是需要可靠建模、计算管理，以及非 SQL 用户能够安全使用的界面。专用平台往往能更快提供交互式路径和漏斗，但团队必须检查身份解析、导出完整性，以及定义能否在界面之外复现。两种架构都不能消除追踪计划与验证的需要。
Evaluate tools with a written test set: build the same account-level activation funnel, reproduce a retention cohort, join one business table, explain a late event, restrict access to a sensitive property, export the result and have a second analyst recreate it. Record setup time, unanswered questions and definition differences—not just screenshot quality. Use the product analytics tools comparison framework for the detailed shortlist, architecture and procurement workflow.
工具评估应使用书面测试集：构建同一个账户级激活漏斗、复现一个留存 cohort、连接一张业务表、解释一条迟到事件、限制敏感属性访问、导出结果，并让第二位分析者重新生成。记录设置时间、未回答问题和定义差异，而不只是截图效果。详细的候选清单、架构与采购流程可参考产品分析工具对比框架。
Analyze product events with InfiniSynapse使用 InfiniSynapse 分析产品事件
Prepare first: a database or warehouse containing product events, stable user or account keys, a short event dictionary, metric definitions and read-only connection details. Then use InfiniSynapse Online to ask cross-table questions in natural language, review the generated analysis and query evidence, compare cohorts or segments, and verify findings against your source data.
开始前请准备：包含产品事件的数据库或数据仓库、稳定用户或账户键、简短事件字典、指标定义以及只读连接信息。随后可使用 InfiniSynapse Online 用自然语言提出跨表问题，复核生成的分析与查询证据，比较 cohort 或细分，并与源数据验证发现。
InfiniSynapse is an AI-assisted analysis layer for connected data sources. It is not described here as an event-collection SDK, session-replay system, experimentation assignment platform or replacement for instrumentation QA. Keep those functions in the appropriate parts of your stack.
InfiniSynapse 是面向已连接数据源的 AI 辅助分析层。本页不把它描述为事件采集 SDK、session replay 系统、实验分流平台或埋点 QA 的替代品；这些功能应由工具栈中适合的部分承担。
A practical first request is narrow and auditable: define the eligible account population, name the activation events and window, ask for step counts by app version, then request the query and assumptions used. Review identity joins, timestamps, filters and denominators before expanding to path or retention questions. Save the approved definition and verification result with the analysis so another reviewer can understand what changed. Natural language accelerates exploration; it does not turn an ambiguous metric into a governed one.
第一个请求应保持狭窄且可审计：定义合格账户人群，写明激活事件与窗口，按应用版本请求各步骤计数，再要求查看所用查询和假设。扩展到路径或留存问题前，要复核身份连接、时间戳、过滤器和分母。把批准后的定义与验证结果和分析一起保存，便于其他复核者理解发生了什么变化。自然语言可以加速探索，但不能把模糊指标自动变成治理指标。
Open InfiniSynapse Online打开 InfiniSynapse OnlineCommon product analytics mistakes, limits and risks产品分析常见错误、局限与风险
- Tracking before deciding: a large event catalog without decisions creates maintenance work, not insight.先采集后决策：没有决策目标的大事件目录只会制造维护工作，不会自动产生洞察。
- Unstable identity: duplicate users, accidental account merges and anonymous resets distort funnels and retention.身份不稳定：重复用户、错误账户合并和匿名身份重置会扭曲漏斗与留存。
- Changing metric definitions silently: a chart can look continuous while its business meaning changes.静默修改指标定义：图表看似连续，业务含义却已改变。
- Using current properties for historical questions: today's plan or segment can overwrite what was true when the event occurred.用当前属性回答历史问题：今天的套餐或细分可能覆盖事件发生时的真实状态。
- Confusing correlation with causation: retained users may adopt more features because they already have stronger intent.混淆相关与因果：留存用户可能因为本来意愿更强而采用更多功能。
- Optimizing an aggregate: overall improvement can hide harm to a platform, region, new user or accessibility segment.只优化汇总值：总体改善可能掩盖某个平台、地区、新用户或无障碍群体受到的伤害。
- Ignoring privacy and access: collect the minimum needed, document purpose, restrict access and follow applicable rules and user commitments.忽视隐私与权限：只采集必要数据，记录目的，限制访问，并遵守适用规则与对用户的承诺。
Product analytics cannot directly observe motives, untracked offline behavior or counterfactual outcomes. Data can be missing not at random: users blocked by a crash may never emit the success event, and people who refuse tracking may differ from those who consent. Automated or AI-assisted analysis can produce plausible but wrong joins, grains, filters or narratives. Preserve query visibility, test definitions and escalate consequential decisions to domain, data, privacy or legal review as appropriate.
产品分析不能直接观察动机、未追踪的线下行为或反事实结果。缺失数据也可能并非随机：被崩溃阻断的用户不会发出成功事件，拒绝追踪的人可能与同意的人不同。自动化或 AI 辅助分析可能生成看似合理却错误的连接、粒度、过滤或叙事。应保留查询可见性、测试定义，并根据影响把重要决策升级到领域、数据、隐私或法律复核。
How to validate product analytics data and conclusions如何验证产品分析数据与结论
Validation operates at four levels. Instrumentation validation checks that the correct trigger sends the correct event and properties. Pipeline validation checks ingestion, deduplication, ordering, lateness and transformations. Metric validation checks grain, eligibility, numerator, denominator and time. Decision validation checks whether the chosen action changed the expected outcome without unacceptable guardrail movement.
验证分为四层：埋点验证检查正确触发是否发送正确事件与属性；管道验证检查摄取、去重、排序、迟到和转换；指标验证检查粒度、资格、分子、分母与时间；决策验证检查行动是否改变预期结果，同时没有造成不可接受的护栏变化。
Complete a controlled flow with a test identity and compare the event stream with the tracking plan step by step.
用测试身份完成受控流程，逐步把事件流与追踪计划比较。
Compare a period and population with application, billing or warehouse facts; explain expected timing and scope differences.
把某周期与人群同应用、计费或仓库事实对比，并解释合理的时间与范围差异。
Test time zones, duplicate clicks, retries, late events, deleted accounts, anonymous merges and zero-denominator periods.
测试时区、重复点击、重试、迟到事件、已删除账户、匿名合并和分母为零的周期。
Reproduce high-stakes results from a saved query or alternative implementation and review differences before action.
从保存查询或替代实现复现高风险结果，并在行动前复核差异。
Keep a change log for event and metric definitions, and annotate releases, outages and migrations. Source-to-result data lineage should record the tables, joins, filters, transformations and metric versions used so reviewers can reproduce the result. Validation does not make a result permanently true; it makes assumptions and evidence visible enough for someone else to challenge and reproduce.
应为事件和指标定义保留变更日志，并标注发布、故障与迁移。来源到结果的数据血缘应记录所用表、连接、筛选、转换和指标版本，使复核者能够复现结果。验证不会让结果永久正确，它的作用是让假设与证据足够可见，使他人能够质疑并复现。
Product analytics best practices and next steps产品分析最佳实践与下一步
- Start each analysis with a decision owner, deadline and disconfirming evidence.每次分析都从决策负责人、期限与反证条件开始。
- Track business actions with stable names; keep volatile UI context in properties.用稳定名称追踪业务动作，把易变界面上下文放入属性。
- Use the correct unit—user, account, device or transaction—and state it beside the metric.选择正确单位——用户、账户、设备或交易——并在指标旁明确标注。
- Pair behavioral data with research, support and operational evidence before explaining why.在解释“为什么”之前，把行为数据与研究、客服和运营证据结合。
- Separate exploration from production reporting; promote only reviewed definitions and repeatable queries.区分探索与生产报告，只提升经过复核的定义和可重复查询。
- Review event usage and remove deprecated, duplicate or sensitive fields under a documented retention process.定期复核事件使用，在有记录的保留流程下移除废弃、重复或敏感字段。
- After every product change, validate instrumentation and outcome together; a broken event can look like a broken feature.每次产品变更后同时验证埋点与结果；损坏事件可能看起来像损坏功能。
A practical next step is to choose one current product decision, write its metric definition, list the minimum events needed, and run a known-journey test. Only then build the funnel or cohort. If the answer requires product events plus billing, CRM or support tables, use a governed warehouse workflow and document joins. The product analytics tools guide provides a framework for evaluating the architecture and verification tradeoffs.
可执行的下一步，是选择一个当前产品决策，写出指标定义，列出最少所需事件，并运行一次已知旅程测试；随后再构建漏斗或 cohort。若答案同时需要产品事件与计费、CRM 或客服表，应使用治理后的仓库工作流并记录连接。产品分析工具指南提供了评估架构与验证取舍的框架。
Frequently asked questions about product analyticsProduct Analytics 产品分析常见问题
What is product analytics?什么是产品分析？
Product analytics is the practice of collecting and analyzing user-level product behavior data to understand journeys, conversion, engagement, retention and feature adoption, then using the findings to make and verify product decisions.
产品分析是收集并分析用户级产品行为数据，以理解旅程、转化、参与、留存和功能采用，再利用这些发现做出并验证产品决策的实践。
How does product analytics work?产品分析如何工作？
Teams define a decision and metric, design an event taxonomy, collect events with stable identity and context, validate the data, analyze funnels, paths, cohorts, retention or adoption, investigate segments, and verify whether the resulting action changed the intended outcome without harming guardrail metrics.
团队先定义决策与指标，设计事件 taxonomy，以稳定身份和上下文采集事件并验证数据；随后分析漏斗、路径、cohort、留存或采用，调查不同细分，最后验证行动是否改善目标结果且未损害护栏指标。
What data do you need for product analytics?产品分析需要哪些数据？
At minimum, you need timestamped product events, stable user or account identifiers, event properties, relevant user or account properties, and documented metric definitions. Sessions, experiments, subscriptions, support data and warehouse tables are optional inputs that answer broader questions.
至少需要带时间戳的产品事件、稳定用户或账户标识、事件属性、相关用户或账户属性，以及有文档的指标定义。会话、实验、订阅、客服数据与仓库表是用于回答更广问题的可选输入。
Which product analytics metrics should a team track?团队应追踪哪些产品分析指标？
Track a small decision-linked set: activation, funnel conversion, time to value, active use, feature adoption, retention, and guardrails such as errors or latency. The right definitions depend on the product, user unit, value event and decision.
应追踪一组与决策相连的精简指标：激活、漏斗转化、价值实现时间、活跃使用、功能采用、留存，以及错误或延迟等护栏。正确的定义取决于产品、用户单位、价值事件与决策。
How do you validate product analytics data?如何验证产品分析数据？
Validate event names and required properties against the tracking plan, test known user journeys, reconcile counts with a trusted source, inspect identity merges and duplicates, check time zones and late events, and reproduce important results from the underlying query or warehouse.
应按追踪计划验证事件名和必需属性，测试已知用户旅程，与可信来源对账，检查身份合并与重复，检查时区与迟到事件，并从底层查询或仓库复现重要结果。
Is product analytics the same as web analytics or business intelligence?产品分析等同于网站分析或 BI 吗？
No. Web analytics usually emphasizes acquisition and site traffic, product analytics emphasizes user behavior inside a product, and business intelligence provides broader governed reporting across business domains. The systems can share data and complement one another.
不等同。网站分析通常强调获客与站点流量，产品分析强调产品内用户行为，商业智能则提供跨业务域的更广治理报告。这些系统可以共享数据并相互补充。
Authoritative sources and evidence notes权威来源与证据说明
Event and taxonomy definitions were checked against the Amplitude taxonomy planning documentation. Event-collection concepts were also compared with the Google Analytics event collection documentation. Privacy risk framing should be adapted to applicable obligations; the NIST Privacy Framework is a general risk-management reference, not legal advice.
事件与 taxonomy 定义核对了 Amplitude taxonomy 规划文档，事件采集概念也与 Google Analytics 事件采集文档进行了比较。隐私风险框架必须根据适用义务调整；NIST Privacy Framework是通用风险管理参考，不构成法律意见。
The selection frameworks, hypothetical onboarding example and implementation sequence are this page's editorial synthesis. Illustrative figures are labeled as such. Product capabilities and external documentation may change, so verify current first-party materials before consequential implementation.
选型框架、假设新手示例和实施顺序属于本页编辑整理；示例数字已明确标注。产品能力与外部文档可能变化，重要实施前应核对当前第一方材料。