移动转化漏斗实践：如何日常操作工具

大多数团队都会像进行翻新一样建立转换漏斗：他们租用工具，实施事件，设置漂亮的仪表板并认为工作已完成。三个月后，再也没有人打开仪表板了。漏斗变成了墙上的一幅画，没人看。

问题不在于工具。它将转换漏斗视为一个项目，当它是例行公事时。有效的漏斗不是具有最佳图表的漏斗，而是每周一周融入团队工作节奏的漏斗。

这篇文章是关于操作的。这与选择哪种工具或诊断示例无关，而是与如何使该工具在日常工作中发挥作用有关，而这正是几乎所有分析投资都失败的地方。

仪表化是产品决策，而不是工程决策

当漏斗仪表作为一项技术任务交给工程部门时，一切就开始出错了。如果没有衡量计划，“在此处添加一个事件”会产生一个充满无用事件的漏斗，并且错过了重要的事件。

在接触代码之前，团队需要一个跟踪计划：漏斗的阶段是什么，哪个事件标记每个阶段，每个事件携带哪些属性。本文档是产品责任，由工程验证可行性。如果没有它，您将在黑暗中进行检测，并在几个月后发现能够回答业务问题的事件丢失了。

一致的命名约定，过去的动词，小写，单一模式，看起来像是细节，但它是将可读的漏斗与事件汤区分开来的，在事件汤中，011和2共存跟踪同一事物。

漏斗只有在有仪式的情况下才起作用。实际上，这意味着每周召开一次简短的会议，团队会研究阶段之间的转化率并回答一个问题：发生了什么变化以及为什么发生变化。

这不是一次欣赏图形的会议。这是一个决策会议。具有相关下降的漏斗的每个阶段都成为要研究的假设或要运行的实验。如果没有这个循环的结束，再次观察、假设、测试、测量，工具就变成了沉思。

运营漏斗的团队将仪表板视为一项活生生的议程。每周的指标都会与前一周、上个月同期进行比较，并按应用程序版本进行细分。最后一点对于移动设备至关重要：下降的数字可能只是存在错误的新版本，而不是用户行为的变化。

在移动设备上操作漏斗会带来网络上没有的痛苦。新版本的采用是渐进的，部分基础仍然是旧版本数天或数周。这意味着今天的数据混合了来自不同版本产品的行为。那些不按版本过滤的人将噪音视为信号。

还有运输延迟。当用户重新连接时，离线触发的事件数小时后到达服务器。实际上，这意味着昨天的数据今天仍然在变化。将前一天的转化视为封闭数字会导致错误的结论。成熟的例程是等待数据稳定后再做出反应。

这些不是该工具可以单独解决的问题。这些是团队需要内化的规则，以免根据不成熟的数据做出决策。

漏斗操作中的第一个错误是对噪音做出反应。周二的转换率下降了三分，球队已经陷入恐慌，成立了一个特别工作组。但一天与一天之间的微小变化几乎总是统计噪音，而不是趋势。

运营成熟度在于知道如何区分什么需要反应，什么需要耐心。关注几周的趋势，而不是一天的波动。当真正的问题出现时，对每一次波动都做出反应的团队就会精疲力竭并失去信誉。

第二个错误是没有关闭循环。实验进行并产生结果，但没有人记录或应用所学到的知识。在实践中，只有当每个周期留下记录时，漏斗才会得到改善：我们测试了什么，我们学到了什么，因此发生了什么变化。

在巴西的背景下，整个操作都会操纵真实的用户行为数据。对您仍然收集哪些数据以及为什么不是[LGPD3]官僚机构进行例行定期审查，数据卫生也可以使漏斗变得更干净。

健康漏斗的最大敌人不是缺乏工具，而是缺乏所有者。当每个人都对漏斗负责时，它最终就不再是任何人的了。仪表板会一直工作，直到第一个优先级发生变化，然后默默地放弃。

成熟的运营会任命一个明确的人来负责渠道的健康。这并不意味着这个人做了所有的事情；这意味着有人可以确保在新功能出现时仪器保持正确，有人注意到事件何时停止触发，并且即使在繁忙的几周内也可以保持每周会议的进行。

这个作用尤其重要，因为漏斗会不知不觉地退化。开发人员在重构中重命名了一个事件，然后漏斗中的一个阶段突然重置，不是因为用户消失，而是因为测量中断。如果没有细心的所有者，团队可能会花费数周时间对测量错误的漏斗做出决策。

定期进行仪器审核也是值得的：有人检查事件是否仍然与产品的实际情况相符。产品不断变化；跟踪需要随之改变，否则该工具就会开始自信地撒谎。这种乏味且乏味的操作护理使得漏斗在几个月内保持可靠。

运营漏斗的团队和执行数据剧院的团队之间的区别在于结果。在运作的团队中，周数会改变决定。在剧院里，表演上演了，每个人都认为这很有趣，但什么也没发生。

漏斗工具在许可方面以及主要在检测时间方面都很昂贵。仅当数据经常成为决策时才会支付此成本。无论仪表板多么漂亮，不能改变团队行为的漏斗都是无回报的成本。

如果你的应用程序的漏斗正在成为一种装饰品，而你想将其转变为真正推动产品的例程，那么它就值得讨论。博客上还有另一篇关于漏斗工具和诊断示例的文章，以及有关产品指标和数据驱动文化的文本。