神策数据徐美玲：如何挖好数据这座矿？（可下载PPT）

本文根据神策数据业务咨询专家徐美玲在神策 2019 数据驱动大会上发表的《如何挖好数据这座矿》主题演讲整理而成。本文将为你重点介绍数据驱动的挖矿模式进阶法和数据基础建设的真相，包含以下内容：

• 看数据——如何正确的看数据？
• 分析数据——有哪些典型的分析场景？各场景下的分析要点是什么？
• 应用数据——应用数据的场景差异有哪些？千人千面、精准营销、精细化运营如何实现？
• 有数据——如何进行数据体系建设？

数据是一个蕴藏无限价值的矿已是大家的共识，问题在于矿在哪？是什么样的矿？如何挖掘矿中真正有价值的钻石，来释放数据真正的价值？从业务角度来看，数据的整体重要性毋庸置疑，但是对于业务人员来说，他们要的是真正称之为钻石的部分。

近段时间我一直在做咨询项目，在给客户规划其整个业务体系以及如何从 0 到 1 落地的相关思考，这些思考对于大家在公司内部与业务方沟通，尤其是对于数据部门跟业务部门的互相理解，可能也会有比较大的帮助。

挖矿这件事情，其实从业务的角度上来讲，可抽象为三个不同阶段的层面，我将其归纳为挖矿模式进阶法，如下图：

具体来说，真正在数据分析应用时的区分，我认为包含三个层次：

1.看数据，其实很多时候大家看数据，只知道数据是什么样子的，但是对业务产生不了价值，很多数据驱动的业务进行从 0 到 1 的搭建时，其往往最初的阶段是先要把看数据这个体系建立起来。但是，我接触的很多企业其看数据还没有达到一个理想状态，之后我会介绍需要达到什么状态，才说明其把数据看好了。

2.分析数据，从分析阶段来讲，其真实目的是企业知道为什么，并且在该过程中，找到解决方案的提示和方向，这是分析层面能够带来的价值。

我在做售前交流时，经常会有一些技术团队的领导会问，神策数据为什么不能做成只要把数据输入，就可以自动跑出数据的情况总结，然后告诉业务应该干什么。这个问题我想了下，其实我理解他的思路，做技术的人会希望工作流自动化，例如在 APM 的监控体系里，一般数据的整个流量与运营有一个惯常的模式，并不需要考虑上层的业务运作，只需了解流量本身有无大的异常，以及流量的结构对于现在 CPU 的占用是否达到峰值，在该阶段，其确实可通过程序化策略直接定位原因。

但是，数据分析很难这样做，核心原因是在业务环境里，一个数据哪怕出现同样的变动状态，也可能是很多不同的原因导致，而这种可能的原因判断，往往取决于业务分析的人本身对业务的敏感度，以及数据采集的丰富度，才能真正做出明确的定位，然后才是给出解决方案。

哪怕同样的数据趋势，既可能是内部的原因导致，也可能是外部的大环境导致。如同样是 GMV 的大幅下跌，有可能是运营活动的激励机制失效导致无法正常运作，也可能是外部的一个热点，如淘宝双十一活动，对小平台的整个成交量有了较大的冲击。

所以，若对数据产生影响的因子本身具备不可预测性和场景的复杂度，加上业务场景和模式差异太大，所以被完全自动化的难度非常大，这种情况下便需要引入人为判断，这也是分析师的核心价值。

3.应用数据，指的是常说的千人千面、精准营销、精细化运营意味着什么，从产品和技术上有无对接的系统和系统本身实现的逻辑原理可挖掘。对于大多数做业务的人，能否正确的与技术和向数据团队提需求很重要。我在神策数据工作之前，主要接触的是产品与数据分析，较少了解 AI 或算法这一层本身与日常的业务统计规则类的分析之间的差别，现在我有了一些认知，也想阶段性就这个主题跟大家分享一下其本质的一些差别，帮助大家在一个齐平的水平线上，正确的向技术提需求，其实对于大多数技术人，只要提需求的姿势和态度正确，配合效果会显著提高。

