本文根据神策数据华南业务中心 leader & 咨询中心负责人徐美玲《数字化运营，从 1 到 100 的跨越》的分享整理所得。主要内容如下：
· 数字化运营的内涵
· 数字化运营体系的构建
· 数字化运营的困局与反思
· 实现从 1 到 100 的跨越
之所以从 1 而不是 0 开始，是因为我相信绝大部分企业已经有一定的数据基础，无非是在数据体系落地程度上有所差异。从 1 到 100，最核心的是要把数据的价值在业务中真正体现出来。本次分享将会从数据体系入手，讲述当下企业面临的现状，数字化运营体系落地过程中的一些思考，以及神策对企业在数字化运营方面的建议。

一、数字化运营的内涵

提到数字化运营的时候，很多人会有不同的认知，但真正的数字化运营究竟体现在哪些地方呢？
对应神策基于数据流的企业运营框架——SDAF，结合实际业务场景，我认为数字化运营主要体现在六个层面，如下图所示： 

1.可度量

业务发展情况和变化程度都是可精准度量的。在度量这件事情上，有许多门道，比如我们期望通过什么样的指标去度量，它包括指标的定义和口径等。举个例子，在做活动效果分析时，企业是想分析独立的活动，还是想分析整个活动运营体系对业务大盘带来的提升？在不同的分析场景中，所参考的指标体系是不一样的。
一个好的度量体系，其完善性、业务价值的准确性以及对维度拆解和全方位诊断方面都是可以全面发挥价值的。

2.可分析

可分析与可度量最大的差异在于，可分析需要通过一定的分析方法、思路和框架，或者一些相对高阶的技术手段，来判断度量指标的合理性，以及指标改进的关键点等。
服务了 1500 余家企业之后，我们发现大多数企业在数据基础建设方面已经起步。在合作过程中，神策分析的灵活性和支持能力具有明显优势，它能够帮助企业梳理指标体系、配置应用上线等。但推进分析的难度相对较大，主要在于每一个分析都与业务主体和业务场景有着强相关性，同样一个数据指标的变化有可能是外部因素导致的，有可能是内部因素导致的，也有可能是周期规律性的因素导致的。
面对此类强业务关联性的分析场景，我们在接收到咨询需求时，必须要深入业务体系去考虑业务现状和接下来的动作，结合数据的表现，给予有价值的诊断和建议。也就是说，分析这件事儿对内部人员和外部接入人员在业务理解和数据分析的专业度方面要求更高。
但是，目前整体看下来，至少有 50% 的企业在分析这个层面没有做好。

3.可反馈

粗略来看，可反馈跟可度量是相似的，差别在于可反馈是针对某一项已经做过的事情的效果反馈，也就是说在某项已完成的活动或业务中，我们期望得到的反馈是哪个动作影响指标如何变化等。与度量大盘指标不同，可反馈有较强的精准指向性，通过精准衡量每一个动作带来的变化情况，基于归因分析和体系化洞察，实现可反馈。
通过观察，我们发现可反馈程度较高的企业有着共通之处，他们对业务变化的应对能力，对动作的归因能力都较强，一方面源于思路框架的强化，另一方面来自于对工具的高效使用。在正常业务流程中，可反馈是一个积少成多、量变影响质变的过程。
正如前面所讲，可反馈的本质是一个归因体系和逻辑，涉及到大量的数据处理，与动作和业务维度强相关，它所面临的挑战在于拿数和用数。
可度量、可分析、可反馈三个层面更偏向数据角度，但业务体系和数据体系属于并行耦合的关系。

4.可预测

预测最明显的表现在于它会根据过往的数据特征表现，结合业务场景逻辑，为业务提供指向性发展、前瞻性处理的建议。
最常见的可预测应用是智能预警。基于企业业务发展状况，对接下来三个月或者一年的业务发展做出预测，然后分配到每个月的业绩指标应该是多少。预测比度量更贴近业务，它指导业务目标的制定，在业务场景异常的判断方面有更强的业务耦合和指导价值。
对于某些需要调度区域资源的企业来说，可预测的精细化程度相对较高，因为外部影响因素过多，比如时间、天气、资源供给情况等，预测难度要比其他类型的企业更高。
从整体上来看，预测的难度不大，但是把目标管理，尤其是增量目标管理，以及业务异常智能预警做好，需要涉及算法或者更高级挖掘的技术，以及平台化的能力、可视化的应用与呈现、实时性等。

