App 服务化, 你想知道的都在这里了! 10 倍增长, 从阅读本文开始!

一、什么是服务化 某一天我发现我周围的同事用起了机械键盘，自己试用下来感觉不错，也想入手一个，工程师的好奇心促使我自己去网上找资料对比哪一款机械键盘更适合我，于是我花了一天时间做了选择，发现 Cherry 的 G80-3000 不错，第二天下单，到货后用下来非常满意，准备推荐给我另一个需要买机械键盘的朋友，于是乎我直接把电商上的这款机械键盘的链接发给我的朋友。假设我的朋友最后通过我给到的链接下单了，那么我就为这个电商带来了一个订单。这是在 PC 端的一个再自然不过的用户转化过程。 5 年之后我发现大家不再用 PC 去浏览各个网站了，而是在手机端用了各种各样的 app 。 某一天我发现某个教瑜伽的 app 中的一个瑜伽课程不错，想推荐给我朋友，我突然发现我只能口述给我朋友这个 app 下的瑜伽课程不错。朋友如果装过 app ，那他需要打开后自己去寻找我说的那个课程，如果没装过还要先下载后再打开，然后再寻找。但是我朋友是个懒人，于是就此作罢。我突然发现在移动时代，用户自传播带来的转换反而不如以前了。 上述的场景在移动时代比比皆是，原因就在于，在传统的 PC 时代用户传播的是网站提供的一个具体内容或者一个具体服务，而非网站本身，我们把具备传播 app 具体内容和功能的能力叫服务化。网站在很大程度上是天生具备服务化能力的，因为有链接！每个链接就代表一个具体的服务。但是移动时代并非如此，用户只能传播 app 本身，很难把 app 所提供的服务或者内容传播开来。好在后来有了 Deep Link 技术，使传播服务和内容成为了可能。所谓 App 的服务化就是利用 Deep Link 功能将 App 的特定页面做为一个单独的服务或者内容，通过一定的渠道和载体传播出去，并且能够像传统的网页链接那样被一键唤醒。

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

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

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

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

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

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

从上述几个场景中我们能得知，如果要在技术上实现这些内容的服务化必须要做到以下几点： 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 服务化, 10 倍增长，你想知道的都在这里了!

四、服务的评估 如何评估一个服务的好坏基本上取决于这个服务的传播效果，这就要求服务需要有被监测的能力，每一个服务都需要能够被分析不同渠道的传播效果，包括用户点击，带来的安装量和转化率，监测能力是帮助开发者进行服务优化的一个重要标准，一切以数据说话。 服务的高级特性 实际上在传播服务的初期，很大一部分用户是没有安装过你的 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 为每个服务提供了归因分析的服务，开发者能知道每个服务从不同渠道带来的用户点击，安装和转化率，帮助开发者评估每个服务的传播效果

作者：魔窗 CTO 大湿胸（张申竣) 拥有超过 10 年的软件和互联网行业研发经验。曾在 HP 、 Sucessfactors 、 EMC 等 500 强企业从事企业级 SaaS 平台的研发和性能调优。亦在 AdMaster 担任研发总监，负责移动监测、 DMP 等平台的架构设计。 现带领魔窗技术团队研发魔窗 SDK 、魔窗 SaaS 平台以及大数据计算平台的研发，希望把企业级开发的严谨和多年互联网研发经验融入魔窗的技术团队，成为创业公司的技术标杆。