A Research on SmartSwitch
0x01 什么是智能運營系統(tǒng)瓶蝴，有什么用
- SmartSwitch是我為「智能運營系統(tǒng)」取的代號。它是一個讓APP能夠自己「運營」自己的系統(tǒng)。
- 「運營」的范疇有點大，這里運營的是APP的特性、呈現(xiàn)方式，比如AB版本侍匙，頁面繁簡，推送策略叮雳；而不是具體的業(yè)務(wù)內(nèi)容想暗，比如某條新聞，某項業(yè)務(wù)帘不。
- 目的：讓用戶不「卸載」APP江滨。「不卸載」意味著讓人不討厭厌均。
0x02 SmartSwitch(智能運營)有沒有意義
「超過40%的應(yīng)用只生存了不到一天」
我了解到目前這個系統(tǒng)的意義在于讓用戶「不卸載」唬滑。針對目的「不卸載」這一點，根據(jù)北大、伊利諾伊香檳分校晶密、普渡和豌豆莢實驗室的研究人員在ACM IMC 2015會議上發(fā)表的論文《Characterizing Smartphone Usage Patterns from Millions of Android Users》 [1]擒悬，
40%的被拋棄應(yīng)用只生存不到一天就 被卸載了，93%的被拋棄應(yīng)用只生存不到一周稻艰。
研究人員還觀察到懂牧，
有許多應(yīng)用啟動過一次后，用戶就沒有再使用尊勿，但也沒有卸載僧凤。
那么，生存時間>1天而<7天的那些應(yīng)用里元扔，又有相當(dāng)一部分是再也第一次打開后就再也沒有使用過的應(yīng)用躯保。亦即，至少有40%澎语，推測有超過60%的應(yīng)用途事，用戶只使用了不到一天。
為什么那么短時間就卸載了擅羞？關(guān)于卸載的原因尸变，通過各種資料可以查到，一共就大概這么多：
是的减俏，一共就這么多召烂。換個角度看：
從卸載時間角度看。大部分卸載發(fā)生在一個月之內(nèi)娃承。也就是說過了一個月骑晶，卸載概率就很低了。
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
這讓我覺得智能運營系統(tǒng)不是很有用草慧。原因是：
- 至少有40%，推測有超過60%的被卸載的應(yīng)用匙头，用戶只使用了不到一天漫谷。可能只用了幾分鐘蹂析。如果是這樣舔示，最重要的是冷啟動（沒有用戶數(shù)據(jù)情況下的首次啟動）時展示給用戶的形態(tài)，這時候還沒有運營的機會电抚。
- 大部分APP卸載發(fā)生在一個月內(nèi)惕稻。一個月后用戶卸載概率很低。關(guān)于運營的用戶留存蝙叛，有這樣的規(guī)律：
流失期——用戶新進入后的前幾天是流失量最大的時期俺祠，留存率顯著下降，是流失期。其中第一天的留存率被稱為“首日留存率”蜘渣。
蒸餾期——在經(jīng)過幾天大幅度流失后淌铐，用戶留存會進入小幅度下降時期，這就如同是蒸餾過程蔫缸，是蒸餾期腿准。
穩(wěn)定期——經(jīng)過一段時間蒸餾后，用戶留存會呈現(xiàn)出一種很穩(wěn)定的態(tài)勢拾碌，不會有明顯的增減吐葱，可稱為穩(wěn)定期，這段時間會保持較長時間校翔。
3.針對金融類APP弟跑，熱力圖顯示，同類金融APP共存性很低展融；which means窖认，下載下來就卸載的概率很高。
金融類APP使用的時間亦很短：
0x03 拋棄上面說的一切
上面是從卸載概率上分析了智能運營系統(tǒng)告希。那假設(shè)在冷啟動之后用戶沒卸載扑浸，度過了流失期的一兩天，智能運營系統(tǒng)能發(fā)揮多大的作用燕偶？
拋棄上面說的一切喝噪，真的要做智能運營系統(tǒng)，應(yīng)該怎么做指么？
行為-特性
前面說了酝惧，智能運營系統(tǒng)要做的是根據(jù)用戶行為改變APP特性。
從figure 1 中可以把各種卸載原因?qū)?yīng)的「行為」歸類伯诬。比如：
- 「在一個很長的頁面中快速滑動」這樣的行為（行為）晚唇，是否可以推測用戶對冗長頁面不感興趣（特性）。
- 用戶很少點擊某些模塊（行為）盗似，是否應(yīng)該把那些用戶從沒點擊過的模塊隱藏起來（特性）哩陕？
- 用戶從來沒有點開過推送消息（行為），是否應(yīng)該把推送頻率降低（特性）赫舒？
聚類分析悍及，可以對特性建模，使用某種算法對特性進行歸類接癌，計算特性之間的距離心赶；比如采用向量夾角的余弦值來表示兩個向量的相似程度，推測喜歡特性A的用戶也喜歡特性B缺猛。
這里的向量代表物品/內(nèi)容缨叫，也就是APP特性椭符。對APP特性打分，比如「不展示超過一屏的頁面」進行打分弯汰，
- 「快速滑動」記1分艰山，
- 「從不打開長頁面」記2分，
- 「在長頁面停留很久」記-1分咏闪，
- 「每次都滑動到長頁面的底部」記-2分曙搬。
夾角余弦 = 向量點積/ (向量長度的叉積) = ( x1x2 + y1y2 + z1z2) / ( 跟號(x1平方+y1平方+z1平方 ) x 跟號(x2平方+y2平方+z2平方 ) )
兩條線夾角越小那么兩條線越接近重合，就按照這個方法可以計算兩個APP特性的相似度鸽嫂。這樣就可以把距離近的特性推薦給用戶了纵装。
缺陷：純粹的「隱式的用戶反饋」
用余弦夾角計算物品相似度是可行的，但是用于APP的「智能運營」据某，不靠譜的地方在于很難「打分」橡娄，因為APP行為是純粹的「隱式的用戶反饋」。
- 顯式的用戶反饋：這類是用戶在網(wǎng)站上自然瀏覽或者使用網(wǎng)站以外癣籽，顯式的提供反饋信息挽唉，例如用戶對物品的評分，或者對物品的評論筷狼。
- 隱式的用戶反饋：這類是用戶在使用網(wǎng)站是產(chǎn)生的數(shù)據(jù)瓶籽，隱式的反應(yīng)了用戶對物品的喜好，例如用戶購買了某物品埂材，用戶查看了某物品的信息等等塑顺。
如果說對于購物網(wǎng)站，「用戶購買了某種物品」也只能歸為「隱式的反饋」俏险，那對于APP來說大部分行為估計連隱式反饋都算不上严拒，比如用戶的快速滑動這樣的反饋也許只是因為無聊而不是因為不喜歡。
*值得借鑒的是知乎APP右上角卡片的「不感興趣」竖独。那是顯式反饋裤唠。
更延伸的問題是，用戶見到的東西會可能越來越少莹痢，最后APP變成了一個跟PayPal一樣的極簡的應(yīng)用种蘸，這是運營的目的嗎？
推薦引擎
從一開始我就感覺這個很像推薦系統(tǒng)格二。把不同的物品(特性)推薦給不同的人。
但是真的可以這么類比（把APP特性類比成物品）嗎竣蹦？
推薦引擎的分類有很多顶猜，從不同角度看推薦引擎，可以把它們分成很多類痘括。
- 根據(jù)推薦引擎是不是給所有人推薦一樣的內(nèi)容**
- 大眾行為的推薦引擎：對于搜索引擎就不是為了給不同用戶推薦不同數(shù)據(jù)长窄，它只需要推薦跟搜索的詞語關(guān)聯(lián)最大的內(nèi)容滔吠。所有用戶看到的都一樣。
- 個性化推薦引擎：對于一些基于內(nèi)容的社交網(wǎng)站挠日，更多的是推薦個性化內(nèi)容疮绷。
對于SMARTSWITCH,顯然是選擇后者。
- 根據(jù)推薦引擎的數(shù)據(jù)源
- 基于人口統(tǒng)計學(xué)的推薦（Demographic-based Recommendation）
- 基于內(nèi)容的推薦（Content-based Recommendation）
- 基于協(xié)同過濾的推薦（Collaborative Filtering-based Recommendation）
- 根據(jù)推薦模型的建立方式
- 基于物品和用戶本身--->二維稀疏矩陣
- 基于關(guān)聯(lián)規(guī)則的推薦（Rule-based Recommendation） -->購物籃問題
- 基于模型的推薦（Model-based Recommendation） --> 將已有的用戶喜好信息作為訓(xùn)練樣本嚣潜，訓(xùn)練出一個預(yù)測用戶喜好的模型
其中冬骚，據(jù)我所知，第3點中的內(nèi)容已經(jīng)有點復(fù)雜懂算，「基于關(guān)聯(lián)規(guī)則的推薦」可以寫很多論文只冻，「 基于模型的推薦」涉及到機器學(xué)習(xí)，需要訓(xùn)練樣本计技；「基于物品和用戶本身」倒是可以利用二維矩陣推測一下喜德。
推薦算法有三種常用的基本套路。下面用音樂推薦舉例子垮媒。
- 基于內(nèi)容的推薦（content-based filtering）舍悯。(//www.zhihu.com/people/76ab4dd8c0bcba5634e6140e44c9129e) 的解釋，是音樂信息檢索的領(lǐng)域睡雇，學(xué)術(shù)上一般content-based是特指音頻內(nèi)容本身的萌衬，主要涉及feature extraction，專輯入桂、歌手和歌詞等基于text或tags的因素奄薇，通常用來與content相結(jié)合來提高檢索效率的。
2） 基于協(xié)同過濾推薦（collaboration filtering）抗愁∧俚伲基于廣義的排行榜行和熱門排行進行推薦。
3）社會化推薦（social recommendation）蜘腌∧牛基于關(guān)系的推薦。
這基本跟根據(jù)推薦引擎的數(shù)據(jù)源分類的推薦引擎一致撮珠，也很容易理解沮脖。具體我不介紹了，可以去http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html#ibm-pcon 了解芯急。
初步設(shè)想的方案
階段1.冷啟動(首次啟動勺届，沒有收集到行為)：
基于人口統(tǒng)計學(xué)的推薦。
根據(jù)用戶的屬性建模娶耍，比如性別免姿，年齡。
更少條件地榕酒，根據(jù)手機機型胚膊、地理位置建模故俐。
計算用戶之間的相似度。把每類用戶喜歡的物品推薦給對應(yīng)的人紊婉。這里的「物品」指的是APP使用偏好药版、UI簡繁、模塊多寡喻犁。
優(yōu)點：不依賴歷史數(shù)據(jù)槽片；不依賴物品屬性。
缺點：不夠準(zhǔn)確株汉，但非常重要筐乳，因為第一次就決定了用戶會不會繼續(xù)用。
階段2.產(chǎn)生行為之后：
基于內(nèi)容的推薦乔妈。
對物品（物品對應(yīng)APP想要動態(tài)調(diào)整的特性）建模蝙云。
注意，物品的屬性是物品固有的屬性路召，比如音樂的流派勃刨，歌手。不是用戶行為產(chǎn)生的股淡。
那么APP能調(diào)整的特性有哪些固有屬性身隐？
采用向量夾角的余弦值來表示兩個向量的相似程度？需要構(gòu)建向量唯灵。
或用其他公式計算物品之間的距離贾铝。
然后把A用戶喜歡的物品，推薦給B埠帕。
優(yōu)點：如果物品屬性的維度增加垢揩，準(zhǔn)確性會提高。
缺點：1.物品屬性有限的情況敛瓷。2.只考慮了物品叁巨。
基于協(xié)同過濾的推薦。
計算用戶和物品之間的相似度呐籽，比如這些計算相似度的方法锋勺。
我羅列出的有限的行為和物品：
A. 用戶
- 用戶基本信息。性別手機型號地理位置狡蝶。
B. 潛在因子(行為)
- 快速滑動長頁面/緩慢滑動頁面
- 短時間內(nèi)多次點擊操作/操作緩慢
- 從來沒有拉到底部過/經(jīng)常拉到底部
- 經(jīng)常點擊某些模塊/很少點擊某些模塊
- 右上角OPTIONMENU中的顯示反饋不感興趣
- 從不點開推送
- 只在某個時間段打開APP
- 打開APP后很快關(guān)閉
C. APP特性（物品）
- 首頁的AB 版本
- 推送頻率(難以體會到改變)
- 頁面復(fù)雜程度（模塊的展示與否）
總結(jié)一下
這個系統(tǒng)的問題庶橱，首先是能做哪些改變，也就是「物品」的缺失贪惹。無論是否是隱式反饋苏章，行為都可以收集一大堆，但是對應(yīng)的物品(APP特性)呢馍乙，有哪些是可以改變的布近，怎么改變，改變了有用嗎丝格，變來變?nèi)粫苌党徘疲恢肋@個就沒法建模。其次就是隱式反饋的不穩(wěn)定性帶來的噪音影響显蝌，做出的改變很可能是不準(zhǔn)確的多此一舉的预伺。
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