5.可决策

分析和预测的核心目的是指导决策，如果分析和预测对业务场景没有带来本质上的影响，就意味着分析和预测对决策的影响力不够理想。
决策在数据分析的完整链路中，难度相对较大。在大部分企业内部，分析团队和业务团队往往是两个不同的群体，他们在数据分析的专业度、对业务的理解和判断上有所差异，业务团队基于业务导向会优先考虑资源优先级，会站在整个大盘的增长体系中，考虑跟分析团队不一定强相关的业务逻辑，甚至有些业务团队会从内部利益出发，拒绝不能够带来明显利益的数据分析应用落地。
从我个人的经验来看，很多时候数据分析驱动决策跟企业的一把手或者业务负责人的认知、理念强相关。
另一个方面，我见过越来越多的数据分析能力强的人开始自己干业务了。因为推动太难，当自己的业务思路和方向性足够强，执行力到位，那么自然可以从分析到决策落地全面把控。这其实是一个挺有意思的事情，但我认为这会是分析师职业发展必然要经历的一个过程。
在我最近负责的几个 Case 中，有一些互联网企业，他们的 CEO 是做数据增长出身，目前整个企业也已经发展到强数据驱动业务增长的阶段。这在某种程度上印证了数据对于行业和业务人员的倒逼，这也就是为什么文锋曾说“将来所有的人都应该要懂数据分析”。不一定要求业务人员能够深入了解并参与到数据分析的过程中，但要求业务人员必须具备基础的数据分析能力，要能够理解数据分析的基本逻辑，以及从分析结果往解决方案方向的推导路径，如果这条路径还未打通，往后只会越来越难，这也是我对业务同学提升数据分析能力的最基础的建议。
因为数据分析在行业内已达成共识，做数据分析的“干掉”做业务的例子也不少见，真正把业务做得好的人数据分析的能力一定不会差。比如神策的张涛老师，他以前是做产品和运营的，但在数据分析领域也同样很厉害，这个便能看得出来行业发展趋势。我早年也是做产品的，当时我发现部分做运营的同学更偏向执行，从数据到决策这件事上很难自主跑通，在某些层面上，运营团队和产品团队有着明显的利益冲突，运营同学更重视短期利益的实现，长期利益依赖于跟产品更好的协作，所以业内的优秀运营通常是在跟产品的短期和长期合作与平衡方面是做得非常优秀的。

6.可行动

神策近期的一个较大变动是，我们会更关注整个产品和工具体系的最后一公里的打通，即行动的闭环。
在数字化基础设施中，我们可以看到，这个完整体系其实全部都是数据独立于业务流运作的，但如果你希望数据运营体系直接实现可行动，那么数据和数据形成的结论，比如对于特定人群的提取、对于特定人群的运营策略，本质上是需要打通业务流和运营通道与机制的，这是目前来看最难的。
在互联网体系中，这种底层偏业务的后台早期建设还是不错的，比如大家知道的内容管理后台、运营后台等。如果要把数据跟行动打通，重要的便是数据、运营后台、前端用户交互体系能够完整融合成一套体系，然后基于数据形成决策结果直接对业务流进行操作，并在操作完成后立刻形成反馈。这是目前体系中耦合难度和处理难度相对较大的部分。
在数据基础建设部分，通常对数据体系、工具体系、数据跟业务的耦合体系、相关人员的意识跟能力等要求较高，呈阶梯状发展。在我看来，目前到分析环节已经有比较明显的阻塞了。
反馈环节的阻塞相对来讲最明显，也是现阶段大家最刚需的。目前大多数企业的基础度量已经没有太大问题了，能够保障业务决策时的业务性指标和关键的核心业务指标，那么所谓的 100 也就是剩下的五个环节所代表的含义了。

二、数字化运营体系的构建

基于整体逻辑演变的数字化运营体系构建路径可以分为三部分，如下图所示：  