以上三个点更强调应用，在这个体系上 ，我还是要强调下数据基础建设本身的重要性。数据本身是数据应用的底盘，如果底盘不稳，其上面的建筑根本无法搭建。这点在上午吕厚昌的演讲中也提及——只有从事大数据领域的人，真正做过实际的 case，才会逐渐萌芽这些意识，区别在于其数据意识的深刻度如何，如其在一个从有数据到看数据到分析数据再到应用数据逐步进阶的体系中，如何将其变为小步快跑的方式，支持快速将业务的价值在有限的数据下释放出来，然后再逐步完善数据体系，构建一个螺旋式上升的完善机制很重要，下面我将展开介绍。

一、看数据

就看数据而言，我认为本质上可拆分为两个问题，第一个是看什么数据，第二个是怎么看数据。

1.看什么数据？

如上图，首先是目标 KPI。比方说从业务角度来看，基本上由本身的业务模式与业务发展阶段所决定，包括 KPI 考核，为什么同样是电商的成交业务，有时老板考核指标为 DAU，有时是 GMV。

就电商的商业模式来说，其本质上最核心的目标一定是 GMV 或净利润率，但大部分都会关注规模，及不同的阶段评估何种核心指标。

其与常提到的第一核心目标或北极星指标一致，但在有目标 KPI 的情况下，大部分的目标 KPI 是一个综合性的数据，如 DAU，其可拆解成新客户拉新、老客户活跃、流失用户的回流等。

第二步是将目标 KPI 细分为业务场景。一般企业会按照一定的逻辑进行业务场景的细分。如对于老客户拉新客户的业务场景，企业会设计一个运营策略，考虑如何让更多人知道老邀新机制，并使其更具吸引力、信任感等，使其点击之后，还需要考虑如何促进下一步的注册、转化等。

本质上，各个业务场景均具备其运作的业务流，在该流中会存在影响这个业务流运作好坏的一些因子或因素。

第三步是将业务场景进一步细分到指标体系。很多企业只在看大盘数据，或进一步看结构数据，但这些数据均无法告知企业的深层次原因及下一步动作。因此，企业需要按照新的模式，从业务场景拆到指标体系，使其与产品、运营、市场等实际业务建立强相关的业务逻辑，该逻辑与企业的业务架构是强相关的。

2.怎么看？

看数据事实上存在一定的技巧。与常见的汇报数据不同，看数据需要多维深入全面的看，如下图：

其一，看量级，这一点基本上企业均了解，在此不赘述；其二看趋势，其意味着企业业务的健康度走向，若往下，企业便需要提高警惕；其三看异常，这要求看数据的人不断提高异常敏感度；其四看结构，企业需了解其数据的组成、组成占比、优先级等；其五看细分，如企业看 DAU 时，需了解 DAU 中安卓和 iOS 操作系统的占比分别为多少，其中往往隐藏着用户的特征或偏好，如使用华为手机的商务人士占比较高，而使用 OPPO、VIVO 系列手机的大多数为娱乐发烧友等。因此，用户属性特征数据本身能辅助企业解读和挖掘一些有价值的信息，这也是数据的价值所在。

下面我举一个例子——某 APP 的月活，怎么看？

假如某 APP 的月活量级是 100 万，首先企业需考量 100 万意味着什么，对于教育或电商业务来说，100 万月活只能称为一般，若其中新增为 30 万，企业还需要进一步看其黏性，尤其是 DAU 占 MAU 的比例为多少，同样也需要结合行业来看，如对于互联网+企业 MAU 达到 100 万，新增用户为 30 万，活跃用户持续活跃用户数为 60 万，回流用户为 10 万，意味着在企业的整个用户盘的结构处于良好，但也需结合具体业务重点分析。

