關(guān)于配置化的版本更新引導(dǎo)，筆者將從幾個方面為大家詳細(xì)講述：什么是配置化版本更新引導(dǎo)？為什么要做配置化？怎么做配置化更新引導(dǎo)？以及一些人工培植的協(xié)作流程是如何的？

目錄

1. 什么是配置化的版本更新引導(dǎo)？
2. 為什么要做配置化？
3. 配置化的版本更新提示怎么做？
4. 一些用戶體驗上的優(yōu)化點
5. 涉及人工配置，協(xié)作流程是怎么樣的？
6. 關(guān)于強制更新
7. 最后，踩過的一個坑及避坑指南

一、什么是配置化的版本更新引導(dǎo)？

這里的“配置化的版本更新引導(dǎo)”是指：使用中臺配置的方式，來為迭代過程中，不同的內(nèi)容不同重要性的版本，量身定制引導(dǎo)更新的方式，降低對用戶的騷擾，并避免用戶陷入“更新麻木”狀態(tài)中，同時保證一定的更新率。

配置化的版本更新引導(dǎo)與一刀切式的更新引導(dǎo)相對。

一般來說，需要配置的內(nèi)容主要有以下3種：

1. 引導(dǎo)更新的方式配置
2. 強制更新配置
3. 新版本更新內(nèi)容和版本信息

本文主要講引導(dǎo)更新方式配置化。

二、為什么要做配置化？

不同的版本更新內(nèi)容不同，有些是新功能發(fā)布，有些是重大bug修復(fù)；有些則是小細(xì)節(jié)優(yōu)化，版本的重要性不同，不同用戶的版本情況也不同，這就意味著不能用一種固定式的更新提醒。
例如：如果每次新版本發(fā)布都用APP內(nèi)的彈窗去提示用戶，在版本更新頻率較高的情況下，一來會對用戶造成比較強的打擾；二來很容易出現(xiàn)“狼來了”的情況（即當(dāng)用戶對更新提示習(xí)慣性麻木后，遇到真正重要的版本，也會習(xí)慣性地忽略掉而不更新）。

三、配置化的版本更新提示怎么做？

不同重要性版本的提示方式應(yīng)有不同，常見的版本的提示方式有：APP內(nèi)彈窗、badge引導(dǎo)，其中，badge引導(dǎo)又分為主tab badge和“檢查更新”菜單badge。

例如：版本依據(jù)重要性劃分為1、2、3三個等級，數(shù)字越低代表重要程度越高。

則不同重要性的版本的提示方式如下（重要性高的提示方式包含重要性低的提示方式，如使用彈窗時會同時使用badge引導(dǎo)）：

重要性1：APP內(nèi)彈窗

APP內(nèi)彈窗的提示強度較高，適用于非常期望用戶更新的版本，例如新功能上線、已有功能做了比較大的優(yōu)化等場景下。

重要性2：主tab badge

主tab badge提示的強度弱于APP內(nèi)彈窗，適用于期望用戶更新的版本，例如：功能的優(yōu)化，bug的修復(fù)等。

重要性3：“檢查更新”菜單badge

提示強度最弱，對用戶更新版本的期望程度一般。適用于修復(fù)bug的小版本。

配置時，根據(jù)版本的重要性定義，為該版本配置相應(yīng)的展示方式。

舉個例子：新版本上線了一個可重要的運營活動，用戶需更新方能參與，則此時以使用APP內(nèi)彈窗的方式提示用戶。

若新版本優(yōu)化了一些細(xì)節(jié)的體驗，修復(fù)了一些bug，用戶是否更新影響不大，此時在“檢查新版本”菜單處標(biāo)識badge，愿意升級的用戶主動點擊即可。

版本的重要性如何去定義？

從產(chǎn)品自身來說：每個產(chǎn)品團隊內(nèi)部都會有自己的一套需求的評估模型，將需求池中的需求通過此模型確定好重要性和優(yōu)先級后，則需求本身的重要性就是對應(yīng)版本的重要性。
從用戶角度來說：大部分用戶常用的或期待的功能，重要性往往也會比較高。

四、一些用戶體驗上的優(yōu)化點

1. 允許用戶勾選“忽略該版本”

允許忽略的邏輯是：如果用戶在更新彈窗上勾選“忽略該版本”，則該版本的更新彈窗對該設(shè)備不再展示；否則彈窗依舊按既定規(guī)則彈出，如每天首次打開APP時彈出。

這個優(yōu)化點的用戶場景是：雖然這個版本在產(chǎn)品內(nèi)部的定義為很重要（因為已經(jīng)用到首頁彈窗去強提醒用戶），但是用戶閱讀更新提示后，覺得對自己并不重要，所以決定不更新該版本。此時把選擇權(quán)交給用戶，比起每天傻瓜式地彈出提醒，雖損失了一定更新率，但是無形中也降低了用戶的不滿和卸載率。

類似的方式還有：用戶對某版本選擇不升級的次數(shù)達(dá)到一定值時，不再對用戶提示該版本等。

