如何通过大数据用户分群实现精细化运营，从而更好的服务于现有的用户群体，就成了每一位互联网产品经理和产品运营的必修课。
题图来自Unsplash，基于CC0协议
2019年初，持续了20年高速增长的互联网行业似乎也踩了一脚急刹车。多家知名公司裁员，风投规模相较2017年同比下降了25.6%，人口红利的消失让产品拉新的成本越来越高，互联网从大肆烧钱，粗放增长的增量时代进入到精耕细作的存量时代。
在这样的背景下，如何通过大数据用户分群实现精细化运营，从而更好的服务于现有的用户群体，就成了每一位互联网产品经理和产品运营的必修课。
一、什么是用户分群
用户分群是指根据产品经理或产品运营指定的某些条件，将用户划分为特定的小群体，针对不同用户群体的特征采用不同的产品策略和营销策略，达到提高运营的效率，提升用户体验的效果。
用户分群的概念与用户画像有些类似，但也并不完全相同。用户画像是指由多个用户特征组合而成的虚拟用户，用于区分不同用户的人口因素以及在使用产品上的行为习惯，通常来讲对于一个用户的特征有完整且具体描述，例如一个电商公司的用户画像小明，他今年22岁，生活在一线城市，月收入约6000，在购物偏好上喜欢性价比高的产品，但也会对近期热门的网红产品感兴趣等等。
用户分群是对于具备某些共性特点的用户群体的组合，与用户画像不同的是，用户分群并不一定构成一个完整的虚拟用户，而是可以仅仅只针对具备某一特征的用户进行分群，例如运营希望提高消息推送的效率，可以对不同渠道的响应情况进行用户分群，将微信公众号，短信，APP消息推送，微博分别进行统计，看哪些用户响应了哪些渠道，在后续的推送中就可以根据响应情况，有针对性的进行消息推送，降低消息推送的成本，提高推送效率。
用户分群和用户画像的另一个差异点在于时间有效期，当用户画像构建完成之后，在较长的一段时间内不会有特别大的改变，但用户分群则可以根据业务需求的不同随时变化，例如当业务场景需要对昨天注册的新用户进行促活，或者对90天未登录的用户进行召回活动，对于“昨天新注册的用户”、“90天未登录的用户”这些分群条件所对应的用户就可能每天都在变化。
除此之外，用户分群还可以用于数据挖掘分析，针对不同用户的特点反推产品需求。同时用户分群还是个性化推荐系统的基础，基于同用户组之间的物品推荐以及协同过滤算法都需要先进行用户分群。
总的来说，用户分群较之用户画像来讲具有更灵活，更细致的特点，可以更好的满足不同用户个性化的需求，提高用户体验，以及根据不同用户特点选择合适的运营方案，降低运营成本。
接下来就让我们用一个案例，看看如何从0到1构建用户分群。
二、 用户标签体系
构建用户分群的第一步是构建用户的标签体系，这是精细化运营的基础。所谓的标签是指用户的某一个特征，这些特征根据不同的用户可能会有不同的值。举个简单的例子，所有人都有身高和性别这两项特征，但是不同的人之间身高和性别可能会不一样，通过不同的身高和性别可以帮助我们区分不同的人群。业内常见的做法是把标签分为三种类型，分别是事实标签，模型标签和预测标签。
1) 事实标签
用户的事实标签根据用户实际的情况以及实际的行为动作，分为人口属性标签和用户行为标签两种，例如一个人的性别，出生日期，籍贯等等就是人口属性，而一个用户在购买了某一款商品，关注了某一位大咖这些则是用户的行为。
事实标签是所有标签的基础，对于要收集用户的哪些数据则需要产品经理或产品运营根据自己产品以及用户的需求来定义，例如在电商产品中，用户查看商品，收藏商品，购买商品和退货等。在社交产品中，用户加好友，聊天互动，拉黑等都是非常关键的行为数据。
我们可以利用用户体验地图来帮助我们梳理用户在使用过程中与产品的接触点，将每个点产生的行为按照MECE原则进行梳理，相互独立且完全穷尽，做到不重复，不遗漏。
2) 模型标签
模型标签又叫规则标签，是根据用户的事实标签，由产品经理或产品运营根据自己对用户或行业的了解来定义的一些分群规则。例如某用户经常在促销的时候进行购物，购物行为本身是一个事实标签，但购买促销打折品则可以归纳为价格敏感型客户，这里的价格敏感型就是一个模型标签。又例如很多平台会构建用户会员等级体系，当用户的会员分达到一定数量的时候，就可以升级至对应的等级。用户获得会员分是一个事实，属于某一个会员等级则是规则模型。
模型标签的定义需要对行业和用户有足够深入的了解才能定义准确，一般都是由公司的产品专家来进行定义。当然也可以通过一些人工智能的聚类算法，例如K-Means，来辅助我们对事实标签进行归类。
3) 预测标签
预测标签是根据用户的模型标签，来预测用户未来的行为或偏好。例如用户通常的活跃频率是一周活跃2次，如果出现了一个月不活跃的情况，则预测这个用户即将流失，需要对用户进行挽回。流失行为这个事实是无法统计到的，但可以根据过去的活跃模型标签进行预测，这就是预测标签。
用户标签划分
除了这三种标签类型之外，如果我们的产品是可以不登录就使用的，那么除了构建基于用户注册账号的用户标签之外，还需要构建基于设备号的用户标签，例如很多网页都是不需要登录就可以浏览的，那么就可以基于Cookie来进行标签体系构建。
三、 埋点文档
当我们构件好标签体系之后，就可以通过数据埋点进行原始数据的收集了，这里我们用友盟移动统计（U-APP AI版）来举例，看看如何产出一份高质量的数据埋点文档。
首先点击官网中的开发者平台，并点击文档中心。进入文档中心后我们会看到包括APP、游戏，小程序等等集成文档。这里各个不同客户端的文档，对应的是不同的开发语言，我们就不一一查看了，以iOS平台为例来讲。
点击iOS集成文档，进到集成文档之后，最开始的这部分是在教开发人员怎么把数据统计的功能快速集成到自己的app里面，我们如果是做一款从0到1的产品，要做数据统计，只要告诉开发同事，我们要使用哪个平台，然后他就会自己找到这个技术文档来看，我们不用去操心这部分的事情。
重点是接口函数功能，埋点文档主要也就是为这个功能服务的。我们看到友盟将数据埋点分成了计数事件和计算事件两种类型，计数事件主要用于统计某一瞬时行为发生的次数，例如进入商品详情页，点击购买按钮等等。而计算事件则用于一些需要一定时长的操作，例如听音频的时间，或者浏览商品详情页的时间
通过查看埋点技术文档，我们可以知道友盟使用eventid来记录自定义事件的名称，使用label来记录自定义事件下的多个追踪项，所以eventid+label就组成了一个具体的事件名称。我们用“人人都是产品经理”APP的首页来做一个说明
人人都是产品经理
1) EventID
在第一列的EventID，我们定义页面的ID号和名字，这里我采用的是英文字母+两位数字的方式，可以通过英文字母区分不同的业务模块，数字区分不同的页面。
2) Label
第二列Label字段，定义的是用户在这个页面上的使用行为，因为Label是从属于前面EventID的，所以在功能点编号上也要继承前面的编号，例如阅读页的EventID是A01，那么阅读页下面的事件就是A01加上两位数的编号，这样可以很方便的查看事件的从属页面，特别是当有同一个事件在多个页面重复被调用的时候。如果两位数的编号不够的话可以再增加位数。
另外一个需要注意的点是，如果某个点击事件是进入到了EventID的子页面，那么这个事件Label的编号就自动变为这个EventID的编号，这样可以很好的体现上级页面与下级页面的从属关系。
但如果一个页面可以由多个Label事件进入，那么就不用这么处理，而是直接使用一个公共的编号就可以了。
例如做一个电商系统的埋点，商品的详情页可以从A01-banner，从A02-广告，从A03-商品列表，从A04-搜索，从A05-收藏等等入口进入，在不同的页面中这些入口的Label编号肯定是不一样，但商品详情页的EventID是唯一的。
3) 上报时机
第三列上报时机字段，需要说明这个埋点事件根据什么条件来触发，通常来讲分为显示时触发和操作时触发两种，前者看的是曝光量，后者看的是转化量，当有了全量的数据之后就可以用来构建曝光-转化的漏斗模型了。
对于平台之间差异化较小或没有差异的产品，例如iOS和安卓如果功能页面交互都一致，那么可以共用同一份埋点文档，但如果产品分布的平台较多，互相之间差异较大，例如既有手机APP又有PC客户端还有网页版，那么最好分不同平台来撰写不同的埋点文档。
4) 上线时间
第四列上线时间，这个字段是说明该埋点是什么时候上线的，有些团队会用版本号来说明上线时间，但我认为版本号有几个弊端，一是如果产品不同平台的版本号码不一致，会导致混乱，二是版本号无法体现埋点的生效时间，需要通过历史的产品文档查找到对应的功能才能知道，不够直观，所以我这边选择使用上线时间来作为埋点的生效时间。
5) 优先级
第五列是优先级，因为代码埋点需要开发人员花费时间来进行代码的编写，所以与功能需求池一样，需要标注埋点的优先级，以便开发人员根据优先级来评估工作量。我这里使用的是腾讯对于需求优先级的排列习惯，以P0为优先级最高。
最后一列是备注列，通常用来做一些备注的说明，例如某个埋点事件可以不再统计了,就可以写在备注说明里面。
四、自定义事件属性
如果仅仅只是按照这样撰写埋点文档，只能统计到事件发生的次数。而代码埋点的核心是自定义事件的属性，也就是在上报事件的时候，同时上报这个事件定义的属性。
还是拿人人都是产品经理的APP来举例，首页上有很多文章，所以会有一个点击查看文章详情的事件，但是要想统计到谁在什么时间点击了一篇什么文章，以便分析用户的喜好和使用习惯，就需要通过定义数据字典来给自定义事件添加用户是谁，点击事件，点击的文章ID这三个属性。
1) 什么是数据字典
数据字典是用来定义自定义事件属性的文档，通常和埋点文档放在一起通常有以下几个字段
数据字典
KEY：Key是数据字典的核心内容，表示的是属性的名称，例如如果要记录用户的ID，那么就需要定义一个名为User_ID的key,如果是记录文章的标题，则需要定义一个名为Title的key。
注释：对于key字段的解释，用来说明key值代表的是什么，便于后续的查询。
数据类型：数据类型分为名义数据、等级数据和连续数据三种，这三个数据类型的定义是基本的统计学知识，本文略去不表，标注数据的类型有助于后续的数据分析工作，
Value：Value是Key对应的值，有一些Key对应的是不确定的值，例如User_ID，有多少个用户就有多少个值，所以Value可以为空。但有一些Key的Value是限制在一定范围内的，所以需要事先对Value的可选择值作出定义，例如如果想统计一篇文章是否读完，可以定义一个Is_Read_Off的Key，那么对应的value值只有两个，是或否。
全局字段Global：在数据统计的过程中，有一些key值是需要所有的事件都要进行统计的，典型的例如用户的ID，为了节省时间，可以将这些key值定义为全局字段，这样就可以不用在每个事件当中重复填写了。
2) 如何给key命名
在给数据字典的key命名的时候，建议可以使用程序员给字段变量取名的常用方法，主要有两种:
驼峰命名法：驼峰命名法是最常用的命名方法之一，第一个单词以小写字母开始；从第二个单词开始以后的每个单词的首字母都采用大写字母,例如userName，这种驼峰命名法又叫小驼峰法。而大驼峰法，则是把第一个单词的首字母也大写，例如UserName
下划线命名法：下划线命名法就顾名思义，是在多个单词之间使用下划线来进行分割，例如如果定义用户名为UserName，那么用下划线命名法则会写为User_Name
我个人倾向于大驼峰+下划线的写法，当然，并没有强制的要求说字段命名一定要这么写，甚至写拼音也可以（就是显得有点low）。这两种命名方法是一种约定俗成的规则，只是如果你这么写的话，负责埋点的开发GG会觉得你很专业。
3) 将自定义事件的属性添加至事件中
基于这份数据字典，我们就可以给自定义事件添加属性了，在原有的埋点文档上添加一列Key/Value字段，然后把要添加的属性加入到事件对应的行就可以了。
添加Key/Vlaue字段
如果要统计的属性很多，可以使用分号或者换一行来描述，同时也可以在每一行后面写上这个属性是用来统计什么内容的，方便负责埋点的开发同事了解属性的内容。
五、创建用户分群
当埋点随着APP的发布上线之后，就可以根据收集回来的数据进行用户分群了，打开友盟管理后台，点击顶部的用户洞察tab，然后点击左侧菜单栏中的用户分群进入分群页面。
点击右上角的新建分群，并选择根据条件分群，在这个配置页面，我们可以给新建的分群进行命名，设置分群的次数是只计算一次还是每天都需要进行计算。并选择数据的时间范围。
而重中之重就是下面的条件选择器，我们可以将埋点的事件的触发次数设置为分群的条件，例如在一个月内查看了某个页面达到10次以上的用户。同时还可以将事件字典作为筛选条件，对分群规则加以限制，例如将不同地区的用户进行分群。
相较于其他平台，友盟的条件选择器还支持否定条件选择，不仅可以根据用户做了某些事情进行分群，还可以根据用户没做某些事进行分群，这一点在统计消息推送的效应率，转化率以及流失用户召回上非常有用。
对比传统的通过IT开发人员采数据的方式，友盟的图形化操作页面降低了操作难度，极大的提高了运营人员进行用户分群的效率，并且支持根据分群的结果对用户进行消息推送，让运营人员再也不用辗转于多个平台和系统，真正做到了从数据收集，数据查看到数据使用的一条龙服务，
六、用户分群应用场景
用户分群在产品设计和运营过程中有非常大的帮助，下面举几个常见的用户分群应用场景：
1) A/B Test
在萌芽期的产品设计阶段，我们通常需要快速迭代，小步快跑的方式快速验证需求真伪。但是对于用户规模较大的成熟期产品而言，任何一个细小的改动都有可能对全平台的用户产生非常大的影响。所以我们需要使用A/B Test来进行产品方案的测试，通过友盟便捷的用户分群功能，我们可以多次对不同的用户进行测试，直到找到最佳产品方案。
2) 精准推送
消息推送是产品运营常用的运营方式，但是传统的对全平台用户推送统一消息的方式效果往往不佳。现在，我们可以通过用户分群进行精准化的消息推送，同时还可以结合A/B Test的思路，对推送的文案进行测试，看哪种文案更能吸引用户。也可以针对推送的时间进行测试，看什么时间给用户进行消息推送的转化率更高。
3) 黑名单用户
在产品的风险管控中，羊毛党是对产品有害的一类用户群体，我们可以根据用户的行为数据对羊毛党进行甄别，防止羊毛党对于正常用户以及公司利益的侵害。
4) 数据分析
用户分群还可以用户数据分析，例如产品的销售下降时，可以通过用户分群来查看销售下降的原因主要在哪部分用户群体，并针对这部分的用户群体做运营方案，防止销售的进一步下降。
5) 社群运营
我们可以根据不同用户的偏好特点，划分不同的用户分群，而这些分群则可以成为社群运营的基础，将相同偏好的用户聚集在一个社群当中，有针对性的进行社群话题的运营，保持社群的活跃度。
6) 财务评估
在设计运营预算的时候，我们通常需要估算运营的成本以及ROI，例如给用户发放优惠券，在没有进行用户分群之前，很多公司都是给平台上所有的用户统一方法等额的优惠券，这种统一的方式一方面成本很大，另一方面用户的响应率也会比较低。那么我们可以根据用户分群，来对不同的用户群体发放不同等级的优惠券，同时，因为我们有了分群的人数数据，所以可以很方便的估算财务的预算，并且通过屏蔽羊毛党用户，进一步降低了运营成本的同时也提高了运营的ROI，一举两得。
七、用户分群注意事项
1) 样本量要足够大
用户分群的本质，是因为产品拥有了大规模的用户，而用户与用户之间对于产品的偏好和行为上有所差别，所以才需要针对不同的用户进行分群，满足用户的个性化需求，这里的首要条件是大规模用户，如果一个产品的用户规模并不是特别大，那么可以先将重点工作放在扩大用户规模上，将用户分群的工作留到用户规模达到一定程度了之后再做。
2) 控制潜在的因素
在我们进行用户分群的A/B Test实验时，需尽量控制潜在的影响因素，最好能确保实验组和对照组的用户除了实验的参数不一致以外，其他的数据都是相同或近似的，只有这样才能确保两组之间的差异是因为实验的不同导致，而不是因为其他一些潜在的影响因素。
3) 尽量使用平常的数据
在进行用户分群时，需尽量使用平常的数据，避开特殊的时间段。例如电商领域的双11就是一个需要避开的时间，这个时间内产生的用户数据并不能代表用户平时的行为偏好。
八、总结
对于产品经理来说，用户分群不仅仅是一种用来提高产品运营能力的工具，更是一种对待用户的态度，当我们面对纷乱复杂的用户需求时，需要保持一颗满足用户需求的初心，即使这个过程需要我们付出很多，但当用户对我们看到用户喜悦的笑容时，我们会相信这一切都是值得的。
作者：黄瀚星
本文为「人人都是产品经理」社区和友盟＋联合举办的“2019「友盟杯」数据分析大赛”中获奖作品，未经作者及平台许可，禁止转载
本文部分数据有脱敏处理，非全部真实数据
有关产品测评大赛合作事宜，请联系邮箱：denis@woshipm.com
网友评论