再者，企业需考虑 iOS 与 Android 的占比，如市场上的 iOS 与 Android 占比的平均趋势为 3：7，如某业务的 iOS 的占比更高且达到 45%，说明企业用户与整个中国大盘的市场结构不一致，此时企业需进一步思考是否该行业的用户本身也具备该特征，来评断企业的特征结构与行业大盘的用户特征结构有无差异。

然后，每月访问仅 1 天的用户占比 45%，即表示该 APP 中低频用户的占比非常高，也意味着用户可带给该业务线的黏性与价值是不一样的。因此，企业需关注月活中的天数分布数据，其很大程度上表明了用户对你产品的黏性价值有多高。

另外，我们再看趋势，此时不仅看态势还需看趋势对比，如对比去年它的上升态势，排除季节性因素影响，再比如分析是否存在月度规律数据，变化是否受到月度差异的影响，如有差异，再进一步下钻分析。

综上所述，若企业的指标体系构建的足够完善，哪怕只看数据，也能看到有意思的信息，实现一些独特的发现与洞察，企业需结合自身的行业、业务、发展阶段等来综合定位和解决问题。

此外，从整个数据体系来看，企业存在一定的数据体系差异基础，一般可从两个维度分析，如下图：

第一，指标的科学性，即企业本身指标体系的设计，是否具备科学性和系统体系。

第二，数据完善性，数据的基础建设呈现何种状态。

综合这两个维度，企业可判断自身的薄弱处及自身所处阶段，一般来说企业可做好这两个维度，其数据化建设不会差。

在神策数据，我们经常回访客户，一般当客户不是很抵触，我们均会建议看一下他们的后台进行评估与建议：

第一，企业的源数据结构如何，是否具备一个合理、有结构、有秩序的源数据体系，以及源数据本身的管理，有没有持续更新迭代；

第二，概览体系建设如何，是否已建成一个相对有逻辑体系的概览，该概览是否能帮助企业看大盘数据和看实时数据；

第三，各业务线的数据看板建设如何，如产品、运营、市场各个不同的职能线是否有相应的数据看板，甚至不同业务线的子团队，有无对应看板。

第四，数据权限的体系建设如何，是否明确，是否科学和安全等。

以上四点如果企业建设的均不错，则这家公司的数据应用应该不会特别差。神策数据在服务客户的过程中不止听对接人的反馈，还会通过数据后台的建设情况直观评估其是否达到比较理想的运作机制和问题所在，并给出相应的解决方案。

在服务的过程中，我们遇到有因企业技术支持薄弱或业务分析薄弱的各种情况，但更常见的是两种都薄弱，对此，神策数据现在的售后服务体系中有增加了重新对接交付的环节，我们会重新帮该客户梳理需求，辅助他们把数据和应用的整个体系重新搭建起来。就像之前讲的一个概念，错的数据其实比没有数据更糟糕，因为当你有错的数据时，你可以告诉并安慰自己说有数据，但问题是该数据对决策与应用毫无帮助，仅会麻痹地告知你有数据，但不起任何作用，甚至比处于没有数据并急迫着建数据的团队的情况更糟糕。

其实这也是神策数据交付团队今年在业务探索上的一个比较核心的思路，即数据采集完成不是终点，如果要扶客户上马，最小最小的终点是帮其把源数据和概览体系建设到对于各个业务部门均适宜，基本上达到开箱即用的状态，助其轻松上马。

二、分析数据

关于分析数据，我认为其核心关键是数据与业务的联系，不关心业务的数据分析师，大部分不是一个好分析师，因为数据本身会显露一些特点，但如果分析师不回到业务场景中分析，会很难解释其真正的情况及原因。事实上，就数据分析而言，数据和分析能力只是其中的一个小环，而对业务的理解与判断能力对分析价值的贡献和影响占比更多。

从分析的角度来说，首先分析者明确知道原因，其次提出一些可行建议，更进一步，分析者可将优化措施常态化为一个常规运作机制，并使该机制自动化与流程化。

