App 上架发布检查清单|从审核提交到公开通知的关卡管理

项目管理与开发

App 上架发布检查清单|从审核提交到公开通知的关卡管理

发布负责人在提交应用商店审核前两周打开的模板。白板上排着必须通过的四道关卡、从提交到上线的流程、以及判断问题是否要在上线前修复的矩阵。任务看板分为提交构建确定、提交物准备、审核应对、上线通知四个父任务,等待提交和审核中两列能看出目前进展到哪一步。

展开全文 收起

适合提交前要做的事情越堆越多、搞不清楚进度到哪里的时候使用。面向正在查找应用发布检查清单做法、应用商店审核流程的个人开发者,也适合几个人一起推进发布的团队。提交前两周打开,容易遗漏的提交物和审核应对就能一页看全。

白板从上到下依次推进。先填好「关卡1 确定构建版本」「关卡2 提交物」「关卡3 审核应对」「关卡4 上线通知」这四个框,凑齐通过条件。接着用「从提交到上线的流程」确认今天所在的位置,发现的问题用「问题是否要在上线前修复」来分类。通知手段在「上线通知的打法」中列出,上线后在「上线后72小时的监控与记录」里写下要看的数字和回退条件。任务看板分为未开始、准备中、等待提交、审核中、已上线五列,把等待提交和审核中分开,等待时间也能看到。

第一周从「确定提交用构建版本」入手,先完成正式环境设置的切换再着手做素材,能减少返工。审核期间把「每天查看审核状态」留在卡片上,提前定好在收到审核意见当天就给出初步回复的负责人,流程就不会卡住。上线后不要只是看数字就结束,把审核花费的天数和被拒理由留下记录,下次的提交准备就能直接缩短。

0 点赞 0 复制 作者: WeProcess
应用开发 发布 应用商店审核 上线通知
免费注册并使用此模板

免费注册后,即可从模板市场复制并使用此模板

白板预览

预览模式 App 上架发布检查清单|从审核提交到公开通知的关卡管理

白板预览

关卡1 确定构建版本 关卡2 提交物 关卡3 审核应对 关卡4 上线通知 提交到上线的流程 问题是否要在上线前修复 上线前修复 用分阶段上线压住 放进下次更新 留作课题 上线后72小时的监控与记录 App 发布准备 使用方法:① 从上到下依次填好四道... 上线的条件 通过标准 卡住的原因 留给下次的记录 提升了版本号和构建号 把 API 和密钥切到了正式环境 去掉了调试菜单和验证用账号 崩溃收集工具正在运行 备齐了所需机型尺寸的截图 说明文案和关键词已定为最终版 隐私政策链接可以打开 收集数据的申报与实现一致 记录了审核账号和密码 在备注中写明了付费确认步骤 对被拒的初步回复要当天给出 重新提交前用真机确认了修改处 定好了上线时间和分阶段比例 准备好了通知文案和横幅 定好了负责答疑的人 定好了首日要看的数字 T-14 提交准备固定发布分支,把提交用构建版本进行内部分发并做最终确认。 T-7 提交向商店申请审核,在备注中附上审核账号和确认步骤。 T-5 审核中每天早上确认审核状态,追加问题当天回复。 T-3 处理审核意见对照关卡修正被拒理由,写明修改点后重新提交。 T-0 上线通过后开始分阶段上线,观察崩溃率和评价再逐步提高比例。 縦軸: 对用户的影响 / 横軸: ... 启动崩溃或购买失败。修复后重新提交,哪怕推迟上线日也要解决。 只在特定机型出现的问题。收窄分发比例,原因不明前不扩大。 文案不一致或留白偏差。加入已修复的分支,在下次发布时推出。 需要改设计的老旧机型支持。写明理由和重新讨论的时间后先放一放。 上线通知的打法 发布通知 应用商店文案 把新功能放进前三行 社交媒体发帖 附上30秒的操作视频 备好答疑 共享5个预想问题 应用内公告 更新后首次启动时 给老用户发邮件 只面向未更新的人 要看的数字例:崩溃率0.5%以下、首日评价平均4.0以上、付费完成率是否低于上一次。 回退条件例:崩溃率超过2%就停止分阶段上线,回退到上一版本的分发。 留给下次的记录例:把审核花费的天数和被拒理由记一行,加进下次的提交物检查。
100%

拖动可平移,滚动可缩放

任务看板内容

未开始 16 项

确定提交用构建版本
备齐提交物
通过审核
上线与通知
提升版本号
切换到正式环境设置
用内部分发确认
导出截图
定稿说明文案
核对数据申报
撰写审核用信息
每天查看审核状态
按审核意见修改后重提
开始分阶段上线
制作通知文案和横幅
查看首日数字

准备中 0 项

等待提交 0 项

审核中 0 项

已上线 0 项

← 返回模板一览