· 看数据，对应度量和基础分析
· 分析数据，它是整个体系进阶中阻塞性最明显的环节
· 应用数据，这一环节的前提是要对数据分析有基本的掌控力，能够通过数据分析形成对业务和用户的判断与认知
从深度学习模型来看，有了清晰和准确的判断与认知，能够保证决策的目标与方向的准确性、和企业战略的一致性等，以及后续数字化运营过程中的诊断与调优。这也是为什么神策一直强调数据分析价值的原因所在。
作为数据分析师，我之所以要把这三个模块分开，是因为在大多数企业内部这三部分工作对应的岗位也是不同的。一般来讲，「看数据」这部分大多由数据分析师、BI 同学来做，包括对数据的清洗处理，采集工作的规范调整等；「分析数据」这部分更多的由分析人员主导，而分析人员通常分为 BI 团队的分析人员和业务团队的分析人员；「应用数据」则是由策略团队的分析师、算法工程师等同学来负责。这三个环节在本质上对应的角色逻辑是不同的。
但不管哪个环节的同学，都会面临最底层的问题——数据本身能不能支撑我想做的事情？
在数据基础建设这件事情上，在不同的业务场景中对数据的需求是不一样的。很多企业最初只是想要做一些基础数据采集，查看某些功能的用户点击率、使用情况、崩溃情况等；但是在应用数据的阶段，数据本身的丰富度和维度至关重要。在神策过往服务客户的过程中，特别是 2017-2018 年期间，大部分客户对数据的需求并没有那么迫切；但到了 2019 年初，整个大环境变了，企业开始加速精细化运营进程。因为一旦精细化运营、降本增效的诉求加入议程时，企业对数据质量的诉求也会明显提升。在这个阶段，外界看到的最明显的表现是，企业在招聘数据基础建设、数据分析应用领域的人才投入显著增加。
因此整套数字化运营体系建设对于数据基础的建设有显著要求。

三、数字化运营的困局与反思

普遍概念上的技术可能是产品、人工智能、算法、SDK 采集等。拆解如下：

1.关于技术：为什么不能是万能神药？

关于技术的典型问题，我们总结如下：
问题 1：有没有一种技术方法，能实现数据默认全部采集？一方面减少研发资源投入，另一方面能够有效避免数据不完整。
问题 2：数据分析能不能实现自动发现问题，并给出解决方案？
问题 3：策略执行之后，系统能否实现自动生产及调优？
在我看来，技术要解决的这些问题，在基本的技术概念上，是具备「可行性」的。在神策，我们有很多厉害的研发人员，很多事情要考虑了「投入产出比」之后，再去决定要不要做，同时，在这个过程中也会涉及到一些「约束条件」。
举个例子，做数据自动诊断时，在特定的业务框架体系中，相应的维度已被量化，且量化的结果能够作为输入因子做相关处理，那么，在对应的实际场景中，自动诊断是可以实现的。但必须要关注的是，「约束条件」的个性化程度较高，也就意味着对执行相关策略的人员要求较高，要求其能够将数据、业务和技术融合到“完美”的状态。
「投入产出比」在问题 1 中表现相对明显。从逻辑上来讲，实现自动默认采集基础数据是可行的，特别是当系统能够采集到你起初并没有规划在内、但在回溯时需要用到的数据时；但并不是系统自动默认采集到的所有数据都会对应使用场景。
从另一方面来看，这也代表着数据采集的量级较大。因此在我们日常与客户沟通过程中，通常不推荐第一种解决方案，虽然框架和方向没有问题，但也仅限于减少研发资源的投入，降低研发人员重复和维护成本。
在报错监控这个典型场景中，需要完整、精确地记录报错率的数据，用接口请求的次数跟接口返回的结果中错误数据的量来计算，如果采用自动默认采集，很有可能监测数据会以十倍、百倍甚至千倍的量级去增加，也就是说需要采集的数据量要足够大。
除此之外，自动默认采集对于存储和性能的消耗也是不能忽视的，性价比太低。那么这个时候，我建议大家在采集报错的结果数据时，分母不要用次数去统计，可以用人次、App 启动次数，或者 App 启动人数去做覆盖率的计算。从本质上来看，衡量报错的趋势和量级的价值是相似的，虽然没有精确到次数的维度，但对于优化系统的价值是相似的。
因此，在具体的解决方案设计方面，会有很多细节的处理，这也是我们很多客户真正遇到问题时希望我们的解决方案能够带来的最优解。 我不建议把技术当做万能神药来做的根本原因在于，我们所做的事情需要站在产品和公司的角度来考虑其「约束条件」和「投入产出比」。

2.关于智能：为什么难做出有价值的成果？

据了解，能够应用深度学习或高阶的数据挖掘方法与技术的企业并不在少数，尤其是一些高阶的互联网企业、金融企业等，在智能领域的投入都很可观，但真正能够做出优质成果的企业却很少。
智能的应用对企业来说是有一定的价值和增长空间的，但是需要遵循以下基本逻辑：  