从建设概览的角度上来讲，做数据分析的人应该帮业务的人建报表，建报表的目的从某种意义上就是将其机制化，并评估机制化的水平，如分析者是只能帮业务机制化到看一个大的数据结构和趋势是什么，还是能够把一些核心的维度与场景帮其提炼出来，做成一个关联的主题，帮助业务人员更快更有效地看懂数据。

对于分析师来说，其工作的价值也是做完整的分析与结构的梳理，并将结构机制化，继而再进行推广，让更多的人能够自主做这件事，而不用每次都依赖分析师出常规的数据分析报告。

对于分析数据，基本上可概括为 3 个较常见的场景：1.场景一：异常情况找原因

我将其分为两个分析方向：有头绪和没头绪。

（1）有头绪——验证式

有头绪的找原因一般带有经验，数据的下降很容易关联 2-3 种原因假设，这几种原因又对应着一定的数据表现特征，然后再定向的查看和分析这些特征的数据表现维度，评估其趋势结构与预设的是否一致，如果一致，则基本验证了假设。

如果不一致，则需要考虑另一种假设，该方式比较高效，一般情况下，出现异常主要由 1 个核心影响因素导致，可能该因素导致数据下降或上升的影响占 70%-80%。因此，分析者依靠业务和分析经验的的验证式策略极其有效。

举个关于分析 GMV 掉了的原因的例子，运营发现数据出现异常时，经常会找产品和技术问是否有 bug，接下来就会来回排查，使事情变得非常低效。我踩过几次坑后，发现大多数业务是强利益导向的，一旦活动在产品中看不到一些显性的精细化营销策略，或当这个策略失效后，数据将会较明显的下降。

因此，我在数据采集体系里增加了一个采集字段——在一次成交的订单中是否用券，并专门做了一个报表，分析 GMV 掉了如何定位原因。其第一个维度是用券的 GMV 结构，是同步上升，还是异步的一个上升另一个下降。如果是同步下降的意味着不是活动的影响，但如果 GMV 是整体下降，且其中用券的结构大幅下降，其没有用券的成交结构反而是小幅上升或是一个稳定状态，便意味着肯定是活动的影响。通过这个分解策略，那个运营再也没来冒昧地找产品或技术排查问题。

这件事情教会我大多数分析师应具备产品敏锐度，包括敏锐度怎么转化到数据采集方向上的结构性解决方案，及数据指标看版的结构性探索。以上是在异常分析中依赖经验的一种非常快速的验证式方案。

（2）没头绪——探索式

若该数据结构没有什么头绪，就需要像技术排查一样做穷举，只不过分析者可通过数据做验证穷举，而不需要技术去排查代码，依次验证场景有无异常。

此时，当发现数据下降时，需先寻找可细分的维度有哪些，这些细分的维度本身有没有出现差异化的趋势，并且这个趋势里面主要影响的维度跟因素有可能是哪些。这变成了一个探索式分析，这种探索式分析取决于企业数据采集的完备性，因为如果某一个核心的维度并未采集数据，企业便很难验证对错，因此，这对数据采集本身的要求很高。

同样是 GMV 掉了的场景，假如我是一个对该业务场景不熟悉的分析师，并无可靠的假设，则需要遍历所有维度，尤其是重点影响维度，当发现维度内表现有差异即很有可能为影响因素，当维度内走势都相似，则需向前追溯。

整体来看，这种分析方式是比较低效的，因此分析者需要与业务合作，逐渐熟悉业务，并积累自己的分析经验，提高自身判断力，尽量使用验证式方法。

2.场景二：业务迭代评估效果好不好

业务迭代评估的业务场景相对固定，其基本上为了解业务原先状态，采取的改动措施，并在这个过程中采用了哪些指标、取了哪些时间段的数据，然后用哪些维度与分析逻辑验证迭代或变动措施是否正确。下面介绍业务迭代评估效果的三个评估诊断原则：

其一，指标准确全面，这点很容易理解；

