从产品，运营两方面优化转化率
但是这个变量本身却很复杂，它包括了至少两方面是我们产品经理和产品负责人特别重视的，一个是我们的产品本身，一个是我们的运营，那产品可能就包括你的UI的设计，然后你到底有哪些功能，你的用户体验流程是什么样，然后细节上的文案是怎么样的，你的界面布局或者用户交互是怎么样的，然后我们后端的一些，比如说推荐算法，排序算法，风控策略，派单策略等等，都是我们产品的一部分，她都可以做各种各样的调整，各种各样的变化。它是一个很复杂的变量。那么运营环节也是，我们可以做各种各样的活动，做各种各样的促销，做内容营销，然后做大量的PR，传播，等等各种各样的努力都可以做。这些都是我们可控的变量，我们通过控制这些变量，来最大化我们的转化率，这就是整个优化所做的事情。
优化方程式的解释无限的
如果大家学过优化理论的话可能知道，如果在一个很明确的限制条件下，有一个很明确的优化目标，再有一个变量解的空间，我们是有很多算法来找到这个最优解的。比如说gradient这种算法，比如说模拟退火等等这样人工智能的算法都可以。但是很遗憾，在我们的企业运作中，在我们的互联网产品优化过程中我们这些算法都帮不上忙，原因就在变量的解的空间太大了，解集是无限的，也就是说我们没有办法去遍历，没有任何的办法找到最优的解，所以我们需要一个迭代的方法。
9、如何优化转化率
在这张图里就展示了它的方法。可能非常非常的原始和粗暴，但它也是我们唯一可以仰仗的方法。也就是说我们不断在已有产品已有运营的基础之上，我们去做些微的调整，然后去尝试哪些调整有可能带来转化率的增长，哪些不可以。然后我们通过这样的方式一点一点去优化提升我们的转化率。方法很简单，根据我们要优化的目标，把比如说页面上的改动灰度的发布给一部分用户，然后去看它的数据。比如在这张图里，可能蓝色的改版放给了一半用户，他们的转化率是11，而原来这个绿色的版本是23。数据结果告诉我们，这个绿色的版本更好，也就是说我们尝试了解空间里至少两个点，其中一个点比另一个点好我们选择绿色的版本。那么在这里要注意，这个流程是只改变一个条件的单盲试验，也就是这个对比里面我们仅仅是对比了这个产品的不同。产品本身的用户流量应该是比较相似的，他们用户的来访时间应该是比较相似的，其他的促销活动，所有的用户应该都享受。在其他条件都不便的情况下，只改变网页一点点的变化，去对比数据转化率的数据，然后去做决策到底哪个更好。要注意这是只改变一个条件的单盲实验，我们后面再去提到这一点。
10、通过优化打造MVP
优化的时候这种迭代的思想其实是从我们第一天就开始的，也就是我们大家都听说过的MVP的概念，最小的最有效的产品，这样一个概念。那么从一个最简单的，可以满足用户需求的，达到我们市场目标的产品开始，我们不断的对它进行优化，进行改进，知道它越来越好，达到一个最优的效果。
那么要注意的一点是，MVP的做法，第一个方法是不对的，最上面那种。MVP说我现有一个很完美的设计，然后我先做它的一部分，做一个轮子不能用，做两个轮子还是不能用，做个车架子也不能用，把他们堆起来才能用，这不是MVP的方法。这样的方法就跟传统产品一样，就跟你做一个牙膏或者手机一样。你先做个设计，然后把它做出来，然后再推向市场，这样的话你就失去了我们刚才所说的产品优化的迭代的效能，你就变得跟传统企业一样，你的优化会变得愈加的困难。
那么另外一种方式也更加不可取，就是你先做一个滑步车，然后再做一个自行车，把它变成摩托车，最后变成汽车，也就是说你总是在改变你的产品形态。那么这个并不是一个不可以的迭代方法，但是它的成本太高，就是它是一个非常糟糕的路径。正确方法就是下面所说的，你现有一个产品，然后不断的对它进行改进，当然改进的时候要通过试验的方法，这是我们后面再提的。
11、优化中常见问题
a)获取优化试验结果，试验结果准确度、可信度可能不准
举例：我们做了一个游戏的产品，很小的一个产品，然后我们发现有一些玩家愿意在上面付费，我们希望能提高玩家在付费环节的转化率，我们做了一个尝试，做了尝试之后呢比如说我们推给500个玩家，我们发现这500个玩家付费比其他的用户要多，那么这一定说明我们新推出的这个方案好么，我们新推出的这个碉堡好么？不一定，可能你做实验的这500个人里面你恰好圈中了王思聪，他的下单率远远大过其他人，那么你的这个试验结果就不准确。那么刚才所说的那种迭代方法就没有真的产生效果，因为结果可能是不对的，它促使你做出了一个错误的判断。
b)试验结果分析算法置信区间的收敛速度，试验的敏感性可能不敏感
另外如果你的试验流量，试验分析，还有试验的设计不是很理想的话，那么你通过一个置信区间的分析你会发现，你统计的结果从概率角度讲可能会非常的不准确。举例来说，你对比两组数据，实验组和对照组相比，结果可能是-200到 500这样一个变化的区间，你根本拿不准这个迭代使你的产品变好了还是变坏了。这也是另外一个痛点。
c)大量优化并发试验，针对特定用户群体的定向试验，分层试验、交叉试验等等可能很繁琐
如果你要去做迭代的话呢，你要大量去做尝试，做改动，但是大量的改动，如果你同时上线，或者分开给不同的用户去体验，可能会遇到一个苦难，就是他们试验的结果会不会互相干扰，试验的用户会不会之间有一些问题，那么这也是一个挑战。
d)管理海量优化试验，包括海量历史数据与经验，细致的试验数据分析可能很复杂
最后当然也包括你如果能够管理海量数据。当然大家都是产品经理，都会有自己的idea。你可能有10个想法，10个对你产品优化的想法去上线，一个公司如果有3个就是30个，如果有10个产品经理就是100个。那么过了两个星期你还会记得你做了哪些试验么，这会很痛苦。
12、优化的方向，可以优化的地方
说了这些，我们要慢慢引出我们核心的概念，其实，我们优化的目的很明确，刚才已经说过了，留存转化，用户活跃转化行为，比如购物车的添加购物车的退出，功能使用等等。然后，你可能要做的优化迭代的方向就是你的各种创意，你的各种想法，你根据用户行为作出一些判断。比如说在UI层面，在用户体验层面做了一些改进。比如说你的页面布局，有的时候这个东西影响非常的大，你是把用户的4个篮子放在最上面，还是最下面，还是左边还是右边，这都很有影响。当然文案也很重要，如果我现在看到这个案子上面写的是现在申请，我打赌它的转化率肯定不如点击领取大奖的效果要好。
13、优化中需要注意的事情
推荐的算法，产品的新功能这些，都是我们平时就想到，就要去迭代的东西。但是这些迭代，和我们前面所说例子的一样，到底能不能产生优化的效果呢，到底能不能提升访问率UE，点击率，支付率等等，那么我们就需要注意什么呢？我们需要科学的流量分隔，我们要让实验组实验对象具备典型的用户特征，不要出现像王思聪这样奇葩的被采样的用户做实验。另外我们需要一个可信的能够快速收敛的95置信区间，他能告诉我们这个迭代能够带10的增长，这10的置信区间是从5到15。那么我就确定了我至少有95的概率可以提升5，另外你也可以考虑在试验当中做人群的定向，比如说我只对上海的或者深圳的女性用户做试验，我能从中学到什么东西，能对我的产品有什么启发。
二、优化的利器：AB测试
1、你的测试真的是AB测试么？
上面所说的所有都是为了引出AB测试这个概念，AB测试就是Alwaysbetesting。它的概念就是一个科学的测试。它能够帮助我们去合理的采样用户流量，带有一部分随机性，帮助我们去实现实验流量的采样，同时支持很多的变量参与实验，我们可能在UI层面要做实验，我们可能在促销或者活动上要尝试，我们到底上不上一个大转盘。我们当然也会在后端的派对算法和推荐算法上做尝试，他们都可能影响我们的效果，这些变量的影响会怎么样，需要一个科学的方法去追踪，我们要知道到底哪个变化产生了什么样的影响，可以帮助我们产品经理在管理产品的时候可以很容易的去选择到底哪个版本你想交给你的用户去体验，然后当然还有实验时间的问题，就是说这个实验跑多久才可以做出决策，这其实也是AB测试需要解决的问题。就是如果我们不做AB测试，我们直接上线了，然后过了两天，我们觉得这个效果，数据不错，就真的数据不错么，真不一定，这后面会说。当然也有收敛区间置信区间等等问题，这都是AB测试要解决的。
2、优化方式
其实AB测试的方法论大家在前面已经知道，有一些概念，但是更重要的是把它集成到我们产品研发，测试，上线，运营的各个环节中去，这个才是在Google的秘诀所在。假如你有了AB测试这个工具，集成了SDK或者怎么样，你总是在设计一些新的迭代方案，就是我刚才说的UI能不能变一变，按钮的位置能不能变一变，文案能不能变一变，上不上一个促销等等，这些方案都可以灰度的上线，就是并不是所有用户都体验的，然后你去设定实验流量，比如方案A让1的用户去体验一下，方案B让2的用户去体验一下，然后这些放进实验组这些用户他们的数据会被实施长期的采集下来，然后根据这个实验数据我们会知道，有些方案特别的棒。比如说我们改了一个文案，使得用户下单率提高了，那么我们就可以把它发布，让更多的人体验这个文案。如果它不好，那我们就要打回去重做，我们就要去思考为什么这个数据和我们想象的不一样呢，为什么他们没有提高呢，为什么没有增长，那么我们该怎么从中吸取经验教训，然后让它不断的去新的迭代。
3、AB测试与统计分析的差异
接下来我要说一些理论性的东西，就是AB测试集成到我们系统里面，是正确的方法，为什么正确呢，它与我们做统计分析，它与我们做后验的数据分析，有什么区别呢。
先验性
如果我们每次改版每次迭代的是都没有经过AB测试就直接上线了，那会发生什么事情呢，那么可能一个不太成功的改版不太成功的策略被上线之后就直接带来了损失，比如说降低了20的用户下单量，那么如果真的发生了这样的事情的话，我们后验的话就产生了不可弥补的损失，但如果我们做AB测试我们可以怎么样呢，我只采样一部分的用户，比如1的用户来做这个实验。
举例来说，我们遇到过一个旅游类的产品，它在他的注册环节做了一个小小的改版，这个改版也经过一些测试，但是他没有想到的是对失眠上的某些安卓手机会有一些不过注册流程上会有问题，那么他每天会花10玩块钱去采购流量，会吸引一万个用户来注册，结果因为这个bug的原因，有40的用户想注册而注册不了而流失掉了，意思就是这10万块钱里面就有4万块钱浪费掉了，但是他的这个心的改版通过我们AB测试来验证一下，用1的流量来验证一下，虽然也有40的损失，但是它是1的40，换句话说他不是损失4万块钱，而是损失400块钱，这就是先验性的意义所在。
并行性
也就是说我们真正AB测试也好，产品优化也好，真正的使用场景并不是说我现在有一个迭代方案，然后去先验证一下然后决定是不是上线，不是这样的。显示当中你要做到优化，你必须，就是我们刚才说到的优化问题，解的空间是无限的，我不能一个个点着找，我必须同时找10个点，20个点，100个点，我要同时上线很多很多可能的方案，然后对它进行测试并行，而不是说上一个，不行再上一个，那样的话我一个月只能去验证2、
