一、画像标签体系
去哪儿在每个业务发展过程中构建了独立的画像标签体系。随着公司的不断壮大，需将各个业务的画像标签体系进行整合。从技术角度看，整合的过程相对简单，但业务层面的整合则较为复杂。因为各个标签在不同业务中的定义存在差异，这增加了整合的难度。为了确保整合后的标签体系能够更好地服务于公司的整体战略，需要进行深入的关键词提取和优化，确保各个标签的逻辑性和一致性。
1. 什么是画像标签
用户行为为用户在 APP 上操作所产生的行为，业务日志则为用户自己点击、下单、搜索等行为在服务器端产生的数据。画像标签是通过规则统计和挖掘算法对用户行为和业务数据进行计算后得出的用户等维度的数据。
2. 画像标签的需求来源
每个业务部门在搭建自己的画像标签平台时，由于目标不同，需求也有所差异，比如机票业务通常以营销为目标，酒店业务通常以服务为目标。我们应从实际业务需求出发，与各个部门沟通，包括公司管理层、实习生等不同层级的人员，进行深入的需求调研，以确保整合后的标签体系能够更好地满足业务需求。在整合过程中，用户画像标签需求主要分为三类：营销风控、内部业务分析应用和描述用户。
- 营销风控：用户营销、个性化推荐、精准广告投放、用户风控。
- 业务分析：业务优化分析、多维度业务指标监控、指导新业务产品设计。
- 描述用户：单一用户的定义、平台用户的定位、行业报告。
3. 画像标签的分类
在画像标签构建的过程中分为业务分类和技术分类。
从需求中提炼出业务需要的用户画像分类，其中一级类目和二级类目偏以业务流程进行分类向的定义，并以此不断扩充。
另外，根据不同的技术需求，我们需要选择合适的技术栈来实现画像标签的生成、存储和调用。
首先，需要明确画像标签的定义和目标，以便确定需要使用哪种技术。其次，需要考虑标签的更新周期和访问方式，这决定了是否需要在线或离线处理标签，以及选择哪种存储资源。最后，根据这些因素，我们可以选择合适的技术栈来实现画像标签体系，确保系统的性能和稳定性。通过这样的技术分类，可以更好地管理和维护画像标签体系，提高其可扩展性和可用性
（1）构建方法
- 统计类：依靠 SQL 即可完成。
- 规则类：面向数据分析师、商业分析师以及产品运营等具有一定业务背景的人通过对业务的理解，去构建一些规则类的标签，这类标签会基于业务的理解变化产生变动。
- 模型类：这类标签需要算法团队进行复杂的计算或需要样本数据。与一些基础标签不同，模型类标签在精度上可能存在挑战，无法达到百分之百的准确。因为有时我们获得的样本数量非常有限，使得标签的准确率难以维持在较高的水准。因此，对于模型类标签，我们可能需要寻找其他的方法和技术来提高其精度和可用性。
（2）更新周期
除了已列出的按小时、周、月的更新周期外，我们目前还实现了实时的标签更新，这更接近于流式更新。
（3）访问方式
由于画像标签平台需要处理大量数据和用户请求，需要根据后台技术栈来选择合适的访问方式，对于一些大型公司，用户量和数据量都非常庞大，因此我们需要考虑如何有效地存储和调用标签。有些标签可能只需要离线构建，而有些标签则可能需要在线调用。对于离线标签，我们可以选择不占用高存储成本的资源，例如将数据存储在 Redis 或 HBase 中。而对于在线标签，需要确保系统能够快速响应用户请求，并提供稳定的服务。因此，在选择访问方式时，我们需要根据实际情况进行权衡和选择，以确保系统的性能和稳定性。
4. 画像标签体系构建过程
在画像标签体系的生产过程中，我们需要对各类数据源进行一系列的处理，最终生成标签。其中，ID Mapping 是一个关键环节。ID Mapping 的目标是解决不同ID 指向同一人的问题，特别针对早期成立的公司，由于注册方式多样，可能会出现多个 ID 对应同一用户的情况。例如，用户通过邮箱注册后可以绑定或更改手机号，或者曾经允许未登录状态下使用，这些情况都可能导致多个 ID 对应同一用户。
为了解决这个问题，ID Mapping 承担着实现多设备关联的任务。另外，ID Mapping 对于风控来说也是至关重要的基础步骤。通过 ID Mapping，可以更好地识别和关联不同设备的使用者，从而更好地进行风险控制和安全管理。通过合理的 ID Mapping 设计和管理，我们可以更好地保护用户隐私和数据安全，同时提高画像标签体系的准确性和可靠性。
二、画像标签平台
画像标签平台也称之为 CDP 平台，包含了画像标签的生产、数据分析、业务应用、效果分析等服务。下图为去哪儿 CDP 平台的功能架构。
在去哪儿网，疫情发生后加强了内部能力的建设，将画像标签与主流策略平台进行了整合。目前该平台涵盖了画像标签的整个生命周期，可实现画像构建、人群圈选以及最终的营销动作等功能。通过这样的整合，能够更好地实现数据驱动的营销策略，将用户画像与营销活动无缝连接起来。这有助于提高营销效果和用户满意度，同时也有利于企业内部的数据整合和协同工作。
三、常见算法类画像标签
1. 常见模型类标签常用算法类型
在实践过程中，基于样本和技术栈，可以将模型类标签常用算法分为如下几大类：
（1）分类算法：在业务流程中利用预测类标签来进行圈选和业务过滤，需要拥有足够的样本数据来进行训练和优化模型，从而提高预测准确率。预测类标签不仅仅局限于订单支付预测，还可以包括搜索支付预测、搜索预测、详情页预测等。
（2）推荐算法：与排序和优先级相关，需要更广泛的前沿知识和技术栈。推荐算法的目标是从召回集中为用户推荐合适的酒店房型。例如，对于亲子出游的场景，推荐算法可以为用户推荐双床房或套间等合适的酒店房型。
（3）知识图谱：利用图数据库技术更好地揭示用户及其周边关系。风控场景中应用较多，例如识别异常用户和判断是否为恶意用户。
（4）因果推断：通过一个例子解释了给用户发短信和 push 消息对营销效果的影响，并涉及到成本问题。
（5）图形图像：结合图形图像处理技术，对图形图像进行打标。涉及到对图像的分割、识别等技术，但更多的是通过用户标签反向应用到图像打标上。例如，对于发表不正当评论的用户，将其标签提取出来，并应用到图形图像打标算法中，以提高打标的效率和准确性。
（6）NLP 机器人
（7）lookalike 营销算法：即通过种子用户进行扩展营销的算法。
基于需求的类型会有不同的分类方法：
- 单一实体：通过关系网络或知识图谱来寻找其他相关实体。例如，利用知识图谱可以发现实体之间的关系，从而扩展单一实体的关联实体。
- 业务实体集：与特定业务相关的标签，由业务本身产生，而非人为控制。例如，酒店搜索用户或机票搜索用户，如果想要针对这些用户进行营销并扩展业务，就要通过对业务实体标签的深入分析和挖掘，更好地理解用户需求和行为，从而优化业务策略，提高转化率和用户体验。业务实体集可以通过品牌模式、关联规则、方案标签平台等方式进行扩充，以获取更丰富的画像标签或画像用户。
- 规则实体集：指基于特定规则或条件生成的标签。这些标签通常是由产品团队根据对业务的理解，利用标签工具圈选出符合特定规则的用户群体。例如，在推荐行程或房型的过程中，有些用户可能已经购买了北京的机票和酒店，那么我们可以将这些具有特定行为链条的用户作为目标群体，进行营销推广。可以使用关系实体和聚类算法来处理。在进行聚类算法时，需要注意不能仅使用规则标签进行聚类，而应该使用其他标签。同时，需要避免将与规则标签强相关的标签与规则标签混为一组。为了避免这种情况，方案标签平台会提供标签与其他标签的相关性分析，帮助用户过滤掉相似的标签。
- 行为实体集：基于用户行为生成的标签。这些标签通过分析用户的行为特征和需求类型，来制定相应的营销策略。例如，对于购买过北京机票和酒店的用户，我们可以进一步分析他们的行为特征，如购买时间、频次、偏好等，以制定更具针对性的营销策略。
2. 基于知识图谱和频繁模式的 looklike 算法
仅依赖画像标签进行筛选可能产生大量不符合需求的目标用户，如何对这些用户进行排序成为了一个难题。传统的方法如根据价值、活跃度等进行排序，很难确保选出的用户与目标用户群最为相似。而通过知识图谱或频繁模式，我们可以衡量用户之间的相似度，并且这种相似度是可量化和扩展的。通过关系层面，该算法能够更准确地找到与目标用户相似的用户群体。
3. 基于因果推断的 lookalike 算法
与传统的关联规则和画像标签相比，因果推断能够解决更深层次的问题。关联规则和画像标签主要解决的是相关性问题，例如“购买啤酒的用户也可能会购买尿布”，但无法解释为什么存在这种相关性。在不同的文化和市场中，这种相关性可能并不成立。因此通过历史数据和模型进行因果推断，可以找到影响用户行为和转化的关键因素。这些关键因素可以通过关系发现被找到，进而帮助我们更好地理解用户行为和业务过程。
例如右上角红色部分通过对业务的理解筛选出的更能体现业务的过程的部分，从而去扩充更多的用户出来。
4. 物的画像
在物的画像构建过程中，我们主要关注的是物的属性和特征，例如酒店画像中的城市、商圈、航线、航班等。这些属性有助于我们更准确地描述和了解物，并为其画像提供丰富的内容。
与用户画像相比，物的画像更强调物与物之间的相似性。在实践中，我们通常利用物的相似性进行推荐和排序等操作。为了衡量物与物之间的相似性，可以采用多种方法，如属性向量和 embedding。这些方法可以将物表示为向量，并利用这些向量进行相似性计算。需要注意的是，物的画像构建过程与用户画像构建过程虽然相似，但在实际应用中，我们需要根据业务需求和场景进行适当的调整和优化。同时，还需要深入分析物与物之间的关系和层次结构，以确保物的画像准确反映业务需求。
此外，在物的画像构建过程中，我们还需要关注一些关键问题。
（1）相近并不意味着相似。例如，在使用 embedding 方法时，如果高价值的用户群体搜索的都是五星级酒店，那么这些五星级酒店之间的相关性可能会很强。但在某些业务场景中，这种相关性可能并不适用。因此，我们需要根据具体业务场景仔细考虑物的相似性。
（2）冷启动问题。例如在酒店画像中，当一个新的酒店上线时，它可能缺乏用户行为数据。为了解决这个问题，我们可以利用属性距离抽取大维度的标签属性，构建一个偏用户态的画像标签，并利用这个标签进行相似度计算。
（3）可解释性
四、画像标签应用场景
应用一：营销人群精选与扩散
画像标签在营销的精选和扩散过程中起到了至关重要的作用。通过合理运用画像标签，运营人员可以对已选定的用户群体进行更细致的分析和筛选，当运营人员觉得初始精选的用户群体过大或过小，或者营销效果需要进一步扩大或优化时，可以通过画像标签进行扩散或重新精选以达到更好的营销效果。
然而，在进行画像标签的精选和扩散时，最常见的是用户转化和运营干预的四象限问题。这四个象限分别代表不同的用户转化状态和运营干预策略，需要针对不同情况进行不同的应对措施。例如，对于高转化低干预的用户，可以采取保持现状的策略；对于低转化低干预的用户，可以采取促进转化的策略等。
以下是画像标签在应用过程中营销精选扩散的四个阶段：
科学分析：深入挖掘用户数据，精准定位目标群体，以提升转化效果。
辅助圈选：利用标签高效筛选目标用户，提高营销活动的针对性和效率。
智能扩量：基于算法和模型，对用户群体进行智能分类和扩量，以扩大营销覆盖面。
模型落地：结合实际营销活动，优化画像标签和策略，实现最佳的营销效果。
应用二：业务指标归因分析
通过画像标签体系来分析业务指标的好坏，并进一步优化策略。在业务迭代过程中，我们通常使用归因分析算法和商业分析等方法来产生策略。然后进行实验测量，如果实验策略表现良好，就会全量上线。
然而，在这个过程中会遇到两个问题：如何分析指标的好坏以及实验结果的好坏。为了解决这些问题，我们需要进行业务指标的归因分析。首先，通过报表、报警等途径发现业务问题，找出问题的原因，明确具体的场景和实际的转化关系。接着，定位问题的原因，并判断这个原因是可控的还是不可控的。如果是不可控的，可能就是一个自然抖动，不需要过多关注；如果是可控的，就需要进一步探究是否存在未知的场景导致这个问题。
在定性分析模块中，我们会明确可控因素和不可控因素，并挖掘一些未知的场景出现问题的原因。最后，给出建议，指导业务人员在什么场景下去做。这个场景其实就是某个业务的转化率下降了，通过整个业务的分析过程，我们可以得出非市场因素和可控因素分别占比多少。如果市场因素占比较大，那我们就可以先滞后解决这个问题，不必立即动用大量人力物力。
应用三：AB 实验效能分析
在负责去哪儿的 AB 实验系统的过程中，我们经常面临一些挑战。当产品团队投入大量时间和资源完成实验后，如果实验结果不显著，很容易产生诸如“为什么实验无效”和“下一步迭代的方向是什么”等疑问。
为了解决这些问题，我们进行了 AB 实验效能分析，主要分为三个部分。首先，我们通过业务流程漏斗模型、核心用户画像标签识别以及业务域误导标签识别，尝试判断实验效果不佳是否因为量提升不够。其次，运用决策树等分析方法，探究质的提升是否存在问题，例如其他实验的冲突或提升量未达到显著性比例的情况。最后，量化动作效能，明确每个动作对目标的影响程度。
通过这些分析过程，我们可以为产品团队提供具体的指导，帮助他们选择效能更高的方向进行优化，从而实现质的提升。这些分析不仅有助于优化产品迭代方向，还能为公司节省资源和时间，提高整体业务效果。
五、问答环节
Q1：用户行为跟业务日志有什么区别？
A1：用户行为数据主要记录了用户在 APP 端的交互行为，如点击等，这些数据主要反映用户的交互过程。而业务数据则涉及后台处理的各种信息，例如代理连接过程、物流信息等，这些数据虽然对用户来说是不可见的，但对于理解整个业务流程和提升用户体验同样至关重要。在实际操作中，我们需要将这些数据纳入到我们的画像标签体系中，以便更好地分析和理解用户行为和业务过程。例如对于电商平台来说，有些数据可能对用户无关紧要，但有些则涉及到用户体验和业务流程，因此需要进行适当的筛选和处理。
Q2：目前流式标签是怎么做的？能支持比较复杂的标签规则嘛？是数据开发出来还是可视化配置的？
A2：流式标签可以通过流式计算来实现，如使用 Flink 等工具。用户可以拖拽定义好的数据，通过流式计算进行标签的计算。同时，也可以上传 Python 代码或 SQL 代码进行自定义的计算。此外，还可以通过 Spark 等方式来支持。在流式标签中，需要限制计算的量和时间窗口，以满足不同需求。
流式标签可以支持复杂的标签规则。用户可以通过上传 Python 代码或 SQL 代码来实现更复杂的标签计算。
流式标签可以通过数据开发和可视化配置两种方式来实现。在去哪旅行平台上，用户可以拖拽定义好的数据，通过流式计算进行标签的计算，也可以上传 Python 代码或 SQL 代码进行自定义的计算。
Q3：什么是实时标签？
A3：实时标签是指在用户行为或业务事件发生时，实时计算并应用的标签。例如，当用户在前端界面提交投诉时，系统会实时地分析用户的诉求和订单问题，并为用户打上相应的实时标签。这种实时标签能够快速地反映用户的需求和问题，以便及时地进行处理和优化。不同公司对实时标签的定义有所不同，去哪儿 3 秒以内的算实时，而小时级都称之为是非实时的一个场景。
Q4：ID Mapping 是将多个手机号/设备号识别成一个唯一的 ID?还是使每个用户都有一个唯一的 ID？比如一个手机号在两个设备登录过，其中一个设备又登录过另外一手机号，是唯一的一个还是三个?
A4：随着移动互联网的普及，越来越多的公司开始采用手机号作为用户唯一的标识符。一键登录已成为行业通用的做法，使得用户能够更加方便地登录和使用应用。对于去哪儿这样的平台，我们也采用了手机号作为用户唯一的 ID。在大多数情况下，我们会将手机号视为用户的唯一标识符。但在某些特殊情况下，我们也会考虑用户更换手机号的场景，并对其进行相应的处理。此外，为了更好地管理和识别用户，当一个手机号在两个设备上登录时，我们会通过一系列的判断来确定用户对设备的持有状态。如果用户是临时登录设备，我们将其视为访问人；如果用户长期持有该设备，则将其视为持有人。
Q5：货品标签有哪些应用场景？
A5：其中最常见的是货品定价。为了实现货品定价的个性化，我们需要使用货品标签。这些标签是基于内部因素和外部因素的具体数值计算得出的。如果内部因素没有得到适当的梳理，外部因素的影响可能会被夸大。可以理解为类似于暴力求解的方式，我们把每一个因素都放进去试，然后去看每个因素对它的影响是多少，并且在每个因素里判断它是相关性还是因果性。
Q6：业务的实时标签是不是要定制化开发？
A6：实时标签在建成之后，我们已经通过开发层面去尽可能地穷举了一些通过基础的统计就能出来的一些实时标签。至于说像规则类和模型类的实时标签，肯定是要定制化开发的。
Q7：标签的生命周期怎么管理？
A7：在建立之初会有一些一次性的标签，用完就不使用了。
Q8：是否可以用一些统计方法来确定 AB 实验的时候的最小样本量？AB 实验有标准的计算过程，这样是不是可以知道大概需要多少样本量可以达到统计显著的一个效果了？
A8：更小的业务公司，可能流量先天性就不够，你想要达到一个最小样本量，操作层面也不太能实现，所以我们需要有一些在没有达到最小样本量的时候，能快速去大致地推断这个实验效果。
Q9：用户口径画像的口径类型是怎么存储和展示的？用户画像的标签除了单一的，还有多标签，形成一个用户偏好角度。这两类标签怎么存储比较好？
A9：展示每一个公司都不一样。从存储角度来说去哪儿是有多个存储方式的，我们可以容忍一部分数据的冗余存储，主要还是为了以实时响应快为准，就是它在访问化标签的时候，我们尽可能地以一个低耗时去访问它。
Q10：模型在方案标签建设中有哪些应用？
A10：其实这个我现在通过去哪儿这边的实践来说，大模型在算法标签应用是非常的广的。首先最简单的一个例子，我们在构建户的画像的时候，经常会遇到 POI 地标数据，地标的数据是从一些文档里面抽取的，可能这个就大模型在用，这个地方的准确率说实话比我们以往自己构建的一些模型效果好很多。以及我们在构建知识图谱的时候，会遇到一些实体消歧、实体合并等等。
Q11：涉及到排序推荐也需要画像算法工程师实现吗？
A11：其实不是的，这个推荐是推荐工程师，但是推荐算法要用到画像工程师的结果，画像工程师需要把画像标签的质量和这个应用的场景作出清晰的描述以便于推荐排序工程师能够更好地使用。