如何将您的分析跟踪转变为持续的协作过程

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

我们都知道，任何构建数字产品和服务的组织都会收集数据。 我们也知道，仅仅收集数据与实际有效地使用数据是不一样的。 即使您制定了出色的跟踪计划并得到强大工具包的支持，但如果您不花时间参与一件关键的事情：协作，您的策略也会失败。

分析触及数据主导型公司中的每个人

考虑为您的产品构建新功能。 这里有两个主要考虑因素：此功能将带来哪些新数据点，以及这些数据点的受众是谁？ 好吧，如果你真的想做出数据驱动的决策，或多或少每个人都会成为你的客户数据的受众。

参与分析跟踪的主要利益相关者都将把他们独特的想法和专业知识带到故事中——领域知识和技术诀窍的健康结合。 我们有：

• 行政人员/领导
• 产品经理
• 分析师/数据团队
• 开发商

这些团队中的每一个都有自己不同的任务和目标，但最终他们将根据相同的跟踪计划开展工作。

提示：拥有太多厨师可能是一场噩梦——阅读这篇文章以了解更多关于谁应该拥有跟踪计划的信息。

这些团队（应该）如何在分析方面相互协作。

行政人员/领导

让我们从需要最高级别事件跟踪视图的团队开始。 在构建新功能时，执行官最关心的是这个新功能的目标是什么，以及将使用什么指标来衡量成功。

这意味着在领导下工作的团队需要具备做一些高质量报告的能力。 一个优秀的领导团队不会希望根据直觉做出关于公司未来的重要决定——他们会想要确凿的证据来证明什么有效，什么无效。

该团队的主要协作行为：

• 领导层应该尽最大努力激发整个组织的协作，并培养一种理解数据驱动决策价值的文化。
• 庆祝基于数据做出决策而取得的成功。
• 粗略地说，如果您的经理不关心良好的分析跟踪，那您为什么要关心？ ‍

产品经理

产品经理非常了解您的产品，以及它在市场/行业中的地位。 他们负责交付这项新功能，因此将寻求将领导层关心的那些指标转化为他们想要跟踪的实际事件。 为了针对此新功能构建可靠的报告，需要从一开始就内置事件跟踪。

虽然产品经理拥有大量领域专业知识，但他们可能不具备自己定义跟踪计划所需的技术技能。 这意味着他们必须与其他团队合作才能完成工作。 一个好的产品经理不太可能指定他们想要跟踪的事件列表，并期望由此产生完美的报告。 相反，他们可能会与分析师和开发人员讨论并就可能实现的目标达成一致，因为这些团队将实施跟踪计划并构建报告。

因此，产品经理会知道哪些指标很重要，但可能会依赖其他人将这些指标转化为可跟踪的事件。 他们将有助于提出正确的数据问题，决定何时进行 A/B 测试，并创建适当的反馈循环：查看先前决策的性能，并对这些决策进行迭代。

该团队的主要协作行为：

• 定期与分析师核实，了解正在跟踪的事件及其原因，并让每个人都在分类和命名约定的同一页面上
• 与开发人员合作，确定需要对跟踪计划进行哪些更改，以及这些更改在给定基础架构的情况下是否可行以及完成这些更改需要多长时间
• 确保他们通过高质量的报告向领导层提供反馈

分析师

您的数据分析师团队就像公司的报告中心枢纽。 他们很可能是最先拿到原始数据的人（可能是唯一的）。 他们将致力于连接、建模和可视化数据。 它们有助于将数据转化为洞察力。

关于分析师团队的一个重要说明：他们不应该被视为一种组织资源，即当您需要与数据相关的东西时“可以问的人”。 如果是这种情况，分析师可能会发现他们的能力被用于满足其他团队的日常要求，而不是实际建立洞察力和生成有意义的报告。

分析师协作过程的一部分是让其他团队尽可能地自助服务。 这方面的一个基本示例可能是与产品经理和营销人员合作，将预定义查询构建到 Tableau 等工具中，以便单击按钮即可回答最常见的问题。 产品和营销团队还可以使用 Amplitude 等自助式数字分析平台自行构建图表并分析客户行为。

