「七千字心得」APP全生命周期管理（全生命周期管理軟件）

2021年，眾多互聯(lián)網APP遇到了通報批評、整改、甚至下架的處理場景。APP仿佛成為了一個“燙手山芋”，但他更是一個自己公司的“掌上明珠”。

從移動互聯(lián)網時代以來，APP成為了每個公司每個產品必備要素。它成為了公司和產品觸達用戶，提供營銷和服務的最佳途徑。

?通過建設自身的APP，有以下主要價值：

1、為用戶提供最優(yōu)質的服務，只有自己的APP可以按照自己的規(guī)劃進行設計和開發(fā)，能夠滿足自身用戶真正的需求，帶來更優(yōu)的用戶體驗。這是在公眾號、生活號等渠道無法做到的。

2、培養(yǎng)自身用戶群體，APP的用戶忠誠度和留存度更高，一般用戶不會隨意下載和卸載APP，比起小程序用戶用完即走的習慣，APP更能提升用戶忠誠度。

3、公司管理自身的APP，通過自己的APP對用戶進行營銷，可以更好的控制成本，提升收益。

當行業(yè)管理更加規(guī)范和嚴格，自身公司對于APP的管理也必須系統(tǒng)化，制度化，規(guī)范化，才能在市場中穩(wěn)步運營，獲客展業(yè)。

對于產品經理來說，尤其是APP產品經理，APP管理是必備技能。包括APP上下架、版本規(guī)劃管理以及日常運營監(jiān)控。本文將對APP管理全流程進行詳細解讀。

一、搭建APP管理團隊

APP需要有專門的團隊來管理，包括產品、運營、研發(fā)、測試、法務、管理等，每個角色承擔自己的責任，包括APP設計、申請、開發(fā)、內部審核、與應用市場溝通等。

在較大的公司中，可能會安排一個實體部門或者組織，進行專門的管理。如果公司規(guī)模較小，也可以采用虛擬組織或者項目組的形式。

常規(guī)的APP管理團隊需要的角色及其對應的職責如下：

1.產品團隊

產品團隊需要進行APP的整體把控，包括版本的迭代和各方的溝通協(xié)調，主要負責

• • 統(tǒng)籌規(guī)劃APP版本

  • 收集APP產品需求

  • 組織體驗并驗收APP、回歸測試用例，確認APP達到上線標準

  • 發(fā)起APP上線流程，同步周知運營、法務等各團隊，檢查相關敏感業(yè)務信息等

2.運營團隊

運營團隊主要進行應用市場的賬號申請、上架，數據的跟進，包括：

• • 申請并管理應用市場賬號

  • 準備APP上架資料及信息

  • 負責ASO、CPD等外部推廣的供應商管理及相關咨詢

  • 跟蹤APP市場數據及應用市場評分等

3.研發(fā)團隊

研發(fā)團隊主要負責APP的研發(fā)和打包，其中相關資質也需要同步處理，包括：

• • APP版本需求的澄清、評審及開發(fā)

  • 輸出APP版本APK包（Android）、IPA包（ios）

  • 發(fā)起APP灰度測試，監(jiān)控灰度數據并解決相關問題

  • 負責研發(fā)相關資質的申請，例如軟著證書等

4.測試團隊

測試團隊主要負責APP的測試，尤其是APP是否達到上線標準的檢測，包括

• • APP版本需求的澄清、評審及測試

  • 監(jiān)控APP灰度測試數據，確認是否達到上線標準

5.數據團隊

數據團隊主要負責數據指標的制定和監(jiān)控，包括：

• • 制定APP測試驗收的相關數據指標的及監(jiān)控數據，確保滿足上線標準

  • 制定APP上線后相關數據指標，協(xié)同運營跟蹤數據

在部分公司或者團隊，數據相關工作可由產品或者運營同事負責完成。

6.法務團隊

法務團隊主要負責APP相當合規(guī)問題，包括：

• • 審核并確認APP的宣傳用語、廣告用詞等合規(guī)內容

  • 審核免責函等相關資質材料內容

