1. 背景
业内已经有丰富的数据证明快速的网页浏览及操作体验对转化率等业务指标有明显的促进作用：
A. Google found out that slowing search results by just 4/10ths of a second would
reduce the number of searches by 8,000,000 per day.
B. You have 5 seconds to engage a customer before they leave your web site.
C. For every 1 second speed improvement to the Amazon website conversions increased +2%
....
AE有面向全世界的用户，这些用户处在参差不齐的网络环境中，且由于跨洲际访问机房的天然的物理距离也会使得AE的用户性能体验无法与淘宝这样内贸网站相提并论。在这种情况下，一方面由于AE性能优化空间更大，对转化率提升的空间也更大；另一这方面由于用户环境的千差万别，以及天然距离，使得AE性能优化的投入成本也会非常距大，比如AE可能需要建立区域机房就近服务于用户才能解决性能问题。
如何精确量化性能回报（即量化性能优化带来的转化率提升最终带来GMV的提升），从而精确计算投入产出比，是AE性能优化工作的前提。业内虽然有较多数据证明性能与转化的关系，但在精确衡量投入产出时，每个网站都是不同的无可比性，且很多数据结果由于数据不足够充分也只能定性不能定量。
基于阿里巴巴ODPS的大数据处理能力的优势，AE性能优化小组@桑植、@跑者、@阿四、@子伟、@冯嘉、@涛明、@震羽、@验钞提出并实现了大数据时代的度量方法，通过采集真实用户访问AE网站的性能Latency数据，以及真实的转化率数据，实现最精确的性能转化度量。
目前这一度量还在内部测试调优过程，且已经在内部性能优化中使用，待稳定成熟后，希望能够贡献出来，让集团内部的用户使用起来。
2. 目标
1）通过大数据的采集、计算、分析，验证性能与转化率等业务指标的关系
2）通过大数据的方法，量化性能对转化率的影响
3）做出通用可复制、业务无关的方案，提供给更多有此类需求的同学使用
3. 方案
3.1 基本思路
1）浏览器异步执行JS，JS调用Navigation timing API获取当前页面各阶段Latency，并将Latency数据及当前页面唯一标识ID、当前用户Cookie_id异步发送打点服务器
2）打点服务器通过TT将数据导入ODPS
3）ODPS中按Latency分组，将各请求样本分到其Latency所对应的组中
3）将PV数据按上下游链接关系关联起来，从而计算转化率
4）分别计算各组中样本转化率
5）最终得出曲线，是在页面功能及业务状态基础上，各Latency范转内的转化率趋势
3.2 关键技术要素
A. 浏览器Navigation-timing和Resource-timing API是方案得以实施的关键技术基础，API由W3C在2012年底提出，它可以让我们获取到页面各个重要的Latency数据
B. ODPS及相关大数据附属技术产品的的开放性、易用性、处理能力使得方案得以顺利实施
3.3 实现细节及相关SQL这里暂不详细介绍，欢迎线下交流
3.4 量化性能优化带来的转化率提升
1）已经计算出性能区间内的转化率
2）统计所有样本在各性能区间内的分布，得出各性能区间的样本占比
3）将优化后的样本在性能区间内的占比乘以所在性能区间的转化率，得出A
4）将优化前的样本在性能区间内的占比乘以所在性能区间的转化率，得出B
5）B-A即得出性能优化所带来的转化率提升
通过一段时间的观察，在大的样本集下，性能与转化率曲线保持稳定。
4. 结果
图中为真实的AE某一分站的搜索数据，柱状图为各性能区间的样本占比，黑色线为各性能区域的转化率，绿色线为各性能区间的跳出率
5. 常见Q&A
Q1:如何排除性能外的业务因素对转化的影响？
A1:此方案单纯的是按性能进行分组统计，在大的样本下，我们可以假定各性能区间内的业务条件是等同的，因此可以不考虑业务因素的影响。当然，还需要更多的时间去证明
Q2:当业务因素变化时，会使得各性能区间内的转化数据发生变化，一般会提升，那如何随时时间去衡量性能带来的转化提升？
A2:每次度量时，以时间最接近的曲线为主，按3.4的方法进行计算。后续会按需看是否采用线性回归，按自然时间上的表现拟合出一条曲线，这样可以去除掉某一天的波动
