振幅已经处理了超过31万亿的用户事件超过40000个数字产品。所以，你可以说我们已经看到了管理传入事件数据的策略。在与大大小小的客户打交道的这些年中，很明显，在产品分析中有三种主要的数据管理策略，它们与公司的成熟度水平相一致：策略#1：清理工作流程-数据管理的初学者成熟度策略#2：审批工作流-数据管理中的中级成熟度策略#3：事件规划工作流-数据管理的高级成熟度虽然公司通常会随着成熟度的提高而从一个步骤过渡到下一个步骤，但是这些数据管理策略并不是相互排斥的，而且公司在使用这些策略时可能会有一些重叠。然而，一般来说，云实，我们发现，对产品分析较新的团队通常会选择对系统中已经存在的数据进行追溯性更正，而更成熟的组织更倾向于提前计划，以确保高功能性并减少所需的更正量。数据管理策略1：清理工作流程成熟度：初级在许多情况下，对产品分析不熟悉的组织都急于将任何事件或事件输入到他们的系统中。组织在决定加入哪些事件方面没有太多经验，因此可能只允许员工添加他们选择的事件。事件数据被视为具有内在价值的数据，每当工程师愿意使用仪器时，它都被视为一种胜利。这个级别的团队通常没有专门的分析功能或正式的数据调控器。有可能一些产品经理正在仔细考虑如何测试他们的新功能，但也有可能工程师只是被告知要发送事件，或者在某些情况下，他们甚至可以实现一个系统，自动跟踪点击并注入相关属性（类似于自动跟踪，造成的问题比它想要解决的问题还多）。这种方法的主要特点是，大多数数据管理发生在事件已经在数据分析平台（如振幅）中之后。事件通常需要重命名或组合，因为它们不容易以接收它们的格式使用。例如，"单击页眉菜单"可能会变成"打开设置"，或者更好地描述它所代表的产品内操作。这使得不熟悉数据的人更容易理解选择哪个事件。此外，这类系统通常有很多不明显有用的事件。工程师可能会认为每一个事件都有重复的例子。在某些情况下，一家公司可能会达到每月的事件配额，结果却发现一些价值不大的事件花费了大量的资金，因为分析平台通常是按接收的数据量收费的。清理工作也常常是由于缺乏清晰性而引发的。尽管处于初级成熟度的组织可能不会发送很多事件，但是很难确定正确的事件来使用分析平台进行检测。随着时间的推移，这就需要重新命名事件或添加描述，因为组织了解到了他们想要跟踪的事件的更多信息。在大多数情况下，清理工作是由一个或多个对分析或数据驱动文化有热情的人来完成的，通常是作为下班后的工作。他们通常没有太多的时间来做这项工作，大数据下，但是事件量很低，可以偶尔进行清理。数据管理策略#2：审批工作流成熟度：中级在某种程度上，入站事件的数量变得太大，并且不可能只追溯性地管理事件。在许多情况下，都有一个激励事件；可能是某个bug创建了数千个不必要的事件类型，需要花费数小时来清理，或者可能公司开始意识到分析的价值，同时也看到了它们的实现存在严重缺陷。组织意识到，清理和纠正虽然仍然是必要的，但可能无法使它们达到所需的状态。他们愿意在"正确的方式"上投入更多的时间，尽管资源通常仍然相当有限。这是组织通常开始过渡到"事件批准"工作流的点。在这一点上，有人决定扮演数据管理者的角色，或者甚至可能被领导层任命为这个角色。数据调控器的任务是跟踪传入事件，并根据具体情况批准它们。在这个阶段，组织通常有某种数据管理风格指南，它给出了一些关于如何恰当地使用事件的基本规则。在某些情况下，数据调控器按原样批准事件，但它们也有机会转换事件甚至直接拒绝它们。如前所述，数据管理策略是重叠的。因此，虽然组织可能已经成熟了，但他们仍然需要做大量的清理/纠正工作（策略1）。此工作流与清理/更正工作流的最大区别在于，清理/更正通常在事件第一次出现时完成，而不是在稍后某个明显存在问题的时候完成。在这个阶段，当我们与组织中的数据管理者交谈时，大数据查询平台，他们经常告诉我们，他们对于直接拒绝事件犹豫不决，因为工程师不太可能花时间重新测量仪器。总的来说，事件仍然被视为"珍贵的"，组织尽其所能挽救一个事件。虽然团队很可能已经制定了一些基本规则，比如活动的风格指南，怎么选购云服务器，但是遵守这些规则可能会不一致。这种中间级别的特点是通常只有一个数据调控器，而在早期阶段没有数据调控器，在后期阶段有多个数据调控器。这个数据调控器通常是兼职的，他们现有的角色通常是由有效的数据管理来帮助的。例如，他们可以是数据科学主管，也可以是过去与运行良好的分析系统合作过的产品经理。不过，不管标题是什么，他们的时间是有限的。每周，数据调控器都会根据入站请求执行一些数据维护工作，但没有时间计划和执行跨团队工具。数据管理策略#3：活动规划工作流成熟度：高级有效的数据治理需要对产品有相当深入的了解，而且随着公司产品种类的扩大，很可能单个数据管理器不可能熟悉所有方面。此时，组织已经发展到数据管理的最终成熟度级别。该公司投资组建一个团队，通常致力于数据科学和/或分析功能，致力于思考产品分析和相关问题。这是公司准备过渡到活动计划工作流的时刻。批准已经让团队走得够远了，但很明显，要让产品分析真正产生最大价值，它必须成为一门学科。因此，分析团队需要仔细考虑发送进来的每个事件和属性。分析团队的每个成员都负责与一个或多个产品团队合作，并在整个事件生命周期中与该团队密切协作。当产品经理和设计师详细说明产品特性时，分析团队会与他们一起确定到底要测量什么。他们还仔细记录了这个过程。然后，分析人员在实现过程中与工程团队密切合作，甚至阅读pull请求，以确保正确执行检测。然后，物联网管理平台，他们在一个系统中计划事件，比如振幅控制，这样可以确保只接收正确的事件。如果一个事件与这些规范不匹配，它通常会被拒绝，工程师需要进行更改。这些组织并没有将事件视为宝贵的，而是将事件视为一种有用的工具，帮助他们了解更多有关用户行为的信息。这些更成熟的组织仍然会进行某种程度的清理/纠正，尽管与审批阶段的情况一样，这实现了某种程度上不同的目的。因为这些组织有很多活动，通常他们需要挑选这些活动。过去可能有用的事件可能不再需要，或者为了降低成本，他们可能需要阻止一些从长期来看不太有用的事件。它们仍然可以合并或重命名事件，但这通常是随着分类标准的发展而进行的，而不是对特定错误的响应。同样，分析团队也可以进行有限数量的事件批准，尽管很可能所有事件都将被计划好。总的来说，这三个数据管理工作流适用于不同成熟度级别的团队。值得思考的一件有趣的事情是，数据管理功能失调（无政府状态和独裁）不仅仅是因为使用了特定的策略，而是因为在错误的时间使用了该策略。无政府状态通常是由于过程中使用清理/纠正策略（甚至是批准策略）太迟而导致的，而独裁则可能是由于过早地使用计划（通常在组织从产品分析中看到价值之前）。在这个由三部分组成的系列文章中，我们讨论了数据管理的四个真理和数据功能的三个关键。现在，有了这个成熟度模型，您就可以更全面地了解如何为整个组织计划事件并使数据更可用、更准确、更全面。下一步是实施这些策略，并开始从数据中获取更多价值。