7.綜合管理團隊

綜合管理團隊主要負責公司相關的證書、營業(yè)執(zhí)照等內容，在部分APP應用市場上架APP時，需要提供該內容，包括：

• • 負責軟著證書申請

  • 負責提供營業(yè)執(zhí)照/許可證/免責函/ICP備案/法人資質等公司用印

二、APP上架

1.上架決策

公司上架全新的APP前，需要經過嚴格的決策和審核，APP管理團隊需準備好相關材料，包括但不限于前期市場調研、可行性分析、產品策劃方案、APP版本計劃、業(yè)務說明、APP體驗包及APP法務合規(guī)報告等。

這些材料體現了一個完整的決策流程：

APP的上架依賴于公司多部門或組織的協(xié)同合作，需要驗證其外部市場需求價值，驗證內部的資源和盈利可行性，并且有明確的方案和執(zhí)行計劃，最終還要由法務確認合規(guī)性和公司資質等問題。

在該決策過程中，需要通過郵件或者公司內部OA系統(tǒng)等，由涉及部門或組織負責人進行審核，最終輸出決策結論。

2.上架流程

APP上架過程包含多個流程，其中運營材料準備、法務審核、灰度驗收、應用市場發(fā)布是幾大核心關鍵點。

3.運營材料準備

運營人員需在各個應用市場完成賬號申請和管理，包括但不限于App Store（ios）、華為應用市場、應用寶、vivo應用商店、小米應用商店等。并管理各個渠道的渠道碼及賬號密碼。

然后需對APP發(fā)布所需的應用市場素材進行整理和準備，包括但不限于：

1)APP軟件著作權登記：需按照軟件著作權文檔規(guī)范要求進行撰寫。

2)ICP備案、營業(yè)執(zhí)照等官方許可證：需帶公司蓋章的官方材料。

3)隱私協(xié)議與權限：有部分應用市場要求說明是否有清晰的隱私協(xié)議，APP收集使用了哪些隱私權限。最好提供配APP的隱私協(xié)議截圖、鏈接，包含所收集的權限及應用說明。

4)應用介紹：簡單介紹APP提供的服務內容。一般在1000字以下。需注意該介紹需符合廣告法等相關規(guī)定，由法務部門進行嚴格審核。

5)應用更新介紹：APP新版本更新的內容說明，一般發(fā)布APP版本時，需同步告知用戶本次有何新的功能服務。同樣需由法務部門進行審核。

6)icon素材圖片：每個APP都會有其專屬icon，但每個應用市場要求不一樣，需按照應用市場規(guī)定的圖片尺寸上傳素材。常見的應用市場icon尺寸和大小要求如下：

（注：以上內容僅供參考，實際操作時以應用市場最新要求為準）

7)應用截圖：與icon類似，需按照應用市場規(guī)定的圖片尺寸上傳素材。常見的應用市場截圖尺寸和大小要求如下：

（注：以上內容僅供參考，實際操作時以應用市場最新要求為準）

應用市場截圖一般需要長*寬和寬*長的系列圖片，例如一般需要同時上傳480*800px和800*480px的圖片。

部分應用市場會要求不能使用其他手機品牌廠商的外觀，必須使用本手機品牌的外殼設計圖，包括應用圖片信息中的系統(tǒng)狀態(tài)欄禁止存在與本應用無關的第三方應用圖標等。

8)測試賬號：有一些應用市場會要求提供業(yè)務測試賬號，應用市場審核時會使用測試賬號進行APP的體驗。所以需要準備能測試業(yè)務的賬號。

9)廣告投放計劃和數據監(jiān)控計劃：在APP上架后，需要進行APP的推廣，一般會進行推廣和搜索優(yōu)化，例如ASO（App Store Optimization），CPD（Cost per Download）等，需要在前期就準備好廣告投放計劃以及對應的數據監(jiān)控體系，以方便上架后及時跟蹤并調整。

4.法務審核

