小程序里访问人数是新用户还是老用户

小程序里访问人数是新用户还是老用户,第1张

程序里访问人数是新用户和老用户都有可能。新用户是指首次使用小程序的用户,老用户是指多次使用小程序的用户。新用户是小程序发展的基础,老用户则是小程序发展的核心。小程序的发展要依靠新老用户的共同支持,才能更好地发展壮大。因此,小程序的发展要以新用户的增加为基础,以老用户的持续支持为保障,才能够取得更好的发展。

网络卡顿。微信是一个通讯类型的软件,该软件小程序访问人数多卡顿是网络卡顿导致的。微信是腾讯公司于2011年1月21日推出的一款通过网络快速发送语音短信、视频、和文字,支持多人群聊的手机聊天软件。

1超过40人,你的邀请需要对方同意;

2超过100人,对方需要通过实名验证才能接受邀请,可通过绑定yhk进行验证。

建群:请登录微信后点击右上角“+”=》发起群聊=》选择好友后开始发起群聊即可。

退群:请进入需要退出的群里点击右上角的图标=》删除并退出即可。

拉人:请进入需要增加人的群里点击右上角的图标=》选择需要增加的人添加即可。

微信对建群是没有太大的要求的,只要你通讯录里有人都可以建微信群发起聊天。

在企业微信管理后台即可创建企业群活码,进入“客户联系”,然后点击“加客户”,进入“加入群聊”页面设置。点击“新建加入群聊”,接着是“通过二维码加入群聊”,即可创建永久有效的进群二维码。

在“可加入的群聊”旁边有一个叹号,点击它可以看到该群活码最多可关联5个群,而一个外部群人数上限是200人,也就是说一个活码最多可承接1000人进群。

设置问题。

群聊,可以只显示头像,也可以显示头像和昵称。打开你的微信群,点击右上角两个叠加的小人的标识,下拉,倒数第六行,显示群成员昵称选中就好了。

微信群组成员人数上限为500人。微信新版本可以由群主升级。微信用户拥有500人的权限。150人群权限需要绑定手机号,可以拥有4个150人的群。

最近有一个需求,就是在小程序中,如果把商品分享到某群,此商品被二次转发(又被分享至其它群), 其它群成员无法领取

这个功能需要在小程序中获取第一次转发的群ID,根据ID,非此群用户无法领取此商品

在此记录此需求,从转发到接收的全流程实现

1) 页面生成后,一开始没有分享信息,故在 onReady 生命周期函数中调用 wxhideShareMenu() ,使右上角按钮无法呼出分享按钮

2) 点击页面下赠送朋友按钮,向服务器请求分享信息,分享信息拿到后使用 wxshowShareMenu({withShareTicket: true}) 方法,使右上角可以呼出分享按钮, withShareTicket: true  设置分享后回掉函数中可以拿到shareTicket信息

3)在 onShareAppMessage 函数中配置配置分享信息, 注意,此函数中不要有异步行为,更不要在异步行为的回调函数中配置分享信息,分享信息要在此函数中 直接return(返回带有分享信息和分享完成后回掉函数的object)

4)此时按右上角,即会触发分享行为,在onShareAppMessage  函数中return 的分享后成功的回调函数参数里可以拿到 shareTickets , shareTickets是一个数组,数组每一项为一个分享了的群组shareTicket信息

5) 拿到shareTicket后, 调用wxgetShareInfo, 即可拿到加密后的微信群ID信息,将此信息通过API接口,交给后台处理。

在小程序的注册文件appjs中,onLaunch函数参数里,可以拿到场景值(opsscene),当场景值为1044(带 shareTicket 的小程序消息卡片),ops中会包含shartTicket信息,同样调用wxgetShareInfo接口,拿到加密后的微信群ID,将此信息保存, 在用户触发接受的时候,将此信息通过API交给后端,后端会进行解密,如果此ID 和分享时候的ID不一致,那么用户不可接收此商品

