这些数字对我们意义重大。 我们投资数据，倾听并理解数据。 我们在决策时会以他们为指导。 尽管在处理数据的基础架构方面我们仍然遥遥领先，但数据驱动方法始终伴随着我们。 在本文中-一个关于我们走的路，我们学到的教训以及我们收集到的耙子的故事。
我的名字叫Andrey Sytsko，我是金融科技公司ID Finance的产品线负责人。 正如我所说，在处理数据的方法和工具方面，我们还有很长的路要走。 自公司成立以来经历的多重增长为分析基础架构设定了无法企及的步伐。 但是，数据驱动方法的期望可能会以更快的速度增长。 最后，众所周知，不仅特定的工具和技术很重要，而且方法，文化和世界观也是如此。
什么是数据驱动文化？
公司中的数据驱动文化意味着什么？ 在我看来，这是我们内部同意数据可以在特定业务困境的框架内给出良好答案或建议的时候。 这种安排有几个后果：
- 我们准备投资处理数据：提取，存储，分析，解释，可视化等。 准备花时间和金钱
- 我们准备聆听数据。 即 当您需要做出业务决策时，我们停下来告诉自己-让我们看看这些数字。
- 我们可以理解数据。 确实，简单地得出错误的结论，手头有所有必要的数字，真是可怕。 说您喜欢的东西，决策者的分析思维有一些最低要求，以便从表格，图表和图表中提取含义。
- 我们信任数据，并在决策时以数据为指导。 当经理在查看准备好的分析报告时说，根据经验告诉他，他会做得比报告更好，而不是报告，那他不一定是错的。 如果分析师没有考虑季节性，即将举行的选举结果或其他因素，该怎么办？ 经理和分析师之间的对话，相互信任在这里很重要。
自然，当公司的创始人已经成为公司的载体时，公司中最容易建立起数据驱动的文化。 在决策中使用数据使此过程更加耗时且昂贵。 并且没有认真地相信这样做是有道理的，否则就不会走远了。 在这种情况下，我们很幸运-未来大楼的正确基础已经奠定。
基础架构的第一步
在实现理想的数据驱动决策的过程中，首先会遇到的问题是您没有足够的数据。 通常，出于客观原因它们总是会被遗漏，但是您必须从某个地方开始。
首先，您需要构建用于收集和存储指标的基础结构。 在绝大多数数据后端项目中（例如，对于我们而言，有关客户，他们的贷款和对他们的付款的信息），首先简单地使用生产基地的副本。 在这种情况下，您将必须充分享受软件的内部数据结构，这些数据是开发人员在不考虑使数据易于分析的情况下创建的。 但是，可以说，我们拥有第一手信息。 刚开始时，通常只有一个数据库，数据结构相对简单，以及您想问这些数据的问题，所以这是一个完全可行的选择，对更复杂的事物进行投资是没有意义的。
对于前端数据（页面视图，与控件的交互，滚动，点击，输入），可以使用经典工具（例如Google Analytics（分析）或Yandex.Metrica）以及HotJar（例如HotJar）来记录会话。 有足够的基本功能可用于市场营销任务，以及针对渠道和a / b测试的产品报告，我们很快就切换到了Google Reporting API。 我们已经在哈布雷（Habré）上谈到了它。
在这里和
这里 。
建立基本基础结构并开始收集基本统计信息之后，需要确保该产品将与其指标同步开发。
即 当您要在产品中实现新功能时，您需要回答大约以下问题：
- 这将影响哪些关键业务指标？
- 客户旅程或后端算法将进行哪些更改？ 以及这将如何影响现有指标？
- 我可以分解哪些阶段/组件的新功能，以便通过收集每个阶段/组件的指标来查看内部并分析功能的工作
现在考虑收集所有以上指标的能力是否是问题陈述的一部分。 实施该功能后，您将如何准确地收集它们？
接下来，您需要确保用于收集和存储统计信息的子系统对于您的开发团队和IT团队而言具有足够的重要性。 它的重要性应该几乎等于生产系统的重要性。 例如，一开始，我们一直遇到Google Analytics（分析）跟踪从不同页面消失的问题，直到我们与开发人员讨论这些问题的重要性为止。 之后，出现了必要的通用库，质量检查指南等。
分析师分析
数据的可用性并不意味着其有效使用。 通常会出现以下问题/任务：
- 从何处获得此或那个指标？ 如何让她离开那里？
- 她对吗？ （突然一切都无法正常工作）
- 我应该得出什么报告，以便得出任何结论？
- 有统计意义吗？
- 是否有可能挖掘更多数据以更好地了解正在发生的事情，或者检查以一种方式/在一个地方由其他指标收集的指标。
事实证明，这是一项相当繁重的工作，需要特殊的技能，最重要的是需要时间。 因此，有必要创建一个分析部门。
就人员数量而言，我们的分析部门非常庞大，几乎等于中层管理人员。 它既包括昨天学习过SQL的知识的学生，又包括非常了解如何制定业务决策所需的数据的专业人员。 传统上，对他们的请求流超出了他们的能力。
湖泊和数据仓库
当将有越来越多的数据时，您可能会遇到的问题之一是它们位于不同的位置，并且某些分析师能够使用某些存储库，而有些则可以使用其他存储库。 对于某些数据库，可能没人会立即知道如何工作。 相互比较这些数据也变得困难。
该问题的解决方案可以是诸如数据仓库（DWH）之类的系统。 在我们的案例中，当我们想将有关网站上用户行为的数据与有关他作为借款人的行为的数据进行组合时，我们是第一次想到这一点。 构建DWH的原理远远超出了本文的范围，我只想说一下我们遇到的困难/特征：
- 我们每个项目（现在6个国家中有9个）的数据结构都略有不同，因此有必要制定统一的原则
- 有必要考虑如何将异构数据合并到一个存储中。
例如：
- 网站上的用户行为-页面之间的过渡，与控件的交互
- 信贷政策工作日志-规则的执行及其结果，沿着逻辑分支的过渡
- 借款人行为-贷款付款，交叉销售
现在我们已经或多或少地学习了如何将数据相互集成并将其合并到一个Data Lake中，我们着手创建店面-预先准备好的数据集，报告和可视化文件-这些都是关于这方面的。 在出口处，我们预计将大大减少分析师对技能和人工成本的要求。
通常在此阶段，公司中会出现专门的数据工程师角色-即 负责数据基础架构的人员。 他们负有维护和发展DWH的任务。
最好立即聘请合适的人。
随着公司的发展，事实证明并非所有员工都能立即理解数据的重要性并能够与之合作。 出现两个问题：内部晋升和雇用合适的人。
至于内部晋升，如上所述，如果公司的创始人是数据文化的载体，那么它就可以归结为高层管理人员，中层管理人员等等。 例如，我要求产品经理在实施之前计算货币的潜在影响或更改关键指标，并在实施新功能后查看计划事实。 或者说，要确定工作的优先级，请以对“业务价值”的相同评估为指导。
我们从两个方面着手构建数据驱动型文化。 我们的IT部门可能会要求业务经理在任务说明中对金钱影响进行估算。 这适用于所有部门：市场营销，支持，会计。 为此，我们最近添加了一项要求，即企业必须明确描述度量标准，以便通过它跟踪已实施的更改的结果，并且IT部门必须确保可以以一种易于理解的方式访问这些度量标准。
当然，重要的是在雇用人员时立即检查他们是否习惯于专注于工作中的数字，是否知道如何去做。 在面试中，当我们讨论候选人的经历时，我最喜欢的问题是：您如何计算该功能将产生什么样的效果，如何衡量该功能实际上会产生什么效果，以及为什么您认为该效果应归因于此功能，而不是其他的东西。 一个好的候选人总是能够从逻辑上证明他这样做的理由，而没有其他理由。
随着业务和数据量的增长，使用更高级的统计技术和更高级的应用程序库（现在称为数据科学）变得有意义。
例如，如果我们从比神经网络和机器学习更广泛的角度谈论数据科学，那么，例如，我们在从SAS之类的经典软件包转变为逻辑回归到自写python工具方面拥有成功的经验。 这
将开发信用评分
的时间减少了 5倍。
在某个时候，我们意识到对某些数量的逻辑回归和聚类分析证明了它们在市场营销和产品管理中用于与客户细分相关的任务以及为每个客户分别确定最佳产品或折扣策略的合理性。
学习预测未来
贷款业务的特殊性在于，仅仅销售产品是不够的-信贷，您需要管理未来的现金流量。 因此，各种预测模型的作用及其在未来损益预测中的整合就显得尤为重要。 这样的模型的示例：基于早期欠款数据的未来费用，基于客户细分数据的平均账单，基于退货数据的贷款数量等。
当有一个工具包可以让您评估功能对各种关键业务指标的影响并预测公司收入的增长时，这通常会非常令人鼓舞。
为了开发，维护和实施此类工具，我们现在正在建立一个财务计划和分析部门（FP＆A），其任务是使业务决策更加受数据，分析和建模的支持。
我们前面还有很多有趣的事情：BI基础架构的进一步开发，支持它的部门的创建以及使用它的流程。
总而言之，我们可以区分以下原则以开发数据驱动的方法，我将坚持以下原则：
- 预期的投资回报率（例如，节省员工时间，提高决策的准确性/速度等）足以满足所消耗的资源。
- 内部产品管理：在创建和开发基础结构时，将调查“愿望清单”和内部客户的反馈。 并考虑在内。
- 基础架构开发必须跟上流程和方法论的发展。 总体而言-就分析需求而言，不要落后，也不能超过公司的发展。