在整個APP管理過程中，涉及APP應用市場材料上傳的審核、APP運營資質的審核，包括ICP備案、營業(yè)制造等。因此，法務團隊需制定APP的法務合規(guī)管理手冊，并依據手冊嚴格審核管理。

如果出現被應用市場審核拒絕或者下架時，法務團隊也需要及時響應，根據對方提出的問題進行分析，必要時進行相關交涉。

對內提供支撐，對外進行對話，在當今市場，一個APP的管理離不開法務團隊的支持。

5.灰度驗收

在APP正式上架前，一般需要先進行灰度驗收，即先上傳灰度包，待灰度包數據達標后，再正式發(fā)布版本至應用市場上線。

灰度階段是面向部分用戶投放應用，目的是驗證應用包的可用性及兼容性問題。正式階段是面向全量用戶投放正式的應用，目的是引導用戶升級到新的版本。灰度階段有兩種方式：APP灰度——全量功能APP分發(fā)給部分用戶試用。功能灰度——部分功能由后臺控制開關供部分用戶使用正式階段：經檢驗沒有問題的APP上傳到各應用市場，同時引導老用戶進行版本升級。本文講述的灰度為APP灰度。

通常情況下灰度包通過的標準如下：

1)灰度時長：48小時以上。

2）灰度期間錯誤率：0.5%以內。

3）灰度覆蓋用戶：

• • 安卓：覆蓋20000 以上用戶

  • iOS：覆蓋10000以上用戶

具體的標準數值與APP體量有關，需根據自身APP用戶數靈活制定。同時，與版本的變更內容也有一定關系。如果是涉及核心流程改動的大版本，灰度時長和覆蓋率需更高，達到更高標準后，才可正式發(fā)布。

6.應用市場發(fā)布

應用市場的發(fā)布，ios和Android存在些許不同。

ios需要輸出IPA包，Android渠道需輸出不同渠道的APK包。并且需要管理好不同渠道的APK包，根據業(yè)務需求，為監(jiān)測不同渠道的數據，一般不同渠道的包體會有不同的渠道碼標識。

因為App Store審核時間較長，預計3至7天，所以一般發(fā)布新包時，是先將ios版本進行提審，再將Android版本提審。

發(fā)布后需及時關注審核和上架結果，如果一直未審核或審核不通過，需及時響應并與應用市場方進行溝通。

7.異常場景

APP上架發(fā)布過程中可能遇到審核被拒駁回的情況，此時需由運營人員查看官方的駁回描述，結合問題分發(fā)至相關產品、研發(fā)等同事，通過一對一的方式針對性的處理駁回問題，待全部優(yōu)化完成后重新上傳對應的審核駁回渠道包。例如，產品相關問題與產品同事溝通，材料合規(guī)相關問題與法務同事溝通，營業(yè)執(zhí)照等資質上傳問題與管理同事溝通。

除此之外，在日常運營中，APP團隊運營人員需定期了解各個應用市場渠道審核規(guī)則，并做好分類統(tǒng)籌，以便及時高效處理審核駁回問題。待重新提交審核后通過微信、QQ、郵件等通訊方式告知應用市場渠道審核，并可以描述問題針對性地尋求解決方案等；如有需要，APP團隊運營人員需直接與應用市場渠道對接人進行對接，聯(lián)動雙方共同快速高效解決問題。

三、APP更新提示

APP新版本上線后，我們需要引導用戶進行更新。因為在對大多數情況下，用戶會關閉應用自動更新，而APP新版本的功能又不一定能兼容舊版本。此時，我們需要采取一定的措施，提示并引導用戶更新APP。

一般的APP更新提示策略有以下四種：

1.強制升級

場景：強制升級一般只會出現在舊版本存在bug，嚴重影響用戶體驗的情況下。強制要求用戶必須更新使用新版本，才能繼續(xù)使用APP。包括但不限于：

• • 對重大風險、合規(guī)事件的優(yōu)化；

  • 對核心業(yè)務影響較大的問題修復；

  • 對業(yè)務指標影響重大的功能更新。

