谁应该真正拥有您的跟踪计划？

编者按：本文最初于 2021 年 1 月 11 日发表在 Iteratively 博客上。

“数据是一项团队运动”是我们坚信并经常在 Amplitude 谈论的话题。 分析跟踪计划没有什么不同——跟踪计划（以及它们的检测）本质上是协作的。 当相关团队齐心协力时，他们才能发挥最佳作用。

让我们以新功能发布为例。 产品团队已经为这个新功能定义了目标和指标，并将了解需要哪些事件跟踪来衡量这些指标。 iOS、Android 和 Web 开发团队负责检测（最好是测试）代码中的这些事件，并将对可行的方法发表意见。 分析师或分析工程师负责对数据建模并关心其结构，您可能有多个团队负责构建报告并使用多种工具分析数据。 简而言之，在以数据为主导的公司中，分析几乎涉及到每个人。

该示例说明了分析跟踪的真正复杂性，还说明了协作在定义和捕获正确事件、准确实施这些事件以及让数据消费者轻松探索数据时的重要性。 也就是说，有这么多人参与，分析跟踪很容易成为烫手山芋。

如果它为所有人所有，那么它就不为任何人所有

由于涉及到如此多的利益相关者，跟踪计划往往成为一项共同的责任，没有明确的所有者。 分担责任几乎没有问责制。

我们已经与许多想要（重新）创建围绕分析跟踪的流程的公司进行了交谈。 它通常围绕电子表格或 Confluence 或概念页面展开。 虽然它主要是手动的，并且没有办法在代码中强制执行跟踪计划，但它在开始时被证明是有用的，并迫使团队更多地考虑事件跟踪。

然而，几个月后，概念页面或谷歌电子表格变得过时：最新版本的跟踪仅记录在 Jira 故事中，而对于其他一些功能发布，现在尚不清楚是否实施了跟踪。 没有人将更新跟踪计划作为自己的责任。

那么，您如何更好地改变这种情况以及谁最适合拥有您的分析跟踪？

首先将分析放在首位和中心位置

在深入探讨所有权问题之前，我们必须提及分析跟踪成功所需的基础：事件跟踪很重要，没有它，您将一无所知。 现实情况是，对于大多数团队而言，分析是事后才想到的。 这是我们经常看到的一个例子：

• PM 负责发布
• 释放发生
• CEO 询问 PM 它的表现如何
• PM：“让我问问数据团队”
• 数据团队：“你从来没有把我们带进来——没有关于这个特征的数据。”
• PM 回到 CEO 那里没有答案
• 数据团队和 PM 心烦意乱

如果分析没有成为每个版本不可或缺的一部分，这种情况会一遍又一遍地发生，而您的跟踪计划是否看起来真的很圆滑并且是最新的也无关紧要。 您需要所有利益相关者（以及您的领导团队）的支持，即分析跟踪与功能本身一样重要。 没有跟踪，没有发布。

您需要明确的责任、时间和资源来授权相关团队，然后您需要将事件跟踪和成功指标嵌入到 Jira 票证级别（仅当跟踪代码与其余代码一起交付时才完成）。

我们从对数据和产品专业人士的 400 多次采访中学到了什么

在两年内，我们采访了 400 多名产品经理、数据团队和工程师。 我们已经看到了一些东西。

当然，您的跟踪计划及其相关流程对于您的业务、团队结构和垂直领域而言是独一无二的（这可能就是为什么很难做到正确的原因）。 电子商务公司的跟踪计划与 B2B SaaS 公司的跟踪计划看起来非常不同。 他们有不同的利益相关者参与并解决完全不同的现实。 最常见的是，我们可以按公司规模细分我们所看到的内容。

创业公司

对于小公司来说，跟踪过程通常是临时的。 这是很自然的，因为很少有人参与，并且使复杂性易于管理。 大多数情况下，我们会看到产品负责人或增长负责人在公司发展历程的这个阶段承担责任。

中小企业

在一家中型公司中，该过程通常落在数据/分析的负责人身上。 现在有更多的利益相关者参与，复杂性很容易成为一个问题。 在这个阶段，明确需要所有权来限制损害，并且通常落在数据团队中的某个人身上。

企业

在较大的公司中，最终拥有跟踪计划的人通常是产品分析的负责人。 对于电商企业来说，往往会是电商的负责人。 通常他们不会是维护计划或执行流程的实际日常人员，而是他们团队中负责的人。

我们已经从这些类型的设置中看到了不同程度的成功。 那么，我们认为什么最有效？

什么有效：产品团队是最终的所有者

这就是我们所知道的：最好的所有权流程发生在产品团队充当最终所有者的时候。 产品经理应该是主要驱动力，并确保分析跟踪是每个功能发布的一部分。 根据您的团队规模，这可能是一名或多名产品经理或一名专门的产品分析师。 作为其角色和 OKR 的一部分，他们应该对分析跟踪负责。

