小红书如何实现用户群体粉丝化,围绕用户的转化而升级

Posted 2023-04-05

参考技术A 一个账号的运营，我们一般把它分为两个部分：

①内容创作：图文/视频的输出，包括脚本、文案撰写、拍摄、后期美化等工作。

②平台玩法：平台规则、涨粉机制、推荐机制等。

内容创作和平台玩法，其实是相辅相成的两个东西。抛开其中一个单独谈另一个，都是耍流氓。

我们以结果导向，倒推拆分，看看这个平台怎么玩。

先看看小红书的涨粉逻辑：

小红书虽然是一个开放的社交平台，但它的流量，也分为公域流量和私域流量。

而根据用户的使用逻辑，会有一个公域流量——私域流量——粉丝流量的用户关注转化过程。

先说说公域流量：①首页推荐、②搜索

1、首页推荐：首页推荐是小红书的主要流量来源，占据了平台80%的流量。剩下20%不到的流量，才是用户搜索、关注、同城等行为。

用户打开小红书，在首页推荐上看到你某一条内容，被吸引了，点进去，觉得，诶？账号不错。点开你主页，看看往期内容，都很对胃口，点个关注，方便下次直接从关注列表里找到你。到这里，就完成了粉丝的关注转化。

根据小红书的首页推荐机制，粉丝下一次点开APP时，推荐页上也会优先呈现你的内容。

2、搜索流量：这种流量，一般来自于目的性比较强的用户，比如五一想去四礵列岛，在搜索框输入“四礵列岛”，点进某一条笔记，觉得内容不错，又看了你的其他的笔记，觉得这个博主不错，点了关注。

从被你的某一条内容吸引，到关注到你的账号成为粉丝，这个就完成了用户关注的转化。

明白这个逻辑之后，那涨粉的关键就在于，怎么提升用户关注转化？

当然是提高自己上推荐页的概率，以及用内容吸引用户。

这里涉及到一个Feed流流量。

怎么做，才会让平台给到Feed流流量？前面说过，小红书的首页推荐，占据了平台80%的流量，在不愿意花钱投薯条的情况下，我们需要做的，是以下6点：

1、遵守社区规范

小红书的热门推荐机制，和内容关键词、笔记质量、热门标签及账号权重环环相扣。下面会分别讲到。但遵守社区规则，是一切的基础。

①原创，真诚分享

②避免修饰过多。之前小红书的“滤镜景点”，让小红书陷入舆论危机。平台现在主张美化有度，不能误导他人的分享原则

③避免使用夸张、猎奇的手法

④禁止销售高风险内容，如医美整形、医疗器械、代购拼单及发布个人联系方式、其他平台联系方式等。

2、提升账号权重

这个其实就是提升你账号在平台的可信度。和知乎一样，小红书也有自己的等级制度，你在这个平台越活跃，等级越高，账号权重就越大。

①平时可以保证每天的浏览量和发布量，有兴趣的话也可以参与一些平台的活动，既能提高账号知名度，又能升级。

②保证持续稳定的原创输出。

这是比较基础的账号工作，这里不做赘述

3、关键词定位

用户发布的笔记，平台经过算法识别以后，会推送给目标用户。如果没有对内容进行关键词定位，那平台只能根据我们的内容，去自己测算，可能会出现定位不准的情况。

那怎么帮助平台加速识别对我们的定位呢？设定关键词。

具体怎么操作？

①在小红书搜索框上，输入一个关键词，比如说旅游，或者保时捷，在下拉选项中出现的，都是用户搜索频率比较高的关键词。

②在小红书首页的上方，点击官方分类频道，找到对应类目，看看别人和你类似的内容里，插入了什么关键词。

③应景、应季关键词

防晒都和夏天有关，清明多和踏青有关，五一多和旅游有关，在设置关键词的时候，除了上述两个方向，还可以从季节变化角度切入，从场景上为用户营造需求。

在笔记中植入平台已有的关键词，能帮助我们更好地被平台识别归类，进入公域流量池的概率更高。

4、账号定位垂类化

这个涉及到内容创作方面。

和抖音、B站不一样，小红书的定位是图文种草平台（现在也在往视频方向发展）。

