移动互联网app营销(APP移动互联网建设方案)
互联网小常识:对程序执行权限加以限制,非必要程序禁止读取通讯录等敏感数据。
今年众多互联网APP遇到了通报批评、整改、甚至下架的处理场景。APP仿佛成为了一个烫手山芋,但他更是一个自己公司的掌上明珠。
从移动互联网时代以来,APP成为了每个公司每个产品必备要素。它成为了公司和产品触达用户,提供营销和服务的最佳途径。
通过建设自身的APP,有以下主要价值:
1、为用户提供最优质的服务,只有自己的APP可以按照自己的规划进行设计和开发,能够满足自身用户真正的需求,带来更优的用户体验。这是在公众号、生活号等渠道无法做到的。
2、培养自身用户群体,APP的用户忠诚度和留存度更高,一般用户不会随意下载和卸载APP,比起小程序用户用完即走的习惯,APP更能提升用户忠诚度。
3、公司管理自身的APP,通过自己的APP对用户进行营销,可以更好的控制成本,提升收益。
当行业管理更加规范和严格,自身公司对于APP的管理也必须系统化,制度化,规范化,才能在市场中稳步运营,获客展业。
对于产品经理来说,尤其是APP产品经理,APP管理是必备技能。包括APP上下架、版本规划管理以及日常运营监控。本文将对APP管理全流程进行详细解读。
一、搭建APP管理团队
APP需要有专门的团队来管理,包括产品、运营、研发、测试、法务、管理等,每个角色承担自己的责任,包括APP设计、申请、开发、内部审核、与应用市场沟通等。
在较大的公司中,可能会安排一个实体部门或者组织,进行专门的管理。如果公司规模较小,也可以采用虚拟组织或者项目组的形式。
常规的APP管理团队需要的角色及其对应的职责如下:
1.产品团队
互联网小常识:电子邮件系统使用的协议主要有:简单邮件传送协议(SMTP,端口25);邮局协议第三版(POP3,端口110);Internet消息访问协议版本4(IMAP4,端口143),可以用telnet IP port的方法测试服务是否正常。
产品团队需要进行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尺寸和大小要求如下:
应用商店
格式
尺寸
大小
背景
App Store
png
1024*1024px
与安装包一致
透明
直角
应用宝
png/jpg
16*16px
<20KB
透明
直角
512*512px
<200KB
华为应用市场
png
216*216px
<200KB
透明
直角
vivo应用商店
png/jpg
512*512px
<50KB
透明
圆角半径48px
小米应用商店
png
512*512px
<1M
与安装包一致
透明
圆角半径70px
百度手机助手
png
512*512px
<800KB
透明
圆角半径70px
360手机助手
png
512*512px
<800KB
透明
圆角半径70px
阿里
png
512*512px
<200KB
透明
圆角半径70px
OPPO
png
512*512px
<1M
与安装包一致
透明
圆角半径70px
魅族
png
512*512px
<1M
与安装包一致
搜狗手机助手
png
512*512px
<1M
透明
圆角半径70px
(注:以上内容仅供参考,实际操作时以应用市场最新要求为准)
7)应用截图:与icon类似,需按照应用市场规定的图片尺寸上传素材。常见的应用市场截图尺寸和大小要求如下:
应用商店
格式
尺寸
大小
数量
App Store
互联网小常识:以太网组网的基本方法:IEEE802.3标准定义了以太网MAC层和物理层的协议标准。Mac层均采用CSMA/CD方法和相同的帧结构。但不同的以太网在物理层的实现方式却不同。传统以太网的物理层标准定义方式为IEEE802.3 x Type-y name。其中x表示传输速率单位为Mbps,Type表示传输方式是基带还是频带,y为网段最大长度单位是100m,name表示局域网名称。
png/jpg
1242*2688px
1242*2208px
2048*2732px
<1M
4-5张
应用宝
png/jpg
480*800px
<1M
2-5张
华为应用市场
png
450*800px
<2M
>=3张
vivo应用商店
png/jpg
480*800px
<2M
3-5张
小米应用商店
png/jpg
720*1280px
1080*1920px
<1M
>=3张
百度手机助手
png
480*800px
<1M
4-6张
360手机助手
png/jpg
480*800px
<3M
4-5张
阿里
png/jpg
480*800px
<1M
>=4张
OPPO
png/jpg
1080*1920px
<1M
3-5张
魅族
png/jpg
1440*2560px
<5M
>=3张
搜狗手机助手
png/jpg
480*800px
<3M
4-5张
(注:以上内容仅供参考,实际操作时以应用市场最新要求为准)
应用市场截图一般需要长*宽和宽*长的系列图片,例如一般需要同时上传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版本的生命周期包括
1.版本规划
2.需求收集
3.需求澄清
4.需求排期
5.需求研发
6.需求测试
7.需求验收
8.版本灰度发布
9.版本正式上线
10.版本数据分析
始于版本规划,终于数据分析。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管理仍存在问题和漏洞,希望本文可以给您一些帮助,也希望我们可以多多沟通,互相学习。
↘好文推荐:
【万字干货】产业互联网B端产品经理实操手册
【产品经理求职攻略】10年产品人经验分享
凯文·凯利:下一个5000天的12个必然趋势!
????欢迎关注:
互联网小常识:VTP有三种工作模式:VTP Server 、VTP Client和VTP Transparent.Server一般一个域中只有一个。用于设置因此不需要学习VLAN信息,Transparent相当于一个独立交换机不参与VTP工作,Client不能建立、删除或修改VLAN,它只能从Sserver学习VLAN配置。
免责声明:本站所有信息均搜集自互联网,并不代表本站观点,本站不对其真实合法性负责。如有信息侵犯了您的权益,请告知,本站将立刻处理。联系QQ:1640731186