AppsFlyer中国总经理王玮：打通产品到运营的闭环(2)

导语：很显然，现在绝大多数的公司都是这样一个合作方式，从产品部门开始，他可能会搜集用户的需求，但是更多的可能是老板的需求，他们把它翻译成产品设计的语言，然后转交给研发的部门，研发的同事加班加点把它开发出来

很显然，现在绝大多数的公司都是这样一个合作方式，从产品部门开始，他可能会搜集用户的需求，但是更多的可能是老板的需求，他们把它翻译成产品设计的语言，然后转交给研发的部门，研发的同事加班加点把它开发出来再转给我们市场的同事，然后市场同事开始花钱买量，等到用户进来之后经过一段时间再转给运营的同事，一环接一环瀑布式的运转方式。但是就像我们刚才举的例子说的那样这种方式很显然是有问题的，至少在效率上是有很大问题的。

那么我们认为一个更好的方式，是让所有的部门坐在一起，当然不是字面上坐在一起，如果可以当然最好，但是在实际情况中是不可能的。这个所谓的坐在一起更多的是强调，每个部门在开展自己工作的时候，同时要想到别的部门可能存在的需求，比方说从设计和研发部门，在日常工作开展的时候，最好要考虑到运营和推广部门的需求。

反过来在推广和运营的时候，我们基于我们的数据往往能发现设计和研发部门存在的一些问题，我们把这些反馈传达给这两个部门，这样我们可以更好的迭代产品。大家可以看到这更像是一个闭环，闭环中的每一个环节在运转的过程中都依赖于其他的环节，而且他们是紧密的结合在一起，这应该是一个更理想的模型。

下面我想给大家带来一些我们在日常工作中的观察和我们的建议。今天主要集中站在产品和研发的角度，讲述在这两个部门的工作中我们怎么考虑推广和运营的需求。这个也是我们最近经常强调的要记录关键的应用内事件并且基于这些事件做运营。如果把刚才的闭环比做一个工业体系，在这中间应用内事件就相当于石油，整个工艺体系的运转和它达到的效果和产出都是基于对应用内事件的开采和提炼，所以应用内事件的重要性无论怎么强调都不为过。

所谓的关键应用内事件不同的产品是不一样的，比如我们是游戏开发者的话，可能关注用户的注册登陆，用户过到了第几关，最重要的是用户的收费这样的事件;对于工具的话可能更多的是工具本身的属性是有关的;如果是键盘的应用，那可能是用户每天多少次弹出了键盘，并且敲了什么关键词，在不影响用户隐私的前提下我们应该搜集这些信息;电商的话当然就是用户浏览了什么样的商品，把什么样的商品加入到我们的购物车，然后对于什么样的商品会付费购买。

所以记录关键性的应用内事件，然后在这个基础上我们可以做，比方说渠道评估。再回到刚才的例子，通过用户留存来评估带来用户的质量，或者说评估渠道的质量，但是用户留存这个指标，其实是不太靠的住的，因为用户留存基于什么呢，是基于应用打开，这是一个比较单薄的事件。我举一个学校的例子，通过用户留存来评估渠道或者用户的质量就等同于通过出勤率来评估学生的成绩。我们大家都上过学，所以大家知道这个所谓的老师点名，我们一般都会有人来帮我们代答到。所以这么一个单纯的基于出勤的方式来评估，第一不全面，第二很容易被作弊。那么留存也是一样。