微信 小程序 转发涉及以下4个方法:

1、PageonShareAppMessage({})

设置右上角“转发”配置,及转发后回调函数返回 shareTicket 票据

2、wxshowSahreMenu()

用户点击右上角后,显示“转发”按钮

3、wxhideShareMenu()

隐藏转发按钮,无视 PageonShareAppMessage({})

4、wxgetShareInfo({})

根据 shareTicket 获取已加密的群信息

把转发流程切分:转发前配置->转发时->转发到群组后打开->二次转发

转发流程图:

这里写描述

U1: 用户

T1,T2,T3:表示转发票据,即 shareTicket

G1,G2,G3:群组

1转发前配置

在页面 onLoad 方法添加

withShareTicket 为 true 时,表示允许转发时是否携带 shareTicket。

shareTicket 是获取转发目标群信息的票据,只有拥有 shareTicket 才能拿到群信息,用户每次转发都会生成对应唯一的shareTicket 。

shareTicket 有两个用途:

用户主动转发后,获取转发到目标群群信息,对应上图UI。

用户在群组中打开小程序,获取群组信息,对应上图 G1 群组中的用户。

2转发时获取群信息

当某个小程序被转发到群组后,开发者想获取到转发目标群组信息,将用户和群组做某种绑定关系(openId + openGid)。

shareTickets 是一个数组,每一项是一个 shareTicket ,对应一个转发对象,转发给用户不会包含shareTicket。

拿到 shareTicket 之后,使用 wxgetShareInfo({}) 方法传入 shareTicket 参数,wxgetShareInfo({}) 里回调函数中包含 已加密的群信息和 向量IV。

3转发到群组后打开

用户将小程序转发到微信群组后,群成员打开小程序,通过 shareTicket,开发者就能将群成员和群组绑定起来(openId + openGid),基于群组关系,小程序有更多的应用场景,例如:王者荣耀群排行,摩拜单车。

在群组中打开小程序,页面onLoad 或 onShow 方法包含 scene 和 shareTicket,需要判断 scene 是否为1044,如果不是则不包含 opt 中 shareTicket 参数。

4二次转发

二次转发重复前3个步骤,没什么可说的,但是有一个方向值得探讨,可否把小程序转发路径比作转发链,进而生成转发树,用数据结构方法(树、马尔科夫链)处理发现群组与群组,群组与成员之间微妙关系。

如开头那张图,我们很容易看出转发链和转发树。

转发链:U1 > G1 > G2

转发树:U1 > G1 > G2 & G3

小程序推广方案之如何做好小程序社群运营

做好小程序推广方案中,有一个是十分重要的,就是小程序的社群运营,合理的利用小程序的社群运营,能够吸引更多潜在的用户,提高用户留存,从而使小程序大力推广出去。下面就为大家介绍这篇小程序推广方案之如何做好小程序社群运营。

其中最主要是依次解决了以下几个问题

1、如何弥补小程序的短板

2、如何持续为为销售人员提供合适的潜在用户

3、如何提高用户的留存时长

1、如何弥补小程序的短板?

做了近一年的小程序产品,虽然享受到了很多小程序带来的实惠,但它的缺点和限制也同样突出,主要集中在以下:

对比一下上下两表,两者之间的优点与缺点大多都能够互补,比如:

社群中使用和推广小程序,能解决用户无法触达的问题;

小程序可以丰富社群体验,提高活动质量;

小程序可以记录下社群活动的关键部分,并对之后的持续展示露出有帮助;

社群可以通过小程序的持续内容更新来低成本维护;

在这之后,我调整了小程序的运营策略,将小程序的使用为主,推荐用户参加社群活动的运营为辅助,转变成活动社群为主,小程序在社群中的使用为辅助,这样才能更好的完成两者的互补与结合。

虽然实际 *** 作起来还是差不多的,但主要改变的是大家的思想方式,及对小程序的认识。