但正如我们之前提到的，数据是一项团队运动，我们建议团队聚在一起定义事件命名和分类法等内容。 工程师和数据团队将拥有重要的观点，因为这也会影响他们的日常工作。 虽然产品团队是执行者和最终所有者，但他们不应该在没有合适的利益相关者参与的情况下孤立地工作或做出重要决策。

建立一个代表所有相关利益相关者的咨询委员会对我们合作过的公司来说效果很好。 并不是每一个决定都会交给顾问委员会，但他们应该是一开始的驱动力，定义你的分类和流程，并根据随着时间的推移发生多少重大变化而定期开会。

为了让产品团队成功拥有它，您需要一个清晰的流程：

• 作为每个用户故事的一部分，为定性和定量指标制定明确的成功标准。 这些应该由 PM 定义，并与数据团队或分析师讨论。
• 缺少跟踪？ 构建失败。 完成的概念需要发展以将分析跟踪作为每个版本的一部分。 这并不意味着在发布之前就阻止发布，而是意味着实施一个从一开始就包含跟踪注意事项的流程。
• 协作是关键。 虽然 PM 将拥有事件跟踪规范，但数据团队或分析师应该可以介入并帮助定义应该跟踪的细节。

让您的产品经理拥有所有权

对于某些 PM，拥有跟踪计划对他们来说是很自然的事情。 他们想要控制权并拥有经验。 他们也不怕在需要时寻求帮助。 但这并非对所有 PM 都是自然而然的。

首先，需要发生文化变革：庆祝新功能或产品发布的性能和成功，而不是它发布的事实！ 令人惊讶的是，对于许多人来说，获得赞誉的仍然是运输，而不是产品是否表现出色。

那么，您如何授权您的产品团队拥有跟踪计划呢？ 这不是一个详尽的清单，但希望是人们开始的地方：

• 定期培训：正确进行事件跟踪既是一门艺术，也是一门科学（即这并不容易），因此请确保您的团队拥有轻松掌握所有权所需的知识。 培训可以是午餐和学习风格、研讨会或一对一课程（请记住记录您的课程以供将来雇用）。
• 办公时间：当数据团队为其他团队举办定期办公时间以利用数据团队的专业知识和知识时，我们已经看到了巨大的成功。 确保团队准备好议程或具体问题，以避免它变成“支持台式”会议。
• 清晰的流程和检查点：我们怎么强调定义流程的重要性都不为过。 确保你有一个每个人都知道、理解和遵循的清晰流程，并包括定期审查点以确保质量，就像软件开发中的代码审查和合并请求一样。
• 嵌入分析师：当然，这并不总是一种选择，但我们已经看到成功的团队将数据分析师部分或全职嵌入到产品团队中，以拥有分析跟踪并帮助 PM 进行数据探索和分析。
• 自助式分析：我们认为最好的做法是让 PM 和组织中的其他人能够轻松探索数据集并快速获得问题的答案。 Amplitude 对此非常有用，可确保整个公司的高水平数据素养。

提醒：好的 PM 不需要懂 SQL

如果您无论如何都无法自己探索数据，为什么还要关心事件跟踪呢？ 为了扩展上面最后一点，我们已经看到拥有中央数据团队的公司拥有所有报告和数据分析。 它有其优点，但根据我们的经验，它会限制 PM 和其他人，他们将不太关心分析跟踪或数据质量。

请记住，让 PM 和其他人访问 Redash 或其他基于 SQL 的工具并不等于授权 PM 进行自助服务。 不要指望您的 PM 了解（或学习）SQL。 那不是他们的工作。相反，为他们提供易于使用的 UI 和大量培训，以配合工具和数据集。 当然，SQL 知识有其​​明显的优势，如果您能够在公司范围内找到或培训人才（想想产品、营销、客户成功等），您就可以让它发挥作用，但它也有明显的缺点和局限性。

如果 PM 能够自助服务，他们更有可能探索来自最近发布的数据。 当他们探索数据时，他们更可能关心数据的质量、丰富性和可用性。 创建一种授权文化并围绕分析跟踪构建可靠的流程，您将拥有快乐的 PM、快乐的分析师、快乐的数据团队，甚至快乐的开发人员。

振幅在这里为您提供帮助

Amplitude 帮助数据团队、产品经理和工程师定义、检测、验证和协作分析跟踪。 我们主动解决因事件命名不一致和跟踪缺失而引起的数据质量问题，并提供用于管理跟踪演变的工作流程。

我们授权产品经理负责跟踪计划并加强团队之间的协作。 如果您有兴趣为您的公司试用 Amplitude，请立即创建一个帐户或与我们的团队一起预订演示以了解更多信息。