原文：
www.kdnuggets.com/2019/10/four-questions-scope-analytics-engineering-project.html
评论
由 Tristan Handy，Fishtown Analytics 创始人兼首席执行官。
1. Google 网络安全证书 - 快速通道进入网络安全职业生涯。
2. Google 数据分析专业证书 - 提升你的数据分析技能。
3. Google IT 支持专业证书 - 支持你的组织 IT。
在 Fishtown Analytics，我们以两周的冲刺周期销售和交付分析工程项目，每个周期都有固定的价格和交付物。在如此紧凑的时间表和明确的结果下交付是非常紧张的！我们在这方面做得相当好：我们已经完成了超过 1000 个冲刺，其中超过 95% 准时交付。
结果是，我们在确定分析项目范围方面变得非常擅长。我们发现，如果我们提前回答四个问题，我们可以显著减少在为时已晚之前发现问题的机会。事实上，早期发现问题是按时交付分析工作的最重要因素。如果你花一周时间走上一条道路，结果发现是死胡同，那是一段巨大的浪费时间。关键是要在陷入困境之前预见到死胡同。
我们的主动问题识别方法已经变得直观——这是我们大家自然会做的事情，因为我们都曾在炉子上烫过手，知道这样做更好：“我本该知道我需要检查那些 ID 是否能匹配。操。”
这是一个如此重要的话题，以至于我想花时间使我们的直观、潜在知识更为明确，并与更大的社区分享。因为这项技能不仅仅是为顾问准备的：任何使用 敏捷方法进行数据团队管理 的人，或者任何管理数据项目截止日期的人，都应该关心。
为什么？ 数据团队成功的关键在于建立信任储备 ——这就是你如何从所有业务利益相关者那里获得“受信任顾问”地位的方式，以及如何最终影响业务的轨迹。我们通过提供高质量、经过测试和准确的数据来赢得信任。我们还通过对项目的过程设定明确期望并一再兑现来建立信任。
以下是我们在 Fishtown Analytics 主动识别问题并按时交付分析工程项目时提出的四个问题。
数据相关但来自错误系统的情况并不罕见。一个常见的例子是：你的公司可能在 Marketo 中存储营销数据，但它通过现有的 Salesforce 集成被引入到数据仓库中。使用 Marketo 数据而非 Salesforce 数据并不错误，但却有风险。双重集成将有更多失败的机会，数据也可能不像原始数据那样详细或完整。最好是直接从数据的源头获取所有数据。
实际上，这里有很多这样的例子。你应该信任：
-
是 Shopify 的收费还是 Stripe 的？ 我会选择 Stripe 的用于财务/收入相关的情况，而 Shopify 的用于电子商务相关的情况。
-
Mixpanel 的事件还是 Segment 的？ 我几乎总是选择 Segment，因为大多数公司将数据通过 Segment 推送到 Mixpanel。
-
Hubspot 的归因还是 Snowplow 的？ 我相信你的网络分析工具（在这种情况下是 Snowplow）需要成为你网络事件数据的权威来源，从而成为你的归因来源。
当你开始一个项目时，坚持直接从源头获取数据是一件有趣的事，因为在某些方面，这并不非常务实。支付额外的集成费用通常有明确的价格标签，而且一开始并不清楚它的价值。为什么你拥有的数据“不够好”？答案是，基于最基本的真实数据源建立你的分析将节省大量的时间、挫折、变通方法和混乱的代码。
如果你有真正的原始数据，你就几乎无所不能：如果一个问题可以回答，你就能回答它。如果你在与一位 VP 开会时，他问：“我们能按获取来源来切分潜在客户吗？”答案要么是“可以”，要么是“我们使用的系统没有提供这样的数据。”如果你没有原始数据，你有时只能回答“根据我们目前的分析管道无法做到这一点。”这并不令人信服。
如果你没有原始数据，请做两件事：
-
试着直接获取这些数据。这可能像设置 Stitch 或 Fivetran 集成一样简单，或者可能需要自定义集成。
-
如果你无法获取原始数据并需要依赖于次级数据源，请提醒你的利益相关者潜在的缺陷，以便每个人对项目有正确的期望。概述你能提供的分析范围，以及如果能够获取原始数据时需要的再加工量。只要你明确告知利益相关者潜在的下游影响，基于 expediency 做出决策本身没有什么问题。
根据Kimball，重要的是“坚持使用与原始来源和收集过程紧密相关的丰富、表达性强的原子级数据。” 我完全同意：细粒度数据给你更多的选择，而汇总数据则有限制。
实践中最常见的一个例子是 Google Analytics 通过 API 导出的数据与 Google Analytics 360 自动加载到 Bigquery 中的数据之间的差异。通过 API，GA 只会提供汇总指标，而 GA 360 会将每一个会话和每一个事件导出到 Bigquery 中。汇总数据仅在创建极高层次的分析时有用，例如页面浏览量或独立访客的趋势线。利用细粒度数据，你可以回答任何问题——多触点归因、漏斗分析、A/B 测试等。
理想情况下，你希望能访问来源数据系统中绝对最细粒度的数据。在这个早期阶段，你还不知道将来会被要求调查的所有后续问题，你希望能够跟踪任何可能的线索。即使你的顶层问题可以通过汇总导出得到答案，你的后续问题几乎肯定无法回答。
实际上了解你所交互的数据源系统非常重要。
-
如果是 SaaS 产品，阅读 API 文档。API 会提供什么数据？好的 API 会提供你所需的所有对象；优秀的 API 会在这些对象上提供变更跟踪。例如，Salesforce API 会提供一个包含所有机会及其状态变化的历史表。这表明，机会历史表对 Salesforce 管道报告的一个大部分至关重要。
-
如果是内部产品数据库，请阅读所有可用的内部文档或与有经验的工程师坐下来了解产品中存储的数据。
总体来说，你离事件越近，情况就越好。如果你拥有一个系统的所有状态变更，你总是可以在任何给定时间点重建该状态——这是一种非常强大的状态。例如，你实际需要的唯一 Stripe API 端点是事件端点：从那个单一端点，你可以在任何时间点推导出所有其他端点的输出。你可以用类似的方式使用 Mailchimp 的事件表来分析电子邮件营销表现。
幸运的是，大多数 Stitch 和 Fivetran 集成默认会提取最大粒度的数据——这两个产品都是为现代分析栈构建的，旨在给予你完全的控制。然而，还是需要自己进行检查。前不久，我在与客户制定销售管道报告的计划时，发现 Stitch Close.io 集成（这是社区支持的）不包含机会历史端点。这显著改变了项目的范围，因为我们实际上无法在不将该额外端点添加到集成中的情况下进行所需的分析。最好在一开始就发现这个问题。
如果你的组织以前没有使用过来自某个数据管道的数据，你应该将其视为有罪，直到证明其清白。数据未使用过的情况下，可能存在大量错误方式，而且许多错误是微妙的。主要有两个类别：
-
**加载错误。**在加载过程中可能会出现错误，导致你的数据仓库中的数据不正确。即使你处理的是 Stitch 和 Fivetran 集成，错误总会发生。每次我看到集成出现问题时，都是由于最奇怪、最深奥的问题，每个问题都是独一无二的。
-
**意外的加载行为。**有时，加载发生的方式是你意想不到的。例如，Stitch 将许多它称之为“报告表”的表作为不可变日志进行加载，然后提供如何从这些表中查询的具体指示。如果你不阅读它们的指示，而是直接开始编写查询，你会得到令人困惑的错误数据。
这两种类型的错误都可以通过在建立关键任务分析之前对新数据集进行数据审计来捕捉。审计数据集究竟意味着什么？对我们来说，这意味着在表格上生成直观的指标，并将这些指标与另一个系统（通常是数据提取自的系统）中的输出进行比较。例如，我们经常计算订单和收入，并将这些指标与我们在 Shopify 中本地获得的结果进行比较。这些指标计算起来非常简单，如果数字匹配，你可以立即对数据集的状态有很高的信心。
原始数据的问题通常是跨切的：它们会影响表中的所有记录或某个日期范围内的所有记录。如果你审核 2-3 个指标，你通常可以对数据质量感到相当满意。
如果你的组织曾经使用过来自某个数据摄取管道的数据，那么你有责任去学习已经建立的内容。如果你使用的是 dbt：
-
查阅使用 dbt 文档进行的现有建模工作。
-
阅读所有模型和列的描述文本，确保你真正理解代码。
-
查找 git 提交历史中的作者，询问是否有任何你需要知道的注意事项。
不要只是说“算了”，然后从头开始你的工作。 分析工程技术债务和错误的主要来源是多个代码库试图转化和分析本质上相同的数据。两个代码路径意味着双倍的错误面和无限的混淆机会。跟踪之前的工作并不总是容易，但将现有代码库融入其中，而不是从零开始，是至关重要的。我见过一些团队不愿意以这种方式协作编写代码，而是每个分析师都建立自己的孤岛。这是一种极其低效的数据团队做法。
新的分析通常会基于现有概念，通过将新数据附加到已经建模的数据上。通常的做法是从你的应用数据库或购物车开始，然后向外扩展到其他数据系统：事件跟踪、客户成功、广告、电子邮件等。当你将这些系统引入你的管道和数据模型时，你需要至少一个关键字来连接数据。
这看起来应该相当简单，但通常情况并非如此。以下是一些例子：
-
你在 Salesforce 实例中将试用注册登记为线索，但提交到 Salesforce 的营销网站上的网页表单在流程中的那个点没有用户的账户号码。没有关键字！
-
你的事件跟踪在过去一周只显示了 15,000 个识别用户，但你的应用数据库确信在同一时间段内有 20,000 个用户登录。你的事件跟踪管道的用户识别代码是“漏的”——一些识别调用丢失了！哪些？
-
你想跟踪整个漏斗中的客户获取成本（CAC），从广告支出开始。但当你整合来自各种广告来源的数据时，你意识到市场团队没有在他们使用的链接中添加 URL 参数！没有这些参数，你就无法将来自你仓库其余部分的数据与广告成本数据连接起来。
这种情况经常发生，知道在哪里寻找问题至关重要。如果两个系统之间缺少一个密钥，可能会使整个分析项目陷入停滞，因为通常 a) 添加密钥涉及从组织的其他部分引入利益相关者，b) 没有办法追溯获取数据。
确保在深入之前检查你的密钥。如果缺少密钥，请与利益相关者合作创建它们。这种“过程仪表化”是优秀分析工程师的关键部分：你不能总是指望业务流程自然输出所需的数据，有时你需要卷起袖子确保数据被收集。
作为顾问，我必须有一个强有力的流程：如果我对一个迭代范围估算错误，这可能意味着接下来的两周我将没有足够的睡眠。或者这可能意味着我们在项目上亏损——风险是真实的。这就是为什么我（以及 Fishtown 的每个人）如此专注于精确范围估算。
在内部数据团队中，风险同样很高，但反馈通常不如外部那样明确或即时。你的利益相关者会注意到如果你持续错过截止日期或未能交付关键结果，他们可能不会直接告诉你。给同事直接反馈往往很困难——你上次说“你们团队错过了那个截止日期导致我错过了季度承诺的 OKR，我很生气”是什么时候？
即使没有明确说明，数据团队一致未能交付可预测的结果也会损害信任，从而影响团队对更大组织的影响力。通过在项目范围确定阶段识别问题，并与利益相关者沟通你的方法的局限性，避免这种结果。
原文。经许可转载。
简介： Tristan Handy目前正在构建 Fishtown Analytics，以帮助获得风险投资的公司通过构建工具来实施先进的分析，从而促进一种有主见的分析工作流程。
相关：