内容创作，包括了封面、标题、内容、排版上的细节，因为本篇讲的是如何涨粉，所以变强斯基在这里对内容的细节不做赘述，但要强调一下，做账号一定要垂类化。

设想一下，如果用户是被你的护肤内容吸引进来的，那是不是说明，这个用户平时就对护肤信息关注的比较多，她想看的，其实就是这类信息。

假设她点进来，看见你今天分享的是护肤，昨天分享的是求职，前天分享的是发型。内容杂七杂八，那八成对你不感兴趣，不会点击关注。

因为小红书的的性质，是一个种草平台，不少用户是带着目的打开APP的，和抖音的泛娱乐化性质有些不同。用户对内容的追求会更垂直。

你要做什么内容的账号，就在这个领域里，持续不断地输出，平台会根据你的定位，把你推送给需要的用户。

5、账号内容差异化

举个例子，同样是说女生的鲻鱼头，为什么这条内容的点赞量就能到9.5W？因为其他内容从封面上看都差不多。这条视频内容和其他视频打了差异化，用“一刀剪出狼尾头”的标题和女生夸张的动作表情吸引了你的视线。

如果你的内容，在同垂类账号中，做出了差异，那必然会吸引到粉丝关注。

6、提高用户互动率

互动数据，是指内容发布到平台上以后，粉丝的打开、点赞、评论、收藏数据。数据越好，平台就会把它推荐给越多人。越多人看到你的内容，就会有越多数据，随之吸引更多粉丝。账号就像滚雪球一样越滚越大。

听起来是不是很绕？机制就是这样的。

那怎么提高互动数据？

①引导评论、点赞

可以在笔记中提出一些简单易答的问题，引导用户参与评论互动。比如说，你用过的好用的精华有哪些？下期想看什么内容？记住问题要简单，太复杂的问题，用户还要动脑子去思考，就不跟你互动了。

②评论区管理

会在你评论区留言的，多是认真看完了你的笔记的用户，谁都不希望自己发出去的消息没人回。记得及时查看评论区消息，并进行友好回复。

小红书 x DorisDB：实现数据服务平台统一化，简化数据链路，提升高并发极速查询能力...

小红书是年轻人的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在2017年后，随着业务类型和用户体量的爆炸式增长，各类数据分析的需求以及应用系统的数据需求快速出现，例如：商业智能分析，数据应用报表，用户行为分析、算法策略数据等。小红书大数据团队逐步引入了多种OLAP分析引擎来更好的满足需求。DorisDB采用了全面向量化的计算技术，是性能非常强悍的新一代MPP数据库。通过引入DorisDB，小红书构建了全新的统一数据服务平台，大大降低了数据链路开发复杂性，提升了高并发极速查询能力。

“  作者：吴浩亮

   小红书大数据团队，数据仓库架构师  ”

OLAP引擎在小红书的演进史

第一阶段，在2017年之前，数据总量还不是特别大，这个阶段使用AWS的Redshift，此时数仓体系还没有完全建立，很多数据需求的实现都是用短平快、烟囱式开发的方式来满足。数据ETL、数仓模型到最后报表端展现，在Redshift中一站式完成。

但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。主要有以下问题：

• Redshift无法在不影响线上查询性能的前提下弹性扩展，一旦涉及到扩容，就会涉及到数据重分布，从而影响集群的性能以及可用性。

• ETL任务严重影响集群可用性。在Redshift中同时进行ETL任务的时候，会大量抢占资源，从而影响数据分析的效率，导致查询超时甚至因为集群负载过大后整个集群崩溃不可用。

• 没有良好的存算分离，数据存储容量存在瓶颈，无法满足随业务而快速增长的数据量存储需求。

第二阶段，随着数据仓库在Hadoop/Hive体系上搭建和完善，ETL任务全部转移至Hadoop集群，这个阶段使用Presto完成OLAP分析。Presto天然和Hive共享元数据信息，且共同使用物理数据存储，即插即用。大量的对数仓表的灵活查询使用Presto完成。

第三阶段，业务实时性增强，对查询性能的要求不断升高，同时许多数据应用产生。这个阶段引入了ClickHouse，用来建设性能更强悍，响应时间更短的数据分析平台以满足实时性要求。

