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

目錄

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

一、什么是配置化的版本更新引導？

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

配置化的版本更新引導與一刀切式的更新引導相對。

一般來說，需要配置的內容主要有以下3種：

1. 引導更新的方式配置
2. 強制更新配置
3. 新版本更新內容和版本信息

本文主要講引導更新方式配置化。

二、為什么要做配置化？

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

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

不同重要性版本的提示方式應有不同，常見的版本的提示方式有：APP內彈窗、badge引導，其中，badge引導又分為主tab badge和“檢查更新”菜單badge。

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

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

重要性1：APP內彈窗

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

重要性2：主tab badge

主tab badge提示的強度弱于APP內彈窗，適用于期望用戶更新的版本，例如：功能的優化，bug的修復等。

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

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

配置時，根據版本的重要性定義，為該版本配置相應的展示方式。

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

若新版本優化了一些細節的體驗，修復了一些bug，用戶是否更新影響不大，此時在“檢查新版本”菜單處標識badge，愿意升級的用戶主動點擊即可。

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

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

四、一些用戶體驗上的優化點

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

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

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

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

2. 不同網絡環境下的邏輯

如用戶當前所處的網絡環境為WiFi環境，在更新彈窗上提示WiFi環境會降低用戶更新的負擔，繼而增加更新率；若用戶處于移動網絡環境，此時彈窗上可以提示預計消耗的流量。如果是應用內更新，則最好是在點擊更新后讓用戶二次確認是否更新，或者允許用戶在通知欄操作暫停下載。

3. 包的大小

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

4. 更新彈窗視覺上及文案上的優化

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

5. WiFi下靜默下載

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

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

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

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

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

不同公司不同團隊，有不同的協作風格和協作流程，沒有最好的流程，只有最適合的流程。

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

六、關于強制更新

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

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

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

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

由于后面主要資源都投放在嘗試業務需求和穩定產品功能上，導致這些基礎性需求一直排不上期。

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

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

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

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

本文由 @曳尾 原創發布于人人都是產品經理。未經許可，禁止轉載。