2. 不同網(wǎng)絡(luò)環(huán)境下的邏輯

如用戶當(dāng)前所處的網(wǎng)絡(luò)環(huán)境為WiFi環(huán)境，在更新彈窗上提示W(wǎng)iFi環(huán)境會降低用戶更新的負(fù)擔(dān)，繼而增加更新率；若用戶處于移動網(wǎng)絡(luò)環(huán)境，此時彈窗上可以提示預(yù)計消耗的流量。如果是應(yīng)用內(nèi)更新，則最好是在點擊更新后讓用戶二次確認(rèn)是否更新，或者允許用戶在通知欄操作暫停下載。

3. 包的大小

如無必要，盡量以“瘦”為美。看到一個一百多M的APP，想到下載要一分鐘，安裝要半分鐘，可能流量還要耗掉幾塊錢，愿意更新的恐怕就是真愛了。

4. 更新彈窗視覺上及文案上的優(yōu)化

文案上盡量避免使用技術(shù)上的描述詞匯，如“修復(fù)了xxx的bug”，有些用戶可能并不知道“bug”是什么意思；另外，精簡和說人話的文案總是優(yōu)于長篇大論和任務(wù)式的描述。
視覺上嘛，舉個例子：對于大部分用戶來說，即使知道賣相好的果子很可能是在農(nóng)藥的懷抱里長大的，依舊會選擇它們而不是那些歪瓜裂棗。既然已經(jīng)呈現(xiàn)到用戶面前，用點心打扮好看點總是沒錯的。

5. WiFi下靜默下載

相對于提示有新版本可下載，直接下載好了提示用戶安裝，用戶的決策成本會被降低，更新率會更高。

不過此操作只有Android版本可以做到，另需注意提示安裝的時機以及用戶未安裝下載的版本而又有新版時的邏輯處理。

五、涉及人工配置，協(xié)作流程是怎么樣的？

版本更新配置化的優(yōu)點是：延展性強，缺點是強依賴人工。

版本上線涉及多人或多部門協(xié)作，如開發(fā)部門打包、QA部門驗收、產(chǎn)品和設(shè)計部門驗收、市場部門發(fā)版、運營部門驗收線上版本及配置更新提示等等，如果協(xié)作流程不順暢，其結(jié)果一定是一言難盡。

不同公司不同團隊，有不同的協(xié)作風(fēng)格和協(xié)作流程，沒有最好的流程，只有最適合的流程。

舉個例子：需求在策劃前就已有了重要性的評估，那么在開發(fā)完成后測試通過前，產(chǎn)品及運營就應(yīng)確定本次提示用戶更新的方式并準(zhǔn)備好相關(guān)素材，并在市場發(fā)版前完成配置并檢查無誤，待版本審核通過后，再分渠道驗證一遍線上的更新流程。

六、關(guān)于強制更新

強制更新的邏輯簡單粗暴：不更新就不讓用。

這個時候，往往解決問題的優(yōu)先級大于用戶體驗，所以無論怎么做都會傷害用戶，只是傷得重還是傷得輕而已。所以，強制更新一定要慎用，否則很容易殺敵一千自損八百，強制更新的使用場景一般有兩種：某版本有重大bug、低版本不再維護(hù)。

七、最后，分享一個踩過的坑

最近在從0到1做一個產(chǎn)品，一開始的計劃是先快速推出MVP去市場試錯，由于資源比較有限（人員、時間等），對于完善基礎(chǔ)設(shè)施的需求（如用戶觸達(dá)和版本更新提示等），團隊內(nèi)部的評估結(jié)果是“不重要不緊急”，所以優(yōu)先級定得比較低。

由于后面主要資源都投放在嘗試業(yè)務(wù)需求和穩(wěn)定產(chǎn)品功能上，導(dǎo)致這些基礎(chǔ)性需求一直排不上期。

堆積到后來就成了，但是由于缺乏用戶觸達(dá)體系，沒有有效的方式可以提示用戶更新版本（后來緊急做了遠(yuǎn)程push），APP內(nèi)也沒有檢測新版本的功能。一次，一個早期的版本出現(xiàn)了一個比較嚴(yán)重bug，用戶直接怒而差評，生生把產(chǎn)品的Google Play評分從4.5拉到了3.2…

經(jīng)過這件事后，我們的迭代策略調(diào)整為：基礎(chǔ)性的需求，較小的就直接混搭到各個業(yè)務(wù)需求中，買一送一 一起做，較大的則按照其優(yōu)先級。排進(jìn)業(yè)務(wù)需求的空隙或單獨拎出來作為一個需求，保證每個月的計劃中，一定可以排上幾個看似“不重要不緊急”基礎(chǔ)需求。這樣既可不耽誤業(yè)務(wù)需求，也避免后面要補的坑太多。

有時候，絆倒你的，不是天上的星辰，而是地上你沒填的坑。

作者：曳尾，兩年運營汪，新入產(chǎn)品坑（微信號：DouhaoTravel），不完善之處，歡迎補充。

本文由 @曳尾 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。