APP推广合作
联系“鸟哥笔记小乔”
游戏运营的数据分析(多维数据分析平台在37手游的技术演进)
2022-11-10 21:27:23

多维数据分析平台在37手游的技术演进

游戏运营的数据分析(多维数据分析平台在37手游的技术演进)
  导读:本次从工程的角度分享一下多维分析平台在37手游的技术演进。本次分享分为以下四个模块:

  37手游业务背景37手游多维分析的实践多维分析技术的业务化和普惠化多维分析平台服务保障--

  01

  37手游业务背景

  首先介绍一下业务背景。

  1. 37手游简介

  37手游是一家游戏发行公司,累计运营的游戏大概有 2000 多款,月活用户在3000万左右。37手游数据需求场景特点,和很多公司都有共性,但本身业务的特殊性也导致了跟其他公司在技术选型上有差异。

  发行的不同游戏可能对应不同游戏研发商,数据来源多样且复杂,数据格式多样;广告投放对接众多外部媒体,不同媒体数据格式、数据时效、数据对接方式差异很大。2.37手游数据分析场景特点

  37手游数据分析的业务场景有如下特点和挑战。

  第一个特点是时效新:比如在广告投放的过程中,需要对广告投放消耗数据进行实时追踪,以及广告投放消耗之后的效果数据进行实时分析;还有游戏运营内部的实时分析,比如进行了某个活动投放,运营人员需要实时知道某个投放活动的效果怎么样。

  第二个特点是维度多:广告投放很多时候要精细到特别细的一些维度,不仅有非常多的广告计划,还有非常多的广告创意,并且同一个广告计划里面可能会有不同的图片,不同素材,按照游戏包+广告投放渠道+广告投放计划+广告投放素材维度排列组合后就会存在一个维度爆炸的问题;另外一个点是历史快照数据更新问题,比如某个广告投放计划原来在某个投手下面,后来变更到另外一个投手下面,从广告追踪的角度来讲,需要回溯历史数据,也就是说现在的一些效果数据(如游戏充值付费)应该归因到新的投手下面时,就会存在历史数据维度更新的问题。

  第三个特点是大数据量:比如基于用户ID+游戏包维度+广告投放维度进行精准去重,根据用户的行为数据,登录充值等,需要归因到是哪个广告或者素材带来的,就会涉及到大量的关联操作和去重操作,计算量很大;如果此时查询并发比较高,那整个集群就很容易出现资源上的瓶颈,导致系统变慢,影响整个业务查询体验。

  --

  02

  37手游多维分析实践

  1. OLAP在37手游的演进

  37手游多维分析的架构选型是跟随公司的业务发展特点进行演进的,为了保证系统性能和SLA,新的业务场景要求引入新的组件来解决特定业务场景问题。在架构演进过程中,主要从计算能力、查询性能、架构简洁性、可扩展性、稳定性、可维护性等维度考虑架构和组件的选型。

  2018年以前,当时业务的数据量相对比较少,很多业务场景是报表查询,此时只需在数仓的建模后,将ADS层的数据推送到MySQL中即可,因为数据本身聚合之后数据量也不大,MySQL够用。随着业务的精细化运营以及数据量增加,MySQL就逐渐顶不住了,另外用户的行为数据分析,无法用MySQL支撑,因此引入了Druid来应对用户行为分析的场景。

  2019年之后,有些业务场景的数据分析采用了Impala,后面会详细讲解。

  2020年之后,之前的架构无法支撑业务发展,就引入了Clickhouse,从最开始单机Clickhouse到ClickHouse集群,主要应用在报表查询和自动投放等业务场景。

  在2021年到2022年期间,引入了一些第三方商业化的工具,包括公有云厂商的一些组件,阿里云ADB、Hologress等,还有最近一两年热门的StarRocks等,用于针对性地解决某些特定业务场景问题。

  2. OLAP平台与数仓

  提到多维分析和OLAP,就不得不提数据仓库。通常经过ODS到DWD,再到DWS,再到ADS层数据建模,经过一系列ETL操作,最终ADS层数据推送到OLAP查询层,供应用层查询。

  下图就是37手游的数据仓库的总体架构图,数据从业务库MySQL和业务日志进来,经过中间的实时/离线数据仓库ETL 数据加工后,最终ADS层数据被推到混合OLAP查询平台,供业务查询。中间的数仓架构采用了Flink引擎,整体满足湖仓一体,流批一体的数仓架构设计思路。实时数仓使用Kafka作为存储层,实时数仓DW层会落一份数据到Hudi供数据分析使用。构建逻辑视图统一实时数仓数据表(kafka)和离线数仓表hudi(hive外部表)。通过统一逻辑视图,做到数仓流批一体存储层面的逻辑统一。其中混合OLAP查询平台,针对不同的业务场景,封装了不同的组件,不同的业务查询请求流量通过路由分发到不同的OLAP的查询引擎上。

  3. Impala读写流程

  Impala是37手游用来做自助式数据提取的计算引擎,下面简单介绍一下Impala的原理和读写流程。Impala主要包含三个组件:Catalog,StateStore,和ImpalaDaemon;Catalog把元数据分发到各个ImpalaDaemon;StateStore收集各个ImpalaDaemon的信息,如进程信息,各个节点的健康信息等,同时StateStore还负责请求调度;ImpalaDaemon对本地数据进行运算后,协同其他的一些ImpalaDaemon进行运算,最终把结果返回给客户端。

  上图是Impala的读写流程,首先客户端提交一个请求后,会对应产生一个Impala请求进程,该Impala请求进程会向StateStore提交一个注册信息,StateStore就会同时产生一个StateStore存储进程来创建多个线程来处理Impala请求进程的注册信息;接下来根据用户输入的SQL语句,经过Impala服务的三个模块:Query Planner、Query Coordinator和Query Executor的词法、语法解析后,拆成各个子任务,然后分发到各个ImpalaDaemon中去执行;各个ImpalaDaemon运算后的结果返回给协调器,协调器进行汇总,最后将结果返回给客户端。

  以上就是Impala的一个简单读写流程。

  4. Impala在自助取数平台的应用

  介绍一下Impala在37手游的自助取数平台的应用。

  业务团队经常会有各种各样的取数需求,取数需求会占用数据开发人员的不少精力。从收到业务团队的取数需求,到开发人员编写SQL到跑代码获取数据返回给业务需求方,经常会遭受业务团队的吐槽和催促:为啥取个数据要这么久。

  为了提高日常业务团队取数类需求的交互效率,37手游构建了自助取数平台。

  用户首先在自助取数平台上筛选维度、选择指标和统计口径。自助取数平台根据用户选择的这些条件进行解析,生成代码和任务,自助取数平台调度执行任务,其中SQL代码发送到Impala集群执行。任务执行成功后生成文件供用户下载。对于业务团队来讲,只需在自助平台上做一些选择,等待取数任务调度执行,之后下载获取数据,非常方便和快捷;对于数据开发团队来讲,减少了80%以上的取数需求,可以从SQL Boy的低效工作中解放出来,极大解放了生产力,从而释放出精力做更高价值的事情。

  5. Impala的优点

  自助取数分析平台的技术底座就是基于Impala的。为什么会选择Impala?首先Impala是MPP架构的,能够处理比较大的数据操作,而且是无状态的,节点挂掉后只需重启;其次是Impala兼容Hive存储,能复用Hadoop体系的存储能力,能避免像GP一样自成一套技术体系和资源体系;第三个点是Impala的高效查询性能,支持CBO、并行计算等,Impala的data location的IO协调机制是计算和数据尽可能在一个节点,减少网络开销,尤其在大数据场景下,非常节省网络资源;Impala的算子下推的特性能够保证非常高效的查询性能;最后一个点是Impala社区活跃度高,因为比较冷门的组件社区活跃度不高,在技术选型上会来带来一些不可控的风险。

  6. Impala的不足

  在使用Impala的过程中,也发现了Impala的不足。

  首先是单点问题,即Catalog和StateStored单点问题,虽然Catalog单点挂掉之后,对正在进行中的查询影响并不是很大,但可能拉取不到最新的元数据。

  第二个是资源隔离的问题,资源隔离不精确,并且资源不能通过YARN统一资源管理调度,无法实现Impala、Spark、Hive等组件的动态资源共享。

  第三个是元数据更新问题,无法感知HDFS操作,每当新的记录/文件被添加到HDFS中的数据目录时,需要手动去刷新元数据。第四个比较重要的点是Impala基于内存计算,速度很快,但存在风险就是内存会溢出,内存溢出就导致任务挂掉。另外Impala的并发能力比较有限,QPS稍高一点,查询性能下降明显。

  7. ClickHouse为什么快

  2019年后,37手游开始引入ClickHouse。当时ClickHouse是一个比较现象级的产品,非常快。为什么ClickHouse会这么快?

  ClickHouse实现了单机多核并行,还支持分布式计算,支持SIMD指令等,能榨干机器的性能,从而提升查询速度;ClickHouse支持多样化的表引擎,包括MergeTree等20多种表引擎,基于不同的业务场景选择不同的表引擎,可以带来性能上的提升;ClickHouse的索引机制包括主键索引,稀疏索引,能够提升查询性能;ClickHouse的向量化引擎能够在多数据流时,为上层应用的性能带来极大提升;ClickHouse是列式存储,自带数据压缩,列式存储更适合OLAP场景,再加上自带的数据压缩的处理速度,能做到百倍级别的性能提升;ClickHouse支持多核并行处理,单条SQL的执行会尽可能地利用更多的CPU核数,榨干CPU的资源来提升执行效率;ClickHouse还支持多服务的并行处理数据,数据保存在不同的节点不同shard上,查询可以并行地在所有shard上进行处理。8. ClickHouse在广告自动化投放平台的应用

  37手游将ClickHouse应用在广告自动化投放平台来做查询的加速。37手游的广告投放平台需要对媒体广告投放效果进行实时监控(比如在头条或腾讯的媒体上投放广告),广告投放之后就有广告费用消耗,同时也会拉来一些用户注册(即对应的广告效果),根据广告效果来调整自动化投放策略。未引入ClickHouse之前,面临着两个技术挑战:

  (1)业务数据的更新频率非常高,因为媒体广告投放时,投放资源时刻在消耗,需要实时拉取。

  (2)多表关联的问题:广告投放资源的消耗需要关联上效果数据,还要关联各种各样的广告数据,多表关联的效率就会比较低。

  针对这些问题使用了ReplicatedMergeTree表引擎。

  对于多表关联,根据相同的join key,哈希到同一个节点,以实现local join,以减少计算时数据做shuffle时的消耗;对于频繁更新的问题,将业务业务库MySQL的数据同步到ClickHouse,将Mysql的update/delete/+insert的方式变成clickhouse insert(append),构建历史数据和新增数据的视图,进行优化合并操作,因为历史数据不会发生变化,相对比较好处理;对于T-1或T的新增数据,只有一天的数据,数据量比较小,在进行更新操作时,取最近一条数据,然后两份数据合起来,我们曾考虑过用默认的replace来进行表更新,通过ClickHouse本身的一些机制来做数据合并,但因为业务数据插入的频率高,数据量大,ClickHouse数据合并是异步的,容易出现Merge不过来的现象。当然可以通过一些手段优化,比如optimize、final进行强制合并,但因为optimize不是一个常规操作,不能太频繁;在查询时,使用final来做合并,会影响查询性能,特别是在ClickHouse的早期版本,是单线程的,性能也不行。因此最终采用了ReplicatedMerge表引擎配合视图的方式。

  9. ClickHouse使用心得

  在使用ClickHouse过程中有一些心得。

  第一个根据应用场景合理选择ClickHouse,避免“让举重运动员参加长跑比赛”(避免让clickhouse干它不擅长干的事情),应多做短查询,避免大数据量的合并或频繁更新;数仓中的数据最好构建大宽表,预聚合之后再写入,并且是批量写入Clickhouse。

  第二个是建表和索引的优化。

  第三个是查询SQL优化,SQL优化的很多策略,无论是列裁剪与分区裁剪,归根结底就是减少查询时的IO,减少网络传输的成本;如果业务上能接受,可以采用数据采样,或者使用simple、limit、uniqCombined等方式做近似计算来提升性能。

  第四个是调整系统参数,比如单次查询的最大执行时间max_execution_time,如果执行某SQL时超过这个时间,在业务上就可能认为该SQL是有问题的,可以做降级操作,停掉该任务;还有单个服务器单次查询的最大内存max_memory_usage、单个服务器所有查询的最大内存

  max_memory_usage_for_all_queries、合并线程量等参数,需要在具体的业务运行过程中来调整这些参数,来使ClickHouse达到最优性能。

  10. ClickHouse使用痛点

  在使用ClickHouse过程中,痛点也非常清晰。

  从查询性能角度看,ClickHouse的高并发能力不足,多表关联查询性能欠佳。从运维角度看,ClickHouse集群强依赖ZooKeeper,增加了运维复杂度;ClickHouse集群缺乏Resharding机制,集群扩容节点比较麻烦。从数据更新角度看,数据Replacing使用merge-on-read模式,类似MOR的表模式,当多个数据版本存在时,不管是直接取数还是合并后取数,要取最新的一条数据,容易存在性能问题;另外ClickHouse不支持删除数据,需要通过表引擎增加删除标识位或TTL来变相实现数据删除的操作,这样就会拖慢性能。

  11. StarRocks的重要特征

  基于37手游的业务特点和ClickHouse的使用情况,2022年开始调研StarRocks,StarRocks的特性和37手游的业务场景匹配度非常高,下面简单介绍一下StarRocks的一些重要特性。

  StarRocks目前有四种数据模型:明细模型、聚合模型、更新模型和主键模型,根据不同的业务场景使用不同的数据模型,可以提升查询性能。

  37手游业务中使用较多的是主键模型。主键模型其实和更新模型比较相似,要求每个表要有唯一的主键,支持按主键进行更新和删除操作,通过牺牲数据写入操作的部分内存,能够极大地提升查询性能。通过各种测试,StarRocks支持多并发查询,并且QPS能力比ClickHouse要好。StarRocks支持多种数据导入方式,简化了数据加工链路。另外StarRocks不依赖ZooKeeper等外部组件,只有自身的FE、BE模块,降低了运维管理难度。

  12.StarRocks在37手游画像场景的应用

  37手游用户画像场景有四个技术诉求。第一,支持大数据量的查询;第二,数据的时效性要强;第三,可以根据任意的规则去圈选用户,再去做一些画像操作,比如聚合操作;第四,是要支持多表关联,比如画像表和用户维度表关联。其中前面的第三、第四点是我们的强需求项。

  13.37手游画像StarRocks方案

  过去37手游的用户画像使用的是ES,但ES的成本比较高,并发能力也比不上StarRocks+Hbase的方案,并且ES有时会出现读写超时(业务上读写时延有要求),因此换成了现在StarRocks+Hbase的方案,过去的痛点都解决了。在StarRocks方案中,用户画像表使用了宽表+众表的数据设计方案,对应的表模式是主键模型+聚合模型来处理宽表和众表;通过使用StarRocks的to_bitmap将user_id转化为Bitmap类型后,后续通过Bitmap运算支持人群圈选等需求,性能相当高。

  --

  03

  37手游多维分析技术业务化和普惠化

  1.数据分析与决策存在痛点

  做数据开发的工作会经常遇到以下的痛点。

  数据开发团队如果整天就只开发报表或者写SQL取数,数据开发人员容易沦为:“表哥”,“表姐”(只开发报表)或者SQL Boy(只写SQL),这样数据开发人员可能自我感觉业务价值存在感偏低;从业务团队的角度来讲,大量的取数需求要提给数据开发团队,并且希望取数需求尽快完成交付以便及时进行数据分析和业务决策,但实际情况是业务团队会觉得数据开发团队实现一张数据报表需求工时好长,取数难,取数慢,效率低。

  2. 多维分析技术业务化与普惠化

  针对以上痛点,37手游的数据开发团队采用的策略是:

  基于多维分析技术,把多维分析技术进行业务化和普惠化,构建了数据自助分析平台提供给业务侧进行数据分析和赋能业务决策。数据开发人员只要准备好数据集搭建数据看板,甚至可以将数据看板搭建交由业务团队自己实现,数据开发人员准备好数据集即可,如下图所示,右边是数据开发人员准备好数据集,左边的数据图表可以由业务团队来搭建。这样处理的好处是,数据开发团队可以从做报表开发中释放出来,有更多精力做业务价值更高的需求;业务团队能发挥自主能动性,利用数据自助分析平台进行数据看板制作,基于业务理解进行业务问题的下钻分析或归因分析。

  --

  04

  37手游多维分析平台服务保障

  1.平台服务健康度监控

  很多时候分析问题比解决问题更关键,只要发现了问题,定位到了问题的原因,解决问题就水到渠成,只是解决问题的难度或者成本不一样而已。多维分析平台的服务健康监控其实是一个问题发现的前置过程,过程分为以下几个阶段:第一,监控数据的采集;第二,监控数据的可视化;第三,异常数据的发现和告警。监控数据采集阶段包括服务器日记的采集、多维分析平台的性能指标采集,比如查询错误率低于95%、99%,异常走势等;数据可视化是基于Promtheus+Grafana的可视化监控方案;根据实际业务场景进行指标配置,然后加上阈值触发告警,辅助以一些智能化的手段检测异常数据(如时序数据异常检测类算法等)就能够实现多维分析平台的健康度监控和告警。

  2. 平台服务健康度监控看板

  可视化的监控看板有很多现成的,比如StarRocks就有现成的监控看板(参考StarRocks社区)能做到开箱即用,基本够用,能够满足大多数的业务需求。

  3. 数据质量监控

  多维分析平台的数据质量监控很重要。数据质量监控是有一套完整方法论的,从需求调研、指标定义、开发规范、到任务和数据质量的监控,有一套完整的流程。业内很多采用数据质量治理模型DMAIC,分别是指Define、Measure、Analyze、Improve、Control;对应数据质量治理边界的定义、数据质量评估模型的建立、数据质量问题的异常发现与问题归因、数据质量改进。DMAIC模型就不展开讲了。在37手游的业务实践中,是从数据有效性、数据的一致性、准确性、完整性和时效性五个维度来进行评估数据质量的。

  4. 多维分析平台数据质量监控预警系统

  37手游构建了一套数据质量监控预警系统来监控数据质量。

  下图是数据质量监控的流程图,主要包括四个模块,第一个就是调度模块,第二个就是后端服务模块,第三个就是执行引擎模块,第四个模块就是告警服务。整个系统主要就是为了检测和发现多维分析平台的数据质量问题,然后提供监控告警。调度器发起监控任务后,后端服务模块就会提交作业任务到执行引擎,执行引擎从多维分析平台中去拉取数据然后再执行引擎里面做计算,或者是把计算下推到多维分析平台执行;之后把计算结果返回给后端服务,后端服务判断返回的结果数据是否存在问题或者异常,如果有问题就会调起告警服务。

  5. 多维分析平台数据质量监控预警信息

  根据异常告警等级,告警信息通过短信、微信或者电话的方式来发送给业务方或者是属主。上图是企业微信上收到的一个告警信息截图。

  6. 未来规划

  下面介绍一下未来的规划。

  前面介绍了37手游OLAP计算引擎的架构演进:从MySQL、Druid,到Impala,再到ClickHouse,最后到StarRocks,有太多的组件,维护的工作量非常大,所以接下来的重要工作之一就是对现有的组件做一些减法,收敛组件,用尽量少的组件来满足更多的业务场景,减轻运维压力。

  第二项重要工作就是SaaS产品的引入,不管是社区还是公共云,都有一些比较好一点的组件和37手游的业务场景非常匹配,比如说阿里云的hologress,一个组件就能够解决用户画像场景中Hbase+StarRocks两个组件组合才能解决的的业务问题,无论K-V点查询、还是OLAP查询,hologess的性能都挺强;如果公司可以使用公共云,hologress也是一个挺不错的解决方案。

  第三项重要工作是ELT模式的探索。数仓经过清晰的数据分层设计与ETL数据计算,链路还是挺长的。随着组件的演进和发展,ELT也是一个挺不错的解决思路,就是原始数据或者是粗加工的数据,导入到多维分析平台之后,在多维分析平台内部进行统一口径的数据转换加工处理,再对外提供服务;这种方式精简了整个数据的加工链路,组件少了,流程少了,时效就能得到提升了。

  今天的分享就到这里,谢谢大家。

  分享嘉宾:闫铁 37手游 数据架构师

  编辑整理:易双凤 vivo

  出品平台:DataFunTalk

  01/分享嘉宾

  闫铁|37手游 数据架构师

  长期从事BI,数据仓库,大数据领域的业务开发和平台建设。对数据中台建设有较丰富的实践经验。

  02/关于我们

  DataFun:专注于大数据、人工智能技术应用的分享与交流。发起于2017年,在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会,已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800+,百万+阅读,14万+精准粉丝。
