- 如何用小程序实现类原生APP下一条无限刷体验
1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包,为了提高用户的后续消费,产品想出了各种各样的方法,例如在微视中,用户可以无限上拉出下一条视频;在知乎中,也可以无限上拉出下一条回答。这样的操作方式用户体验更好,后续消费也更多。最近几年的时间,微信小程序已经从一颗小小的萌芽成长为参天大树,形成了较大规模的生态,小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验? 这篇文章详细记录了下一条无限刷效果的实现原理,以及细节和体验优化,并将相关代码抽象成一个微信小程序代码片段,有需要的同学可查看demo源码。 线上效果请用微信扫码体验: [图片] 小程序demo体验请点击:https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑,我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现,可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图,又由于每一篇文章的内容长度高于一屏幕高度,所以需要实现文章内部可滚动,以及文章之间可以上拉和下拉切换的功能。 在多次尝试后,我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现,利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能,利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示: [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的,所以前端领域的大多数优化方式都有用。例如减少代码包体积,使用分包,渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新,所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码],这样必然会导致页面的dom节点成倍数的增加,最后非常卡顿。 为了优化页面的dom节点,我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化,控制是否渲染dom节点。首先,仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码],也就是页面中最多预先加载出下一条,而不是将接口返回的所有后续数据都渲染出来;其次,对于用户已经消费过的之前的[代码]<swiper-item>[代码],不能直接销毁dom节点,否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱,但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点,我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容,也就是仅渲染当先文章,及上一篇和下一篇的文章内容,其他文章的dom节点都被销毁了。 这样,无论用户上拉刷新了多少次,页面中最多只会渲染3篇文章的内容,避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体,而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上,[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块,并不具备数据直接共享的通道。当前,视图层和逻辑层的数据传输,实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据,需要将其转换为字符串形式传递,同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本,再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响,数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程,通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新,这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口,也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据,其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据,会增加 setData 传输的数据量,。 使用 [代码]setData[代码] 传输大量数据,通讯耗时与数据正相关,页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据,使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码],避免短时间内频繁调用 [代码]setData[代码],对连续的setData调用进行合并。不然会导致操作卡顿,交互延迟,阻塞通信,页面渲染延迟。 避免在后台页面进行 [代码]setData[代码],这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式,分多次请求回来。在使用分页接口拉取到下一刷的数据后,我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中,这个[代码]articleData[代码]是一个数组,里面存放着所有的文章数据,数据量十分庞大,如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销,导致操作卡顿,交互延迟。 为了避免这个问题,我们将[代码]articleData[代码]改进为一个二维数组,每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新,具体代码如下: [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下: [图片] 4.3 体验优化 解决了操作卡顿,交互延迟等问题,我们还需要对动画和交互的体验进行优化,以达到类原生APP效果的体验。 在文章间上拉切换时,我们使用了[代码]<swiper>[代码]组件自带的动画效果,并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时,会提示下一篇文章的标题等信息,而在页面上拉时,由于下一篇文章的内容已经加载出来了,这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现,我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕,并在滚动结束时,通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码],并对这个空白[代码]<view>[代码]的高度变化增加动画,来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果: [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时,我们需要给用户一个“下滑查看上一条”提示,所以也可以采用同上的方式,通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕,并在滚动结束时,通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码],并对这个提示语[代码]<view>[代码]的透明度变化增加动画,来实现下拉时提示“下滑查看上一条”的效果: [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此,这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此,欢迎交流和讨论。 小程序demo体验请点击:https://developers.weixin.qq.com/s/vIfPUomP7f9a
2019-06-25 - 永远对微信小程序保持尊重——小程序心得体会和开发经验
开篇 我第一次接触小程序时,还清楚的记得是在2017年的春节期间。当我升级最新版的微信后,开始摸索着新的功能变化。在发现页有一个叫小程序的入口,点进去有一列的“应用”。当我打开一个叫“亲戚关系计算器”的小程序后,简单的使用,然后退出,再去寻找其他的小程序,猫眼电影,自选股,滴滴出行…… 当我尝试着去探索更多小程序的过程中,我突然发现,微信正在发展为一个超级的应用流量入口。而微信中的小程序也可以轻松的坐拥10亿的可用用户人群。 那时候过年,我做的唯一一件事情就是细细的读了小程序的开发文档,心想他可以具有多大的活力与动力,能够引发多大的改变。而我能不能适应他,去随着他的发展,带动自己的腾飞。 很遗憾,当时的小程序并不对个人开发者开放,没有办法注册一个小程序,只能在开发者工具上写一些小的应用,去熟悉小程序的开发。 3月27日,小程序重要更新,其中之一就是支持个人开发者注册小程序。那时候的我,在学校上大一,用一个运营公众号的微信号注册了第一个小程序,并做了一些实验性的开发,并上线。 从这个过程中,我开始细细的体会小程序的优势以及不足,小程序适用于那些领域,小程序适合怎么推广。小程序适合那些行业领域的应用。现在看来,其实从小程序提供的能力,就可以依稀端详出小程序所致力的场景与应用领域。 2018年1月,在我历经半年多的思考和衡量下,做出第一款真正属于自己的小程序——GS比赛计分。去尝试探索线上小程序和线下场景的交融,在这过程中有顾虑,有大胆创新,但都为我更深层次理解小程序有很大的帮助。 目前,自己已经做过10余款小程序,除了GS比赛计分开发时间很长,其他的小程序都是一个月左右的时间完工。比如2019年2月的高校课程助手;2019年3月的数据查询助手;2019年4月的数据汇总助手。 我接下来会从小程序的需求分析与应用设计,小程序的开发,小程序的运营3篇来讲述我对于微信小程序的独自见解与经验。希望能为更多的学生开发者有所启发和借鉴。 需求分析与应用设计 要清楚的认识到小程序对自己需求的最大赋能,需要从最初去理解小程序的定位,微信团队对于小程序的定义是这样的: 微信小程序是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验。 通过对小程序提供能力的分析,不难看出。小程序相对于APP来说,在降低开发门槛的同时能够满足最普遍的应用需求,适合生活服务类线下商铺以及非刚需低频应用领域。使得微信通过小程序作为生态的建立者和维护者,赋能商家和应用者。以一种生态触角的状态来迅速的捕捉最大化生态红利。 当清楚的理解小程序的定位后,那么就需要合理的筛选需求并进行应用的功能设计。我将会使用【GS比赛计分】作为例子进行分析说明。 1.用实质的问题引出明确需求,并确定解决问题的功能边界 首先思考的是,自己需要做的功能都有哪些,使用人群是谁?使用场景是什么?需要数据的实时性吗? 一开始设计【GS比赛计分】的时候,目的是为了解决现在的中小型比赛使用人工计分的失效性差,出错率高,人工和时间成本昂贵的问题。程序的目的是将比赛计分的相关人员用互联网工具联系起来,以提升计分效率。 [图片] 当明晰了产品目标后,开始考虑使用人群。一般来看,大多数的比赛计分都是由两种角色构成的,一个是评委(分数确定者),另一个是工作人员(分数汇总者)。 传统的计分过程是通过现场工作人员将评委的分数以纸质的形式送达计分人员。在这一过程中就有大量的成本浪费了(一个是人力成本,另一个是时间成本)。另外,计分人员以Excel或计算器和笔记的形式进行比分汇总,在这一过程中又存在大量的成本浪费(人力成本和时间成本甚至还有错误风险)。 [图片] 所以横观所有的主观评分的线下比赛,无一例外都存在比赛结束后有长时间的节目或视频热场环节,其实这都是在为人工计分的缓慢争取时间。 所以,【GS比赛计分】的使用人群和使用场景就确定下来了,与传统人工计分的过程类似,只不过需要互联网赋能,解决时间和人力成本。需要数据的实时交互。 【GS比赛计分】作为解决现象问题的工具,首先需要做的就是不要违背现象中事件的发生次序。所以功能完全参照比赛计分过程来设计。具体功能如下,提交成绩,撤回成绩,弃权处理,实时的选手分数,实时的选手名次,清楚评委数据,解绑评委,重启比赛,结束比赛,比赛内置会话。 2.对程序平台进行横向比对,明确小程序的优势和劣势 当程序的功能确定好后,不要着急着手界面设计,功能模块的组合,交互设计这些过程。当你在进行这些过程之前,需要认真的去考虑你的应用是不是适合在小程序上开发。 小程序的火爆,注定有许多人盲目的进入这一领域,但不是所有的应用都适合小程序的推广模式,也不是所有应用都能吃得起小程序的运行效率的。所以在确定开发小程序之前,正确的认识的合适与不合适,避免让自己的成本白白的付出。 如何确定适不适合用小程序来做呢?我们可以让小程序作为一个互联网平台,把应用带入到互联网的每一个平台中去,进行横向的对比,去找出各自的优点与不足,当做出客观的判断后,应用在小程序上相比于其他平台有没有优势就很明显了。 还是以【GS比赛计分】举例。我所横向对比平台包括PC、原生APP、Web平台、轻应用、小程序。首先从满足功能来说,比赛计分需要很稳定的实时性,所以我将Web平台排除(因为复杂的比赛环境,不同的设备浏览器难免会有问题)。 然后将剩下的平台做分析。PC平台使用可能性太小(原因:比赛现场成本太高昂,租借笔记本可能都不是现实的);原生APP不适合(原因:评委评分前需要下载APP,比赛结束后没什么用了,需要把这个APP卸载。而且IOS和安卓两大平台增加了研发成本);轻应用有阻碍(原因:百度轻应用由于装机量小,覆盖人群不多。支付宝小程序没有社交关系链,无法有效的推送给需要的人。产业联盟轻应用,苹果用户怎么考虑?) [图片] 经过一系列的对比,很明显。对于【GS比赛计分】来讲,微信小程序是最好的应用平台。同时微信小程序仍然可以和不同的平台进行联系,所以可扩展性,功能延展性都是最佳的。 3.应用设计要满足即用即走的理念 当确定小程序是最理想的应用平台时,我们需要对小程序进行便利化的设计。这就需要抛弃一部分原生应用开发或Web开发的一些设计理念。追求“极致、简约”的风格设计。 在【GS比赛计分】的详细设计时,我考虑到,以个人账户的形式去下发比赛的流程是行不通的,既然服务于比赛,那么就以比赛为最基本的账户组成单元,明确一个比赛ID。而同一个比赛的不同角色,以不同的IK进行区别,而角色的设置包含在比赛设计中,由比赛创建者在创建比赛时自行创建。 那么小程序的使用场景就出来了。以比赛现场的告知或者微信聊天的分享,告知比赛参与角色其ID和IK,就可以让角色快速的进入绑定角色并使用程序。免去注册的一系列烦恼。 同时在微信用户面前,这个账户体系是平权的,任何用户在得知ID和IK的情况下都可以进入(账户绑定情况下不可以进入),一定程度上免除密码和忘记密码,注销账户这一系列的麻烦。 当完成比赛后,程序已经完成了自己所有的任务时,使用者可以直接退出程序,不需要注销比赛等操作。真正做到即走。 在使用过程中,要清楚的考虑用户的使用过程,从而做一些保险机制。微信小程序运行在微信上,微信是社交工具,就免不了用户会退出小程序甚至微信去做一些其他的事情。所以【GS比赛计分】在设计时要保证用户回来要用到自己想要的,在程序设计中有中间状态界面能够保证用户可以迅速进入使用状态。 4.对于很大的系统,要把最适合小程序部分拿出来,而不是全部 现在的【GS比赛计分】其实是一个大的生态系统,结合有线下的网络接口,展示接口,线上小程序,web平台。每一个部分都承载着自己独特的应用价值。 比如Web平台就承载比赛管理的任务,创建比赛,上传比赛文件,选手图片,设置选手(名称、介绍、手机号、图片、出场顺序),设置评分项(名称、权值、预置分数),设置评委(名称、权值,IK)。从实际的分析来看,比赛管理最适合在PC端进行,不管是文件还是图片,公认都是PC上传比较容易。 在最初设计的时候,我错误的把系统分成了多个小程序进行系统搭建,在实际使用过程中造成了重大的缺陷和用户流失。最大的表现是,我开发了【GS比赛创建】小程序,作为比赛的入口程序。从而造成比赛数量增速缓慢,大的使用场景无法突破,老用户意见上升等一系列问题。不得不注销了【GS比赛创建】小程序,并进行很大的架构调整。【GS比赛计分】暂停使用,造成大量的用户流失。 [图片] 所以,当设计多场景,前后联动性很强的应用时,需要将功能进行使用划分,每一个划分需要找最适合的平台。最适合小程序的部分,就做好与其他平台的无缝结合。 5.小程序的应用场景和机会 目前来看,小程序的应用场景主要包括支付场景,比如扫码支付、快消餐饮、移动购物、交通出行等等,工具类小程序能更碎片化、垂直化地满足细分的应用场景需求。 根据微信的最近更新变化来看,公众号和小程序的协同作用将越发明显,公众号的作用也将进一步放大,因此未来发展的机会可能在这几方面。 内容营销,小程序能通过更完善更精准的服务进而提高用户黏性。具体来看包括各大知识付费的小程序以及在教育风口上的小程序。当然,这些小程序也可同时开发APP(按微信对小程序的开发步骤来看)从而实现用户沉淀。 具有支付场景的各类商家。包括传统的已有一定客户群的商家提供更方便的服务或者实现线上线下联动以及新零售。 工具类小程序。包括共享经济领域,这类小程序即用即走,轻量化,便捷化。 天生具有社交属性的小程序。比如抽奖、互赠礼品、拼团减价、社交性的小游戏以及帮拿快递等。 小程序的开发经验 1. 微信小程序开发文档是最好的学习文档 很多同学喜欢看视频教程,或者买一本小程序开发书来学习。觉得这么学会加深理解更加容易上手,而官方文档干巴巴不好学。现在的微信小程序能力更新速度很快,当一个教程或书出来的时候,其实已经过时了。建议同学去微信公开课中学习微信小程序的入门教程,开发入门后,根据自己的开发需要,自行阅读官方文档来学习。 [图片] 2. 必须了解小程序的运行原理 微信小程序是运行在微信中的,所以运行速度并不能和原生媲美。但是在开发小程序的过程中,可以用良好的编程思路来追求程序的高效运行水平。但前提是,你需要对小程序的运行环境有所理解,需要知道在开发环境和真实环境(IOS和Android)下的运行差别。大部分的开发坑都是因为不同运行环境造成的。 官方的声明:微信小程序运行在三端:iOS、Android 和 用于调试的开发者工具;在 iOS 上,小程序的 javascript代码是运行在JavaScriptCore中;在Android上,小程序的javascript代码是通过 X5 内核来解析;在开发工具上,小程序的javascript代码是运行在nwjs(chrome内核)中。 微信小程序的运行环境类似 ReactNative ,而不是纯 Html5。两者最大的不同在于,ReactNative 的界面是由原生控件渲染出来的,而 Html5 的界面是由浏览器内核渲染出来的。两者在性能上有较大的差异,从而表现出来微信小程序要比h5页面好很多。 3.安利小程序云开发 云开发为开发者提供完整的云端支持,弱化后端和运维概念,无需搭建服务器,使用平台提供的 API 进行核心业务开发,即可实现快速上线和迭代,同时这一能力,同开发者已经使用的云服务相互兼容,并不互斥。目前提供三大基础能力支持: 云函数:在云端运行的代码,微信私有协议天然鉴权,开发者只需编写自身业务逻辑代码 数据库:一个既可在小程序前端操作,也能在云函数中读写的 JSON 数据库 存储:在小程序前端直接上传/下载云端文件,在云开发控制台可视化管理 云开发使得小程序开发门槛进一步降低,甚至偏前端的开发人员也可以独立开发小程序了。另外,云开发中云函数支持去请求第三方服务接口。所以云开发最大程度上提供了小程序所需基本API的构建,另外可以通过第三方服务请求能力扩展API能力。 [图片] 而且云开发的数据库和存储完全可以与云函数构建一个小型的后端平台。并发能力中等,适合大部分的小程序业务API的构建。 4. 养成良好的小程序代码习惯 微信小程序的代码文件分为4种,WXML、WXSS、JS、JSON。 JSON文件是小程序的配置文件,APP.JSON是小程序全局配置,另外每个页面也会有配置文件。建议页面中的JSON文件只填写页面需要配置的(比如页面标题),而不变化的不要写到里面(比如标题风格,背景颜色等等)。 JS主要是javascript语法,建议以模块的形式对通用的方法进行封装,尽可能的利用好代码,不要有大量重复的方法语句。如果多个页面需要,可以单独建立js文件,在需要的页面进行引入。 WXSS是样式文件,遵从css的编写规则,尽可能的少些样式表,多多利用已经写过的样式,如果多个页面需要,可以单独建立wxss或者写到app.wxss中 WXML是页面结构文件。如果多个页面中有相同的结构,可以单独封装为模块,而模块中的逻辑方面也尽可能遵从代码最大效益化。 总之,开发代码简洁,会使得编译后的小程序包很小,使加载速度更加快速。 5. 小程序填坑总结: 首先,微信开发者社区是好的小程序开发交流平台,从中可以获得大多数问题的解决方法: https://developers.weixin.qq.com/community/develop/question 另外,许多人常用搜索引擎来直接搜索问题的解决方法,一般大部分的错误或者问题都会在开发文档上写的很清楚,只不过很少有人去注意到,推荐几个小程序填坑的集合文章: https://blog.csdn.net/weixin_42448956/article/details/82414225 https://www.cnblogs.com/shaoting/p/6051261.html https://www.imooc.com/article/36148 https://www.cnblogs.com/wangking/p/6946438.html https://www.jianshu.com/p/4362e52f5c49 小程序的运营 小程序运营属于软件产品运营的一种类别。从产品生命期来看,小程序运营分别为研发期、种子期、成长期、成熟期、衰退期。另外由于小程序在运行模式和定位的不同,表现在推广形式上与平常的软件产品有很大的差别。接下来,我会用【GS比赛计分】【数据查询助手】小程序为例子佐证分享小程序的运营经验。 1. 小程序研发期,搞清楚产品的定位以及目标用户 当你不是运营小程序的产品策划者,你需要首先要搞清楚产品的定位以及目标用户。(这也是多数互联网公司将产品策划和运营作为一个岗位的原因)。在整个产品的研发期,需要跟进产品的每一个细微功能点,要明晰产品的使用用户;还要时刻去观察产品的领域有没有竞品的出现,用户习惯有什么改变;要时刻去衡量产品的竞争优势,为之后的发布运营做好准备。 【数据查询助手】是提供自定义信息查询服务的小程序。任何微信用户均可以上传自定义的数据(报表,成绩单等任何表格数据)建立查询。 [图片] 当在产品研发的一个月,我不断的探索小程序领域,APP领域,Web领域有没有相同的功能产品或服务。甚至将问卷系统(腾讯问卷、问卷星、问卷网)作为潜在的竞争对手。 另外我还制作了web版和原生APP的Demo去体验他们与小程序体验的不同。去确定微信小程序是很好的适应平台。从而为之后的运营做足了准备,提升了自己的信心。 2. 小程序种子期,要充分利用体验版过程 小程序体验版相当于其他应用平台的内测版。体验版可以更高层次的模仿真实的用户环境。在这一阶段更容易发现用户间连接要求高的应用缺陷。同时可以在安全的范围内去聆听用户的真是使用反馈。 【GS比赛计分】开展了长达1个月的体验版。邀请了20个核心用户去体验。由于应用需要与服务端建立实时连接。用户不同的设备,不同网络环境对程序的稳定性做出了很大的考验。在这一阶段修复了不少场景不同导致的错误或者效率低下问题。 另外一开始推出的小程序界面设计只遵从了功能设计,没有很好的考虑真实的使用场景。所以在这一阶段,我最大程度上听取体验用户的建议,对整个界面进行改版,使交互更加的亲近用户。 3. 小程序成长期,明晰获取用户的手段和推广手段,最大化的成长: 当小程序功能稳定后,到了成长阶段,用户使用是最核心的任务。获取用户的时候,必须先让对方了解自己的产品,建立认知,将产品介绍给用户,让用户进入小程序之后,想方设法让产品与用户产生交互,让用户不断体验产品,让活动始终覆盖用户,让用户对产品认可,要完成产品与用户的关系构建。 从现在许多小程序的运营手段来看,基本上都围绕着社交裂变和线下推广的方式来提升小程序的获客表现。而小程序由于较低的开发成本,较快的更新速度,以及较低的试错成本,使得多数很强势的小程序都采用功能矩阵发展模式,快速实现功能及迭代。 小程序获取用户的手段主要由下: 朋友圈分享(包括图片二维码、广告直接进入); 聊天好友推荐转发; 线下二维码(包含商家推广、广告推广); 微信搜索(一般由其他社交平台或者用户需求引起); 线上识别二维码(线上推广,文章推广,或其他社交平台的推广); 其他小程序的跳转(互相推荐) 公众号跳转(公众号运营推广) APP跳转(一般是APP延展的简洁功能推广,或者轻量级触达用户形式的推广) 小程序发掘社交推广的手段主要由下: 社交立减金,实现社交裂变; 社交比拼玩法,引导社交裂变; 互动加入分享按钮,提醒用户转发; 设计同伴环境,鼓励社群传播; 设计任务玩法,领取奖励; 设计福利,鼓励好友助力; 聚焦核心功能,促进口碑传播; 【数据查询助手】从产品定位上就自带社交裂变的元素,当查询创建者创建了一个查询后,他可以根据要分享的人群情况选择多种分享方法。如果是企业微信或者微信工作群,那么可以直接分享小程序到聊天窗口。其他的用户可以直接进入小程序进行查询。如果是线下的查询(推广会,现场发布等),可以通过小程序二维码的方式进入查询界面查询。对于其他社交平台来讲,可以用二维码来做分享,如果是常用用户(添加到我饿小程序或者桌面作为常用工具的用户),可以直接通过复制文字(含查询码)然后进入应用的方式快速开始查询。 同时每一个查询者,都可能是潜在的查询创建者和程序推广者。所以要在这一阶段不断的优化体验流程,尽可能做更多事情覆盖多场景的查询(比如微信搜一搜直接搜索查询码,直接查询),去吸引用户,留住用户。 由于小程序用完即走的理念,导致许多工具类小程序(不含深度融合线下和社交的)用户的留存普遍较低。既然工具类就是服务用户,那么就把小程序慢慢的做成一种用户习惯,从习惯的养成变为行业应用的转化。从转化中寻找切入点,进而挖掘可以创造价值的功能产品。 所以,做小程序不要过分贪图大规模的使用率,大批量的用户。他本身是一种服务理念的触达和养成,你需要在用户心里养成使用习惯,而不要上来糖衣炮弹把用户打蒙,甚至反感。这样小程序的生态就被搞乱了。 4. 小程序成熟期,稳定期最重要的就是小版本的迭代更新: 刚才讲到,小程序有较低的开发成本,较快的更新速度,以及较低的试错成本。所以在小程序成熟期需要根据用户数据不断的去更正调整功能,去保持较高的运营分数。在产品功能中,适时的进行用户付费转化。 付费转化一方面可以拉开用户层次,对小程序的用户是一种活水作用,提升用户的使用粘性,容易过滤最核心的用户,提供更加好的产品服务。如果在成长期很好的进行用户习惯的养成,这个过程会更加自然。反之,应用将会更快的进入衰退期。 付费转化的方式主要由几类: 电商类:主要靠活动、优惠刺激(现实抢购、秒杀、预约、限时满减、显示商品库存和抢购人数); 游戏类:游戏道具(向朋友求助、每日签到、社区活动等方式免费获得,但数量有限,且都是一些级别较低的道具)高价值道具付费、皮肤售卖、游戏币购买; 内容类:付费文章、阅读币购买、付费课程; 5.小程序衰退期:适时舍弃,进行新产品开始推出 小程序开发周期短,很多时候应用分析不够透彻,更多的是一些商业或推广试错。导致许多小程序还没有进入成长期就进入晚期了。这一类小程序直接舍弃就好,不需要什么转化了,这也不算小程序的衰退期(没有盛何来衰)。 对于经历过成熟期的产品主要有几个原因导致进入衰退期: 市场中有新的创新型产品,导致冲击衰退。 自身功能设计有缺陷,导致用户流失。 对用户了解不透彻,付费转化失败,用户迁移到同类产品。 产品质量下降,不能适应用户行为的变化。 由于运营组织的原因,产品运营出现危机。 在这一阶段,运营已经无能为力。那么就进行产品的复盘,积极的去投入到新产品或者新领域的探究上面去。小程序的开发成本较低,所以可以有很多机会去重新塑造一个好的产品。 6.总结,谈谈自己的想法: 现在多种多样的互联网产品不断产生,产品竞争异常激烈。互联网产品的运营手段也是推陈出新,花样繁多。在这里我不给大家分享一些运营花样,因为每个小程序都是独特的,应该有自己独特的运营手段,具体是什么,希望产品者和运营者本身用热爱小程序的心去发现和实践。 永远保持对产品的尊重,对用户的尊敬是每个产品人最重要的事情。如果对应用足够热爱,你会厌恶他被污染,他被别人嫌弃;你会尽自己的可能让他变得更加本真,你会合理的去运营突破,去帮助产品走向更高的位置。 如果你没有爱你的产品,再出色的产品也只是昙花一现而已,并不能给你带来任何长远的意义。 这是最好的小程序运营指南:https://developers.weixin.qq.com/miniprogram/product。 [图片]
2019-06-23