最近从某某头部出海应用离职，有些空闲来重新思考一些项目和产品上的思路，想着重新去梳理下数据分析的框架，分为数据基础（指标体系、埋点体系、AB流程）和分析方法（用户分群、行为分析、漏斗分析等）。更多的是想从过往的一些案例中重新思考数据的应用场景。
先从AB这个谈起吧，主要是在睿琪的时候，看着这AB实验框架和流程逐步搭建完善，从中也有不小的收获。重新认识到了过往对于AB的一些误区。当然，睿琪这块也是有着不小的问题，也和我从这里离开的一个原因。
定义
通过随机分组的方式，对于两组用户呈现不同的产品方案，然后根据实验数据反馈，确定实验方案是否胜出的方法。
为什么
版本评估
验证产品判断
流程
规划阶段
过往的时候，会把AB限定在一个版本评估的工具上，而忽视了其贯穿在整个产品迭代的过程作用
对于一款产品，其流量是可预期和估量的，那就可以导致在特定的时间区间内，其可测的方案数量是有限的。即产品方案争夺的不仅是研发等资源，还要争取流量资源。
那就需要在规划阶段，尤其在两月期，就需要结合目标和指标，反过来思考方案的节奏，通道的分配。
评审阶段
需要根据版本针对人群，目标指标，预期提升，占用功能模块及对应流量，计算所需时间段（根据现有指标，预期提升，通道流量）
注：过长的时间跨度会引入过多变量导致方案胜出的不可信
方案价值和可行性评审，同常规流程
方案胜出铺开和失败下线影响评估
上线阶段
观测多维度指标，目标指标，过程与行为指标，保护性指标
复盘阶段
指标提升置信度
指标提升与过程变化相关性
结合用户分群进一步细分挖掘，找出可进一步优化的空间
注：对于胜出方案和失败方案，其实其价值是类似的，说明用户没有受到影响，这个迭代方向可能都是有问题的。
胜出铺开阶段
不同用户群体可能差异测试
不同平台可能调整
案例
讲个有趣的案例，进入这家公司后，过往的方案文档还是比较完善，近一年上线方案，无论失败还是成功，相应的文档、埋点和数据都是可以追溯。这个还是需要为睿琪点个赞
我在对过往的几个方案进行横向比较，会发现有个用户特征标签，在多个失败方案中通过特征标签划分分群会看到截然相反的数据结果。
在进行进一步的分析后，想了几个假设，重新提交了几个方案进行验证。
这里想通过这个案例说的是，AB测试是否胜出其实都是一个很宝贵的资源，其被不同的人所解读可能会产生很多的假设和后续的方案。
思考
AB虽好，不可全依赖
当下这家公司就进入了这个误区，无论什么方案都是需要走AB，但这个又决定了整个产品部门，难以去做大的规划和分步骤的迭代。
虽在规则里说，可以接受不胜出的方案，通过分布迭代产出最后的胜出。但AB的小步性，决定了很难和大的版本进行结合。
基于假设，单变量测试
这个是在产品方案评审的时候，新人常范的错误，会把一些想法一股脑的放进一个方案里，而没有考虑不同假设之间的冲突影响。这样才能在最终数据结果出现，难以确定是哪个假设影响导致的。
实验影响用户群体
受AB技术影响，一些方案其分配的用户流量和真实收到方案影响的用户群体其实会存在较大的差异（一般为子集），则需要在计算数据置信度的时候，进行切分，否则可能会导致实际胜出的方案最终被判断为失败。
不同通道交叉
对于同个通道方案一般会有较为清晰的评估是否会有相应的影响，进而切分为前后版本。
但有些时候即使是不同的通道，也会造成一定的影响，需要有人从全局的角度对其进行把控。