其二，可比基准较高，企业对比的数据基准本身具有可比性，否则将无意义，就是大多数 A/B 测试的基本实现原理，其要保证两组分析的数据本身具备可比较性，并屏蔽它的外部影响因素和其它可能的干预措施对于分析结果的影响，尽量保证两组数据之间唯一的干预因子为实验方案。

其三，分析逻辑清晰。举个例子，互金行业存在新增难，羊毛客户多的问题，我还在互金行业时，针对这个问题，我们决定更改企业的新增方案，评估在新增方案下面能否实现更好的用户和资金的留存。

图中包含两期它的原本方案和一个新的测试方案，在测试方案中的主要修改点有四个：利率结构调整；限额调整；用户到期续持，优惠调整。最后的优惠调整主要是为提高用户后续的二次投资，促进用户从首投到新增转化，避免薅完羊毛之后就直接断点。

当时，关于持有天数的设计有不同的看法，推广人员担心天数加长影响新客转化，运营会考虑引流用户的质量等。

但是，从产品的角度上来讲，我认为主要是一个效率思维，在做产品约 2 年的时间中，我最大的感触是，对于产品来说，量只是它的一个舞台，而产品的实质好坏，很大程度上取决于产品转化能力。

比方说，同样是 100 万用户，产品的转化能力有多高才是产品真正实力的体现，而 100 万用户与 1000 万用户，只能说明产品舞台不一样，实际发挥的价值也不一样。

上图中是推广人员当时给出的数据结果，对比方案一、方案二、方案三的数据，方案三的日均注册人数与日均首投金额均有下降，甚至客单价出现了下降。所以，推广人员的第一反应是要回滚整个新客转化的运营方案，但我看到该数据时是存疑的，因为直观上从产品的角度上来讲，尤其是从投资用户的角度上来讲，我认为真实用户的比例结构肯定是上升的，长期的健康度价值来看一定是更好的。

后来，我花了 2 天时间，重新整理了新的推广方案上线后的数据，如下图：

呈现该数据的核心原因是大部分的新客转化有一个统计窗口期的概念，每个时间段引进来的新用户，其转化逻辑有差异，所以不能只看统计窗口期当天的注册转化。因此，我重新按照用户从统计窗口期进来的结构来看有多少激活、注册、充值、投资以及普通标（普通标代表用户二次投资转化的能力）。

从图中，大家可以看到激活的整个转化率结构，实际上新方案从投资激活转化能力上来看是有所提高的，尤其我不只看用户的首次投资，还分析首日投资的客单价与均价，整体来看方案三的表现更好。

该方案从产品设计的逻辑上阻绝了大多数羊毛党的短期套利空间，对于长期用户价值是更有利的。因此，我便使用该数据进行第二次汇报，该数据与上次数据的最大差别是整个数据汇报思路是从现阶段分析的，该阶段很大程度上取决于激活量本身，其最终真正转化的有效投资，尤其是用户的二次投资能力更强，因此后续采用的是第三种方案，后续该方案至少应用了约半年。

通过这个案例，我发现整个公司的数据应用思路与逻辑具备很大的差异和可提升空间。

3.场景三：寻找业务增长突破点

从整个数据驱动角度上来看，基本上企业的思路要从前往后走，首先企业提升增长的目标究竟是什么，然后围绕这个目标做诊断分析，再从诊断分析里提出一些解决方案或思路，最后在解决方案与思路的方向上形成一个闭环的运作机制，如下图：

企业需要做整个开发测量的闭环反馈机制，现在大部分做增长也按照这样的思路，在相对早期未采用 A/B 测试时，在整个机制的情况下，大多数数据驱动做的比较好的公司用的是这套机制，区别在于同时的测试数及测试速度，甚至在业界相对较杰出的人也基本上是按照这套机制做产品迭代和增长。

我认为，寻找增长点的核心在于第一指标，可从两个维度来分析：

其一，业务模式。一般考量产品或业务真正为用户提供的价值是什么，价值如果被量化，量化的指标是什么，以及业务在频率与价格上呈现什么样的特征，这些特征很大程度上决定了数据运作的上限。

