从用户扩张到技术更迭复盘社区的体系搭建

简介: 社区也借用了第三方数据产品——友盟+,不管是哪一家公司的数据产品,都会有对应的使用场景。在教育、医疗、金融等不同的行业,所用数据的使用目的都不同,用户分群而视之,如医疗行业是提高用户留存,金融行业进行网站优化、提高线索转化等,每个行业都有各自的数据优势。

作者:友盟+数据大使 kevin

如今,移动互联网的红利期接近尾声,导致整个市场增量放缓,“寒冬”一词不断被提起,使得更多的产品经理也都开始思考:到底该如何实现用户增长。虽然看起来如临大敌,不少人甚至不知所措,但其实,只要拥有正确的方法论指导,一切都将迎刃而解。

数据本身是没有意义的,用数据带来直接转化才有效,这也是为什么很多团队做数据产品或者数据运营时,想用数据驱动业务却一直做不起来的原因。

以一个产品社区为例进行分享,可分为四个板块:

第一,产品设计。在没有数据的时候,如何从0到1做产品数据;

第二,数据场景设计。每访问每一款产品时,每一个场景里如何设计数据是非常重要的;

第三,当前设计的场景好不好,怎么用数据迭代;

第四,社区产品的应用性能设计。

1.jpg

当从0到1做一个互联网产品时,首先要明确需求,即idea。在idea范畴中,社区小程序中有作者、游客、会员、平台运营,各具职能;其次,重视互联网产品的数据问题,如指标定义,现在很多企业内部都定义不出指标,原因如数据不准。每个公司的DAU定义和活跃度标准也都不一样;然后是有缺乏数据的情况;最后是怎么应对“脏乱差”的数据和应用性设计情况。

社区从0到1的搭建思路

社区在创业初期一定是摸着石头过河的,不断在反思数据产品跟市场情况。去年社区营收指标比前年翻了2倍,但运营效果并不好,我们就开始倒推,判定是否方向或指标出现了问题。

2.jpg

目前,社区的小程序产品里记录着用户登录、注册以及报名活动流程。组织用户报名、参加活动,进行线下活动交流,以及引导用户回看录播视频。但从数据看到用户并不会在小程序支付,这也启发我们开始社区在数据指标埋点前进行事件定义的想法。

社区从微信小程序点击、广告位点击,再到活动报名详情,顺序是从左到右,暗合了用户大脑里起点到终点的路径。

3.jpg

社区也借用了第三方数据产品——友盟+,不管是哪一家公司的数据产品,都会有对应的使用场景。在教育、医疗、金融等不同的行业,所用数据的使用目的都不同,用户分群而视之,如医疗行业是提高用户留存,金融行业进行网站优化、提高线索转化等,每个行业都有各自的数据优势。

比特币最近很火爆,试想比特币量化投资能不能在金融或者网站里全程追踪用户行为?数据模型设计思路有全程追踪用户行为之后,增强用户在站内浏览体验和内容交互,提高用户注册率,最终转化为交易所或者券商用户的新订单。这也再次表明,在每个行业里,各自数据模型的不同。

4.jpg

关于数据可视化,今天是1.0,明天就可能是1.01,后天是2.0。每个版本当前的数据表现,都是互联网团队的核心KPI。他提到,自己在做产品经理时,经常有被问及产品指标是什么?每个版本在数据可视化上都清晰可见。而这里会涉及到提供不同行业的专属看板,比如TOB公司,相关方要去做数据专项化设计。比如社区在互联网企业咨询服务上有医疗、金融企业,但行业的关注点也不同,但却可以发现用户的需求点。

同时,可以借鉴如阿里、腾讯、百度等平台,分析他们对应的核心业务路径,再通过调研,快速确定事件定义的想法。

社区的核心与观察

社区的核心是版本的优良率,这会涉及产品稳定性检测,主要分为以下几块:

第一,错误次数采集和错误分析管理。定义产品UV会面临很多情况,我们要考虑它的错误日志,比如崩溃自定义意向。

第二,产品稳定性检测要与数据可视化结合起来。可以借用第三方的数据工具快速搭建数据平台,节省成本提高效率。

企业日益增长的数据应用需求和当前App产生的各种矛盾,会产生产品应用性能监测需求。在应用性能检测中就涵盖了敏捷开发测试、监控、分析和修复,并且都会考究对于工具的选择。
5.jpg

对产品稳定性检测意义体现在对高并发趋势的观察上。一旦用户选择10万、7万公众号或者媒体矩阵进行推广,随之而来的是流量的马上上涨,用户点击率增高,这就是高并发。这时,可能会存在没有处理好用户体验的问题。

6.jpg

社区用数据驱动时,产品发生了显而易见的裂变。

裂变方式是从左到右的,比如一些自设社区或付费社群里,用户通过扫朋友圈进H5页面的二维码;接着,在社群中,相关方通过进群宝这种机器化社群工具进行自动营销;最后,操作者便模拟出让用户进入社群的一系列操作。

社区数据驱动裂变有一个北极星指标,记录用户的真实发帖数。社区大概有800多名作者发帖,通过H5、注册账号、创建项目,到用户使用或者会员付费定义北极星指标,每个节点都会对应一些数据指标。

7.jpg