第一，数据基础。当下的技术型人才和开源方案已经足够满足企业所需，其最大的难点在于数据基础。
第二，对业务的理解。在进行模型训练时，需要输入模型训练的目标，这个类似指标度量，对于业务的健康发展和价值提升是强相关的。举个例子，在社交场景中，计算指标可以选择用户之间匹配的次率或者人率作为目标，如果以次率为匹配目标的话，当用户和另外三个用户发生了互动，但仅有一个用户响应，那么就会被记录为三次；如果按照人率，当该用户与响应的用户产生了 5 次互动且都得到了回应，那么就会计算出 5 个基准值。因为调参和改进的方向不一样，所以类似这样的简单指标对于模型训练能否提升社区健康度、运营价值有非常大的影响。
第三，算法模型。坦率来讲，如果只看匹配次率会导致算法体系把优质的、TOP 级的资源推送给所有用户，因为这些优质推荐能够带来更高的反馈率。但与此同时会有一个核心问题，真正的社区健康度在很大程度上依赖于新客，尤其是腰部力量，也就是那些可能反馈率并没有那么高的用户群体，他们通常是社区的中坚力量，需要平台对其投入和扶持。这个时候，如果算法优化方向是次率，那么它对于留存的影响是非常大的。因此，智能算法通常取决于对业务的理解，这也是为什么算法团队需要策略、产品、数据分析师的原因。
第四，闭环验证。它的本质是什么？算法的功能性实现依赖于功能开发的逻辑，如果缺乏诊断分析，就很难得到真正的业务成效反馈。除非功能一上线效果便很好，且好到无需优化，但这种情况发生的概率极低。无论是算法的策略还是运营的规则性策略，都需要投入时间来做迭代，并在迭代体系中跑通闭环，真正实现数据化运营。

3.关于工具：重要 or 不重要？

作为业务人员、资源统筹人员，工具究竟意味着什么？能否对这件事情有清晰的认识？在跟很多客户交流的时候，我了解到，更多人强调的是“我要的不是工具，而是解决问题的方法”。对于这个观点，我个人是很认可的，因为工具本身其实很难解决全部的问题，它并不是解决方案里的所有，只是解决方案里的一个环节。
但是，如果你认为“工具本身都差不多”，那就是大错特错了。这里我们通过“会用”“好用”“持续运营”三点来拆解。
假如说一个工具的价值是 100 分，会用的人最少能够将价值发挥到 70-80 分，那不会用的人可能只能感知到 10-20 分的价值，那么对于这些用户来说，工具确实没什么差别，因为他们很难了解到差别在哪儿。如果没有好的方法去使用工具，自然无法判断工具的价值。想知道工具真正的差异在哪里，前提是要会用工具。
在我来神策之前，我所在的公司有自己的 BI 报表平台和取数逻辑，但我们还是用了神策的系统，这是为什么呢？首先，数据团队的人觉得工具、平台、数仓都建好了，使用层面的问题不需要他们参与，但问题就在于他们研发出来的工具不支持全面、完整的分析模型，基本上只有 PV、UV 等基础的业务数据。因此，我们选择接入神策，和数据团队形成两个并列的数据体系。
在神策的产品迭代过程中，有 60%-70%的需求来自于售后交付的客户，这与神策售后为主的迭代逻辑息息相关。关于持续运营，值得特别强调的是，工具买回来不是终点，正如产品上线后仍需要运营同学持续维护一样。在任何企业内部，运营都是需要强数据体系、强业务视角来推动的。

4.关于数据：究竟是资产，还是负资产？

我们也曾遇到客户提出疑问：“我们已经实现了数据采集，为什么要使用神策的系统再次采集一遍？为什么要通过神策对我们现有的数据体系重新梳理和优化呢？”这件事情背后的原理是什么呢？如何评估企业的数据体系建设带来的数据资产是正向的还是负向的呢？基于此，我梳理相关评估指标，如下图：  

