大家好，我们最近
写了关于我们如何学会使用GoPractice Simulator进行数据驱动的文章！ 在本期中，我们将继续进行数据分析的主题，并讨论在Plesk团队中构建分析工作的过程。
Plesk是一个具有20年背景的复杂产品，我们并不总是能够有效地收集必要的统计信息。 长期以来，我们只是回顾性地看待数据，而决策是基于“应有”的主观感觉做出的。 过去，我们已经为这种方法带来了可悲的后果-2012年，我们更改了设计，希望做到最好，但收到了一阵负面反馈，拒绝更新产品的最新版本和客户流失。
理解了这一不幸的经历之后，我们得出了结论，并决定着手建立一家数据驱动公司。 这样，不同性质的困难在等待着我们。 在很大程度上，它们可以分为两个主要组-系统和流程，在本文中，我将重点介绍构建分析工作流程的任务。
与盒装产品的特性相关的系统性问题值得在单独的文章中找到，因此在此我将不对其进行详细介绍，仅列出最重要的问题。
- 许多事件，大量使用。 如果我们仅讨论跟踪面板中的用户操作，根据我们的估计，这是每月6000万个事件，可惜的是要为高级Google Analytics（分析）提供15万美元。 另一个困难是，要使用GA，您需要显式处理每个自定义操作，但是我们希望获得一个统一的机制，该机制不需要为每个新功能手动标记事件或操作。
- 由于包装盒的数量和格式（展开任何更改都需要时间），因此分析无法实时进行。 用户正在使用该产品的8种不同版本，其中4种已经停产。 即使是最新版本，在发布后的前两周中也只有60％的用户进行了新更改。
- 复杂的产品。 Plesk支持Linux家族的14个操作系统，4个OC Windows，150个第三方组件，多个Web服务器，邮件服务器，Webmail客户端，统计可视化工具，防病毒解决方案等。 大量可能的配置主要影响测试的复杂性和数量，并且几乎不可能使用A / B测试。
- B2B2C细节。 决策者并不总是等于“专家组的真实用户”。
- GDPR-遵守法律规定需要进一步努力以使数据匿名化，并使用户细分的任务复杂化，并且使我们无法使用他们的联系信息轻松快速地联系客户。
我们将更详细地讨论过程难题。 直到最近，与我们一起收集分析的过程完全脱离了开发过程-我们记得最后的跟踪和指标，搞定了一次性解决方案，依此类推直到下一个功能。 此外，这些年来，Plesk积累了许多数据源-包括维护数据一致性，数据相关性，需要牢记数据的来源，在什么条件下进入数据库以及为什么在不同位置使用相同度量的成本不同（例如，许可证密钥和物理安装的数量）。 这些信息被写入了很多信息（每月从27万个密钥的数据库中删减，并且从30万台服务器到达的报告的访问频率是两倍），但是只有少数人能够使用此数据并找到时间。 我于2015年加入Plesk，最初的任务只是从OLAP多维数据集和MongoDB数据库中获取异构统计信息。 该数据库的“操作方法”是一个页面，其中包含来自主机的用户名和密码，以及具有来自上一个受欢迎请求的js脚本的文本文件。
一堆资源意味着一堆工具和服务，每个程序管理者都应该能够使用它们。 上班初期的感觉是这样的：
我们做了什么？
解决方案如下：大约一年半之前，我们开始对数据收集过程进行全面检查-现在我们以与功能本身相同的方式开发分析，从PM和开发到QA工程师，整个团队（功能人员）都参与其中。
假说
这一切都始于功能规划阶段：PM提出一个假设，在下一步将基于该假设选择度量。 例如：Plesk有一个Advisor推荐系统，它可以按照建议的步骤（添加ssl证书，启用更新，更新PHP版本等）来帮助用户改善服务器的状态。 通过发布Advisor，我们假设用户将遵循建议，服务器的“运行状况”等级将提高，并且由于游戏化的“成就”，用户将持续参与与Advisor的交互。
公制
在下一步中，为每个假设选择一个度量标准：对于Advisor，这是建议中的点击次数，受证书保护的网站百分比，评级得分等。 所有这些信息（假设+指标）都已在Vision-文档中输入，其中包含功能要求。 在这一点上，数据分析人员参与了该过程-他们的任务是帮助使度量标准可测量，易于收集且明确。 即使诸如数据库或报告中的Future字段的结构之类的细节也很重要-由于负责该功能的PM经常会访问此信息，因此决定如何更方便地执行此操作（直到数据库请求的所需结构）符合他的利益。 顺便说一下，由于采用了这种方法，从某种意义上来说，进入100,500个数据源的需求已经大大减少了，这对每个人来说都变得更加容易-现在，您可以决定将以哪种格式收集数据以及更喜欢如何获取数据。 通过固定视图中的计数逻辑，PM还可以随时有机会返回文档并根据数据库进入/增加计数器/发送事实的标准来回想。 这解决了理解报告逻辑的问题。
实作
提出假设并选择度量标准时，该轮到实施了。 开发人员同时实现功能本身和收集其统计信息的机制。 如前所述，由于各种原因，使用GA等现成的解决方案非常困难，因此，两年前，我们的工程师实施了自己的机制来跟踪面板中的用户操作。 除用户操作外，各种技术细节，配置设置等也可能引起关注。 -所有这些都发送到已经提到的MongoDB数据库。
测试和预览
像任何产品一样，数据收集机制也应进行测试-在我们的案例中，质量检查工程师检查是否显示并打开了建议，监控了评级，并在数据库中收集了有关所有这些事件的信息。 通常，选择用于跟踪和分析的用例会成为测试功能本身功能的新测试用例。
质量检查工程师检查完所有方案后，项目经理和开发人员一起查看了第一笔数据，并确保功能1）并未破坏任何东西，以及2）可以正常工作，并且统计信息收集了他的兴趣-一切准备就绪，可以发布。释放。
功能寿命
当某个功能在发行版中启动时，最有趣的部分开始出现-它在产品中的“生命”。 不再抛出：“您是否偶然知道我们数据库中的哪个字段存储有关显示推荐的信息？ 不行吗 blin ...”。 数据分析人员没有收到闲适的消息：“您能再数一次最新版本的印象数吗？” -为此，在仪表板上具有配置好的警报的图表，如果监视的值急剧下降/增加/更改/在数据库中找不到记录，则这些警报会发送字母。 但这还不是全部。 仅仅知道计数器已经增加或减少了n％，还不足以使人确信这是一个重大变化，而不是季节性跳动或误差范围内的波动。 我们的团队成员之一正在开发一种框架，用于衡量指标变化的统计显着性。 他使用数学统计仪器计算了评估变化的重要性所需的最小样本（用户/设施/事件的数量），选择了可以比较的细分并确定了最有可能包含我们感兴趣的指标的实际价值的置信区间。 这个框架已经过测试，并在上周获得了有趣的结果：我们发现，在Plesk面板内的扩展目录中开始显示价格之后，人们开始为这些产品购买更少的年度许可证，而每月购买的许可证则更多。 目前，我们的同事正在计算LTV预测，此后很明显，这些变化从长远来看对我们来说是正确的，在显示价格的逻辑上我们应该推广哪种选择。
终止支持
如果由于缺乏需求或其他原因（例如，出于对过时的操作系统或PHP版本的支持而终止的安全考虑），则任何产品或功能的使用寿命都是终止其支持的结果。 在这里，分析还可以为我们提供帮助：例如，当我们决定鼓励用户切换到新版本的PHP时，我们要做的第一件事就是收集Plesk用户之间的版本使用情况统计信息。 我们了解到，使用PHP 7的百分比仅覆盖20％的用户，并且意识到以数百万个损坏站点的形式强制切换的潜在成本超过了旧版本可能存在的漏洞的风险。 结果，我们决定采用较温和的影响力衡量标准，并从有关是否需要升级面板的通知开始。 另一个例子可能是无数的故事，其中包括对操作系统停止支持的案例-如果我们发现拥有成千上万个Plesk安装的最大客户之一正在使用某个OS，我们有针对性地与该合作伙伴进行通信，并在无法快速过渡的情况下向他提供所谓的惰性删除-终止对新安装的支持，以及在升级到最新版本的Plesk之后继续进行现有安装的功能。
结论
总而言之，我想再说一次我们认为最重要的事情-现在为我们使用分析工作是每个功能工作不可或缺的一部分。 但是构建的过程并没有结束。 根据我们自己的经验，我们确信数据质量控制并不比过程本身重要。 如果在收集的任何阶段数据丢失或失真，一切都没有意义。 为了防止这种情况的发生，我们在每个阶段都努力添加数据完整性和正确性检查，并记录每个处理步骤。
还有最后一个。 不要仅仅因为可以做到就用度量衡量自己：)清楚说明这些信息对您有用，并且在收到信息时，请问自己是否得出可以采取行动的结论。 毕竟，了解要做什么才是刚开始的一切：)