2、如何持续为为销售人员提供合适的潜在用户?

据我所了解:目前国内所有的在线教育公司,其获客成本会随着销售单位价上升而上升。我们也不例外,所以最近给我制定的KPI就是要能够给销售同事提供足够多的Sales Leads(潜在用户)。之前这些潜在用户仅来源于线上线下活动,长期社群运营,用户自己看了广告推文后联系我们。

之前团队做活动,会让用户在活动开始之前填写像户口调查一样的问卷,每次活动也只能说是做一次收割一次,跟品牌越做越大,获取例子省时省力不沾边。而做长线社群本身就需要花很大的精力,而从大量的社群中获取用户,很多时候只能靠运气,就是几个用户刚好在运群里讨论到了你能够出售的产品时,恰好有销售人员出现又能解决。

这些都都跟持续、高效、省力完成挂不上关系,至少离我的理想方案差得太远,但最近就通过小程序将这个问题迎刃而解。

我们一直有个单词对赌的社群活动,每月能够举办两到三期,每期都有几百名新用户,没有限制用户背单词的形式和内容,但需要把当天背的单词打卡截图发送到我们的小卡小程序里,最后会根据用户的打卡情况来退还报名费。

很长一段时间,我们都没发现这个活动和用户有什么价值,运营也是是为了做而做,每次在打卡活动结束后,在群里打打自己的广告,最后在越来越多其它竞品的广告出现的时候,就把群解散了。直到某天,新来的同事在看数据的时候,发现其实每期目标用户的身份就已经写在这些打卡的照片上了。

这一点其实怪我自己,当初做这个打卡小程序的主要目的就是为了筛选用户。无论是用户在小程序中的参与行为,还是其在小程序内提交的各种数据,都可以很快的对新用户进行筛分。

所以在想到这点后,第二个问题其实也就不是问题了,只要做更多能够吸引所有人眼球的活动就好,然后在活动中,通过小程序逐步完成用户的筛分。

3、如何提高用户的留存时长?

这里先举两个的例子:

要从街上找一群喜欢看**的人容易,还是找喜欢看推理剧的容易?

同样,是找喜欢体育的人容易,还是找喜欢打台球的人容易?

假如,我们可以选择不浪费任何进来的流量,只要你喜欢体育,我可以组织各种各样的比赛来满足你,直到有一天你发现你喜欢的女孩也打桌球。同样,我也可以让你喜欢上我们推荐的各种各样的**,然后终有一天你会向你喜欢的推理剧的朋友推荐我们。

这一切,需要时间来浇灌等待用户发芽,需要肥料来给养让用户更喜欢我们的产品。

这里就继续说说最近的运营工作,我自己是有一个运营用的微信号的,主要是添加用户,解答他们在使用小程序中的问题。在活动期间,用户会比较积极的把我们的活动分享到朋友圈。但在活动结束之后,因为没有新的内容来填充,不出半个月,我的朋友圈经常就会变成下图的样子,全部都是竞品活动在刷屏,甚至有些会直接进入到这些社群当中。

为了避免用户口碑的进一步下滑,最后多只能将群解散,白白浪费活动进来的流量,对于我们这种不太擅长做流量的团队来说,太可惜、太浪费。

随着新的小程序发布和之前运营方案的调整,所以完整的跟踪了一个系列活动,分析这两次活动数据的时候,也发现了答案。下图将截取两次活动的部分数据。

运营过程:

第一次活动总共有177名付费用户,这些用户全部集中在社群A;

活动中每天都需要使用小程序来完成相应的学习,培养了良好的用户习惯;

活动结束后,小程序内的学习内容继续保持更新,且因为Bug还需要时间修正,所以只在社群A内进行内容更新的发布,除此之外并没有花费太多的人力。

在经过上述三周以上的社群运营,第二次活动时,给出了以下的数据:

