1704198940
1704198941
虽然我们倾向于使用ICE评分，但是其他增长黑客也提出了其他评分体系。比如被誉为“转化率优化之父”的布莱恩·埃森伯格就提出了“TIR体系”，即time（时间）、impact（影响力）和resources（资源）。3另外一个体系是“PIE”，即potential（潜力）、importance（重要性）和ease（简易性）。4虽然不同的体系细节上可能存在差异，但是它们的总目标是一致的，即以量化的方式评估试验想法，帮助团队筛选不同试验选择、决定下一个试验内容。
1704198942
1704198943
经过评分缩小了选择范围之后，你手里的试验可能仍然超出了接下来一周所能完成的量。有些想法需要更长时间去准备，比如那些需要大量软件开发或设计工作的试验。对于这样的试验应当在咨询试验筹备直接参与人员之后设定一个具体的测试日期。如果筹备工作涉及软件开发，工程师和产品经理就应当为增长团队估算一个时间框架，而如果要测试一个新的获客渠道，市场团队就要负责为增长团队提供一个时间表做参考。
1704198944
1704198945
在当周无法启动的试验想法都应储存在储备库中。你可以从中选择一些用于接下来一周的试验，而保留其他想法日后使用。关键是团队应以时间和资源利用的最优化为目标安排他们的工作，专注于增长负责人选定的关注领域中最紧迫的需求。
1704198946
1704198947
让我们再回到食品商店App的案例中来看一看如何开展筛选过程。App团队的目标是增加每个用户创造的收入。在收集了一些点子之后，他们决定选择“初次下单优惠”和“把免运费政策信息放在更明显的位置”这两个影响力和简易性评分较高的想法进行测试（见表4–1）。
1704198948
1704198949
初次下单优惠试验很可能会交由营销人员负责，而免运费试验则交由产品设计师负责。
1704198950
1704198951
假设团队同时决定购物清单试验也值得一试，但由于这一功能的开发比较复杂，增长负责人可能会让产品经理询问产品团队的时间安排。获得了这一信息之后，增长团队就可以考虑设定试验启动时间了。
1704198952
1704198953
我们建议团队通过协作来进行试验选择。在增长会议召开前一天，增长负责人应通知团队查看想法储备库并从中选择他们认为最有潜力的想法（不一定只是新提交的想法，可能也包括已经在库里的想法）。这些想法将作为候选在增长会议上讨论，届时团队将共同决定在什么时间启动哪些试验。团队成员可以通过邮件对想法进行提名，或者如果系统允许的话，也可以在储备库中设置突出显示。例如，在GrowthHackers的“Projects”系统中，团队成员可以给想法加星标，加星之后想法就会进入单独的列表中，增长负责人可以查看并在会议上与成员展开讨论。为保证被提名想法的数量在可管理范围内，我们通常限制每个成员每周最多提出三个想法。
1704198954
1704198955
这些被提名的想法将会在增长会议上由成员进行讨论，并选出将于下一周启动的试验。我们将在下一部分作详细介绍。
1704198956
1704198957
第四阶段：测试
1704198958
1704198959
一旦团队选出下一周的试验项目之后，这些试验就会进入我们所谓的“Up Next”（即将开展）列表，如果你们采用手动追踪，那么这个列表可以是一张新的数据表。而如果你们使用项目管理软件，这些试验则会进入系统中的一个特别工作序列或列表。接下来负责试验的成员就要和增长团队的其他成员（或和其他部门的同事）一起筹备并部署试验了。
1704198960
1704198961
真正意义上的跨职能合作正是在这时展开。再回到食品购物App的例子中，市场团队成员可能会跟图形设计和邮件营销团队合作设计初次下单优惠信息的图片与营销文案。他们也会和数据分析师一起确定对照组（不参与试验的用户群）和试验组，并保证试验结果可正常追踪。
1704198962
1704198963
当一切准备就绪时，增长负责人将向公司所有同事发送试验启动通知，以保证其他负责该产品的团队知晓试验情况。如果在启动某些试验时遭遇障碍，比如工程师忙于其他重要项目，有可能几周内无暇顾及试验所需代码的编写，那么负责试验的团队成员必须立即通知增长负责人，以便负责人筛选“Up Next”列表中的其他想法来替换暂时无法进行的试验。
1704198964
1704198965
每一个试验的运行都意味着另一个试验的落选。因此，对于点子的筛选和测试方式的选择都应当十分慎重。一次糟糕的试验就意味着团队失去了一次宝贵的学习机会，这会放慢团队工作的进度，而错误的数据会误导团队走错方向。因此，必须保证每一次试验都能产生统计上有效的结果。应当制定确保结果可靠的完善的指导规则，同时，团队里的数据分析师应负责将这些规则落实到试验中去。本书不会探讨试验设计的细节，但是我们希望提出以下两个我们认为非常有用的经验法则。
1704198966
1704198967
采用99%的置信水平：很多工具都会自动设定或允许用户自定义试验的置信水平。常用的置信水平为95%和99%。虽然这二者之间4个百分点的差别看起来并不大，但是从统计学的角度来看这会产生显著的差异。95%的置信水平意味着一个“成功”的试验仍然有5%的概率出错。这意味着，每20次看似成功的试验中就可能有一次其实是失败的。而99%的置信水平则意味着100次测试里只有一次是“假阳性”。因此，当你不确定时，就选择99%的置信水平，从而大大降低因为“假阳性”结果而选错试验的风险。
1704198968
1704198969
1704198970
1704198971
1704198972
1704198973
1704198974
1704198975
1704198976
1704198977
1704198978
1704198979
永远以对照组为依据：当试验明显失败时，团队通常能够在查看数据之后迅速认识到这一点。但当试验结果并不确定时，达成共识就不那么容易了，特别是当需要耗费大量时间和精力确定结果时。没有人希望看到自己辛苦付出的结果却是竹篮打水一场空，所以团队成员可能会让试验运行超出合理时间，寄希望于试验样本的扩大能够改变走势。这样做虽然可以理解，但是当结果不确定时，最好的办法就是坚持试验的最初版本或者对照版本。因为虽然结果不确定，但是增加新的变量可能会导致试验最终的失败，成为一个巨大的潜在风险。可以这么想，把试验当作试验组和对照组之间的比赛，双方打成平手时，胜利就应当属于对照组。5
1704198980
1704198981
1704198982
1704198983
1704198984
1704198985
1704198986
1704198987
1704198988
1704198989
回到第一阶段：分析与学习
[
上一页 ]
[ :1.70419894e+09 ]
[
下一页 ]