A Research on SmartSwitch
0x01 什么是智能运营系统，有什么用
- SmartSwitch是我为「智能运营系统」取的代号。它是一个让APP能够自己「运营」自己的系统。
- 「运营」的范畴有点大，这里运营的是APP的特性、呈现方式，比如AB版本，页面繁简，推送策略；而不是具体的业务内容，比如某条新闻，某项业务。
- 目的：让用户不「卸载」APP。「不卸载」意味着让人不讨厌。
0x02 SmartSwitch(智能运营)有没有意义
「超过40%的应用只生存了不到一天」
我了解到目前这个系统的意义在于让用户「不卸载」。针对目的「不卸载」这一点，根据北大、伊利诺伊香槟分校、普渡和豌豆荚实验室的研究人员在ACM IMC 2015会议上发表的论文《Characterizing Smartphone Usage Patterns from Millions of Android Users》 [1]，
40%的被抛弃应用只生存不到一天就 被卸载了，93%的被抛弃应用只生存不到一周。
研究人员还观察到，
有许多应用启动过一次后，用户就没有再使用，但也没有卸载。
那么，生存时间>1天而<7天的那些应用里，又有相当一部分是再也第一次打开后就再也没有使用过的应用。亦即，至少有40%，推测有超过60%的应用，用户只使用了不到一天。
为什么那么短时间就卸载了？关于卸载的原因，通过各种资料可以查到，一共就大概这么多：
是的，一共就这么多。换个角度看：
从卸载时间角度看。大部分卸载发生在一个月之内。也就是说过了一个月，卸载概率就很低了。
Categorise the uninstallation into 4 stages[2]:
Day 1
a. Buggy app（有bug）
b. Poor UI/UX（UI/UX差）
c. Different proposition stated（表意不明）
d. Downloaded for trial（下载玩玩）First week
a. Not attractive enough to convert into a regular user
b. Not of immediate useSecond week
a. Not engaging enough (notification strategy might help here)
b. No problem solvedThird & Fourth week
a. Too many notifications
b. Consuming too much data/battery
c. Found better alternative
d. too many updates
这让我觉得智能运营系统不是很有用。原因是：
- 至少有40%，推测有超过60%的被卸载的应用，用户只使用了不到一天。可能只用了几分钟。如果是这样，最重要的是冷启动（没有用户数据情况下的首次启动）时展示给用户的形态，这时候还没有运营的机会。
- 大部分APP卸载发生在一个月内。一个月后用户卸载概率很低。关于运营的用户留存，有这样的规律：
流失期——用户新进入后的前几天是流失量最大的时期，留存率显著下降，是流失期。其中第一天的留存率被称为“首日留存率”。
蒸馏期——在经过几天大幅度流失后，用户留存会进入小幅度下降时期，这就如同是蒸馏过程，是蒸馏期。
稳定期——经过一段时间蒸馏后，用户留存会呈现出一种很稳定的态势，不会有明显的增减，可称为稳定期，这段时间会保持较长时间。
3.针对金融类APP，热力图显示，同类金融APP共存性很低；which means，下载下来就卸载的概率很高。
金融类APP使用的时间亦很短：
0x03 抛弃上面说的一切
上面是从卸载概率上分析了智能运营系统。那假设在冷启动之后用户没卸载，度过了流失期的一两天，智能运营系统能发挥多大的作用？
抛弃上面说的一切，真的要做智能运营系统，应该怎么做？
行为-特性
前面说了，智能运营系统要做的是根据用户行为改变APP特性。
从figure 1 中可以把各种卸载原因对应的「行为」归类。比如：
- 「在一个很长的页面中快速滑动」这样的行为（行为），是否可以推测用户对冗长页面不感兴趣（特性）。
- 用户很少点击某些模块（行为），是否应该把那些用户从没点击过的模块隐藏起来（特性）？
- 用户从来没有点开过推送消息（行为），是否应该把推送频率降低（特性）？
聚类分析，可以对特性建模，使用某种算法对特性进行归类，计算特性之间的距离；比如采用向量夹角的余弦值来表示两个向量的相似程度，推测喜欢特性A的用户也喜欢特性B。
这里的向量代表物品/内容，也就是APP特性。对APP特性打分，比如「不展示超过一屏的页面」进行打分，
- 「快速滑动」记1分，
- 「从不打开长页面」记2分，
- 「在长页面停留很久」记-1分，
- 「每次都滑动到长页面的底部」记-2分。
夹角余弦 = 向量点积/ (向量长度的叉积) = ( x1x2 + y1y2 + z1z2) / ( 跟号(x1平方+y1平方+z1平方 ) x 跟号(x2平方+y2平方+z2平方 ) )
两条线夹角越小那么两条线越接近重合，就按照这个方法可以计算两个APP特性的相似度。这样就可以把距离近的特性推荐给用户了。
缺陷：纯粹的「隐式的用户反馈」
用余弦夹角计算物品相似度是可行的，但是用于APP的「智能运营」，不靠谱的地方在于很难「打分」，因为APP行为是纯粹的「隐式的用户反馈」。
- 显式的用户反馈：这类是用户在网站上自然浏览或者使用网站以外，显式的提供反馈信息，例如用户对物品的评分，或者对物品的评论。
- 隐式的用户反馈：这类是用户在使用网站是产生的数据，隐式的反应了用户对物品的喜好，例如用户购买了某物品，用户查看了某物品的信息等等。
如果说对于购物网站，「用户购买了某种物品」也只能归为「隐式的反馈」，那对于APP来说大部分行为估计连隐式反馈都算不上，比如用户的快速滑动这样的反馈也许只是因为无聊而不是因为不喜欢。
*值得借鉴的是知乎APP右上角卡片的「不感兴趣」。那是显式反馈。
更延伸的问题是，用户见到的东西会可能越来越少，最后APP变成了一个跟PayPal一样的极简的应用，这是运营的目的吗？
推荐引擎
从一开始我就感觉这个很像推荐系统。把不同的物品(特性)推荐给不同的人。
但是真的可以这么类比（把APP特性类比成物品）吗？
推荐引擎的分类有很多，从不同角度看推荐引擎，可以把它们分成很多类。
- 根据推荐引擎是不是给所有人推荐一样的内容**
- 大众行为的推荐引擎：对于搜索引擎就不是为了给不同用户推荐不同数据，它只需要推荐跟搜索的词语关联最大的内容。所有用户看到的都一样。
- 个性化推荐引擎：对于一些基于内容的社交网站，更多的是推荐个性化内容。
对于SMARTSWITCH,显然是选择后者。
- 根据推荐引擎的数据源
- 基于人口统计学的推荐（Demographic-based Recommendation）
- 基于内容的推荐（Content-based Recommendation）
- 基于协同过滤的推荐（Collaborative Filtering-based Recommendation）
- 根据推荐模型的建立方式
- 基于物品和用户本身--->二维稀疏矩阵
- 基于关联规则的推荐（Rule-based Recommendation） -->购物篮问题
- 基于模型的推荐（Model-based Recommendation） --> 将已有的用户喜好信息作为训练样本，训练出一个预测用户喜好的模型
其中，据我所知，第3点中的内容已经有点复杂，「基于关联规则的推荐」可以写很多论文，「 基于模型的推荐」涉及到机器学习，需要训练样本；「基于物品和用户本身」倒是可以利用二维矩阵推测一下。
推荐算法有三种常用的基本套路。下面用音乐推荐举例子。
- 基于内容的推荐（content-based filtering）。(//www.zhihu.com/people/76ab4dd8c0bcba5634e6140e44c9129e) 的解释，是音乐信息检索的领域，学术上一般content-based是特指音频内容本身的，主要涉及feature extraction，专辑、歌手和歌词等基于text或tags的因素，通常用来与content相结合来提高检索效率的。
2） 基于协同过滤推荐（collaboration filtering）。基于广义的排行榜行和热门排行进行推荐。
3）社会化推荐（social recommendation）。基于关系的推荐。
这基本跟根据推荐引擎的数据源分类的推荐引擎一致，也很容易理解。具体我不介绍了，可以去http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html#ibm-pcon 了解。
初步设想的方案
阶段1.冷启动(首次启动，没有收集到行为)：
基于人口统计学的推荐。
根据用户的属性建模，比如性别，年龄。
更少条件地，根据手机机型、地理位置建模。
计算用户之间的相似度。把每类用户喜欢的物品推荐给对应的人。这里的「物品」指的是APP使用偏好、UI简繁、模块多寡。
优点：不依赖历史数据；不依赖物品属性。
缺点：不够准确，但非常重要，因为第一次就决定了用户会不会继续用。
阶段2.产生行为之后：
基于内容的推荐。
对物品（物品对应APP想要动态调整的特性）建模。
注意，物品的属性是物品固有的属性，比如音乐的流派，歌手。不是用户行为产生的。
那么APP能调整的特性有哪些固有属性？
采用向量夹角的余弦值来表示两个向量的相似程度？需要构建向量。
或用其他公式计算物品之间的距离。
然后把A用户喜欢的物品，推荐给B。
优点：如果物品属性的维度增加，准确性会提高。
缺点：1.物品属性有限的情况。2.只考虑了物品。
基于协同过滤的推荐。
计算用户和物品之间的相似度，比如这些计算相似度的方法。
我罗列出的有限的行为和物品：
A. 用户
- 用户基本信息。性别手机型号地理位置。
B. 潜在因子(行为)
- 快速滑动长页面/缓慢滑动页面
- 短时间内多次点击操作/操作缓慢
- 从来没有拉到底部过/经常拉到底部
- 经常点击某些模块/很少点击某些模块
- 右上角OPTIONMENU中的显示反馈不感兴趣
- 从不点开推送
- 只在某个时间段打开APP
- 打开APP后很快关闭
C. APP特性（物品）
- 首页的AB 版本
- 推送频率(难以体会到改变)
- 页面复杂程度（模块的展示与否）
总结一下
这个系统的问题，首先是能做哪些改变，也就是「物品」的缺失。无论是否是隐式反馈，行为都可以收集一大堆，但是对应的物品(APP特性)呢，有哪些是可以改变的，怎么改变，改变了有用吗，变来变去会不会很傻，不知道这个就没法建模。其次就是隐式反馈的不稳定性带来的噪音影响，做出的改变很可能是不准确的多此一举的。
15/02/2017
-Reference-
[1]https://www.oschina.net/news/67846/characterizing-smartphone-usage-patterns-of-android-users
[2]https://www.quora.com/Why-do-people-uninstall-the-apps
[3]http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html#ibm-pcon
[4]http://www.cnblogs.com/luchen927/archive/2012/02/01/2325360.html
[5]https://www.zhihu.com/question/26743347
[6]http://www.360doc.com/content/12/0601/10/1083_215150645.shtml
