用户画像：方法论与工程化解决方案

《方法论与工程化解决方案》知识总结，本书借助数据仓库实现一套用户画像系统的方案。从实际工程案例出发，结合多业务场景，内容涵盖开发离线批处理计算的标签及流式计算标签，为读者的分析、开发、搭建用户画像系统，并借助该用户画像系统为运营人员制定运营用户的策略提供端到端的解决方案。

用户画像：方法论 与工程化解决方案

• 0 序言
  • 书名：用户画像：方法论与工程化解决方案 作者：赵宏田 出版社：机械工业出版社 出版时间：2019-10-01 ISBN：9787111635642 作者简介：赵宏田，资深大数据技术专家，先后在中国地质大学（武汉）和武汉大学获得工学和经济学双学士学位。在大数据、数据分析和数据化运营领域有多年的实践经验，擅长Hadoop、Spark等大数据技术，以及业务数据分析、数据仓库开发、爬虫、用户画像系统搭建等。 本书借助数据仓库实现一套用户画像系统的方案。从实际工程案例出发，结合多业务场景，内容涵盖开发离线批处理计算的标签及流式计算标签，为读者的分析、开发、搭建用户画像系统，并借助该用户画像系统为运营人员制定运营用户的策略提供端到端的解决方案。
• 1 用户画像基础
  • 0 概述
    • 主要讲用户画像的基础知识，包括搭建用户画像系统需要覆盖的模块，开发阶段流程，各阶段的关键产出，以及数据仓库架构、表结构的设计等内容。
  • 1 用户画像是什么
    • 前言
      • 在互联网步入大数据时代后，用户行为给企业的产品和服务带来了一系列的改变和重塑，其中最大的变化在于，用户的一切行为在企业面前是可“追溯”“分析”的。企业内保存了大量的原始数据和各种业务数据，这是企业经营活动的真实记录，如何更加有效地利用这些数据进行分析和评估，成为企业基于更大数据量背景的问题所在。随着大数据技术的深入研究与应用，企业的关注点日益聚焦在如何利用大数据来为精细化运营和精准营销服务，而要做精细化运营，首先要建立本企业的用户画像。
    • 用户画像概念
      • 用户画像，即用户信息标签化，通过收集用户的社会属性、消费习惯、偏好特征等各个维度的数据，进而对用户或者产品特征属性进行刻画，并对这些特征进行分析、统计，挖掘潜在价值信息，从而抽象出用户的信息全貌。 用户画像可看作企业应用大数据的根基，是定向广告投放与个性化推荐的前置条件，为数据驱动运营奠定了基础。
    • 数据应用层级
    • 标签类型
      • 用户画像建模其实就是对用户“打标签”。 按打标签的方式划分3种类型： 统计类标签 规则类标签 机器学习挖掘类标签
      • 统计类标签
        • 最为常见标签类型。基于用户各维度数据进行统计得出。 该类标签构成了用户画像的基础。
      • 规则类标签
        • 基于用户行为及确定的规则产生。
          • 例如，对平台上“消费活跃”用户这一口径的定义为“近30天交易次数≥2”。 在实际开发画像的过程中，由于运营人员对业务更为熟悉，而数据人员对数据的结构、分布、特征更为熟悉，因此规则类标签的规则由运营人员和数据人员共同协商确定；
      • 机器学习挖掘类标签
        • 该类标签通过机器学习挖掘产生，用于对用户的某些属性或某些行为进行预测判断。
          • 例如，根据一个用户的行为习惯判断该用户是男性还是女性、根据一个用户的消费习惯判断其对某商品的偏好程度。该类标签需要通过算法挖掘产生。
      • 总结
        • 在项目工程实践中，一般统计类和规则类的标签即可以满足应用需求，在开发中占有较大比例。机器学习挖掘类标签多用于预测场景，如判断用户性别、用户购买商品偏好、用户流失意向等。一般地，机器学习标签开发周期较长，开发成本较高，因此其开发所占比例较小。
  • 2 技术架构
    • 层级结构图
    • 基础数据层
      • 汇集关注的业务数据、日志数据、埋点数据，进行简单的ETL处理，加工到数据仓库对应的ODS层、DW层、DM层中。
    • 用户画像主题层
      • 基于基础数据层数据对用户画像建模，生成相应的主题数据以及用户标签计算结果写入Hive。
    • 业务存储层
      • Hive：存储用户标签计算结果、用户人群计算结果、用户特征库计算结果。 用户标签数据在Hive中加工完成后，部分标签通过Sqoop同步到MySQL数据库，提供用于BI报表展示的数据、多维透视分析数据、圈人服务数据；另一部分标签同步到HBase数据库用于产品的线上个性化推荐。
      • MySQL：存储标签元数据，监控相关数据，导出到业务系统的数据
      • HBase：存储线上接口实时调用类数据
      • Elasticserch：支持海量数据的实时查询分析，用于存储用户人群计算、用户群透视分析所需的用户标签数据。
    • 画像产品端
    • 纵向实时数据处理层
  • 3 用户画像方案流程
    • 图
    • 用户画像基础
      • 需要了解、明确用户画像是什么，包含哪些模块，数据仓库架构是什么样子，开发流程，表结构设计，ETL设计等。 这些都是框架，大方向的规划，只有明确了方向才能做好项目的排期和人员投入预算。
    • 数据指标体系
      • 根据业务线梳理，包括用户属性、用户行为、用户消费、风险控制等维度的指标体系。
    • 标签数据存储
      • 标签相关数据可存储在Hive、MySQL、HBase、Elasticsearch等数据库中，不同存储方式适用于不同的应用场景。
    • 标签数据开发
      • 这是用户画像工程化的重点模块，包含统计类、规则类、挖掘类、流式计算类标签的开发，以及人群计算功能的开发，打通画像数据和各业务系统之间的通路，提供接口服务等开发内容。
    • 开发性能调优
      • 标签加工、人群计算等脚本上线调度后，为了缩短调度时间、保障数据的稳定性等，需要对开发的脚本进行迭代重构、调优。
    • 作业流程调度
      • 标签加工、人群计算、同步数据到业务系统、数据监控预警等脚本开发完成后，需要调度工具把整套流程调度起来。
    • 用户画像产品化
      • 为了能让用户数据更好地服务于业务方，需要以产品化的形态应用在业务上。产品化的模块主要包括标签视图、用户标签查询、用户分群、透视分析等。
    • 用户画像应用
      • 画像的应用场景包括用户特征分析、短信、邮件、站内信、Push消息的精准推送、客服针对用户的不同话术、针对高价值用户的极速退货退款等VIP服务应用。
  • 4 开发阶段流程
    • 用户画像建设项目流程
    • 1) 目标解读
      • 需要明确用户画像服务于企业的对象，再根据业务方需求，明确未来产品建设目标和用户画像分析之后的预期效果。
        • 一般而言，用户画像的服务对象包括运营人员和数据分析人员。不同业务方对用户画像的需求有不同的侧重点，就运营人员来说，他们需要分析用户的特征、定位用户行为偏好，做商品或内容的个性化推送以提高点击转化率，所以画像的侧重点就落在了用户个人行为偏好上；就数据分析人员来说，他们需要分析用户行为特征，做好用户的流失预警工作，还可根据用户的消费偏好做更有针对性的精准营销。
    • 2) 任务分解与需求调研
      • 针对服务对象的需求侧重点，结合产品现有业务体系和“数据字典”规约实体和标签之间的关联关系，明确分析维度。
    • 3) 需求场景讨论与明确
      • 数据运营人员需要根据与需求方的沟通结果，输出产品用户画像需求文档，在该文档中明确画像应用场景、最终开发出的标签内容与应用方式，并就该文档与需求方反复沟通并确认无误。
    • 4) 应用场景与数据口径确认
      • 经过第三个阶段明确了需求场景与最终实现的标签维度、标签类型后，数据运营人员需要结合业务与数据仓库中已有的相关表，明确与各业务场景相关的数据口径。在该阶段中，数据运营方需要输出产品用户画像开发文档，该文档需要明确应用场景、标签开发的模型、涉及的数据库与表以及应用实施流程。该文档不需要再与运营方讨论，只需面向数据运营团队内部就开发实施流程达成一致意见即可。
    • 5) 特征选取与模型数据落表
      • 本阶段中数据分析挖掘人员需要根据前面明确的需求场景进行业务建模，写好HQL逻辑，将相应的模型逻辑写入临时表中，并抽取数据校验是否符合业务场景需求。
    • 6) 线下模型数据验收与测试
    • 7) 线上模型发布与效果追踪
  • 5 开发阶段关键产出
    • 图表
    • 标签开发
      • 根据业务需求和应用场景梳理标签指标体系，调研业务上定义的数据口径，确认数据来源，开发相应的标签。标签开发在整个画像项目周期中占有较大比重。
    • ETL调度开发
      • 梳理需要调度的各任务之间的依赖关系，开发调度脚本及调度监控告警脚本，上线调度系统。
    • 打通服务层接口
      • 为了让画像数据走出数据仓库，应用到用户身上，需要打通数据仓库和各业务系统的接口。
    • 画像产品化
      • 需要产品经理与业务人员、技术开发人员一起对接业务需求点和产品功能实现形式，画产品原型，确定工作排期。Java Web端开发完成后，需要数据开发人员向对应的库表中灌入数据。
    • 开发调优
      • 在画像的数据和产品端搭建好架构、能提供稳定服务的基础上，为了让调度任务执行起来更加高效、提供服务更加稳健，需要对标签计算脚本、调度脚本、数据同步脚本等相关计算任务进行重构优化。
    • 面向业务推广应用
      • 相关人员需要撰写画像的使用文档，提供业务支持。
  • 6 画像应用的落地
    • 将标签应用到业务中。 画像开发完成后，需要数据分析人员、运营人员、客服等团队真正将画像应用使用起来，这样才能更好地推动画像标签的迭代优化，带来流量的提升和营收增长。
