linpingta's blog

在项目组，除了广告管理（AdManagement），统计更新（Stats Update）和规则应用（Rule Management）这三部分直接与用户交互服务相关的工作外，我其余的时间都主要投入在策略和数据这两个大的方向。后续计划会有一系列文章介绍我在这些方向上究竟做了什么，这篇博客仅仅作为一个总纲，谈谈我对它们的理解。

一. 数据分析, 策略，数据挖掘，数据监控的异同 算是先挖一个大坑吧，首先说，实际上这些概念在很多方面本身并没有明确的界限区分，比如很多招聘里的数据挖掘很可能是数据分析工作，而数据工程师又可能在做报表，所以一定要分清这些概念未必有意义。我之所以在这里拎起这些名词，主要是想把我做的事做归类，因为它们大概可以覆盖我做的策略和数据工作 （下面的内容，也是混合了概念和我具体工作的内容）。

发起者\接收者	人	机器
人	数据分析	策略
机器	数据监控	数据挖掘

关于发起者的定义是：数据规则的制定者，或者对数据操作的执行人。 关于接收者的定义是：数据规则的执行者，或者对操作结果的观察者。

1.数据分析：它是一个人到人的操作。 它更多强调的是分析师的价值，通过查看DashBoard（高端的通过BI工具）进而分析数据。分析本身有一些特定的模式（比如漏斗），分析师作为对业务最了解的人，在数据分析中起最重要的作用，更多的是偏宏观和经验的处理问题。 作为技术人员，经常会忽视数据分析的作用（或者认为这个过程没有技术含量），但在实际问题里，数据分析作为最快捷的方式，其实往往是用处最大的，所谓用20%的时间解决80%的问题，数据分析要求业务经验，技术更多的是提供辅助工具：报表，分析工具（同样不要轻视辅助工具，看到看不到，多快看到对业务价值影响很大，BI的生存点主要在此）。 多说一句题外话，我毕业后的第一份工作是在一家BI厂商（Microstrategy），因为在研发中心不会直接接触客户，当时并不了解产品的价值。现在真的到做业务后，才明白好的分析系统对数据应用的价值。

具体到我们的业务，我也有一部分工作在客户数据需求输出上面，为此我开发了一个小的任务执行框架，减轻一些工作的负担。 我近期在做的是，如何输出一些能够吸引客户的，对客户有用的数据信息。为此我搭建了从FB抓取数据到存储的数据流，也给出了一些业务相关的数据应用方案 （简单举个例子，比如图片质量得分随天变化趋势），但我更想强调的是，在我想法里，如果想吸引用户，必须抓住两点：

1.提供给用户FB现有分析工具不能提供的数据
2.要把有用数据“推”给用户，而不是等用户去查

这两点提出的原因是，FB的分析工具是很多比我更优秀的工程师开发而成的，虽然我们的系统也有报表，但无论从数据内容和展现效果看都无法相提并论，那么，用户为什么要用我们的报表分析？

第一点，举个例子，ad出价bid_amount是一个状态变量，但它直接影响广告投放给什么人群（CPM），我们去记录bid_amount与CPM的关系，分析竞争情况，这是FB自带分析工具没有的。 第二点，只是把大量数据交给运营是没有意义的，比如广告账户分天的成本，能不能让系统找到里面成本异常的时候，及时告知用户，再多做一步分析。 这两点的内容，是我在这方面工作之后的方向。

2.策略：它是一个人到机器的过程 首先你得熟悉业务。举个例子，在实际管理过大量广告后统计发现：

(1)今天或者过去7天成本达到A的ad必须要关闭
(2)发现某类账户在某些国家下新ad必须要出高于目标1.5倍的价格才能投放，然后投放稳定后价格又要回收到某个价格
(3)广告预算需要缓慢增加，甚至一定时候降低

这些信息，有些是可以通过理论解释的（比如出价高量级大），有些是不能有理论解释但客观存在的（比如某些账号的成本就会更低），它们必须通过实际业务经营获取，换句话说，就是花钱花出来的。 这些经验，我们称之为规则，可能是一个规则，也可能是一组规则，但最终规则会被表述为策略的方式，交由服务来执行，因此我觉得策略是一个由人到机器的过程，因为它是由人发现总结出来的（广告成本超过A应该停止投放），而由机器去执行的（满足要求停止投放，无论现在是凌晨还是正午）。 但策略又不仅仅是规则，有可能不是人可以观察到的，具体到我做的部分，在线策略主要包括状态机和反馈系统，离线策略主要包括动态参数的调整。这些内容我计划后续会详细介绍，这里只提一个引子：