除此之外，基于資源的合理利用和維護，一般APP維護版本有數量限制，例如不多于5個或10個。當APP維護版本最多為5個時，就需要對低版本用戶啟動強更機制。

方法：打開APP即彈窗，要求用戶更新APP才能繼續(xù)使用。用戶如果拒絕或者關閉彈窗則關閉APP。

2.強提示升級

場景：強提示升級一般在新版本發(fā)布后，功能較舊版本有較大提升，且與當前業(yè)務發(fā)展有緊密關系。一般這種情況下會引導用戶升級體驗新的業(yè)務功能，但不升級也不會影響用戶基本使用。例如，很多電商APP在雙十一或者618等大促開啟前會發(fā)布新版本，涵蓋大促的新玩法，引導用戶升級體驗。

方法：打開APP即彈窗，用戶可選擇更新版本或關閉彈窗。一般會對“立即更新”進行視覺強突出。同時彈窗頻率較高，或為每次打開APP，或為每天彈窗一次。

3.弱提示升級

場景：弱提示升級一般在新版本發(fā)布后，功能較舊版本有一定提示，但無明顯的業(yè)務強關聯(lián)性或業(yè)務突出性，且對舊版本用戶的基本使用無影響。一般這種情況下，會進行弱提示升級。

方法：打開APP即彈窗，用戶可選擇更新版本或關閉彈窗。該彈窗頻率較低，或為僅為用戶彈出一次。

4.不提示升級

場景：如果版本更新內容較少，且對用戶體驗影響較小，為了更好地用戶體驗，進行策略平衡，一般選擇不提示升級。但這種情況下也會告知用戶有新的版本。

方法：在版本信息的頁面及對應的tab頁有“小紅點”提示，告知用戶有新的版本。

除此之外，我們還可以針對部分版本，或者部分用戶進行提升升級。例如，APP版本更新已到3.0版本，1.0版本已不滿足業(yè)務發(fā)展需要，但2.0版本仍能正常使用且不影響用戶體驗。這種情況下，我們可以設置對仍使用1.0版本的用戶進行強制升級或者強提示升級，對于使用2.0版本的用戶僅弱提示升級或者不提示升級。

四、APP下架

APP有上架與更新，自然也會有下架。下架的原因有多種，包括因公司經營情況主動選擇下架，或者因為應用市場審查等原因被動下架。

如果是主動下架，則按照應用市場相關流程執(zhí)行即可。

需要注意的是，當APP主動下架時，運營團隊需準備好業(yè)務遷移和用戶遷移方案。例如，該APP下架，那么對應的用戶需要怎么經營，他們的業(yè)務需怎么維護。需要在APP內有明確的公告和客服話術，平穩(wěn)遷移其客戶和業(yè)務。避免造成對應的客訴，甚至法律糾紛。

如果是被動下架，則要明確下架原因。

如前文所述，APP上架或者更新版本時，需要提交隱私協(xié)議與權限素材。如果APP在該應用市場未達到其隱私協(xié)議要求，就會被該應用市場下架。近些年互聯(lián)網監(jiān)管日趨嚴格，這種被動情況并不罕見。面對這種情況，我們只能按照應用市場要求，完善用戶隱私協(xié)議的管理，修復完成再提交申請上架。

除此之外，APP store也有著非常嚴格的管理條例，比如視頻會員充值業(yè)務，就是蘋果高度敏感的業(yè)務范圍。如果審核期間被蘋果發(fā)現APP中有這部分業(yè)務，就面臨被APP store下架的風險。面對這種情況，只能與蘋果公司通過郵件積極溝通，并取消該部分業(yè)務的露出，修復完成再提交申請上架。

五、APP版本管理

一般情況下，APP版本的生命周期包括

1.版本規(guī)劃

2.需求收集

3.需求澄清

4.需求排期

5.需求研發(fā)

6.需求測試

7.需求驗收

8.版本灰度發(fā)布

9.版本正式上線

10.版本數據分析

