关于配置化的版本更新引导，笔者将从几个方面为大家详细讲述：什么是配置化版本更新引导？为什么要做配置化？怎么做配置化更新引导？以及一些人工培植的协作流程是如何的？
目录
为什么要做配置化？
一些用户体验上的优化点
涉及人工配置，协作流程是怎么样的？
关于强制更新
最后，踩过的一个坑及避坑指南
这里的“配置化的版本更新引导”是指：使用中台配置的方式，来为迭代过程中，不同的内容不同重要性的版本，量身定制引导更新的方式，降低对用户的骚扰，并避免用户陷入“更新麻木”状态中，同时保证一定的更新率。
一般来说，需要配置的内容主要有以下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…
经过这件事后，我们的迭代策略调整为：基础性的需求，较小的就直接混搭到各个业务需求中，买一送一 一起做，较大的则按照其优先级。排进业务需求的空隙或单独拎出来作为一个需求，保证每个月的计划中，一定可以排上几个看似“不重要不紧急”基础需求。这样既可不耽误业务需求，也避免后面要补的坑太多。
有时候，绊倒你的，不是天上的星辰，而是地上你没填的坑。