• 2 数据指标体系
  • 0 概述
    • 数据指标体系是建立用户画像的关键环节，也是在标签开发前要进行的工作，具体来说就是需要结合企业的业务情况设定相关的指标。 互联网相关企业在建立用户画像时一般除了基于用户维度（userid）建立一套用户标签体系外，还会基于用户使用设备维度（cookieid）建立相应的标签体系。基于cookieid维度的标签应用也很容易理解，当用户没有登录账户而访问设备时，也可以基于用户在设备上的行为对该设备推送相关的广告、产品和服务。 本章介绍如何从常用的用户属性、行为、消费、风险控制等维度设定指标体系。
  • 1 用户属性维度
    • 常见用户属性
      • 包括：用户的年龄、性别、安装时间、注册状态、城市、省份、活跃登录地、历史购买状态、历史购买金额等。
    • 用户属性标签举例
      • 举例
      • 说明
        • 对于相同的一级标签类型，需要判断多个标签之间的关系为互斥关系还是非互斥关系。例如，在判断性别时，用户性别为男的情况下就不能同时为女，所以标签之间为互斥关系 对于根据数值进行统计、分类的标签开发相对容易。例如，用户的“性别”“年龄”“城市”“历史购买金额”等确定性的标签。而在对规则类的标签进行开发前则首先需要进行数据调研。例如，对于用户价值度划分（RFM），如何确定一个用户是重要价值用户还是一般价值用户，对于用户活跃度的划分如何确定是高活跃、中活跃、低活跃还是已经流失，需要结合数据调研情况给出科学的规则并进行划分。
    • 用户性别说明
      • 用户性别可细分为自然性别和购物性别两种。 自然性别是指用户的实际性别，一般可通过用户注册信息得到。 用户购物性别是指用户购买物品时的性别取向。
  • 2 用户行为维度
    • 常见用户行为
      • 用户订单相关行为、下单/访问行为、用户近30天行为类型指标、用户高频活跃时间段、用户购买品类、点击偏好、营销敏感度等相关行为。
    • 用户行为维度标签举例
  • 3 用户消费维度
    • 常见消费行为
      • 可从用户浏览、加购、下单、收藏、搜索商品对应的品类入手
    • 标签维度举例
    • 标签维度指标梳理举例
    • 使用举例
      • 通过一个场景来介绍构建用户消费维度的标签的应用。某女装大促活动期间，渠道运营人员需要筛选出平台上的优质用户，并通过短信、邮件、Push等渠道进行营销，可以通过圈选“浏览”“收藏”“加购”“购买”“搜索”与该女装相关品类”的标签来筛选出可能对该女装感兴趣的潜在用户，进一步组合其他标签（如“性别”“消费金额”“活跃度”等）筛选出对应的高质量用户群，推送到对应渠道。因此将商品品类抽象成标签后，可通过品类+行为的组合应用方式找到目标潜在用户人群。
  • 4 风险控制维度
    • 说明
      • 互联网企业的用户可能会遇到薅羊毛、恶意刷单、借贷欺诈等行为的用户，为了防止这类用户给平台带来损失和风险，互联网公司需要在风险控制维度构建起相关的指标体系，有效监控平台的不良用户。结合公司业务方向，例如可从账号风险、设备风险、借贷风险等维度入手构建风控维度标签体系。
    • 标签维度举例
  • 5 社交属性维度
    • 说明
      • 社交属性用于了解用户的家庭成员、社交关系、社交偏好、社交活跃程度等方面，通过这些信息可以更好地为用户提供个性化服务。
    • 标签举例
  • 6 其他划分方式
    • 按应用场景划分
      • 说明
      • 举例
  • 7 标签ID命名方式
    • 说明
      • 为了便于对诸多标签进行集中管理，需要对每个标签对应的标签id进行命名。 例如，对性别为“男”的用户打上标签“ATTRITUBE_U_01_001”，性别为“女”的用户打上标签“ATTRITUBE_U_01_002”。
    • 层级式命名规则
      • 对于一个标签，可以从标签主题、刻画维度、标签类型、一级归类等多角度入手来确定每个标签的唯一名称。  标签主题：用于刻画属于哪种类型的标签，如人口属性、行为属性、用户消费、风险控制等多种类型； 用户维度：用于刻画该标签是打在用户唯一标识（userid）上，还是打在用户使用的设备（cookieid）上。可用U、C等字母分别标识userid和cookieid维度。 标签类型：类型可划分为统计型、规则型和算法型。其中统计型开发可直接从数据仓库中各主题表建模加工而成，规则型需要结合公司业务和数据情况，算法型开发需要对数据做机器学习的算法处理得到相应的标签。 一级维度：在每个标签主题大类下面，进一步细分维度来刻画用户。 标签统一命名后，维护一张码表记录标签id名称、标签含义及标签口径等主要信息，后期方便元数据的维护和管理。本节介绍的标签命名方式可作为开发标签过程中的一种参考方式