小庄
分享到朋友圈
收藏
收藏
评分

综合评分:

我的评分
Xinstall 15天会员特权
Xinstall是专业的数据分析服务商,帮企业追踪渠道安装来源、裂变拉新统计、广告流量指导等,广泛应用于广告效果统计、APP地推与CPS/CPA归属统计等方面。
20羽毛
立即兑换
一书一课30天会员体验卡
领30天VIP会员,110+门职场大课,250+本精读好书免费学!助你提升职场力!
20羽毛
立即兑换
顺丰同城急送全国通用20元优惠券
顺丰同城急送是顺丰推出的平均1小时送全城的即时快送服务,专业安全,准时送达!
30羽毛
立即兑换
小庄
小庄
发表文章10348
确认要消耗 羽毛购买
游戏运营的数据分析(多维数据分析平台在37手游的技术演进)吗?
考虑一下
很遗憾,羽毛不足
我知道了

我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求,为完善跟帖评论自律管理,为了保护用户创造的内容、维护开放、真实、专业的平台氛围,我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容,同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。


一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规,对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息,主要表现为:
    1)反对宪法所确定的基本原则;
    2)危害国家安全,泄露国家秘密,颠覆国家政权,破坏国家统一,损害国家荣誉和利益;
    3)侮辱、滥用英烈形象,歪曲、丑化、亵渎、否定英雄烈士事迹和精神,以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉;
    4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动;
    5)煽动民族仇恨、民族歧视,破坏民族团结;
    6)破坏国家宗教政策,宣扬邪教和封建迷信;
    7)散布谣言,扰乱社会秩序,破坏社会稳定;
    8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪;
    9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序;
    10)侮辱或者诽谤他人,侵害他人名誉、隐私和其他合法权益;
    11)通过网络以文字、图片、音视频等形式,对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的;
    12)危害未成年人身心健康的;
    13)含有法律、行政法规禁止的其他内容;


