Nancy导读：现在PM动不动就拿数据说话，找RD跑数据，有些数据是肯定必要的，有些数据是可要可不要的，比如对于某项目,PM凭经验可说4级以上的用户可xxx，这时候会有人跳出来问，为什么不是3级、5级？拿出数据来。

怎么评价产品经理拿数据说话这回事?如何做数据分析?

这几个月在一家为客户在 Facebook 上做广告的加拿大公司工作。简单说说他们对于数据的态度吧。这是一家小型 Startup 公司，总共不到 20 个人。其中 4 个人(包括我)是技术，剩下的除了 CEO 都是 Account Manager。当然 CEO 很多时候也在做 Account Manager 的事情。

刚到这个公司的时候，觉得他们的 code 很 烂，他们的数据库设计也很烂。后来才知道，当初 startup 的时候，是找了印度公司做外包的，他们对这个外包很不满意，所以一期项目搞定之后，就全部拿过来自己搞了。但是后遗症也留下了。

这个公司的数据模型很清楚，只要通过低于广告主给出的 CPA 价格能赚到钱，就想办法增加广告覆盖率。但是常识大家都明白，增加覆盖率很可能导致转化率下降。但是如果接受这个假设，那么就没有什么赚钱的机会了。恰恰是因为他们相信，除了常识之外，还有一些事情是经验之外的。

比如说关键词……有些关键词对某些人有用，对另外一些人没用。如果不做数据挖掘，生想广告词或者关键词的组合，累死了也赚不到什么钱。

所以……这个公司在代码中设计了几个基本核心算法：

1. 一种止损的 trigger，对于任何亏钱的广告，自动停止。

2. 一个自动发布广告的 cron，程序一直在扫描。一旦发现一些广告能赚钱，就自由组合这些广告元素再自动发布到广告系统里面。这样，就能出乎意料的发现一些更加赚钱的广告形式。

3. 做了很多广告更新的算法，搞了一个自动化的 A/B 测试策略来针对 Facebook 广告价格的浮动，来更新广告的价格。

通过阅读这些算法让我感受很深。所谓的数据分析，不是一个产品经理跑到运维，数据库管理员或者工程师那里说：我现在要跟踪什么什么数据，你帮我出一下吧。然后再对着跑出来的数据琢磨这些数据是否合理。

在这个公司里，只要发现一个数据模式对收入有影响，就会直接编码到系统里，变成自动执行的代码。基于这样的数据导向原则，代码面临无穷多次的重构，因为谁也不知道，下一个数据模式会发生在哪个层面，哪几个数据之间会发生关系。

我觉得国内的不少公司，还在以 daily report 分析数据，还在说数据只是为了验证产品经理想法的阶段。这动作是不是太慢了?

接下来的话，随便说说，不一定有参考价值：

1. 对于大多数网站，如果你想用数据为导向，必须建立系统级的 A/B 测试机制。对于界面层面的重构，一个产品经理 + 一个工程师，一天用这个系统一天至少能做 3-4 个。系统级别的 A/B 测试要能够保证快速上线，第一时间看到数据，一旦超过临界值直接结束测试、保留数据并生成报告(直接邮件发送，而不是让产品经理想起来跑到后台再查)

2. 对于做社交网站，或者有复杂用户数据模型的公司，要在界面呈现和用户数据之间建立匹配系统。这样产品经理可以设计几种呈现模式，丢到匹配系统中，过不了多久，就能发现用户对不同呈现的数据反映的不同，然后系统性地固化这种机制。

3. 通过 cookie 或者用户登录信息，建立针对不同用户的内部 tag 系统，看这些 tag 在系统 2 里有没有明显差异。如果有就可以固化下来，用来提高关键指标。

所以，我现在对于数据分析的感觉是：

1.要提高一个数据指标，盯着它是没有用的。必须找到影响这个数据的另几个可操作性更强的数据指标，调整它们。

2.分析数据的可能性要充分，充分分析的基础是测试充分多的可能性。如果你想测试图标的颜色从绿色变成红色会不会更好。那为什么不测试一下蓝色，紫色和黄色呢?

3. 如果小规模数据已经可以说明问题，就没有必要延长测试时间，也没有必要扩大测试范围。

4. 要充分利用计算机来帮你做数据采集和分析，缩短数据分析的周期，降低数据分析的成本。

5. 有必要的时候，可以让计算机帮你找 pattern，因为计算机没有偏见。

本文作者：@丁士正  转载自：产品中国