原活动社群A,在小程序的内的活跃人数为70人(参加第二次活动的70加上未参加的10人),活跃比例在47%,完全填补之前社群运营的活跃人数数据的空缺;

没有参加第二次活动的用户,依旧有87人在原活动社群A中,且有相当一部分在继续使用小程序,这部分用户后续可以随时激活;

第一次活动中有60名用户通过第二次活动报名,进入到社群B,相当于第一次活动的续报率达到34%,对比之前没有小程序时,有近10个百分点的增长;

而只有30名用户从两个活动社群中消失,排除部分用户改昵称和昵称无法匹配,整体用户的流失率应该是低于15%的。

说实话,如果团队能在这个活动动上更用心,运营的流程更细致,小程序没有一开始人人都遇到Bug这样的开局,相信这个数据和结果还能更好。但总得来说,这个数据对比过去也还是有了明显的增长,而这也将是用户能够长期停留在社群和产品运营体系中的保证。

体系搭建

分解和整理以上的思考内容,主要抽象出以下几个主要对象:

短期活动;

活动社群;

小程序;

社群矩阵;

用户管理;

运营指数。

短期活动

选择短期活动作为整个体系的入口,是因为公司运营团队之前一直都在做的事情,如果需要推行这套体系,原有的工作尽量保持不变。

而且短期活动本身也有很多的优点:

短期活动让新用户的参与压力,团队的持续运营压力都比较小;

短期活动每次结束后,能够及时复盘,也能不断改进活动形式,优化活动质量;

持续的输出高价值的内容也不现实,需要在非活动期,给团队预留相应的储备时间;

如果活动不能经常有新鲜内容,对老用户也会丧失吸引力,需要隔一段时间有新的活动来激活用户。

除此之外,通过宣传活动可以规避一些小程序的审核雷区,比如:常用的裂变机制、积赞砍价、提高用户参与度的激励机制,别看别人做得欢,但你做的时候未必让你审核通过。

活动社群

用户通过活动进入到活动社中之后,这是一个双方互相构建信任的阶段。优质的运营服务,活动内容,小程序体验都将会为之后的体系打下良好的基本。

而在这一阶段,小程序对于社群的依赖比较大,需要持续的督促用户来使用小程序。

一是让用户尽快的熟悉小程序的使用,培养他们的使用习惯;

二是从用户进入到这套体系开始起,尽量的使用小程序将会用户的行为有迹可寻。

对于社群运营而言,小程序丰富了社群运营内容,包括小程序内经常出现的Bug。

解决Bug比较比较有意思的是,团队因为没有QA人员,外加研发对于小程序的经验不足,我们的小程序即便是在发布时,也会有相当多的Bug。虽然在活动过程中这一点虽然非常让我不爽,但却变相创造了相当多的和用户沟通机会;并且能够及时为出现Bug的用户进行处理,处理得及时得当,用户的好感度和信任度UP。

小程序

小程序在整体体系中扮演的是骨架作用,将体系中的各个部分串联嫁接在一起。对于用户是提供服务,解决用户需求;对于团队而言,是个默默的记录仪,而不是个筛分工具。

作为筛选工具的小程序,最简单粗爆的作法当然是下面左边这种,一上来就问用户的户口,迎面扑来了一种饥渴感。

上右边是我们其中一款学习型小程序的使用数据,截取的时候已经是长线运营时期,每天用户需要在十几页面中停留,总计从高峰的人均1400秒到现在的700秒左右。相信有经验的同学,会有足够的时间、空间、数据积累来完善用户画像,识别用户身份和价值。

社群矩阵

由活动社群到社群矩阵我用沉淀这个词,主要有三层意思:

一层,活动用户沉淀,顾名思义;

二层,系列活动社群沉淀,是系列活动本身每次都会创建新的社群,形成一个同系列的主题矩阵;

三层,是不同的活动主题,本身会构成不同系列的社群矩阵。

