App服务化, 10倍增长，你想知道的都在这里了!

导读：如何让app的每个页面/服务能够像web page那样被发现、管理和监测？如何基于特定的情景让移动端用户能够在各个app之间进行无缝的唤醒切换？如何利用Growth Hacking的理念提高app的用户和留存？如何评估app的某个具体页面/服务的传播效果？我们将在持续分享以增长为主题的系列干货文章中为您一一解读，本期魔窗CTO大湿胸首先带您了解app服务化的方方面面。



什么是服务化

某一天我发现我周围的同事用起了机械键盘，自己试用下来感觉不错，也想入手一个，工程师的好奇心促使我自己去网上找资料对比哪一款机械键盘更适合我，于是我花了一天时间做了选择，发现Cherry的G80-3000不错，第二天下单，到货后用下来非常满意，准备推荐给我另一个需要买机械键盘的朋友，于是乎我直接把电商上的这款机械键盘的链接发给我的朋友。假设我的朋友最后通过我给到的链接下单了，那么我就为这个电商带来了一个订单。这是在PC端的一个再自然不过的用户转化过程。5年之后我发现大家不再用PC去浏览各个网站了，而是在手机端用了各种各样的app。

某一天我发现某个教瑜伽的app中的一个瑜伽课程不错，想推荐给我朋友，我突然发现我只能口述给我朋友这个app下的瑜伽课程不错。朋友如果装过app，那他需要打开后自己去寻找我说的那个课程，如果没装过还要先下载后再打开，然后再寻找。但是我朋友是个懒人，于是就此作罢。我突然发现在移动时代，用户自传播带来的转换反而不如以前了。

上述的场景在移动时代比比皆是，原因就在于，在传统的PC时代用户传播的是网站提供的一个具体内容或者一个具体服务，而非网站本身，我们把具备传播app具体内容和功能的能力叫服务化。网站在很大程度上是天生具备服务化能力的，因为有链接！每个链接就代表一个具体的服务。但是移动时代并非如此，用户只能传播app本身，很难把app所提供的服务或者内容传播开来。好在后来有了Deep Link技术，使传播服务和内容成为了可能。所谓App的服务化就是利用Deep Link功能将App的特定页面做为一个单独的服务或者内容，通过一定的渠道和载体传播出去，并且能够像传统的网页链接那样被一键唤醒。

服务的内容

实际上各种App根据自己不同的业务场景最终呈现出的服务化的具体内容也不尽相同，而将哪些服务或者内容做成服务化，是根据app想要达到的转化目标而定的。

1. 对于电商类应用，它的转化目标一定是下单率，因此每件商品的页面都可以做成服务化，比如京东商城的某个手机单品页面。



2. 对于工具类应用，它的转化目的在于拉新和留存，因此他必须最大程度的引导用户直接进入某个用户想要的功能页面，因此工具类应用的一个个功能页面都会做成服务化，比如中华万年历的在某一天添加提醒事项的服务。



3. 对于新闻类应用，它所传播的一定是一条条具体的新闻内容，因此，每一个内容都会被服务化，比如新浪新闻中的一则体育新闻。

4. 对于O2O 应用来说，它最关心的是拉新，因此它会把许多吸引用户的活动页面以及老带新的注册页面做成服务化，比如HotelTonight。



5. 对于生活服务类应用，和工具类类似，也会把具体的某个服务订阅/购买的功能完成服务化，但是往往这些服务是能够接受不同的上下文环境的参数，比如携程的订阅某个时间点从某个出发地到某个目的地的机票的服务。



从上述几个场景中我们能得知，如果要在技术上实现这些内容的服务化必须要做到以下几点：

Deep Link 的Schema 支持动态参数，比如新闻类应用，schema 的规则可能就是sina://article?id=:articleid 具体使用的时候把:articleid 替换成具体的文章id；

Deep Link的上下文还原，比如对于O2O类应用的老带新，为了促使老用户带新用户注册，必须要知道新用户注册是由某个老用户带过来的，用来给老用户奖励，所以他的schema 可能是, hotel://register?referral=:oldUserId, 这个oldUserId会还原到注册页面以告知新用户你是由哪个老用户推荐过来的，并在后台记录。

