1704198925
简易性：简易性衡量的是进行一项试验所需投入的时间和资源。重新进行界面设计或是改进结账环节购物车的样式都是具有潜在高影响力的想法，但是这样的想法往往不容易落实，可能需要几周甚至几个月的准备时间。简易性得分不仅可以帮助增长团队认清一些不太现实的想法，也可以帮助他们在每一轮增长循环中发现一些“唾手可得”的试验。
1704198926
1704198927
1704198928
1704198929
1704198930
1704198931
1704198932
1704198933
1704198934
1704198935
在召开团队会议之前，增长负责人应查看各个想法的初始得分，他可能会发现想法提交者没有想到的一些问题。增长负责人可以基于他的过往经验以及其他团队成员的意见给出分数调整建议。但是，团队不应过分纠结分数调整。这个分数只是用来进行优先级的比较，不需要尽善尽美。如果团队成员浪费太多时间争论一项试验的影响力得分，那么增长会议很快就会陷入僵局。团队应把这一分数作为一个重要参考，而不是当作优先级排定的唯一依据。如果团队对于某个分数存疑，增长负责人应依据自己的最佳判断果断做出决定，以引导团队推进工作。
1704198936
1704198937
这一评分体系并非万无一失，测试结果也经常与预期不符。有些评分最低的试验结果反而产生了最好的效果。在GrowthHackers，我们曾做过一个简单试验，调整了网页上每周“最佳帖子”简报邮箱登记表的位置。这个登记表原本是在网站主页的底部，因为我们原以为需要给用户时间先浏览我们在首页上主推的最受欢迎的帖子，然后再决定是否登记邮箱地址以接收我们的每周简报。后来摩根提出了一个建议，即把登记邀请改到页面顶端，把它放在一个更显眼的位置。事实上，他本来并不认为这个调整能带来多大的变化，所以只打了4分。但是我们还是决定测试一下这个想法，这是因为基于工程师团队的反馈，这个试验比较容易开展，我们在简易性一栏给它打了9分。同时摩根有比较大的把握这个调整将能够使用户更容易看到登记邀请从而会在一定程度上增加登记量，于是在信心一栏打了8分。结果非常令人惊讶——登记量增加了7倍，远远超出了我们原本的预期。
1704198938
1704198939
讲述这个例子并不是要说明摩根能提出这个点子有多厉害，其实他也提过不少以失败而告终的点子。提出这个案例是为了说明我们对于自己想法的预期并不总是很准确，同时也说明不要轻易抛弃分数较低的想法。
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
[
上一页 ]
[ :1.704198925e+09 ]
[
下一页 ]