2. 不友善:不尊重用户及其所贡献内容的信息或行为。主要表现为:
    1)轻蔑:贬低、轻视他人及其劳动成果;
    2)诽谤:捏造、散布虚假事实,损害他人名誉;
    3)嘲讽:以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述,以此来激怒他人;
    4)挑衅:以不友好的方式激怒他人,意图使对方对自己的言论作出回应,蓄意制造事端;
    5)羞辱:贬低他人的能力、行为、生理或身份特征,让对方难堪;
    6)谩骂:以不文明的语言对他人进行负面评价;
    7)歧视:煽动人群歧视、地域歧视等,针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击;
    8)威胁:许诺以不良的后果来迫使他人服从自己的意志;


3. 发布垃圾广告信息:以推广曝光为目的,发布影响用户体验、扰乱本网站秩序的内容,或进行相关行为。主要表现为:
    1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式:
    2)单个帐号多次发布包含垃圾广告的内容;
    3)多个广告帐号互相配合发布、传播包含垃圾广告的内容;
    4)多次发布包含欺骗性外链的内容,如未注明的淘宝客链接、跳转网站等,诱骗用户点击链接
    5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光;
    6)购买或出售帐号之间虚假地互动,发布干扰网站秩序的推广内容及相关交易。
    7)发布包含欺骗性的恶意营销内容,如通过伪造经历、冒充他人等方式进行恶意营销;
    8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。