服务的传播渠道和传播载体

服务的传播渠道有两大类，一类是自传播渠道，也就是app或者app的用户发起的对某个服务内容的传播，在这种情况下要么是你的app中的某个服务化的页面，有一个分享或者类似的功能按钮，然后将这个页面通过诸如短信，email，以及其他诸如微信，facebook这样的第三方平台。比如HotelTonight的短信传播。



另一类是app与app间的相互协作调用，这个时候渠道就是帮你传播的那个app的某个界面元素，比如格瓦拉唤醒uber。



对于第一类自传播渠道，它的传播载体是一个链接，这个链接能够最终投放在短信，email或者一个h5的页面元素中。而对于第二类app间的调用，它的传播载体就是这个页面元素相应的点击事件代码。

因此从技术上来说，想要实现服务的自传播，就需要提供链接服务，为什么不直接是deep link的schema呢？原因在于：

一个app如果既有ios端也有android端，他的schema可能不一样，更不用说还有ios 9以后支持的universal link 和android 6.0以后支持的app links

如果用户没有安装过app，那打开schema的结果就是一个无效页面，无法做任何优化因此技术上需要为每一个服务都生成一个统一的链接服务，通过这个链接服务可以获取所有关于这个服务在技术上的meta data，不过ios 和android 的schema，包括在用户没有安装的情况下引导用户去的市场的下载页面或者是落地页，并且这个链接是要具备传递动态参数的能力。

除了链接服务之外，无论是自传播渠道还是app间的调用，在最后的的安装和转化的统计中，都必须具备渠道归因的能力。举例来说，uber从格瓦拉那边获得了一个用户转化，那么格瓦拉就是一个uber轿车服务的渠道，是需要能够单独统计到的。同样如果uber在短信里用链接的方式传播自己，那它也必须统计到通过短信带来的转化是多少。

服务的形态

一般而言服务化的内容有两种形态，一种是原生app的某个页面，另一种是一个具体的H5。为什么还需要有H5？假设你把一个具体的服务化的内容传播了出去，这时候需要考虑两种情况：

用户已经安装过你的app，这种情况不言而喻，将会直接唤醒app；

用户还未安装过你的app，这时候分两种情况，一种是引导用户去应用市场下载。但是对于电商这种类型的app，它更关心的是下单，而不是原声app的拉新，所以它会提供一个具体的替代app的单品wap页面，这个就是上述说的服务化的H5形态，让用户能在这个wap页面里直接下单，让我们之后统一把这样的页面叫做landing page。

究竟引导用户是去应用市场下载，还是到达landing page，又或是直接唤醒，在技术上是需要能通过当时的上下文环境智能选择或在后台配一个具体的策略。拿淘宝的例子来说，即时用户已经安装过淘宝，它也是先回跳转到一个landing page，再提示用户是否打开app的。



服务的评估

如何评估一个服务的好坏基本上取决于这个服务的传播效果，这就要求服务需要有被监测的能力，每一个服务都需要能够被分析不同渠道的传播效果，包括用户点击，带来的安装量和转化率，监测能力是帮助开发者进行服务优化的一个重要标准，一切以数据说话。

服务的高级特性

实际上在传播服务的初期，很大一部分用户是没有安装过你的app的。如果你的服务看中的是拉新又或者你没有额外的研发实力开发替代原生功能的基于H5的landing page。那么给你的选择就只能是引导用户去你的应用市场下载app。这个时候如果用户第一次打开还需要找到相应服务页的话，那实际上是和没有实现服务化是没有任何区别的。所以你的服务化必须具备用户在第一次打开应用时需要跳到相应引导过来的具体服务化页面的能力，而非首页。这个能力叫做技术上Deferred Deep Link。我们把它叫做第一次安装时的场景还原。





在中国有一个特殊的服务传播渠道，就是微信。但是由于微信本身的性质，在许多情况下是不能利用DeepLink在微信里做到应用直接唤醒的。一种情况除外，如果用户是iOS平台，并且将系统升级到了iOS 9 以上，而你的app又实现了iOS 9 的universal link 功能，那么久可以在微信里做到直接唤醒。因此要做到全渠道的极致体验，universal link 是必须实现的。从技术上来说实现universal link 至少需要两点：