• 3 标签数据存储
  • 0 概述
    • 讲解了标签相关数据的存储，包括Hive存储、MySQL存储、HBase存储和Elasticsearch存储。不同的存储方式适用于不同的场景和业务需要。
  • 1 Hive存储
    • 作用
      • 计算、存储用户标签数据。 画像系统主要使用Hive作为数仓工具，开发计算相应的维度表和事实表来存储标签、人群、应用到服务层的相关数据。
    • 表分区
      • 为了防止单表ETL作业耗时较长，且便于管理标签，通常会对数据进行分区存储，分别执行作业。 比如：根据标签体系中的用户属性、行为属性、消费属性、风险控制、社交属性分别建立对应标签表。
    • 标签聚合
      • 用户的每个标签都插入到相应的分区下面，但是对一个用户来说，打在他身上的全部标签存储在不同的分区下面。为了方便分析和查询，需要将用户身上的标签做聚合处理。
    • 做好ID-Mapping
      • 即把用户不同来源的身份标识通过数据手段识别为同一个主体。用户的属性、行为相关数据分散在不同的数据来源中，通过ID-MApping能够把用户在不同场景下的行为串联起来，消除数据孤岛。
  • 2 MySQL存储
    • 作用
      • 用于元数据管理、监控预警数据、结果集存储等
    • 元数据管理
      • 标签元数据
        • 标签定义等信息：标签id、名称、所属主题、所属分类、创建时间、是否有效...
      • 管理操作
        • 标签记录的CRUD
    • 监控预警数据
      • 关注内容
        • 用于存储每天对ETL结果的监控信息。从整个画像调度流的关键节点来看，需要监控的环节主要包括对每天标签的产出量、服务层数据同步情况的监控等主要场景。
      • 监控标签计算数据
        • 监控每天标签ETL的数据量是否出现异常，如果有异常情况则发出告警邮件，同时暂停后面的ETL任务。
      • 监控服务层同步数据
        • 服务层一般采用HBase、Elasticsearch等作为数据库存储标签数据供线上调用，将标签相关数据从Hive数仓向服务层同步的过程中，有出现差错的可能，因此需要记录相关数据在Hive中的数量及同步到对应服务层后的数量，如果数量不一致则触发告警。
    • 结果集存储
      • 若线上业务系统使用的是MySQL，用于同步Hive中的标签结果信息。
  • 3 HBase存储
    • 画像系统中每天在Hive里跑出的结果集数据可同步到HBase数据库，用于线上实时应用的场景。
  • 4 Elasticsearch存储
    • 基于HBase的存储方案并没有解决数据的高效检索问题。 为了既能支持对数据的高效查询，同时也能支持通过条件筛选进行复杂查询，采用Elasticsearch存储HBase的索引信息，以支持复杂高效的查询功能。
    • 流程