第四阶段，小红书大数据团队进行了实时数仓的整体设计和搭建，同时为统一对各业务团队提供数据接口而构建了数据服务平台，外接了多个内部或者To B服务的应用系统。既需要做低延时的复杂查询，同时对并发量也有很高的要求。这个阶段我们又根据场景引入了DorisDB，以满足以上各类需求。

小红书数据分析体系架构

小红书OLAP体系现状

小红书的整个数据分析体系，由数据采集、数据存储加工/数据共享和应用层组成。

数据采集

服务器日志或者App日志通过Flume收集埋点日志，数据同时分发到离线存储S3和实时存储kafka；线上业务数据库通过Canal实时采集MySQL binlog等信息。

数据存储加工

离线数据处理：利用Hive/Spark高可扩展的批处理能力承担所有的离线数仓的ETL和数据模型加工的工作。

实时数据处理：Flink完成实时侧数据的ETL（包括维度丰富，双流Join，实时汇总）；离线表通过调度平台同步到ClickHouse/DorisDB，Flink实现了ClickHouse和DorisDB的sink connector，落地到DorisDB或ClickHouse。

数据共享

数据共享层的主要提供对外服务的底层数据存储,离线或者实时的数据写入相关的数据库组件中，面向多种服务，不同场景提供查询能力。

数据共享层主要有TiDB/Hbase/ClickHouse/DorisDB。通过DorisDB和ClickHouse提供的高速OLAP查询能力，在应用侧承接了报表平台，提供即席分析的平台，对开发侧提供数据接口，以及实现多个数据产品（比如流量分析平台，用户标签平台）。

应用层

应用层主要为面向管理和运营人员的报表，具有并发、延迟、需求更新频繁等要求，面向数据分析师的即席查询，要求支持复杂sql处理、海量数据查询等能力。

各OLAP分析工具选型比较

Clickhouse：

优点：

• 很强的单表查询性能，适合基于大宽表的灵活即席查询。

• 包含丰富的MergeTree Family，支持预聚合。

• 非常适合大规模日志明细数据写入分析。

缺点：

• 不支持真正的删除与更新。

• Join方式不是很友好。

• 并发能力比较低。

• MergeTree合并不完全。

DorisDB：

优点：

• 单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。

• 支持高并发查询。

• 支持实时数据微批ETL处理。

• 流式和批量数据写入都能都比较强。

• 兼容MySQL协议和标准SQL。

缺点：

• 周边生态比较不完善。

• 部分SQL语法不支持。

TiDB/TiFlash：

优点

• 支持更新/删除。

• 兼顾了OLTP的需求。

• 支持Flink  ExactlyOnce语意，支持幂等。

缺点

• 查询性能弱，无法较好支持OLAP查询场景。

• 不支持实时预聚合。

• TiFlash暂时不支持所有的SQL写法以及函数。

DorisDB在广告数据中心的应用实践

业务场景概述

广告业务的核心数据有两大块：一个是广告的曝光点击流，即所有广告单元的展点销信息；第二个是广告效果归因数据，比如说在小红书站内的订单转化，相关表单提交，笔记的点赞、收藏、加关注等参与程度。

基于这些数据，根据不同的业务场景需求，实时汇总出相关业务统计指标，对外提供查询分析服务。

原有解决方案

技术架构

在引入DorisDB之前，是用大量Flink任务进行写入MySQL/Redis/HDFS/ClickHouse，以达到数据的落地。

Flink中核心处理逻辑有几类：

• 前端用户广告展示信息事件流和后端算法推荐流双流关联并去重，完善广告信息。

• 接入反作弊，清除作弊事件。

• 按不同业务场景需求汇总结果写入不同的数据库组件中。

技术痛点

原有架构主要有以下问题：

• 数据逻辑没有很好做归拢合并，维护工作量大，新需求无法快速响应。

• Clickhouse的并发能力不足以及扩容复杂度在可见未来会成为整体广告系统瓶颈。

• 因为Flink层逻辑散落，由大量小的Flink任务构成，因此导致整个架构无法满足高可用要求，只要任何一个任务出现问题，都会影响线上业务。

基于DorisDB的解决方案

因此我们希望对原有体系进行优化，核心思路是利用一个OLAP引擎进行这一层的统一， 对OLAP引擎的要求是比较高的：