比如，关于提升留存，留存有一个明显的价值天花板，如果企业本身产品的使用频次，与其能够为用户提供的价值受到限制，不管企业如何努力，也很难把真正的长期留存做出来。因此，数据表现由业务模式决定，不同的业务模式存在不同的天花板。

其二，AARRR，即在业务模式既定的情况下，各环节的数据表现与其承接的结构能力，是企业判定第一指标或增长目标的核心点。

第二步为构建增长模型，用第一指标做拆解，可搭建出相应的增长模型，如常见的 GMV 的拆分，当在增长模型中定位了增长点，继而可关联几个核心的业务场景。

第三步为业务场景，企业可从几个关联的业务场景出发设定具体动作方案提升业务场景的数据表现，最终提升增长模型中的核心杠杆点，从而促进第一指标的提升。

这是个基本思路模式（如下图），只是每个人的理解或思考深度会有一定的差异。

下面我们再谈谈如何寻找解决方案？因无法公开具体案例的相关数据，我和大家分享下解决方案的思路。

在业务场景的分析闭环中，企业需首先进行业务场景的定义，如现在经常会遇到的场景逻辑是把整个新用户的转换路径拉长，寻找不同节点的里程碑，而里程碑中的激励策略如何，表现出的业务转化率如何便需要进行其指标体系的设计，来评估整个环节的效果。

从指标体系来说，可大体分为四类（下将以金融行业举例说明）：

第一，量级指标。就金融来说，需查看每天带来的投资金额多少，投资人数多少等。

第二，效率指标。大部分指标都是看转化率，从一个环节到下一个环节，或整个链条的转化率是多少。

第三，结构指标。如每日投资金额里，投资新手专项包、日常活动包的占比结构如何，在该结构中投 30 天或 90 天的比例是多少，如测试数据显示基本上约 90% 的人只投 30 天，那么从产品设计的逻辑上来讲，企业可直接删除 90 天的选择，简化用户在这个环节的选择跟停留。因此，其结构和细分维度非常关键，往往深层次原因和关键点就藏在其中。

在指标体系完善后，企业需进一步做特征挖掘，这是分析中比较重点的环节，因为找趋势或找特征这件事，需看数据全局，从各个细分维度分析可先把有异常或较特殊的数据高亮出来，再继续做原因分析和得出最终的解决方案（如下图）。

就个人经验来看，我接触的分析师一般可做到第三层，第四层、第五层只是一笔代过，将最后一层做好需极强的业务思维，需把自己当成这条业务线的 owner 进行分析，如此其提出的解决方案才可具备极强的可行性与价值。我曾经做了一年的用户研究与数据体系，当时整个产品研发部的数据体系和运营分析，包括某些版本能不能上线的决策都是由我这里的数据决定，后面为了效果和效率甚至整个业务线的迭代全部由我负责，包括数据、研发、测试、产品等。

因此，在业务闭环的最后，一定是经验或能力发挥更大的价值，并且一定要做到闭环，不管因这个闭环职能可再往前走一步，还是往交叉线再多走一步。因此，业务人员具备数据分析能力很重要。如果要为其阶段性定一个目标，我认为可做两件事：第一，看懂数据；第二，会提需求。

三、应用数据

关于应用数据，我们先看一下数据应用全景图，如下：

首先我们可从通道和粒度两个维度进行分析：

其一为粒度，指可具体到群体还是精准化个人，一般有两种大策略，其策略力度基本上决定了一个因子是用规则类的分层，还是精细到个人的推荐算法；其二为通道，通道在产品内，还是产品外，决定了其对应的应用场景是什么。产品内是大家常见的一些资源，比如广告资源位/item 栏目列表等；产品外的通道如短信、push、电销、广告等。

另外，时效性是数据应用的一个关键，包含数据本身和数据分析的时效性等，特别是个性化推荐策略更需要实时在线、个性化的千人千面展示。下面我介绍下具体应用：