• 4 标签数据开发
  • 0 概述
    • 重点章节，本章讲解了对常见的统计类、规则类、挖掘类、流式计算类标签以及用户特征库等与用户相关的数据的开发，还进一步介绍了如何计算人群数据、打通数据到服务层通路的开发。
  • 1 统计类标签开发
    • 案例:近30日购买行为标签
      • 标签细分
        • 付款订单量（对应标签“ACTION_U_01_001”） 总付款金额（对应标签“ACTION_U_01_002”） 加入购物车次数（对应标签“ACTION_U_01_003”）
      • 计算标签
        • 编写标签计算HQL
          • select 'ACTION_U_01_001' as labelid, # ------付款订单量标签id cast(user_id as string) as userid, count(distinct order_id) as labelweight # ---付款订单量 from dw.order_info_fact # -------------------商品订单表 where pay_status = 1 # ----------------------订单状态是已支付 and to_date(add_time) >= "month_day_ago" # --付款日期大于等于30日前 and to_date(add_time) <= "yesterday_date" # -付款日期小于等于昨天 union all select 'ACTION_U_01_002' as labelid, # ------总付款金额标签id cast(user_id as string) as userid, sum(order_total_amount) as labelweight # ----总付款金额 from dw.order_info_fact where pay_status = 1 # ----------------------订单状态是已支付 and to_date(add_time) >= "month_day_ago" and to_date(add_time) <= "yesterday_date" union all select 'ACTION_U_01_003' as labelid, # ------加入购物车事件次数标签id cast(userid as string) as userid, count(distinct eventid) as labelweight # ----加入购物车事件次数 from ods.page_event_log # -------------------埋点行为事件表 where data_date >= "month_day_ago" and data_date <= "yesterday_date" and eventkey = 'add_to_shoppingbag' # -------行为事件名称为“加入购物车” and userid is not null # -------------------用户id为非空值
      • 考虑增量数据
        • 每日定时运行一次计算标签HQL
  • 2 规则类标签开发
    • 案例:用户价值标签
      • RFM模型
        • Recency，最近一次消费时间 Frequency，消费频率，即一定时间段内消费次数 Money，一定时间段内累计消费金额
        • 模型解读
      • 如何利用RFM模型
        • 在开发对应的标签前需要进行数据调研。根据对数据仓库中拉取的用户消费相关数据进行分析后得出用户这RFM3个维度的指标在数值上划分的界限。
          • 1 找出最近一次消费时间的时间边界 分析数仓数据，得到用户最近一次交易时间的分布情况  根据累计用户量的占比，可按照二八比例进行划分，将最近一次交易时间距今0，到90日的用户划分为“近”，将最近一次交易时间距今90日以上的用户划分为“远”。 2 找出消费频率的低高边界值 分析数仓数据，得到最近一年订单量分布  根据累计用户量的占比，按二八比例进行划分，将历史交易订单量在3单以下的用户划分为低频，将交易订单量在3单及以上的用户划分为高频。 3 找出累计消费金额的高低边界值 分析数仓数据，得到用户历史交易金额分布  根据用户近一年交易金额情况，将交易金额在300元以下的用户划分为“低额”，将交易金额大于300元的用户划分为“高额”。 经过上面从3个维度对用户的数据调研，对这3个维度进行交叉分析（R≤90为“近”，R>90为“远”，F≤3为“低频次”，F>3为“高频次”，M≤300为“低额”，M>300为“高额”），划分出以下8类人群，如图所示。 
    • 案例:用户活跃度标签
      • 说明
        • 用户活跃度通常用某时间范围内，用户访问系统或模块的次数来定义。 如何划定时间范围，如将××天未访问的用户定义为流失用户，将××天内活跃×次的用户定义为高活跃用户，需要结合业务数据调研情况来确定数值。
      • 思路
        • 首先需要划分用户的流失周期，在流失周期内，根据用户的活跃情况进一步将其划分为高活跃、中活跃、低活跃。
      • 步骤
        • 1 划分流失周期 1）根据用户回访率来划分：初始日期圈定的一批首次访问用户，观察后续时间内该批用户仍有访问行为的占初始用户的比例。随着时间的推移，该比例逐渐降低。当曲线出现明显下降时可划分为流失周期。 2）统计用户最后一次访问与倒数第二次访问之间的时间间隔，可认为大于这个时间间隔后用户基本不会再访问，即用户已经流失。然后统计各时间段内用户人数的占比，累计占比达到一定比例时可认为大部分用户在这段时间后已经流失。根据下图所示的用户回访率曲线图，可认为30日为用户的流失周期。  从上图可以看出，用户在第5周以后回访率下降速度减慢，回访率已经低于10%且后续趋势保持平稳。第5周作为拐点即为用户流失周期，流失的关键指标是用户没有访问App的行为。  用户最后一次访问与倒数第二次访问间隔30日以上的用户占比不足10%，可认为大于这个访问时间间隔的用户已流失，即最后一次访问距今30日以上的用户可认为已流失。
  • 3 挖掘类标签开发
    • 说明
      • 挖掘类标签需要应用算法挖掘用户相关特征，一般用户相关的挖掘类标签可以包括预测用户男女性别、预测用户点击下单、判断用户已经流失或将要流失、判断用户购买品类偏好等。 由于挖掘类标签需要进行数据调研，找用户行为特征进行特征工程开发、算法参数调优以及上线工程化调度等多个开发环节，一般开发周期较长。
  • 4 流式计算标签开发
    • 基本流程步骤
      • 1）对接数据源读取数据
      • 2）解析处理（主要是预处理）数据
      • 3）实时计算数据
      • 4）数据存储持久化（MySQL、HDFS、HBase）
    • 核心组件
      • Flume
        • Flume是高可用，高可靠，分布式的海量日志采集、聚合和传输的系统。 Flume可以对接磁盘文件（目录）、HTTP接口、数据库等多种数据源； Flume可以将数据发送给HTTP接口、数据库、Kafka等多各类型数据存储端。
      • Kafka
        • 介绍
          • Kafka的核心功能是作为分布式消息中间件。Kafka集群由多个Broker server组成，其中，消息的发送者称为Producer；消息的消费者称为Cousumer；Broker是消息处理的节点，多个Broker组成Kafka集群；Topic是数据主题，用来区分不同的业务系统，消费者通过订阅不同的Topic来消费不同主题的数据，每个Topic又被分为多个Partition，Partition是topic的分组，每个Partition都是一个有序队列；offset用于定位消费者在每个Partition中消费的位置。
      • SparkStreaming
        • 介绍
          • Spark框架实时数据流处理组件，具有可扩展、高吞吐量、容错的特点。数据可以从Kafka、Flume等多个来源获取，可以使用map、reduce、window等多个高级函数对业务逻辑进行处理。最后，处理后的数据被推送到文件系统、数据库等
  • 5 用户特征库开发
    • 是什么
      • 用户特征库就是对用户每一次的不同行为（如浏览、收藏、搜索、购买等）及该行为对应的对象（或商品品类）进行详细的记录，以便从用户的行为特征中挖掘用户的偏好。与开发用户标签相比，用户特征库可以对数据进行汇总统计，从多个维度分析用户特征，而用户标签则“相对静态”地记录了用户当前的状态。
    • 意义
      • 丰富描述用户画像的维度，提高用户特征挖掘的效率，是用户标签的一种补充
    • 开发切入点
      • 用户维度（主要是用户行为）
      • 用户操作对象（如商品、商家等）维度
  • 6 标签权重计算
    • 说明
      • 用户在平台上的不同行为具体到用户标签层面有着不同的行为权重。 比如在电商场景中，用户购买某商品的行为权重要比用户添加到购物车、收藏某商品、浏览某商品的行为权重依次要高。 具体到某个产品层面，需要用户画像建模人员与运营人员密切沟通，结合业务场景给不同的行为类型定权重（基本思想是复杂程度越高的行为价值越大），同时需要考虑标签本身在全体标签类型中的权重属性。
    • 意义
      • 集合标签权重计算公式，对用户特征库的行为数据计算标签权重，筛选出与用户行为相关性最大的标签
    • 标签频率与权重
      • TF-IDF统计方法
        • 作用
          • 用以评估一个字或词相对于一个文件集或一个语料库中的其他词语的重要程度。
        • 原理
          • 字词的重要性随着它在文件集中出现的次数的增加成正比增加，同时随着它在语料库中出现的频率成反比下降。
        • 定义标签权重
          • 对于单个用户来说，其身上同一个标签出现的次数越多，该标签对于这个用户来说越重要（比如用户在购买商品时，总是偏向小米品牌，即标签：米粉出现频次高，则该标签对于该用户权重较大）。 对所有用户的所有标签全集来说，某个标签出现的次数越多，其重要性越低（比如，将每天12:00-14:00及19:00-21:00购物时间段作为一个标签：茶余饭后，发现在所有标签中，它出现的频率极高，则其权重较低）。
    • 时间衰减系数
      • 当用户数据达到足够的密集程度后，用户身上打的标签对应的属性会表现出较高的稳定性，这种稳定性与用户长期行为形成的个人真实特征相匹配。 时间衰减是指随着时间的推移，用户的历史行为和当前行为的相关性不断减弱。 在用户画像的应用中，用户的某些行为会随时间衰减，而某些行为不会随时间衰减。一般来说，用户操作的复杂程度越高，其行为随时间衰减的影响性越小，我们可视该类行为不随时间衰减（如下单、购买行为）。对于随时间衰减的行为，在计算行为权重时需考虑时间因素，衰减方式可套用牛顿冷却定律；对于不随时间衰减的行为则不必考虑时间的影响。
        • 举例
    • 标签权重计算
      • 公式
        • 用户标签权重=行为类型权重×时间衰减×用户行为次数×TF–IDF计算标签权重
        • 参数释义
          • 行为类型权重
            • 用户浏览、搜索、收藏、下单、购买等不同行为对用户而言有着不同的重要性。一般而言，操作复杂度越高的行为权重越大。该权重值一般由运营人员或数据分析人员主观给出。
          • 时间衰减
            • 用户某些行为受时间影响不断减弱，行为时间距现在越远，该行为对用户当前行为来说意义越小。
          • 行为次数
            • 用户标签权重按天统计，用户某天与该标签产生的行为次数越多，该标签对用户的影响越大。
          • TF-IDF计算标签权重
            • 由每个标签对用户的重要性与该标签在全体标签中的重要性的乘积得出每个标签的客观权重值。
  • 7 标签相似度计算
    • 说明
      • 根据标签之间的相关关系进行聚类也是画像开发中经常遇到的一类问题。如何结合业务背景对标签进行有效聚类，不同的公司或业务背景有不同的处理方式。
  • 8 组合标签计算
    • 说明
      • 当业务方根据业务规则应用标签时，有时需要组合多个标签来创建对应的用户群体的，此时需要应用到组合标签计算。
  • 9 数据服务层开发
    • 目的
      • 用户画像数据走出数据仓库，应用到各业务系统和营销场景中，进行链路打通。
    • 开发内容
      • 离线服务层：将ETL后的用户群数据推送到对应的业务系统
      • 在线服务层：以RESTful API方式提供接口服务，可支持个性化推荐、营销推送、在线特征库等场景
• 9 实践案例详解
  • 0 概述
    • 通过场景化介绍用户画像实际应用的8个案例，清楚地展现了用户画像 作为一种分析、触达用户的工具在实际业务上的应用方式和应用流程。
• 8 经营分析
  • 0 概述
    • 介绍了用户画像的应用场景，包括经营分析、精准营销、个性化推荐等应用 方向，方便业务人员、产品经理、数据分析师更好地了解用户、触达用户。
• 7 用户画像产品化
  • 0 概述
    • 画像产品化是数据从数据仓库走向业务服务的重要环节， 本章为数据产品人员、业务人员提供了解决方案的思路。
• 6 作业流程调度
  • 0 概述
    • 讲解了如何使用开源ETL工具Airflow实现画像系统相关任务的 工程化上线调度，以及对数据的监控预警和调度异常的排查。
• 5 开发性能调试
  • 0 概述
    • 讲解了开发过程中常见的数据倾斜调优、对小文件的读取、 缓存中间数据、开发中间表等调优工作。