始于版本規(guī)劃，終于數據分析。N 1版本的規(guī)劃，與N版本的數據分析是密不可分的。

假設一個版本的時間周期是2個月，那將以上版本周期節(jié)點套用在2個月時間周期中，大致如下圖所示。

以上情況適用于常規(guī)版本迭代，如果遇到緊急版本需要上線，例如發(fā)現重大bug或被應用市場要求整改等情況，則可壓縮版本管理時間。一般情況下，涉及事故類的緊急版本，多在一到兩周內上線；僅涉及業(yè)務類的緊急版本，多在半個月至一個月內上線。緊急版本的流程節(jié)點依然需要保持完整，但時間上進行壓縮。

六、APP日常運營

APP的日常運營主要包括應用市場運營和數據監(jiān)控等。

1.應用市場運營

應用市場運營包括日常的ASO排名優(yōu)化，以及對于侵權盜版APP的檢查舉報。

1)ASO排名優(yōu)化

ASO(App store Optimization)就是提升你APP在各類APP應用商店/市場排行榜和搜索結果排名的過程。類似普通網站針對搜索引擎的優(yōu)化，即SEO優(yōu)化。ASO優(yōu)化就是利用APP Store的搜索規(guī)則和排名規(guī)則讓APP更容易被用戶搜索或看到。通常我們說的ASO就是APP Store中的關鍵詞優(yōu)化排名。重點在于關鍵詞搜索排名優(yōu)化。

廣義上的ASO優(yōu)化不僅針對APP Store，在安卓應用市場也是同理。做好ASO也就是要做好關鍵詞覆蓋。從關鍵詞的語種、選擇到頻次，甚至針對不同應用市場，都會有不同的策略和選擇。具體的工作內容可由ASO團隊或專業(yè)供應商負責。

需注意，產品的更新頻率、更新日志內容對線上市場的推廣、Aso影響也比較大，正常情況下1—2周進行一個小版本的迭代，在同類關鍵詞中比較容易排名靠前。

2)舉報盜版APP

現在的APP應用市場，尤其是安卓應用市場，存在很多名字高度相似的盜版APP，這部分APP對于官方正版APP而言，是侵權行為，對自身的品牌形象會造成負面影響。由于應用市場存在些許漏洞，無法排查解決所有的侵權盜版問題。所以有時候就需要我們對應用市場進行監(jiān)控，對發(fā)現的侵權盜版APP及時舉報。這部分工作同樣可由ASO團隊或專業(yè)供應商負責。

2.數據監(jiān)控

日常APP的數據監(jiān)控包括了市場數據和內部數據。

1)市場數據

市場數據即APP上架或更新版本后，在應用市場的表現。

首先，各個應用市場的下載量和安裝量是一定要監(jiān)控到的，這是最直觀的的數據。

其次，可以通過專業(yè)的數據平臺，如易觀數據、百度指數觀測APP熱度。一般情況下，易觀數據可用于觀測長時間段的數據，如一個月或者一個季度。百度指數可觀測用戶的實時搜索熱度。

2)內部數據

內部數據指APP內的用戶行為數據，例如用戶的點擊數據、行為路徑、流量等，這些可通過在APP內的埋點來實現觀測。尤其是對于新版本中的功能，在設計和開發(fā)時，必須要加入對應的埋點，以觀測功能上線后的數據變化，進而進行數據驗證和分析，對下一版本的功能規(guī)劃將有重要的指導意義。

七、總結

APP的管理存在諸多細節(jié)，其中的坑更是千奇百怪，曾經遇到過突然被莫名下架、也遇到過審核遲遲不過、數據對不齊等種種問題。這些經驗讓我更加相信，一個APP完善的管理和維護，需要一個各司其職的團隊，需要一個暢通無阻的流程，需要一套詳細完整的機制。

如果您的APP管理仍存在問題和漏洞，希望本文可以給您一些幫助，也希望我們可以多多溝通，互相學習。

歡迎關注個人公眾號：【產品小球】