这里就根据大家各自的团队实际情况,是做专一点还是做宽一点,选择做两层还是做三层了。

社群矩阵在有小程序的加持下,维持住用户并不困难:

社群因为有小程序的存在,给了社群一个继续运营的理由。用户会觉得你每天把更新的内容放在社群里是之前活动的一种理所应当的延续,也是非常认真负责的表现;

用户因为有小程序的存在,有留在社群的理由。只要用户最初参与活动的目的还在,当用户遇到问题的时候,用户需要有个提问的出口。这时候,因为我们的持续运营,让这个社群看上去是个活的,有人冒泡的,往往将会成为用户的第一选择;

如果你有多个不同的主题社群,能够把握住用户的机会也会更大一些。

用户管理

在这套体系之前,用户仅仅只是一个微信号,社群之间也是没有联系的,管理后台无法获取用户的微信,如果只能通过用户昵称来定位也会变得难以琢磨,具体可以看下图(我们粉丝自己建立的熟人小团体),以上种种都会带来大量统计上、管理上的困难。

所以为了构建相应的用户管理,主要在小程序的管理端,会有以下几个工作:

学号体系,每一个进入到体系内的用户,我们都生成一个由小到大的五位ID,跟用户在开发者平台下的UnionID一对一映射。这样我们可以从几十个社群,几万名用户当中,快速的找出我们需要的用户。

用户画像,通过在小程序中设计的各种标签系统(而不是简单粗爆的问卷表单),用户会打上越来越多的标记,这样无论流量多大,我们总能有序有效的对用户进行筛选

用户记录,服务一名用户经常需要多个同事来协同完成,在此基础上建立的用户服务记录也是很件很自然的事情。比如:查询用户的学习记录来提醒用户及时学习,之前的服务情况来判断用户价值等。

权限管理,社群中经常打广告的用户也会我们打上相应的标签,再也无法报名新活动,需要改学号的社群也会被及时清除。

这些都让整体社群的规模效应得到充分发挥。

运营指数

如果想不断提升品牌的口碑,不断的修正和调整活动是非常有必要的。问卷调查虽然可以了解一部分用户的想法,但更为真实的则是用户自己用户脚投票的行为。

之前文中也提到,活动需要不断的改进,那么在这套体系下的活动将会提供更为强大的数据支持。这在一两年前是比较难做到的,但现在有了这套产品运营体系,通过前面用户的数据积累,将给我们更多的社群运营和活动运营的观察维度。

最新的渠道借给的流量精准度;

各期活动的报名具体人数;

用户在整体体系内的停留时间,活跃周期,活跃的时间点;

[]活动之间的人员留存比,人员是由哪些之前的活动构成的;

整个体系下每天的新增和日活;

结语

最后想说的是,有同学可能会觉得这可能没什么了不起,就是小程序+社群运营而已,没有大数据分析,没有人工智能的自动应答,没有区块链。但对于公司和团队来说,脚踏实地地选择最适合自己方案能够解决问题才是最重要的。

这种脚踏实地的难点就在于:

如何有效利用现有的团队资源和人力做出合理的方案,而不是去等待最优解;

最大化的整合团队的力量,将团队中不同项目组的特长发挥出来;

即要能满足当前需求,也要考虑未来的长远发展。

为了能够保证这一体系能够让团队能够稳定和持续的使用一段时间,就把这次的整体方案总结发上来和大家分享讨论,希望有人能批评指正。

请关注并询问集客宝智能名片。集客宝智能名片,一个拥有8大功能,60项黑科技的智能小程序

>

以上就是关于小程序里访问人数是新用户还是老用户全部的内容,包括:小程序里访问人数是新用户还是老用户、微信小程序访问人数多卡顿、微信及小程序有建群聊人数不上限的吗等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/web/9687817.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-30
下一篇2023-04-30

发表评论

登录后才能评论

评论列表(0条)

    保存