• 能支撑大吞吐量的数据写入要求。

• 可以支持多维度组合的灵活查询，TP99在100ms以下。

• 有实时汇总上卷的能力，提高查询性能，支持qps达到上万的要求。

• 通过Binlog实时同步MySQL的数据，并及时对数据进行封装。

• 比较好的支持多表关联。

经过大量调研，DorisDB比较契合广告数据中心的整体要求。基于DorisDB本身高效的查询能力，支持高QPS的特性，可以为广告的算法策略、广告实时计费、广告平台实时的数据报告提供一体化服务。 

新架构具备以下优点：

• 结构清晰，Flink专注于数据的清洗，业务逻辑计算从Flink迁到DorisDB内实现，DorisDB就是数据业务逻辑的终点。

• 可以维护统一的数据口径，一份数据输入，一套广告统计口径输出。

• 在底层实现DorisDB主备双活，更好的支持高QPS场景。

数据表设计

数据模型设计

DorisDB本身提供三种数据模型：明细模型/聚合模型/更新模型。对小红书广告业务来说，三种数据模型各尽其用：

• 广告曝光点击流写入聚合模型，按照业务所需要的维度，如广告主、广告类型、创意，广告单元，搜索词，地域，用户属性等设计聚合的所有维度，根据所需要的指标进行聚合。

• 广告侧后端有很多的线上MySQL，通过DorisDB更新模型接入MySQL进行实时的表更新。

• 在Hadoop离线数仓中还定期统计了一些数据报告同步到DorisDB中，这些数据使用了DorisDB的明细模型。

数据分区/分桶

DorisDB提供的数据分区功能，可以很好的提升广告场景下查询的性能。例如，广告侧查询常见的一种查询场景，是查询过去某一段时间内的数据，我们可以在DorisDB中根据时间进行分区，过滤掉不必要的分区数据。另外，广告查询会根据广告主进行筛选，我们将广告主ID作为排序键的最前列，就可以快速定位到广告主的数据，DorisDB还支持按照广告主ID进行Hash分桶，减少整个查询的数据量进行快速定位，这对高并发场景也具有非常大的意义，尽量减少了查询语句所覆盖的数据范围，提高了并发能力。

物化视图

我们利用DorisDB物化视图能够实时、批量构建，灵活增加删除以及透明化使用的特性，建立了基于广告主粒度、基于用户特征粒度、基于广告单元粒度、基于具体创意粒度的物化视图。基于这些物化视图，可以极大加速查询。

数据导入

实时的数据导入分为两种：

• 有ETL处理需求的，会利用Flink进行ETL逻辑转化，使用Flink DorisDB Connector写入DorisDB。

• 在实时数仓公共层的，配置Routine Load任务，将数据10s一个batch写入DorisDB表中。

离线数据报告导入DorisDB：

• 在DorisDB提供的原生的Broker Load基础上在小红书数仓的调度平台上封装了导数模版，通过界面化配置的方式，将离线数仓的表导入到DorisDB中。

数据查询

在我们的查询场景中，广告主业务查询服务对查询并发度要求很高。DorisDB采用的是MPP查询架构，底层数据按照Range和Hash两级分片，非常适合广告主业务的查询场景。

内部做的线上查询压测结果，每个FE能到2000左右的QPS，整个集群能提供上万的QPS，TP99的查询在100毫秒以下。

系统运维

广告数据中心是非常核心的一个线上服务，因此对高可用及灵活扩容能力有非常高的要求。DorisDB支持fe/be多副本，没有单节点问题，当有节点故障的时候也可以保证整个集群的高可用。另外，DorisDB在大数据规模下可以进行在线弹性扩展，在扩容时无需下线，不会影响到在线业务，这个能力也是我们非常需要的。

总结

小红书从今年年初开始调研引入DorisDB，当前已经有五个DorisDB集群在稳定运行中，其中有两个开始稳定提供线上服务，三个还在试运行。引入DorisDB后，实现了数据服务统一化，大大简化了实时数据处理链路，同时也能保障较高的查询并发和较低的响应延迟要求，之后将用来提升更多业务场景的数据服务和查询能力。最后，感谢鼎石科技的大力支持，也期望DorisDB作为性能强悍的新一代MPP数据库引领者越来越好！