****状态机：广告有它的生命周期，初始，稳定，衰退，用一个自管理的系统去控制广告投放时，在不同阶段有不同的投放策略。比如出价，初始阶段，可能出价会高一些去获取展现，稳定阶段又要根据实际CPA反馈去调整出价，衰退阶段可能会去尝试保CPM，不行就做关停。这些阶段的定义，ad在阶段间的跳转条件，都是通过状态机实现的

****反馈：由于我们业务的特点（在FB上投放广告，不是RTB的模式，是在FB优化的基础上再做优化），我们不能直接控制每一份流量的出价，而只能去宏观调整ad目标，这种情况下完全准确预测广告出价不太可能，所以我把系统做成一个反馈系统，简单说，看最近一段时间（花费）的成本，高了就调低，低了就调高 （但实际问题里很多时候不是这么简单的，最简单的一个问题，你要是调低的太低花不出去钱了怎么办）

****动态调整：举个例子，对每个广告账户，它能投起来的初始出价是不一样的，我们可以根据经验去规定一个统一的初始倍数，但它未必合适，如果让系统去学习一个账户过去一段时间内的平均出价和CPA关系，再确定一个初始倍数，应该合理的多。

3.数据监控：机器发现一件事情发生，及时通知相关的业务人员 策略不是万能的，而且很多时候是差很远的，因为很多人为的信息并没有告知计算机，因此操作还需要人参与。 举个例子，一个广告的日预算是500$，它花到了，广告被暂停了，那么之后是应该扩大预算继续投放呢，还是保持预算暂停呢？这个问题，可能运营会先看成本，成本低于目标继续投放，高于暂停，但业务的情况是，广告主可能在这个广告定向上有每天投放的配额，这样即使预算花到成本OK，也不能继续投放了。 这些信息，不是机器能够了解的，也不可能交给机器自主决定后续方案。 关于数据监控，对我们的问题，我在如下层次上开发监控：

基础监控：它本身也包括运维类的监控，比如CPU,IO,内存，硬盘等，以及关键字、进程状态监控，很重要，但不是我工作的重点 业务设置监控：例如用户设置了过高的出价，过小的预算或者过小的定向人群 业务状态监控：例如账户是否被封禁，创意是否被拒审 业务效果监控：例如ROI不符合预期，突然剧烈变化

监控部分的输出，我还是认为用户不会主动去看我们的报表，因此从“推”的角度，主要考虑邮件和微信（算是中国特色）两种形式，我剥离了业务本身内容后，相关的代码可见这里和这里。

4.数据挖掘：机器到机器的过程 策略和数据挖掘其实很难划分，因为策略也有基于离线数据的处理，数据挖掘也有在线的算法，但前者更简单，可以认为是通过规则把数据分析和监控的结果机器化处理，业务本身的耦合性更强，后者更复杂，通过目标函数的优化去发现一些人无法发现或者解决人无法处理的问题。 这部分的工作，我在项目里去年做过一些尝试，但不太成功，原因首先在于：

对数据挖掘的效果太理想化，认为用和不用能有很明显的区别

客观来讲主要在于三点：

系统本身数据量不大
A/B测试没法做
业务人员应用意愿不强

具体来说，第一点是说，我们的广告主不多，反复就这么多数据，区分性不大，第二点是FB业务本身的特点，即使所有设置都一样的两个广告投放，也可能会因为彼此抢量而又不一样的效果，无法像RTB那样按idfa保证A/B测试条件，第三点在于，既然你的系统说不出好，那么业务人员为什么要使用呢？ 这部分的教训，我后续应该会专门做下记录。

数据挖掘也是我近期工作的重点，因为我们有了额外的数据源，也有了可评估的历史数据，可以基于Spark做更多的分析，但结果，现在还是未知的。 依据之前在Kaggle的一个比赛，我开发了一个简单的基于python pandas的模型框架，在这里。

二. 介绍 说完上述内容，我在这里列下之后博客文章的内容，希望一步步把它们补充完整。

1.自管理系统演化：介绍策略系统的演化过程，包括在线离线部分，以及理想和现实的差距 2.离线数据流建立/应用：介绍离线数据抓取到存储的过程，以及数据分析需求的解决 3.监控内容与方式梳理：业务监控的分类，输出方式，后台服务管理 4.数据挖掘的教训和更新：我做了什么，为什么失败，之后要怎么做