需要有web开发的能力，准备一个自己的web 站点；

需要购买SSL证书，因为universal link 只支持https协议。

这些毫无疑问会带来额外的研发成本。

服务化之于Growth Hacking

Growth Hacking的本质在于摒弃购买大流量的方式进行用户增长。而是根据数据，不断的优化用户体验，产品和传播方式，从而持续不断地带来具有粘性的用户增长。在Growth Hacking中，用户的转化是遵循AARRR的漏斗模型的。



我们来看看服务化在AARRR的每一个阶段带来的好处：

Accuision（用户获取），因为服务化的链接服务，使得服务化能在各个渠道被用户感知，包括短信，email，微信公众平台上的某篇文章等等；

Activation（用户激活），由于app能够根据用户直接传播用户需要的服务页面，而不需要用户手都查找功能，那么用户的激活率自然会提升，因为体验是无缝的，在用户到达的服务页里用户就能看到或者完成所需要的服务；

Retention（用户留存），当你推出一个新功能或者一个新的运营活动的时候，利用服务化能把这个功能或者活动直接向用户传播，让用户在第一时间就能跳转到此功能或者活动，那留存率自然会升高；

Revenue（用户转化），和激活和留存一样，转化页面（比如下单）也是直达的。无需经过繁琐的跳转；

Referral （用户分享），服务化后，相应的页面都可以加入分享按钮，非常方便用户进行自传播，并且由于能够将进行自传播的用户参数带入，当发生老带新时，还可以给老用户带来奖励。

魔窗mLink之于服务化

相信任何一个具备基本app开发能力的人针对app进行服务化改造都不是问题。问题在于要实现完整的服务内容，传播，形态，评估以及全渠道的体验优化，就必须要覆盖到之前谈到的各种技术细节，这正是魔窗的mLink帮助开发者解决的问题，让开发者只需要考虑将哪些页面进行服务化即可。这些技术细节包括：

服务的管理，mLink能够帮助开发者在后台管理起自己的服务，统一管理便于开发者有统一的入口区配置，更改和投放服务，并且评估每个服务的效果。

服务的链接化，针对每个服务，开发者都能够根据不同的渠道生成不同的传播链接，帮助开发者做渠道分析。链接服务也具备让开发者设置默认参数，或者动态传递参数的能力。

服务形态的智能切换，mLink会根据用户有没有安装过app配合后台配置的策略，自动决定是唤醒应用，还是跳转到应用市场或者landingpage

全渠道投放和唤醒优化，有了链接服务，开发者能将链接投放到各种渠道，同时我们也针对ios，android的不同版本以及微信的情况做了各种唤醒优化

universal link，mLink具备帮助app 自动生成universal link的功能，只需要在后台填入app的bundle id和team id即可。

第一次安装的场景还原，mLink完整的实现了deferred deep link的功能，大部分情况下都能够做到100%的在第一次安装打开应用后还原到相应的服务化页面。

服务评估，mLink为每个服务提供了归因分析的服务，开发者能知道每个服务从不同渠道带来的用户点击，安装和转化率，帮助开发者评估每个服务的传播效果

最后附上魔窗mLink的体系架构图，和数据流图。





后续魔窗团队将继续提供一系列文章，文章的主题将涵盖但不限于：

app 服务化的最佳实践和场景；

GrowthHacking的最佳实践；

结合魔窗的mLink功能谈谈Deep Link的技术细节；

魔窗相关产品的功能点介绍和技术细节；

……



大湿胸（张申竣)

魔窗CTO 

拥有超过10年的软件和互联网行业研发经验。曾在HP、Sucessfactors、EMC等500强企业从事企业级SaaS平台的研发和性能调优。亦在AdMaster担任研发总监，负责移动监测、DMP等平台的架构设计。

现带领魔窗技术团队研发魔窗SDK、魔窗 SaaS 平台以及大数据计算平台的研发，希望把企业级开发的严谨和多年互联网研发经验融入魔窗的技术团队，成为创业公司的技术标杆。