Question

数据处理工作不仅依赖于数据工作者的经验，也需要考虑实际的运营业务因素。这种兼顾两种工作逻辑的工作方式会帮助数据工作者少走弯路并降低数据项目失败的可能性，还有利于提高数据工作的效率和产出效果，真正让运营理解数据、应用数据并驱动业务。

数据处理时应该考虑的运营业务因素包括固定和突发运营周期、运营需求的有效性、交付时要贴合运营落地场景、专家经验、业务需求等变动因素。

3.11.1　考虑固定和突发运营周期

运营业务的周期属性主要表现在两个方面：

有计划的周期性：运营业务计划的制定都有明显的周期性规律，运营业务的执行也是如此。这种有计划的周期性规律一般包含不同层次的周期。例如，运营一般都会先做年度计划、季度计划，然后分解到月度计划，月度计划再细化到周度和日度计划，层层递进，步步追踪。

临时或突发周期：除了有规划的运营周期以外，偶然事件的发生也会影响运营业务。例如，由于内部DBA的误操作，导致数据库部分数据被删除，直接影响了公司正常的销售和运营状态。这种情况发生的时间以及产生的影响周期通常都是不固定的。

运营业务的周期性特征对数据的影响：

有计划的运营周期在数据的选取和分析过程中非常重要，尤其涉及对比（环比、同比等）时，选对具有相同属性的对比周期是形成结论的基础。

有计划的运营周期对于时间序列特征明显的建模影响很大，包括时间序列、时序关联、隐马尔可夫模型等，这些算法和模型都需要数据带有明显的前后序列状态的关联属性。使用这类算法需要将运营周期的属性与算法和应用的属性相匹配。

不同周期下产生的数据可能有差异，尤其是对于高速发展的新型公司，不同周期下的数据可能带有明显的线性、指数、二项式以及其他变化特征，甚至可能带有业务因素导致的异常数据点。

运营过程可能产生突发的数据工作需求，例如针对异常事件的临时性分析，而这些需求很可能由于没有提前针对性地做数据布点、跟踪和采集，而导致数据不完整或根本没有有效数据可进行分析。

数据工作的整个过程都需要运营业务人员参与，而依赖于运营业务人员参与的时机以及对应的方式和切入点也很重要。例如，在业务正常工作非常繁重甚至无法脱身的情况下，如果需要业务过多地参与数据工作，必然会形成来自于业务端的重重阻力，此时需要更多数据自动化和程序化的工作模式。

3.11.2　考虑运营需求的有效性

在数据工作项目真正开始前，通常会有多次沟通、反馈、验证和摸底的过程，这些动作的目的是根据业务的需求、数据的实际状态以及数据工作本身的限制来综合考虑运营需求是否有效。数据工作者并不是一定需要承接所有的运营数据需求，他们可能会对某些需求做拒绝或延迟处理，主要原因如下：

缺少数据：现有数据无法满足运营人员提出的数据分析需求，典型案例是在应对突发事件时的数据分析需求。

需求不合理：经过验证后，发现运营人员提出的需求不合理，或无法通过数据得出结论。例如运营人员要分析客户对于新产品的预期，这种需求除了市场和客户调研外，其他方法基本无法实现，因为预期本身无法通过数据衡量。

条件限制：虽然运营人员需求合理，但现有服务器、算法、技术、经验等主客观条件无法实现。例如运营提出要从监控视频中得到整个人在线下店铺内的所有浏览、查看和购买商品的轨迹行为，由于缺少相应的技术和经验而无法实现。

资源限制：目前数据工作已经满负荷，无法并行开展更多工作。

低价值需求：运营人员可以自己实现的基本需求。很多时候运营人员会犯懒，基本的取数、查询、统计和分析等工作全部交给数据工作者来实现，对于这些简单且常用的工作内容，由于本身属于数据工作的范畴，数据工作者大多都会接收执行。这些工作当然有价值，但是要真正最大化发挥数据工作者的价值，绝不能只着眼于这些内容。这些基本工作可以通过可视化报表、自动邮件、数据工作文化的培养等逐步从数据工作中剥离，或逐步降低内容比例。这样才能有更多资源应用到潜在规律、预测性和探索性的知识发现中。

对于符合以上特征的数据场景，数据工作者需要慎重考虑是否还要继续投入资源，对于需要拒绝的一定要及时提出，以免导致数据工作项目失败以及数据工作价值度降低。

3.11.3　考虑交付时要贴合运营落地场景

数据处理虽然只是中间过程，并没有到达数据分析、建模、部署及应用等后期阶段，但该阶段的很多工作都会直接影响后期交付和运营落地效果。典型因素包括：

（1）维持原有指标

后期应用时需要原始业务指标（变量）以便于业务理解和应用。如果有类似的需求，那么在数据处理（比如降维）时就不能采用数据转换的方法，要根据实际情况通过多种方式选择维度或不进行降维。

（2）更容易理解的算法模型