1.差异化展示：基于分发效率提升体验和业绩

很多产品，如神策智能运营、神策用户画像、神策智能推荐从真正应用场景来讲，其逻辑基本上通过业务属性、用户属性或行为特征数据进行筛选人群分组，再得到分组的结构标签，精准定义人群，再根据人群分组标签匹配对应的方案或内容库，继而根据规则进行是否展示和展示顺序的两个判断。

整体最终的目的包括提升体验、分发效率、业绩等，其差别只在于实现这套体系时的内容供给类型与时效性，其很大程度决定了实现需求本身的成本大小。其整体逻辑如下图：

对应我前面提到的概念，如何正确的给开发提需求，每一个产品或每一个运营都希望拥有实时性的业务上线规则，甚至脱离研发排期，实现创意与落地的快速打通。

2.个性化展示：产品内个性化推荐实现原理

这也是神策智能运营可实现的一个子场景，即产品内的差异化分发，而神策智能推荐会再多出来一层，其本身会搭一个数据集市，并做特征工程，在这个工程后面会做索引构建与模型训练，继而再做推荐服务。因此其整个产品的运作机制会比以上描述的体系复杂很多，其力度也会做的更细，这种场景下其实现的基本是实时的推荐服务，因为推荐服务本身会对接到客户业务后端和用户端。

在这两个体系里均会实现埋点收集和业务执行反馈，然后再回收效果数据和业务运作的实际数据。因此，这套系统的搭建会复杂很多，神策智能推荐的报价也比神策智能运营的报价更高，在提需求时大概可以思考实现的成本与实现效果，究竟要落到哪个通道，哪个力度，以及什么样的时效性，在这三个维度上掌握好再给技术提需求，技术才知道业务究竟要干嘛，这是给做业务的人正确提需求的一个参考指南。

3.差异化触达营销：精准名单输出，对接营销渠道和手段，推动目标达成

营销的逻辑与第一个场景的整体实现逻辑有点像，差别在于分群名单对接的是通道或营销系统，实现的是通过哪些通道，推送哪些内容，以及是否要发优惠券，这是产品外的一种营销机制，其最终的结果是目标转化，如下图：

相比产品场景，该对接的系统与逻辑存在差异会有时效性的问题，如其是可支持准实时，还是最多可支持 T+1。举个例子，某些场景下实际上并不需要时效性，如有很多相对低频的业务，其更新时间可做到 T+30 便已很好。这是因为如果企业的业务本身极其低频，若提一个高频的需求则不适用，如某些业务一个月并未累计几条数据，这几条数据从算法或规则策略运行上来说，其数据质量很差，根本达不到决定策略更新的层级，所以策略与时效性本身也与业务场景强相关，提需求时需考量在内。

事实上，我一直觉得做好数据不是一件容易的事，如很多公司花较高的成本招聘算法策略工程师，但其真正用来做算法调参的时间可能只占他工作时间的 20%，剩下的 70%、80% 天天在洗数据、捞数据，并每天查看数据本身是否异常，是否需要做数据归一化或特色化的工程处理，这实际上与高端的算法毫无关系，只是在做挖矿的活。下面我展开介绍下价值实现和资源投入的矛盾，如下图：

从整个价值感知上来说，大多数老板认为应用数据非常高大上，虽然对大多数业务来说确实如此，但当有部分业务非常低频，其用户差异度并不大时，其应用数据的的价值也相对较弱。

再看分析数据，我之所以把它画成梯型，是因为我认为在这个领域里面能够真正做好的分析师太少，导致实际产生的价值并不多。但真正做好数据分析的团队，产生的分析数据的价值其实应该更大。而看数据之所以放大来看，是因为看数据是一家公司做好数据驱动的第一步，这一步非常难，并且其做好的前提是先实现下面的数据生产整合，因此看数据的整体成本相比分析数据会更高一点。当然对价值实现和资源投入有以上认知的老板已经很好，有的老板会认为这是你该做的事，甚至还会因为将其整体搭建起来成本太高而认为没价值。