4. 色情低俗信息,主要表现为:
    1)包含自己或他人性经验的细节描述或露骨的感受描述;
    2)涉及色情段子、两性笑话的低俗内容;
    3)配图、头图中包含庸俗或挑逗性图片的内容;
    4)带有性暗示、性挑逗等易使人产生性联想;
    5)展现血腥、惊悚、残忍等致人身心不适;
    6)炒作绯闻、丑闻、劣迹等;
    7)宣扬低俗、庸俗、媚俗内容。


5. 不实信息,主要表现为:
    1)可能存在事实性错误或者造谣等内容;
    2)存在事实夸大、伪造虚假经历等误导他人的内容;
    3)伪造身份、冒充他人,通过头像、用户名等个人信息暗示自己具有特定身份,或与特定机构或个人存在关联。


6. 传播封建迷信,主要表现为:
    1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病;
    2)求推荐算命看相大师;
    3)针对具体风水等问题进行求助或咨询;
    4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失,包括通过占卜方法问婚姻、前程、运势,东西宠物丢了能不能找回、取名改名等;


7. 文章标题党,主要表现为:
    1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户;
    2)内容与标题之间存在严重不实或者原意扭曲;
    3)使用夸张标题,内容与标题严重不符的。


8.「饭圈」乱象行为,主要表现为:
    1)诱导未成年人应援集资、高额消费、投票打榜
    2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
    3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
    4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
    5)通过「蹭热点」、制造话题等形式干扰舆论,影响传播秩序


9. 其他危害行为或内容,主要表现为:
    1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的;
    2)不当评述自然灾害、重大事故等灾难的;
    3)美化、粉饰侵略战争行为的;
    4)法律、行政法规禁止,或可能对网络生态造成不良影响的其他内容。


二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时,本网站将依据相关用户违规情节严重程度,对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号,或者滥用多个帐号发布违规内容时,本网站将加重处罚。


三、申诉
随着平台管理经验的不断丰富,本网站出于维护本网站氛围和秩序的目的,将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议,可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)

我知道了
恭喜你~答对了
+5羽毛
下一次认真读哦
成功推荐给其他人
+ 10羽毛
评论成功且进入审核!审核通过后,您将获得10羽毛的奖励。分享本文章给好友阅读最高再得15羽毛~
(羽毛可至 "羽毛精选" 兑换礼品)
好友微信扫一扫
复制链接