某些运营人员可能比较“认真”，会非常关注算法模型的实现过程，如果采用无法解释具体过程的算法（例如神经网络的实现过程）或难以理解的算法（例如SVM中的超平面），那么这类运营人员通常会怀疑数据工作的有效性和正确性。此时，选择更加容易理解的算法模型（例如决策树、线性回归等）则比算法准确度、时效性更重要。在数据处理过程中，要针对这些容易理解的模型做针对性的数据处理。

（3）数据生产和应用环境

如果数据工作项目的结果不是分析、挖掘报告，需要通过程序化的方式执行，那么交付的一般都是代码或脚本。在数据处理程序发布上线时，应该尽量使用生产和应用中既有的模块、环境、库、语言、版本等，减少额外部署、开发和维护的工作量。

3.11.4　不要忽视业务专家经验

本书中多次提到了业务专家经验的重要作用。业务专家经验在数据处理工作中的重要作用体现在以下两个方面。

1.数据工作方向

数据工作方向指的是整个数据工作项目中需要做什么、产出是什么、中间的过程应该向哪个方向考虑等，这些内容侧重于“是什么”。这些内容直接产生于业务专家经验，主要影响的数据工作内容包括：

数据项目工作目标和需求；

数据探索和摸底方向；

数据交付物的形式和规格。

2.数据工作逻辑

数据工作逻辑指的是在数据工作本身方面，业务人员能够为数据工作者提供的价值参考和工作建议，这些内容侧重于“怎么做”。主要影响的数据工作环节包括：

总体数据周期、规则、条件等的选取；

数据抽样规则，尤其涉及分层、整群抽样；

多数据的整合、匹配和关联关系；

不同数据源和数据间的清洗、转换逻辑；

重复值、异常值和缺失值的处理逻辑；

数据离散化的方法选择和区间定义；

根据变量重要性进行数据变量的选取和降维；

数据算法和模型选择；

数据模型的调整、评估和优化。

如果只擅长于运营，这是一个纯业务属性价值点；如果只擅长于数据，这是一个纯数据属性价值点。只有同时具备业务+数据的双重属性，才能成就真正的“分析师”。成功的数据工作一定是数据+运营两条腿走路！

3.11.5　考虑业务需求的变动因素

业务需求的变动主要来源于业务环境的变动或业务需求本身的变动。前者是由于客观环境的变化导致业务需求不得不变动，后者则产生于运营业务本身的主观环境。

在数据工作项目中，变化的需求会影响整个数据工作的所有环节，如果业务需求频繁变动，会给数据工作带有极大困扰甚至可能直接导致数据工作项目的失败。因此，数据处理一定要将业务需求的变动因素考虑进去，涉及客观环境的变化无法预测，而业务主观思想上的变化在很多情况下可以提前做好准备：

（1）充分、有效的沟通

沟通是建立持久、稳定关系的重要方法，在开始数据项目的工作之前，数据工作者千万不要嫌麻烦而略过这一步。多次邀请相关的直接需求业务人员、业务领导、数据提供者（通常对应业务口的数据管理员）进行正式会议的沟通是必要的。同时，为了避免会议沟通上口头表达和理解的误差，一定要在每次会议之后都撰写会议纪要并找相应人员确认作为备案，还要抄送多方领导来让各方都重视并慎重考虑沟通和落实内容。

（2）更完整、更原始的数据集

在数据集的选择和处理时，涵盖更多时间、维度、来源等方面的数据，并放宽甚至去掉业务给出的数据过滤条件，这样可以减少重复取数工作并尽量降低对后续所有处理流程的二次调整影响；对于涉及数据归约的，尽量优先选择直接选取而非转换的形式，这样可以最大限度满足业务对原始数据维度和指标的需求。

（3）可理解性强、规则清晰的算法和模型

在保证一定的模型准确度的情况下，优先选择可理解性强、规则清晰的算法和模型，以降低因业务无法理解而导致的返工或无法落地等情况。

（4）模块化工作方法

在大多数程序式数据工作中，我们发现很多工作内容的基本功能模块是可以复用的，这意味着假如我们第一次需要开发10个模块，第二次可能只需要额外开发5个，其中5个模块复用第一次开发的即可，第三次可能只需要额外开发3个，以此类推，随着项目的增加可复用的功能模块会越来越多。虽然根据不同的场景、数据，同一个模块也会有不同的实现方法、参数等，但这仅仅是对原有模块进行优化和升级，越到后期就越会形成更加通用、完善且具有高复用能力的功能模块。这些功能模块不仅可以用来提高数据项目的工作效率，还能有效应对业务需求的个性化、灵活性的需求变动。

模块化工作方法是笔者倡导的一种有效的工作方式，在Python中，笔者会更多的使用面向函数的编程方法来实现。

（5）建立数据工作流程和机制

无规矩不成方圆。所有的数据工作都应该有对应的流程和机制才能保障其正常运行。对于数据工作流程而言，要建立起从数据需求提出到数据落地的完整流程，其中需要包含应对需求变动的时间、频率、方式、范围、影响的规范，以及审批和授权制度（一定要经相应人员和领导同意），这样制度才有可能落地。当然，只有制度还不够，更关键的还要看执行！