首先，数据是否准确。这是一个致命的评估指标，若数据准确性无法保障，那么为数据付出的成本、资源等都是浪费。
其次，在数据采集方面，我建议按需采集。数据的时效性是极其重要的度量机制，在没有想好如何用数的时候就去采集所有数据，最终只能导致存储成本无限增加。这是因为每个人做事的思路和出发点不一样，或是应用导向，或是系统建设导向。“先采再说”反映的是负责数据采集的人或者团队对数据应用没有足够的认知，想当然地认为数据都是有价值的。
这里需要强调一下，在行为数据领域，除了基本的大盘指标建议长期保留，很多交互级别的行为数据，超过三个月基本上就没有什么参考价值了，因为在这三个月内，很有可能你的版本已经做了更替，甚至用户本身的结构已经发生了变化。
然后，针对数据本身的整合，是否是有数据就够了？对于运营团队来说，他们在应用数据时，通常需要将行为数据和业务数据做有机整合，一方面是业务结构导向，另一方面是用户视角的转化和运作导向，此时的数据整合对数据应用是有足够的说服力的。在我们常常提及的精细化运营中，如果只看结果不看过程，并不能算做有机整合。
最后，应用交付环节是尤其重要的，特别是对做数据分析或 BI 的同学。真正做数据的同学的闭环在于应用交付，一方面赋能业务同事，另一方面在深度场景中寻找自己的定位与价值。在应用交付层面，对业务的理解和思考，以及持续运营是极其关键的。这也是我们在思考如何实现从 1 到 100 的跨越的时候形成的基础认知。

四、实现从 1 到 100 的跨越

1. 认清现实：四要素缺一不可，差别只在基础及重要性

在系统化推进的过程中，组织、人才、流程、工具四要素需要同步考虑其当前状况与策略的匹配程度。如下图：  

组织并不一定代表大的企业组织，也可以代表一个 team，或者一个小的组织。真正能够把数据用好的标准通常是具备完善组织架构和人员运作机制的组织，人才和组织决定了运作流程以及对工具的应用能力。
当资源协调困难时，决定资源投入与分配的角色的认知就会显得特别关键。我在上一家公司的时候，之所以能够在内部顺利推动神策产品的全面应用，关键在于整个组织人员的调整——从部门直管调整为业务线逻辑，这样一来，每个小组线正常运作的时候，资源都可以实现自协调，发版的节奏和逻辑是自控制的。
很多时候，组织的模式跟企业内部的数据文化是有重要关联的。一家企业着手推动数据全面应用有两个契机：一是公司整体组织架构开始重视数据；另一种是团队内空降了一个厉害的决策者，由他负责调动资源和人力等。从我们过往的服务客户经验中来看，组织和人才是最顶层、最重要的两个因素。
而流程和工具，在某种程度上是相辅相成的。在落地层面，流程体现在以下两点：
（1）运作的机制。埋点体系是按照什么样的业务流程和机制进行的？
（2）每一个环节的具体操作的标准方法、对应的角色是否具备操作的相关技能，能否成功落地？
同时，工具在工程化、产品化方面的支持力度在很大程度上决定了流程的运作及是能否更好的管控和落地。
一个好的工具，本质上会把流程体系、操作标准等内化，让真正做体系运营的人有强劲的抓手，让每一个人都能够按照心意去运作。这个时候，我们会在产品体系里面强调两点：
（1）数据需求的管理需要从源头做好控制；
（2）数据上线阶段，要从数据的质量和标准层面做好控制。
只有遵循以上两点原则，才能把控好从需求到研发的完整质量流。这也是我们近两年在辅导客户内部建立机制流程和数据运营体系方面被证实的实践经验。
整体来说，公司的规模越大，传统转型的属性会越强，组织和流程方面的因素会越干净，也就意味着左侧因素无调整的话，右侧的流程和工具落地会很困难，即从微观撬动大局是一件困难的事情。因此我们在很多时候，会建议先去影响能够做出决策的“人”，搞定“人”就能更好地解决问题。这里的“人”可能是组织内部决策的人，也可能是在落地层面具备操作技能和方法的人。

2.数据文化：基于数据深化对业务及用户的认知，提升决策质量

数据本身是一种“原材料”，经过加工即数据应用后能够带来什么样的价值，与数据分析人员对业务模式的认知息息相关。
但在很多时候，数据分析人员缺乏对业务模式的认知，特别是在做企业增长的时候，尤其需要对业务模式和用户洞察深入理解。  

正是因此，我在和客户日常交流时，经常聊这几个问题：用户是谁？用户为什么用你的产品？你能为用户带来什么样的价值……这些问题是很难通过纯粹的数据推论出来的，需要基于对业务的理解。如果客户对这些问题都没有答案，那么想要撬动用户，实现留存和增长是很困难的，即便短期内可以做运营刺激，也很难形成长期留存。

