A Research on SmartSwitch
0x01 什么是智能運營系統，有什么用
- SmartSwitch是我為「智能運營系統」取的代號。它是一個讓APP能夠自己「運營」自己的系統。
- 「運營」的范疇有點大，這里運營的是APP的特性、呈現方式，比如AB版本，頁面繁簡，推送策略；而不是具體的業務內容，比如某條新聞，某項業務。
- 目的：讓用戶不「卸載」APP?！覆恍遁d」意味著讓人不討厭。
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）?；趶V義的排行榜行和熱門排行進行推薦。
3）社會化推薦（social recommendation）?；陉P系的推薦。
這基本跟根據推薦引擎的數據源分類的推薦引擎一致，也很容易理解。具體我不介紹了，可以去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
