APP全生命周期管理
編輯導語:近兩年來,行業管理變得更加規范和嚴格,眾多互聯網APP遇到了通報批評、整改、甚至下架的情況。對于產品經理來說,APP管理是必備技能。本篇文章作者將結合實際經驗對APP管理全流程進行詳細解讀,感興趣的小伙伴們快來一起看看吧。
2021年,眾多互聯網APP遇到了通報批評、整改、甚至下架的處理場景。
APP仿佛成為了一個“燙手山芋”,但他更是一個自己公司的“掌上明珠”。
從移動互聯網時代以來,APP成為了每個公司每個產品必備要素。
它成為了公司和產品觸達用戶,提供營銷和服務的最佳途徑。
通過建設自身的APP,有以下主要價值:
- 為用戶提供最優質的服務,只有自己的APP可以按照自己的規劃進行設計和開發,能夠滿足自身用戶真正的需求,帶來更優的用戶體驗。這是在公眾號、生活號等渠道無法做到的。
- 培養自身用戶群體,APP的用戶忠誠度和留存度更高,一般用戶不會隨意下載和卸載APP,比起小程序用戶用完即走的習慣,APP更能提升用戶忠誠度。
- 公司管理自身的APP,通過自己的APP對用戶進行營銷,可以更好的控制成本,提升收益。
當行業管理更加規范和嚴格,自身公司對于APP的管理也必須系統化,制度化,規范化,才能在市場中穩步運營,獲客展業。
對于產品經理來說,尤其是APP產品經理,APP管理是必備技能。包括APP上下架、版本規劃管理以及日常運營監控。本文將對APP管理全流程進行詳細解讀。
一、搭建APP管理團隊
APP需要有專門的團隊來管理,包括產品、運營、研發、測試、法務、管理等,每個角色承擔自己的責任,包括APP設計、申請、開發、內部審核、與應用市場溝通等。
在較大的公司中,可能會安排一個實體部門或者組織,進行專門的管理。
如果公司規模較小,也可以采用虛擬組織或者項目組的形式。
常規的APP管理團隊需要的角色及其對應的職責如下:
(1)產品團隊
產品團隊需要進行APP的整體把控,包括版本的迭代和各方的溝通協調,主要負責
- 統籌規劃APP版本
- 收集APP產品需求
- 組織體驗并驗收APP、回歸測試用例,確認APP達到上線標準
- 發起APP上線流程,同步周知運營、法務等各團隊,檢查相關敏感業務信息等
(2)運營團隊
運營團隊主要進行應用市場的賬號申請、上架,數據的跟進,包括:
- 申請并管理應用市場賬號
- 準備APP上架資料及信息
- 負責ASO、CPD等外部推廣的供應商管理及相關咨詢
- 跟蹤APP市場數據及應用市場評分等
(3)研發團隊
研發團隊主要負責APP的研發和打包,其中相關資質也需要同步處理,包括:
- APP版本需求的澄清、評審及開發
- 輸出APP版本APK包(Android)、IPA包(ios)
- 發起APP灰度測試,監控灰度數據并解決相關問題
- 負責研發相關資質的申請,例如軟著證書等
(4)測試團隊
測試團隊主要負責APP的測試,尤其是APP是否達到上線標準的檢測,包括
- APP版本需求的澄清、評審及測試
- 監控APP灰度測試數據,確認是否達到上線標準
(5)數據團隊
數據團隊主要負責數據指標的制定和監控,包括:
- 制定APP測試驗收的相關數據指標的及監控數據,確保滿足上線標準
- 制定APP上線后相關數據指標,協同運營跟蹤數據
在部分公司或者團隊,數據相關工作可由產品或者運營同事負責完成。
(6)法務團隊
法務團隊主要負責APP相當合規問題,包括:
- 審核并確認APP的宣傳用語、廣告用詞等合規內容
- 審核免責函等相關資質材料內容
(7)綜合管理團隊
綜合管理團隊主要負責公司相關的證書、營業執照等內容,在部分APP應用市場上架APP時,需要提供該內容,包括:
- 負責軟著證書申請
- 負責提供營業執照/許可證/免責函/ICP備案/法人資質等公司用印
二、APP上架
1. 上架決策
公司上架全新的APP前,需要經過嚴格的決策和審核,APP管理團隊需準備好相關材料,包括但不限于前期市場調研、可行性分析、產品策劃方案、APP版本計劃、業務說明、APP體驗包及APP法務合規報告等。
這些材料體現了一個完整的決策流程:
APP的上架依賴于公司多部門或組織的協同合作,需要驗證其外部市場需求價值,驗證內部的資源和盈利可行性,并且有明確的方案和執行計劃,最終還要由法務確認合規性和公司資質等問題。
在該決策過程中,需要通過郵件或者公司內部OA系統等,由涉及部門或組織負責人進行審核,最終輸出決策結論。
2. 上架流程
APP上架過程包含多個流程,其中運營材料準備、法務審核、灰度驗收、應用市場發布是幾大核心關鍵點。
3. 運營材料準備
運營人員需在各個應用市場完成賬號申請和管理,包括但不限于App Store(ios)、華為應用市場、應用寶、vivo應用商店、小米應用商店等。并管理各個渠道的渠道碼及賬號密碼。
然后需對APP發布所需的應用市場素材進行整理和準備,包括但不限于:
(1)APP軟件著作權登記:需按照軟件著作權文檔規范要求進行撰寫。
(2)ICP備案、營業執照等官方許可證:需帶公司蓋章的官方材料。
(3)隱私協議與權限:有部分應用市場要求說明是否有清晰的隱私協議,APP收集使用了哪些隱私權限。最好提供配APP的隱私協議截圖、鏈接,包含所收集的權限及應用說明。
(4)應用介紹:簡單介紹APP提供的服務內容。一般在1000字以下。需注意該介紹需符合廣告法等相關規定,由法務部門進行嚴格審核。
(5)應用更新介紹:APP新版本更新的內容說明,一般發布APP版本時,需同步告知用戶本次有何新的功能服務。同樣需由法務部門進行審核。
(6)icon素材圖片:每個APP都會有其專屬icon,但每個應用市場要求不一樣,需按照應用市場規定的圖片尺寸上傳素材。常見的應用市場icon尺寸和大小要求如下:
(注:以上內容僅供參考,實際操作時以應用市場最新要求為準)
(7)應用截圖:與icon類似,需按照應用市場規定的圖片尺寸上傳素材。常見的應用市場截圖尺寸和大小要求如下:
(注:以上內容僅供參考,實際操作時以應用市場最新要求為準)
應用市場截圖一般需要長*寬和寬*長的系列圖片,例如一般需要同時上傳480*800px和800*480px的圖片。
部分應用市場會要求不能使用其他手機品牌廠商的外觀,必須使用本手機品牌的外殼設計圖,包括應用圖片信息中的系統狀態欄禁止存在與本應用無關的第三方應用圖標等。
(8)測試賬號:有一些應用市場會要求提供業務測試賬號,應用市場審核時會使用測試賬號進行APP的體驗。所以需要準備能測試業務的賬號。
(9)廣告投放計劃和數據監控計劃:在APP上架后,需要進行APP的推廣,一般會進行推廣和搜索優化,例如ASO(App Store Optimization),CPD(Cost per Download)等,需要在前期就準備好廣告投放計劃以及對應的數據監控體系,以方便上架后及時跟蹤并調整。
4. 法務審核
在整個APP管理過程中,涉及APP應用市場材料上傳的審核、APP運營資質的審核,包括ICP備案、營業制造等。
因此,法務團隊需制定APP的法務合規管理手冊,并依據手冊嚴格審核管理。
如果出現被應用市場審核拒絕或者下架時,法務團隊也需要及時響應,根據對方提出的問題進行分析,必要時進行相關交涉。
對內提供支撐,對外進行對話,在當今市場,一個APP的管理離不開法務團隊的支持。
5. 灰度驗收
在APP正式上架前,一般需要先進行灰度驗收,即先上傳灰度包,待灰度包數據達標后,再正式發布版本至應用市場上線。
灰度階段是面向部分用戶投放應用,目的是驗證應用包的可用性及兼容性問題。正式階段是面向全量用戶投放正式的應用,目的是引導用戶升級到新的版本。
灰度階段有兩種方式:APP灰度——全量功能APP分發給部分用戶試用。
功能灰度——部分功能由后臺控制開關供部分用戶使用正式階段:經檢驗沒有問題的APP上傳到各應用市場,同時引導老用戶進行版本升級。
本文講述的灰度為APP灰度。
通常情況下灰度包通過的標準如下:
(1)灰度時長:48小時以上。
(2)灰度期間錯誤率:0.5%以內。
(3)灰度覆蓋用戶:
- 安卓:覆蓋20000 以上用戶
- iOS:覆蓋10000以上用戶
具體的標準數值與APP體量有關,需根據自身APP用戶數靈活制定。
同時,與版本的變更內容也有一定關系。如果是涉及核心流程改動的大版本,灰度時長和覆蓋率需更高,達到更高標準后,才可正式發布。
6. 應用市場發布
應用市場的發布,ios和Android存在些許不同。
ios需要輸出IPA包,Android渠道需輸出不同渠道的APK包。并且需要管理好不同渠道的APK包,根據業務需求,為監測不同渠道的數據,一般不同渠道的包體會有不同的渠道碼標識。
因為App Store審核時間較長,預計3至7天,所以一般發布新包時,是先將ios版本進行提審,再將Android版本提審。
發布后需及時關注審核和上架結果,如果一直未審核或審核不通過,需及時響應并與應用市場方進行溝通。
7. 異常場景
APP上架發布過程中可能遇到審核被拒駁回的情況,此時需由運營人員查看官方的駁回描述,結合問題分發至相關產品、研發等同事,通過一對一的方式針對性的處理駁回問題,待全部優化完成后重新上傳對應的審核駁回渠道包。
例如,產品相關問題與產品同事溝通,材料合規相關問題與法務同事溝通,營業執照等資質上傳問題與管理同事溝通。
除此之外,在日常運營中,APP團隊運營人員需定期了解各個應用市場渠道審核規則,并做好分類統籌,以便及時高效處理審核駁回問題。
待重新提交審核后通過微信、QQ、郵件等通訊方式告知應用市場渠道審核,并可以描述問題針對性地尋求解決方案等;如有需要,APP團隊運營人員需直接與應用市場渠道對接人進行對接,聯動雙方共同快速高效解決問題。
三、APP更新提示
APP新版本上線后,我們需要引導用戶進行更新。
因為在對大多數情況下,用戶會關閉應用自動更新,而APP新版本的功能又不一定能兼容舊版本。
此時,我們需要采取一定的措施,提示并引導用戶更新APP。
一般的APP更新提示策略有以下四種:
1. 強制升級
場景:強制升級一般只會出現在舊版本存在bug,嚴重影響用戶體驗的情況下。強制要求用戶必須更新使用新版本,才能繼續使用APP。
包括但不限于:
- 對重大風險、合規事件的優化;
- 對核心業務影響較大的問題修復;
- 對業務指標影響重大的功能更新。
除此之外,基于資源的合理利用和維護,一般APP維護版本有數量限制,例如不多于5個或10個。
當APP維護版本最多為5個時,就需要對低版本用戶啟動強更機制。
方法:打開APP即彈窗,要求用戶更新APP才能繼續使用。用戶如果拒絕或者關閉彈窗則關閉APP。
2. 強提示升級
場景:強提示升級一般在新版本發布后,功能較舊版本有較大提升,且與當前業務發展有緊密關系。
一般這種情況下會引導用戶升級體驗新的業務功能,但不升級也不會影響用戶基本使用。
例如,很多電商APP在雙十一或者618等大促開啟前會發布新版本,涵蓋大促的新玩法,引導用戶升級體驗。
方法:打開APP即彈窗,用戶可選擇更新版本或關閉彈窗。一般會對“立即更新”進行視覺強突出。同時彈窗頻率較高,或為每次打開APP,或為每天彈窗一次。
3. 弱提示升級
場景:弱提示升級一般在新版本發布后,功能較舊版本有一定提示,但無明顯的業務強關聯性或業務突出性,且對舊版本用戶的基本使用無影響。一般這種情況下,會進行弱提示升級。
方法:打開APP即彈窗,用戶可選擇更新版本或關閉彈窗。該彈窗頻率較低,或為僅為用戶彈出一次。
4. 不提示升級
場景:如果版本更新內容較少,且對用戶體驗影響較小,為了更好地用戶體驗,進行策略平衡,一般選擇不提示升級。但這種情況下也會告知用戶有新的版本。
方法:在版本信息的頁面及對應的tab頁有“小紅點”提示,告知用戶有新的版本。
除此之外,我們還可以針對部分版本,或者部分用戶進行提升升級。
例如,APP版本更新已到3.0版本,1.0版本已不滿足業務發展需要,但2.0版本仍能正常使用且不影響用戶體驗。
這種情況下,我們可以設置對仍使用1.0版本的用戶進行強制升級或者強提示升級,對于使用2.0版本的用戶僅弱提示升級或者不提示升級。
四、APP下架
APP有上架與更新,自然也會有下架。下架的原因有多種,包括因公司經營情況主動選擇下架,或者因為應用市場審查等原因被動下架。
如果是主動下架,則按照應用市場相關流程執行即可。
需要注意的是,當APP主動下架時,運營團隊需準備好業務遷移和用戶遷移方案。
例如,該APP下架,那么對應的用戶需要怎么經營,他們的業務需怎么維護。
需要在APP內有明確的公告和客服話術,平穩遷移其客戶和業務。避免造成對應的客訴,甚至法律糾紛。
如果是被動下架,則要明確下架原因。
如前文所述,APP上架或者更新版本時,需要提交隱私協議與權限素材。如果APP在該應用市場未達到其隱私協議要求,就會被該應用市場下架。
近些年互聯網監管日趨嚴格,這種被動情況并不罕見。面對這種情況,我們只能按照應用市場要求,完善用戶隱私協議的管理,修復完成再提交申請上架。
除此之外,APP store也有著非常嚴格的管理條例,比如視頻會員充值業務,就是蘋果高度敏感的業務范圍。
如果審核期間被蘋果發現APP中有這部分業務,就面臨被APP store下架的風險。
面對這種情況,只能與蘋果公司通過郵件積極溝通,并取消該部分業務的露出,修復完成再提交申請上架。
五、APP版本管理
一般情況下,APP版本的生命周期包括
- 版本規劃
- 需求收集
- 需求澄清
- 需求排期
- 需求研發
- 需求測試
- 需求驗收
- 版本灰度發布
- 版本正式上線
- 版本數據分析
始于版本規劃,終于數據分析。N+1版本的規劃,與N版本的數據分析是密不可分的。
假設一個版本的時間周期是2個月,那將以上版本周期節點套用在2個月時間周期中,大致如下圖所示。
以上情況適用于常規版本迭代,如果遇到緊急版本需要上線,例如發現重大bug或被應用市場要求整改等情況,則可壓縮版本管理時間。
一般情況下,涉及事故類的緊急版本,多在一到兩周內上線;僅涉及業務類的緊急版本,多在半個月至一個月內上線。
緊急版本的流程節點依然需要保持完整,但時間上進行壓縮。
六、APP日常運營
APP的日常運營主要包括應用市場運營和數據監控等。
1. 應用市場運營
應用市場運營包括日常的ASO排名優化,以及對于侵權盜版APP的檢查舉報。
(1)ASO排名優化
ASO(App store Optimization)就是提升你APP在各類APP應用商店/市場排行榜和搜索結果排名的過程。類似普通網站針對搜索引擎的優化,即SEO優化。
ASO優化就是利用APP Store的搜索規則和排名規則讓APP更容易被用戶搜索或看到。
通常我們說的ASO就是APP Store中的關鍵詞優化排名。重點在于關鍵詞搜索排名優化。
廣義上的ASO優化不僅針對APP Store,在安卓應用市場也是同理。做好ASO也就是要做好關鍵詞覆蓋。
從關鍵詞的語種、選擇到頻次,甚至針對不同應用市場,都會有不同的策略和選擇。具體的工作內容可由ASO團隊或專業供應商負責。
需注意,產品的更新頻率、更新日志內容對線上市場的推廣、Aso影響也比較大,正常情況下1—2周進行一個小版本的迭代,在同類關鍵詞中比較容易排名靠前。
(2)舉報盜版APP
現在的APP應用市場,尤其是安卓應用市場,存在很多名字高度相似的盜版APP,這部分APP對于官方正版APP而言,是侵權行為,對自身的品牌形象會造成負面影響。
由于應用市場存在些許漏洞,無法排查解決所有的侵權盜版問題。
所以有時候就需要我們對應用市場進行監控,對發現的侵權盜版APP及時舉報。
這部分工作同樣可由ASO團隊或專業供應商負責。
2. 數據監控
日常APP的數據監控包括了市場數據和內部數據。
(1)市場數據
市場數據即APP上架或更新版本后,在應用市場的表現。
首先,各個應用市場的下載量和安裝量是一定要監控到的,這是最直觀的的數據。
其次,可以通過專業的數據平臺,如易觀數據、百度指數觀測APP熱度。
一般情況下,易觀數據可用于觀測長時間段的數據,如一個月或者一個季度。百度指數可觀測用戶的實時搜索熱度。
(2)內部數據
內部數據指APP內的用戶行為數據,例如用戶的點擊數據、行為路徑、流量等,這些可通過在APP內的埋點來實現觀測。
尤其是對于新版本中的功能,在設計和開發時,必須要加入對應的埋點,以觀測功能上線后的數據變化,進而進行數據驗證和分析,對下一版本的功能規劃將有重要的指導意義。
七、總結
APP的管理存在諸多細節,其中的坑更是千奇百怪,曾經遇到過突然被莫名下架、也遇到過審核遲遲不過、數據對不齊等種種問題。
這些經驗讓我更加相信,一個APP完善的管理和維護,需要一個各司其職的團隊,需要一個暢通無阻的流程,需要一套詳細完整的機制。
如果您的APP管理仍存在問題和漏洞,希望本文可以給您一些幫助,也希望我們可以多多溝通,互相學習。
作者:球溜溜,微信公眾號:產品小球
本文由 @溜溜球 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
學習了!感謝普及了APP項目管理的一些范圍
點贊點贊
感謝感謝 多多交流
寫的很詳細,給作者點贊
感謝感謝 多多交流