社区裂变会设计一些从左到右的路径。这些路径就是用户端扫码、发消息、点击、返回、退出、付费、支付、退货等行为。社区还会把不同节点制成一张图,其中,标红的是一些系统级判断,比如用户归型和成功购买页面;标黑色的是当前用户状态,同时会区分开来系统层面和用户层面,然后规划路径图,选择对应的数据驱动方式。

8.jpg

如支付宝,将手机充值助手优化为仅含充值助手,同时增加了广告位的布局,把页面的落地页放在中间,这其实是分解了一些北极星指标的。它的日活×交易转化率×营收=新增用户数。裂变需要注意规律,这是可以用数据可视化去观察的。

社区的版本与管理

数据驱动分为三个版本,很多时候互联网团队一开始是不知道怎么去定义自己当前的版本,他建议大家可以拆分成1.0、2.0、3.0阶段,建立从付费到免费的过程,见证产品迭代升级。

第一、1.0阶段:产品核心问题,即提供给用户的核心价值是什么?核心价值以什么形式提供给用户,以及如何让用户认同,这是1.0。1.0不考虑赚钱,而是考虑提供给用户的核心价值是什么。1.0的时候可能会有一些营收,但一般情况下,它更多是处于亏钱状态。但营收和亏钱是两码事。

9.png

第二、2.0阶段:主要解决规模化运营,这个阶段一定要有营收,而不是亏钱。这是拓展新用户、留住现有用户,以及招回流失用户和高效将用户规模做大的阶段。

第三、3.0阶段:在2.0到3.0的过渡中,是一个团队创建的过程。以前一个团队可能运营人员也是客服人员,客服人员也是运营人员,产品人员也是运营人员,运营人员也是产品人员。一圈看下来,除了老板不是客服,或者可能老板也是客服,整体来讲,团队结构会很乱。现在通过这种迭代之后,有人会发现产品运营和团队发展的规律,指示大家按照各自业务场景展开工作。每个团队的2.0版本迭代,都有对应的负责人去落地。

最后,产品形成一个标准用户Usual Cycle(用户生命周期)。通过这样的用户生命周期去解决留存、拉新、回流问题。3.0阶段下,用户从浏览到分享、传播,再到获取,构成产品/社区运营生态。

10.jpg

就互联网团队来说,如果某团队只有20个人以下,或某项目的人数在20人以下,建议采用Strum方式。同时,把荣誉、参与感和团队归属感做到最好。现在,年轻团队一定要注意,如果一味给人员讲工作是行不通的,反而大家会欣赏你或者团队成员而愿意工作,这是年轻化互联网团队管理的优势。

相关文章
|
6月前
|
消息中间件 存储 缓存
阿里P8架构师带你“一窥”大型网站架构的主要技术挑战和解决方案
传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非功能性需求;功能性需求也许还有“人月神话”聊以自慰,通过增加人手解决问题,而非功能需求大多是实实在在的技术难题,无论有多少工程师,做不到就是做不到。
|
存储 监控 架构师
十年业务开发总结,如何做好高效高质量的价值交付
软件交付是一个非常复杂的过程和体系,需要保障好每个阶段的质量和效率才能保障最终的质量和效率。本文将尝试从需求交付的前、中、后三个环节来阐述一下如何做高效高质量的价值交付。
142429 3
|
运维 监控 负载均衡
《泛娱乐行业技术服务白皮书》——四、泛娱乐业务保障与调优最佳实践——4.1游戏运维SRE实践——4.1.1 制定SRE黄金准则
《泛娱乐行业技术服务白皮书》——四、泛娱乐业务保障与调优最佳实践——4.1游戏运维SRE实践——4.1.1 制定SRE黄金准则
146 0
|
运维 监控 Cloud Native
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力
《必致(BizDevOps)白皮书2022》——04必致(BizDevOps)实践案例——4.2 案例二:阿里巴巴,以应用为核心打造持续业务交付能力
434 0
《云上大型赛事保障白皮书》——第二章 云上大型赛事保障体系——2.4 云上大型赛事保障方法论——2.4.1 赛前全局梳理
《云上大型赛事保障白皮书》——第二章 云上大型赛事保障体系——2.4 云上大型赛事保障方法论——2.4.1 赛前全局梳理
784 0
|
达摩院 架构师 Cloud Native
数智洞察 | 企业背后的驱动力——探索阿里的超大团队管理秘籍
编者按: 当一群高智商、高薪酬的人聚在一起,是脑力的风暴还是角力的漩涡?是在冥思苦想还是在浑水摸鱼?这很大程度上决定了一家公司的生产力。 本文揭秘阿里巴巴的研发团队,看阿里云智能总裁、达摩院院长张建锋(花名行癫)如何管理超大规模开发团队。
374 0
|
前端开发 搜索推荐 小程序
蚂蚁P10玉伯的产品思考:技术人如何做产品
蚂蚁P10玉伯的产品思考:技术人如何做产品
308 0
严选售后服务架构演变之路:把复杂业务做简单(2)
严选售后服务架构演变之路:把复杂业务做简单
131 0
严选售后服务架构演变之路:把复杂业务做简单(1)
严选售后服务架构演变之路:把复杂业务做简单
118 0
|
机器学习/深度学习 人工智能 监控
作为今年业务流程领域最热的技术赛道,国产流程挖掘都有哪些特点与优势?
以艺赛旗iS-RPM为例,聊聊国产流程挖掘产品的特性与优势。
542 0
作为今年业务流程领域最热的技术赛道,国产流程挖掘都有哪些特点与优势?