3. 数据基础建设：围绕用户、场景构建体系，深度融入业务流

从数据采集、处理、校验到存储，我们在每个环节都做了大量的配套设施。举个例子，在数据采集方面，如果不做数据梳理和需求定义，那么到了数据校验环节，缺乏相应的管控和入库限制的话，就会很难保证数据的质量。  

在做数据基础建设时，我们希望能够帮助客户把数据体系和应用建设得更好，这就需要在前期梳理需求的时候，能够围绕用户场景构建，并将数据上线的研发流和业务流同步，这就对应了前文所讲的数据的时效性。在我此前的工作场景中，我只允许 H5、后端埋点等这类快节奏的功能可以独立发版或延迟发版，其他情况下都必须实现同步发布，这在很大程度上解决了我们当时数据应用螺旋式上升的最根本的问题。
本质上，整个数据基础建设的流程是一个系统性工程，对待每一个问题都不能仅在应用层考虑，而应该关注它的「性价比」和「成效」。比如，为什么我们要严格控制源头和上线前的质量校验？这是因为一个入口、一个出口相对更容易控制，且成效最高。

4.数据赋能及人才培养体系：数据驱动体系搭建，从入门到专精全覆盖

我们很难要求每个分析师在每个特定场景都做到极致完美，因为对于服务于产品、运营和推广的分析师来说，他们的经验和判断力是不一样的。
为了更好地将专业人才通过培养实现标准化输出，神策搭建了人才的利基市场培养体系，业务导向+ 数据专精 + 产研基础为市场做培育，这是我们接下来重点发力的方向。在整个数据链条中，围绕不同的角色、技术建设的体系防范以及专业性人才和行业性应用等，把相应的培训体系进行完善，一方面作为服务和赋能的体系来做，另一方面作为特定的专项培训体系。
在神策，我们是从意识文化、基础建设、数据分析、精细化运营四大模块，结合主流行业的业务特点、业务场景及真实案例，来制定分析师培养阶段及课程体系的，为企业提供强业务型、数据应用体系全流程覆盖专业数据分析师人才培养方案，我们希望这套培训体系能够为具有行业适用的数据驱动体系建设及最佳实践赋能，真正解决客户在人才和流程方面的需求，并在一定程度上影响组织的数据文化。

5. 策略引擎：数据流与业务流打通形成强大的主动运营与高效转化能力

精细化运营、精准推荐、千人千面等基本上可以通过粒度和通道两个维度来做详细拆解，其规则和算法是聚焦在各个不同的应用场景中去实现的。如下图： 

6. 精细化运营突破点：用户视角下对动机的挖掘 + 持续的验证迭代

大部分企业和用户都可以完成定义业务目标和用户群体，但其难点在于，精细化运营的目标客群购买产品和服务的动机是什么？这就涉及对动机挖掘和场景构建，这也是在落地层面上最难的两点。

这里我额外再强调一下分析的重要性——分析是帮助企业构建对用户和场景认知的最底层内核，没有分析，所有的决策都只是拍脑袋结论，很难体系化往前推进，完成从 1 到 100 的跨越。
关于精细化运营这件事情，很大程度上与不断迭代、用户的动机和场景是息息相关的。
策略诊断和调优是另一个对分析要求较高的环节，但能做好的分析师寥寥可数。通常情况下，在完成精细化运营之后，分析师只关心效果提升，至于为什么提升，是客群的精准选择、还是运营策略的吸引他并不知道。所以大多数的数据分析师在精细化运营活动中，需要运营同学的配合。

7.关于工具：理念 + 实践方法的工程化

我认为神策的“护城河”在于产品和技术，而咨询和服务是在其上帮助解决方案落地的。可以这样理解，工具化和工程化的底层逻辑衍生出配套的服务和咨询体系，这套服务和咨询体系是为了帮助客户真正构建数据根基、实现数字化运营，这也是神策的最新愿景——帮助中国三千万企业重构数据根基，实现数字化经营。
综合来说，数字化运营从 1 到 100 的跨越心法是：模式重塑，小步快跑；业务视角，应用驱动；基础扎实，效用最优。希望本次分享能为更多企业和客户在数字化运营过程中提供有效帮助，感谢大家的聆听！