该团队的主要协作行为：

• 与产品经理合作以更多地了解数据背后的人：他们可以使用抽象数据，而无需对最终用户了解太多，但如果他们对这些数据的重要性有更深入的了解，将会更加有效
• 促进具有挑战性的对话，讨论哪些问题对数据提出的问题最有帮助，以及其他团队想要跟踪什么（例如，如果团队要求收集的数据比需要的多，知道什么时候该推迟）

开发商

当然，开发人员是实际构建产品并因此实施您的跟踪计划的人。 从技术上讲，软件工程师不必非常了解您所从事的行业或最终用户的行为。 这并非全面如此，并且导致了开发人员不关心分析的假设。

实际上，如果没有系统化的协作流程，工程团队可能很难以有意义的方式参与分析。 在构建新功能时，收到要跟踪哪些事件的电子表格可能会令人沮丧，因为这对工作流程造成了巨大的干扰。 在 IDE、电子表格和 Jira 票证之间来回切换很麻烦，而且很容易导致错误和不一致。

优秀的开发人员更有可能关心他们构建的产品的性能——他们也比任何人都更了解产品的实际工作原理，因此最有能力以最有效的方式实施跟踪计划。

该团队的主要协作行为：

• 确保产品经理了解其产品基础架构的局限性、何时何地进行跟踪以及实施可能需要多长时间
• 与分析师密切合作以构建数据和分析管道，并确保一切都按预期进行
• 帮助所有其他团队了解，要有效地跟踪事件，他们需要时间从一开始就将跟踪构建到功能中，而不是事后才想到

促进围绕分析跟踪的协作

有了对团队如何在分析跟踪方面协同工作的广泛理解，开始开发协作流程应该会更容易。 很明显，如果每个人都致力于构建和维护相同的产品，那么跨团队的沟通将非常重要。

开始将您的分析视为产品后端的关键设计点。 它不仅仅是您在交付功能后添加的东西，而是 SDLC 的组成部分。

许多公司，尤其是科技行业的公司，已经习惯于使用协作和知识共享工具，例如 Jira、Slack，当然还有 Amplitude。 如果您热衷于在您的组织中采用更强大的协作流程，我们建议您根据自己的意愿构建案例。 获得新流程的支持通常是最困难的部分。

没有必要重新发明轮子。 应用已经有效的现有流程。

通常，采用新流程（例如在分析方面有效协作）几乎与技术无关，而与文化息息相关。 在分析方面，知识不会存在于一个人或一个团队中——每个人都需要共同努力才能充分利用您的数据。

重要的是要注意，没有人会采用新流程（无论它有多好），除非他们看到它的意义。 实际上，让全公司都接受新流程的一个好方法是通过将其与其他现有流程进行比较来证明该流程的价值。 几个例子：

GitHub：如果我说几乎每个构建软件的人/公司/组织都使用 GitHub，我认为我不会夸大其词。 这是一个非常优雅但硬编码的过程：编写的每一段代码都要进行分支、提交和合并。 所以 Github 实际上不像一个工具，而更像是一个过程：如果每个人都不使用它，它就根本无法工作。

Figma：完美展示无缝跨团队协作的工具； Figma 使产品设计师能够将原型交给开发人员，清楚地展示所有元素是如何组合在一起的。 提示：使用 Figma 中的 Amplitude Event Planner。

Amplitude 可帮助您协作

将 Amplitude 的数据治理功能视为分析的 GitHub 很有用。 Amplitude 促进了围绕活动规划的透明、可审计的过程，无论技术能力如何，每个关键利益相关者都可以参与其中。

最好的流程是您甚至没有注意到的流程：我们拥有开发人员工具，因此不会中断任何人的工作流程，使工程师能够使用类型安全的开源 SDK、CLI 和 CI/CD 轻松准确地实施分析跟踪一体化。

Amplitude 首先是一个协作平台，为分析提供可靠的事实来源。 这意味着那些使用数据的人知道他们可以信任它。 如果您已经为新的协作流程获得了大量支持，Amplitude 肯定可以在支持方面发挥作用。 申请免费演示并立即开始您的探索。