从资源投入的角度来看，假如企业的数据基础资源建设做好是一个非常大的投入，再往上看数据和分析数据的成本会逐渐降低。但是，再往上因为应用数据其实是重新又建了一套完整运作的体系，它其实是需要被产品化与平台化的，其成本会变的更高。

现在我们与客户沟通时，从神策数据的服务角度切入，往往会推荐其先做数据生产整合和看数据，分析数据需要企业进行数据分析的培养或通过神策数据的解决方案学习一些分析的模式、策略再进行实际应用，在数据基础具备及具备数据分析人才与能力后可进行应用数据体系的建设，这是我比较推荐的阶段性规划。

四、有数据——基础建设

数据本身的类型和它可实现的价值本身就拥有很大的弹性和可发挥空间，需要根据自身业务实际情况做优先级与逻辑考虑。以神策数据为例，神策在数据采集层面考虑的核心问题是 ID-Mapping，之后采集端内的通用采集和主流程数据采集，收集核心关联的用户属性数据，之后将业务数据中更细力度或更多丰富维度的数据采集，将行为数据、业务数据、用户数据形成一个可运转的机制，去扩大数据本身的协同效应。

在数据基础进行建设时，可通过人力、能力、权利形成缺一不可的铁三角，保证数据基础建设的顺利进行。首先，在人力层面，保证数据采集和迭代各环节的资源投入；其次，在能力层面，需熟悉和掌握采集的方法与要求；最后，在权利方面，需要资源投入管控和质量管理的抓手。三方共同协作，形成闭环，推进数据基础的建设。

提到数据基础建设，就不得不引入“埋点”的相关内容。简而言之，埋点其实是为了满足快捷、高效、丰富的数据应用而做的行为过程及结果的数据上报，从 ID 识别、时间戳、具体内容、位置环境场景、维度特征五个方面组成事件埋点。数据分析师、研发工程师等相关人员从产生需求、整理需求、Review 需求、事件设计、埋点开发、应用交付等具体步骤，完成数据从生产到应用的全流程。

从核心岗位的资源投入而言，根据实际经验，平均单挑业务线需要 1.5 个人力。在业务线中，企业指定顶层业务规范建设及程序迭代，促进各业务线规范和流程培训、推广及经验共享，数据产品/分析师及技术对接人确保业务线/项目组数据接入符合规范，保证数据质量。

站在业务线数据体系和数据应用负责人的角度，并不仅仅是完成数据分析的工作，需要从埋点实施与迭代、文档规整维护、系统更新维护、应用交付和支持四大方面整体贯穿并掌控。

所以，当我们需要规划公司整个内部数据驱动落地时，可参考上述思路，用一种轻量级的思维去逐渐体现数据的价值，之后不断获得更大的资源。

结合我们的创始人&CEO 桑文锋提出的数据组织建设（DO）的概念，其实不难理解数据驱动本身不只是数据，就算数据团队清楚的知道要做什么，若业务团队和公司的投入以及组织架构本身上无法支持，基本上便很难落地。

因此，DO 的概念在于建设整个数据体系，其对于整个组织结构，或这个业务流本身的组织架构和关联人的资源投入具备一定的要求，若具备一个好的运作模式对整个公司来讲，即使体系中并未划分一个虚拟数据驱动团队，其整个业务运作的逻辑流也将非常顺畅。神策数据的大部分优质客户，基本上会具备该特征或存在类似的机构组织。

事实上，从我接触的很多企业来看，企业中有专门做数据采集和数据可视化的数据产品或类似职能的人还是其他人兼职来做是企业能否做好的核心原因。兼职做数据驱动的人很容易出现无法确定自身定位和角色认知，或相应组织的结构授权没有达到理想态的问题，导致其做数据驱动这件事很受限，无法让整个机制运转起来。

综上所述，企业要做好数据建设，需道与术全面兼备才可更高速地挖掘出矿中的钻石，释放价值。