数据产品经理进阶实战
2024-09-06 11:42:21 0 举报
AI智能生成
数据分析方法论 产品路线图 数据埋点 数据中台 数据指标体系 A/B测试系统搭建 数据管理与数据服务
作者其他创作
大纲/内容
“全面认识数据产品经理”
“什么是数据产品
“数据产品是一种降低用户使用数据的门槛,并发挥或提高数据价值的产品类型,与之对应的有用户产品和商家产品等。负责设计、维护和优化数据产品的人,我们称其为“数据产品经理”。”
数据产品组成
“一个完整的数据产品通常由采集清洗、计算管理、分析展示和挖掘应用四个部分组成”
(1)采集清洗
“采集指的是产品通过各种技术手段,将现实世界的信息线上化之后,再传输到企业的服务器和数据库中。根据采集源头的不同,可以分为日志信息采集和业务库表采集两种。前者主要是从各种联网设备中采集,有App日志、服务器日志和智能设备日志等;后者一般从企业的业务数据库中获取,如电商企业中用户的下单数据、支付数据等。为了准确采集这些内容,我们会构建一套埋点系统来进行规范和管理(具体参见第4章)。由于采集的信息一般会存在数据缺失或冗余、数据错报等情况,因此不能直接使用,需要一个预定义的清洗流程进行整理和优化。”
(2)计算管理
“从严格意义上说,这些经过初步采集和清洗得到的信号尚不能称为“数据”,因为此时人们并不能根据这些信号扩大自己对客观世界的认知。只有根据不同的业务场景和需求汇总计算之后,才能称为“数据”。
“数据分为度量、指标和维度,它们随着业务的进展会逐渐膨胀,变得十分复杂。我们可“以构建一套元数据管理系统来更好地管理这些数据”
(3)分析展示
“需要经过合适的分析思维和展示方案进行组装,才能变成漂亮的模型,发挥相应的数据价值。合适的分析模型可以大幅降低用户使用数据的门槛,更好地获取数据背后的洞察,如漏斗分析模型和留存分析等。同时,这些分析思维需要搭配一定的可视化工具才能更好地传达。
(4)挖掘应用
“除了分析展示外,数据的价值还体现在与业务结合的挖掘和应用上。通用的业务场景有搜索、推荐、排序和风控四种,数据通过构建合适的策略和模型来提高这些场景的业务效率,如用户画像、反作弊模型、推荐展示策略等。同时,也有基于某些特定业务场景的数据应用,如针对销售推广人员的数字化绩效系统和针对客户留存唤醒的精细化用户运营系统等。
数据产品类型
“根据产品的使用对象,我们可以将数据产品分为三大类:用户数据产品、商用数据产品和企业数据产品。
“用户数据产品一般面向普通用户提供数据查询服务,如Google推出的Google Trends,其特点是任何用户均可访问,数据经过一定程度的提炼便于使用和分析。商用数据产品则是由企业开发,为其他企业或商家等实体提供数据服务,如GrowingIO和阿里巴巴的生意参谋。而企业数据产品则是由企业自建自用,主要目的是降低员工使用数据的门槛,辅助人员作出决策和提高业务效率。”
数据产品衡量
“我们一般采用准确性、及时性、全面性、易用性四个维度来评估数据产品,排列的顺序也是其重要性的体现。
“准确性。准确性是数据产品的根本,是最重要的评价维度”
“及时性。衡量数据准备的及时程度。这里分为实时和离线两类场景,“实时”类场景会衡量刷新频率和顺畅程度,比如能否做到分钟级甚至秒级的更新。这在双十一等公共场景下十分重要。衡量指标一般是“更新频率”及“刷新失败频“次”等实时类指标。“离线”一类场景则会衡量数据在第二天指定时间点前是否就绪的情况。一般团队遇到的问题是员工上午9点后陆续上班,但数据计算量太大导致10点多了数据还没准备好。衡量指标则是“未及时就位频次”等指标。
“全面性。衡量数据覆盖的指标全面性及业务全面性。”
“·易用性。衡量数据产品的用户体验:一方面可以通过平台内监控各项功能的使用量(如PV、UV及使用时长)来进行量化;另一方面也需要定期进行用户访谈和问卷调研,来获得用户的使用反馈。”
数据产品详解
用户数据产品
“在三类数据产品中,用户数据产品是普通用户接触最多也是最容易的一类”
“三类用户数据产品的比较”
“根据数据来源,可将用户数据产品细分为指数型、统计型和生活型
1.指数型
“指数型数据产品一般由企业利用自己的数据提炼出相应观点和洞察趋势,提供给用户分析使用,如Google Trends、百度指数、微指数等”
“指数型数据产品的设计精髓是“比较”,通过比较各种关键词在不同区域和不同时间段内的出现频次,形成热度的高低演化。”
2.统计型
“统计型与指数型产品相比,最大的差别是数据均来自外部采集,然后经过企业内部整理呈现。这些产品往往可以供用户免费试用,同时有商用版本。”
“统计型数据产品的关键是可靠的数据源和数据清洗。一般来讲,数据源都来自网络爬虫或者统计模块(SDK或插件)植入,前者存在一定的法律风险,且有数据容易脏乱的问题;后者获客难度较大,好处是能拿到比较优质的数据。”
3.生活型
“生活型数据产品是收集用户自身数据并进行一定程度的归类、分析与可视化的产品。数据对于公司来说,作用是通过统计分析来提升效率和节约成本;数据对于个人来说,则可帮助人们量化并提升自己的生活品质。这种产品可以大致分为记账类、运动类、天气类、时间管理类、信息记录类、机器信息类等。这些产品早期只是简单记录和统计,使用起来大多比较烦琐,而随着技术越来越成熟,此类产品慢慢地朝着智能化、便捷化和游戏化三个方向发展。”
商用数据产品
“商用数据产品,即由企业或个人开发,提供给外部企业使用的,具备数据采集、计算、存储、展示和分析等功能的产品。”
“可以看到目前商用数据产品的具体分类及领域中的相关产品。它们可分为数据分析师平台(Data Analyst Platforms)、数据科学平台(Data Science Platforms)、机器学习(Machine Learning)产品、BI平台(BI Platforms)、Web/移动端/交易分析(Web/Mobile/Commerce Analytics)、可视化产品(Visualization)、社交分析(Social Analytics)和数据源产品(Data Source,在下图中并未标识)等8个类型。”
企业数据产品
“企业数据产品,由企业自建自用,主要目的是降低员工使用数据的门槛,辅助人员作出决策和提高业务效率。根据内部定位,企业数据产品可再细分为应用型和平台型。应用型的企业数据产品专注于解决某个具体的业务问题或者部门问题,如客服数据监控系统和建立在集团平台的事业部决策分析系统;而平台型的目的就是为前者提供更好的支撑。
“企业数据产品分为应用型和平台型两种。应用型的核心是业务敏感度,根据不同的业“务需求设计对应的数据产品,如根据风控部门的需求来实时更新对应的风控标签和数据阈值,并且提供对应的监控和分析工具,完成从策略应用到分析落地的闭环。平台型强调的是面向各个业务提供服务,这要求产品具备较高的标准化和抽象化水平。标准化指的是主动出击,定下一些关键的数据资产规范,方便在企业中流通使用,如埋点管理、指标管理和数据库表管理等。抽象化指的是不能只关注于解决一两个具体的需求点,而是关注整个面的抽象和满足,是一个由点及面的过程。”
“企业数据平台之产品框架”
“数据产品经理能力模型”
产品经理能力
“对于产品经理,核心能力是为需求或问题提供最有效的解决方案。
定义需求或问题是首当其冲的。我们常说要分清需要(Need)、想要(Want)和要求(Demand)这三个需求类型”
定义需求或问题是首当其冲的。我们常说要分清需要(Need)、想要(Want)和要求(Demand)这三个需求类型”
“触一个需求,我们除了判断其是否存在及所属类型外,还需要判断其合理性,以及可能被满足的方式。如果是平台型的数据产品,我们要做到该需求尽可能被抽象化的平台或工具解决,避免重复制作轮子。应用型的数据产品则要尽可能贴合业务场景,力求提供更好的解决方案。”
“用“用户产品经理”的心态做数据产品,力求提供最好的分析体验和数据使用体验。”
数据专业能力
“数据专业能力的核心部分是数据产品设计能力、数据分析能力,如果还有余力,可以再多了解大数据技术架构及数据挖掘算法等方面的基础知识。这些知识只需了解其原理,以更准确地判断需求实施的可能性或复杂度。
“数据产品设计方法属于产品设计的一个分支,一样需要从需求和问题出发,着力于提供优秀的解决方案,同时有自己的独特要求——发挥数据价值,突出表现在数据资产管理和数据业务效率提升两方面。”
“数据分析也是数据产品经理有别于其他产品经理的特质能力之一。”
“常用的工具有Excel、SQL、Python和R等,在少数情况下会用到SPSS等统计挖掘软件。”
“常用的工具有Excel、SQL、Python和R等,在少数情况下会用到SPSS等统计挖掘软件。”
“除此之外,一些技术相关知识也必不可少,主要是数据仓库、数据采集传输、大数据架构和数据挖掘等方面的基础知识。”
软能力
“洞察需求后,我们需要知道背后的商业模式和业务运转原理,从而更好地服务用户和公司,这是“商业认知能力”。为了落地产品方案,推动项目按时按质上线,我们经常要和团队内外的同事一起合作,协调时间、排期和平衡利益,这是“沟通协调能力”和“项目管理能力”。”
“不同级别的能力要求”
“不同级别的能力要求”
子主题
“数据产品经理分类”
“数据产品包括采集清洗、存储管理、展示分析、挖掘应用四个环节。
与之对应的,数据产品经理分为应用型、策略型、平台型三种。
应用型主要负责展示分析和挖掘应用环节,目的是在特定的业务场景下,利用已有数据提高业务效率。
策略型集中在挖掘应用环节,业务场景聚焦在搜索、推荐、风控的数据策略和模型部分。
平台型则比较复杂,一般会负责采集清洗和存储管理两个模块,同时会根据情况抽象提取后两个环节的通用部分,提高企业的使用效率。”
与之对应的,数据产品经理分为应用型、策略型、平台型三种。
应用型主要负责展示分析和挖掘应用环节,目的是在特定的业务场景下,利用已有数据提高业务效率。
策略型集中在挖掘应用环节,业务场景聚焦在搜索、推荐、风控的数据策略和模型部分。
平台型则比较复杂,一般会负责采集清洗和存储管理两个模块,同时会根据情况抽象提取后两个环节的通用部分,提高企业的使用效率。”
数据分析方法论
“数据分析的基础流程”
“有价值的数据结论”
“数据分析基础方法”
组成因子分解
“把整体指标数据按照某种分类标准分成不同的因子的过程,称为组成因子分解。整体目标等于所有的组成因子之和。”
影响因子拆解
“很多时候,因子对结果的影响是定性的,并不能完全把结果拆成多个因子的相加,这时候就可以采用影响因子拆解的方式,列出对结果有影响的所有因子,逐个分析。”
“影响因子对结果的影响是定性的,并不能直接推出来,如果想通过影响因子分解这种方式做增长,测试是一个好办法。”
枚举法
“枚举法是把所有的数据一一列举出来,然后进行后续的分析。枚举法是策略产品经理日常分析数据用得最多的方法,当然对于其他类型的数据产品经理而言,也非常好用。”
“枚举法的通用分析步骤
“要想快速抓住重点,还需要借助两种思维:排序思维和抽样思维。
1.排序思维
排序指把某个指标降序排列和升序排列,然后按上述的枚举方式进行分析
“2.随机抽样
枚举的方式可以快速看到问题,但是不能保证问题的典型性;加入排序思维后,可以划定范围,但是可能会造成偏差,因为不代表全部用户行为。”
1.排序思维
排序指把某个指标降序排列和升序排列,然后按上述的枚举方式进行分析
“2.随机抽样
枚举的方式可以快速看到问题,但是不能保证问题的典型性;加入排序思维后,可以划定范围,但是可能会造成偏差,因为不代表全部用户行为。”
产品路线图
“制订产品路线图是从产品战略目标出发,通过需求管理和优先级排序,找到产品阶段性目标并制订规划的一系列过程,这个过程可分为4个主要步骤:制定产品战略目标、收集并整理需求、确定优先级和规划路线图。”
“制定产品战略目标”
“产品的战略规划,自上而下可分为4个层级,依次是产品愿景、产品目标、产品路线图、产品迭代计划与任务”
产品愿景
“产品愿景一般已经由CEO和高管层制定好,产品经理所需要做的就是深入理解,思考如何制定有效的产品战略目标来实现这个愿景”
产品目标
“产品目标就是为了达到产品愿景,所需要达到的一个或多个目标。产品目标是阶段性变化的,在不同的产品生命周期,有不同的产品目标。好的产品目标有一定挑战性且能够满足用户以及商业目标的达成。可以从以下几个方向来制定产品目标。”
“(1)用户/客户满意度
(2)产品指标
“(3)业务指标
(4)技术改进
“(5)推广新服务”
产品路线图
“产品路线图是产品需求在时间轴上的总体视图,能够宏观展示产品的发展方向和目标,同时又是一个强调产品迭代计划的时间表,是个动态文档,在实际情况中需要不断更新,所以在创建的初期,对需求、工作量、优先级和完成时间的评估不需要很精确,可以随着项目的进行随时调整。”
“产品路线图能够让产品负责人和团队成员了解产品的长远方向和计划,并提供关于实现这些目标和时间节点的指导,避免团队冲突,提升团队的协同效率。”
“收集并整理需求”
“收集并整理需求的方式有很多,下面介绍几种最常见的方式。
用户/客户反馈
“根据需求的目标客群不同,可以选择不同的收集方式,常见的方式有意见反馈、种子用户或忠诚用户的访谈。用户访谈中需要注意的是,避免刻意引导式的提问。”
竞品分析
“好的竞品分析,其实就是完整、可靠、全面的分析过程,最后得出有目标、有数据支撑的分析结论。”
“销售人员和客户服务人员”
“一线业务销售人员和客户服务人员,因为经常与客户接触,他们的需求往往都来源于客户,所以建议产品团队建立起定期与业务及客服团队沟通的机制。
要提供给业务及客服团队标准化的需求登记表,这个表格中的内容可以一同商议决定,结合现有的业务、产品线确定需求的分类(便于分类整理需求),需求的描述要有标准和范例指导。
有必要对需求登记表的填录人进行相关需求描述的培训,确保需求提出人能够准确描述需求,这样可以节省很多沟通成本。每周在固定时间共同确认需求登记表中的需求,并及时反馈给需求提出方,以确保需求沟通机制的良性循环。”
要提供给业务及客服团队标准化的需求登记表,这个表格中的内容可以一同商议决定,结合现有的业务、产品线确定需求的分类(便于分类整理需求),需求的描述要有标准和范例指导。
有必要对需求登记表的填录人进行相关需求描述的培训,确保需求提出人能够准确描述需求,这样可以节省很多沟通成本。每周在固定时间共同确认需求登记表中的需求,并及时反馈给需求提出方,以确保需求沟通机制的良性循环。”
行业分析
“在对行业进行深入挖掘时,一般需要进行以下几个方面的信息收集:
·行业背景(市场规模、主要竞争对手、市场发展趋势、机会和风险等)
·商业模式(商业画布、盈利模式、细分领域机会等)”
“·竞品分析(市场占比、产品优劣势、竞争壁垒、上下游合作伙伴等)
·用户研究(目标用户、需求、痛点、群体特征、解决方案等)
我们能从行业分析中提前了解趋势,布局未来。”
·行业背景(市场规模、主要竞争对手、市场发展趋势、机会和风险等)
·商业模式(商业画布、盈利模式、细分领域机会等)”
“·竞品分析(市场占比、产品优劣势、竞争壁垒、上下游合作伙伴等)
·用户研究(目标用户、需求、痛点、群体特征、解决方案等)
我们能从行业分析中提前了解趋势,布局未来。”
头脑风暴
“推荐使用六顶思考帽的方式,通过使用一些脑图工具,明确目标和参会人员,严格限定发言时间和讨论规则。当遇到跑题、超时的情况时,主持人需要控制节奏和话题,对不同的意见或评价,一定要放到最后进行评判,避免打击发言积极性,鼓励相互之间补充完善。
数据反馈
“数据源有三大类:行为数据、用户信息数据、交易及日志数据”
“需求收集和整理完成后,我们需要进行需求的分类与分析,不思考就直接拿去和研发或业务部门沟通需求,是极其不负责的做法。
另外,通过对需求的整理,会对需求有个整体的全局观。”
另外,通过对需求的整理,会对需求有个整体的全局观。”
确定优先级
“在设定需求优先级时,根据以往的工作经验,有以下几项工作需要注意:
·对需求进行合理的分类;
·把这件事作为一项团队的共同活动(不仅仅是产品经理的事);
·限制优先事项的数量(不能所有事情都紧急,数量上限取决于研发资源);
·选择适用的方法论或工具;
·需求目标要明确;
·粗略的估算成本(不一定要按人天估算,也可以是大中小)。.
·对需求进行合理的分类;
·把这件事作为一项团队的共同活动(不仅仅是产品经理的事);
·限制优先事项的数量(不能所有事情都紧急,数量上限取决于研发资源);
·选择适用的方法论或工具;
·需求目标要明确;
·粗略的估算成本(不一定要按人天估算,也可以是大中小)。.
“一些常见的优先级设定的方法和工具。”
“价值与复杂度模型”
“价值与复杂度模型是比较常见的方法,有经验的产品经理每天都会本能地进行这种评估,主要基于两个方面:
·商业价值(Business Value)
·复杂度/投入成本(Complexity/Effort”
·商业价值(Business Value)
·复杂度/投入成本(Complexity/Effort”
“优先级最高的就是第一象限内的,商业价值高、复杂度和投入成本相对低。此方法适合那些能够直接体现商业价值的需求,比如会员相关的付费功能、一些产品的核心业务流程中的功能等。”
“价值与复杂度模型”
加权评分
“这是一种相对客观的评估方法,从收益和成本两个方面找到多个关键衡量指标,通过对各个指标进行加权评分,可以帮助团队更客观地评估优先级,适合精细化经营管理的团队,如图3-3所示。以下是收益和成本两方面的关键衡量指标。
·收益:收入、客户价值、战略价值等。
·成本:研发成本、运营成本、复杂度、风险等。”
·收益:收入、客户价值、战略价值等。
·成本:研发成本、运营成本、复杂度、风险等。”
“加权评分表(案例)”
KANO模型
“KANO模型是通过分析需求对用户满意度的影响,以及产品性能和用户满意度之间的非线性关系,从用户角度进行需求分类的方法。不同类型的特性和用户满意度之间的关系可分为以下5类:
“·基本(必备)型需求”
“·期望(意愿)型需求
·兴奋(魅力)型需求
·无差异型需求
·反向(逆向)型需求
“·基本(必备)型需求”
“·期望(意愿)型需求
·兴奋(魅力)型需求
·无差异型需求
·反向(逆向)型需求
KANO 模型
SWOT分析
“SWOT分析常用于做产品的战略规划,是对内外部的一个综合评估分析,它包括以下4个方面:
·优势(Strengths)
·劣势(Weaknesses)
·机会(Opportunities)
·威胁(Threats)
·优势(Strengths)
·劣势(Weaknesses)
·机会(Opportunities)
·威胁(Threats)
SWOT分析
四象限分析法
四象限分析法
规划路线图
“产品路线图建议包含版本目标、核心需求、时间周期和里程碑,具体介绍如下。”
“1)版本目标
设定每个版本的核心目标,不需要多,一两个就够,注意最好是可衡量的结果目标,并与战略及业务目标挂钩。
(2)核心需求
找到对每个版本的目标影响最大的几个核心需求,简要地列出来。注意不要把一些小功能当作核心需求。
(3)时间周期
建议选定一个大版本迭代周期的3~5倍作为产品规划的时间周期,这样做的合理性在于,一个迭代周期往往是确定的任务工作事项和目标,以此为基础来确定规划的时间周期,既不会感觉特别长远、不太实际,又不会导致规划节奏太紧。当然,时间周期的设定是比较灵活的,我们是按照季度来设定的。
“时间周期的规划并不是固定不变的,只是要有一个预计,项目团队不用太担心日期到了没有实现会怎样,这是一个规划目标或者是优先事项的鸟瞰图,是允许变动和适量调整的,并且我们应当积极拥抱变化,要留出适当的空间去适应变化,所以可以在周期设定上预留一些时间,建议是预估值的10%~20%。
(4)里程碑
找到关键目标,并为此设定一个时间节点,作为里程碑。”
设定每个版本的核心目标,不需要多,一两个就够,注意最好是可衡量的结果目标,并与战略及业务目标挂钩。
(2)核心需求
找到对每个版本的目标影响最大的几个核心需求,简要地列出来。注意不要把一些小功能当作核心需求。
(3)时间周期
建议选定一个大版本迭代周期的3~5倍作为产品规划的时间周期,这样做的合理性在于,一个迭代周期往往是确定的任务工作事项和目标,以此为基础来确定规划的时间周期,既不会感觉特别长远、不太实际,又不会导致规划节奏太紧。当然,时间周期的设定是比较灵活的,我们是按照季度来设定的。
“时间周期的规划并不是固定不变的,只是要有一个预计,项目团队不用太担心日期到了没有实现会怎样,这是一个规划目标或者是优先事项的鸟瞰图,是允许变动和适量调整的,并且我们应当积极拥抱变化,要留出适当的空间去适应变化,所以可以在周期设定上预留一些时间,建议是预估值的10%~20%。
(4)里程碑
找到关键目标,并为此设定一个时间节点,作为里程碑。”
产品路线图示例
“数据埋点体系
“数据埋点概述”
“通常我们说的埋点,实际上是埋点技术。埋点技术是一种数据采集技术,特指针对用户行为或时间进行捕获、处理和上报的相关技术及其实施过程。”
“埋点的意义”
“数据产生价值的前提是数据源可信任,而埋点的意义就是解决数据源可靠性的问题。
“埋点的类型
“埋点类型有三种:Web埋点、App埋点和接口埋点。”
“1.Web埋点”
“Web埋点主要是通过先在页面中注入一段JavaScript代码,然后对收集的数据进行上报的技术。”
“在大数据运营之前,Web埋点主要关注的是各种指标和漏斗分析法。重要的指标有页面访问次数、页面用户数、页面停留时长和跳出率。漏斗分析法主要是指有递进关系的页面之间用户的流失率。Web埋点的意义更多的是优化页面,提高用户留存。在大数据运营之后,Web埋点更多地开始关注事件,同时上报用户信息,这样就可以对用户的兴趣点进行挖掘。”
2.App埋点
“App埋点技术是通过在代码中加入特殊的代码或者引入一个SDK,对App中的信息进行收集的一种技术。”
“pp埋点已经不仅仅关注页面优化带来的用户留存提升,而更加关注数据的全面性。”
“3.接口埋点”
“接口埋点。这种埋点不同于其他埋点的地方在于,它不是通过数据库系统直接存储,而是通过日志系统存储,然后通过ETL保存到数据仓库。
“接口埋点的意义主要是用于实时接口监控,可以让我们快速发现接口的异常情况。运维的报警系统很多都是通过接口埋点实现的。
“如何做好埋点
目标收集
“目标收集主要从两个角度思考,一个是用户信息(包含浏览器信息),一个是目标及事件。
“用户信息主要是指用户的身份与硬件环境信息。身份信息包括未登录的唯一码、登录后的唯一码、联合登录信息等,硬件环境信息包括操作系统、硬件设备码和经纬度等”
“目标及事件主要是指页面中的元素及元素触发的事件。元素要进行分级收集,主要遵从三个级别:页面、模块和元素。模块是有可能分级的,但是在埋点系统里一般我们不做分级上报,只对最子级的模块进行上报,在服务器端存储模块层级关系。”
“其实目标收集有一个很好的简单要义:谁对什么做了什么。这里的“谁”就是用户,“对什么”中的“什么”就是目标,“做什么”就是事件。在做埋点的时候,一定要记住这个要义。”
“埋点所谓的必要和全面”
“关于埋的点位要全,这就需要依赖交互设计图了。在交互设计图中,任何有交互的元素都是需要考虑是否要进行埋的点。决定是否埋的依据是这个元素的交互是否有业务意义,如果有就需要进行埋点。此外,在用户行为产生结果的逻辑代码中也需要进行埋点。这样就可以保证埋点的全面性。”
“埋点上报的信息如何做到全面呢?以事件驱动。用事件作为埋点的点,需要上传的信息包括事件本身和触发事件的用户信息,以及触发元素本身所在实体(对于客观世界物体的抽象)的信息。”
“是不是所有的事件及其相关信息都需要上报呢?答案是否定的,特别是在用户量级很大的应用中,每多上报一种信息,就代表多很多的流量费用和存储费用。所以只有能够产生业务意义的事件及相关信息才需要上报。”
“以UI设计为底、以业务价值为依据、以事件为起点、以“要义”为目标进行埋点,就可以保证目标收集的必要和全面。”
字典管理
“字典管理的第一个要点是埋有所编。一个埋点对应一个标识信息,这样每一个埋点就相当于有了一个身份。这个标识信息既可以在后续的数据分析中发挥重要价值,也方便在埋点管理平台中进行管理。”
“字典管理的第二个要点是便于检索。在给模块起名的时候要遵从全路径原则,也就是页面→模块→最子级模块→元素→事件。
“埋点管理平台
“除了字典管理之外,埋点管理平台还包括埋点可视化管理、埋点状态监控及埋点测试几个模块
“1.埋点可视化管理模块”
“2.埋点状态监控模块”
“3.埋点测试模块”
埋点技术
JavaScript埋点
“JavaScript埋点是主要应用于Web应用的埋点,通过在页面的底部加入一段JavaScript代码来完成埋点。一般在页面上显示为一个GIF小图标,图标的来源是一个JavaScript文件地址。
JavaScript埋点一般支持自定义事件的收集,这样就可以充分地对用户的行为进行收集。
JavaScript埋点也会应用Cookie技术,对用户身份进行标识,但是如果用户清除了Cookie,会导致用户身份丢失。”
JavaScript埋点一般支持自定义事件的收集,这样就可以充分地对用户的行为进行收集。
JavaScript埋点也会应用Cookie技术,对用户身份进行标识,但是如果用户清除了Cookie,会导致用户身份丢失。”
App埋点
“App埋点主要分成两种方式,有埋点技术和无埋点技术。”
“有埋点技术”
“埋点技术就是在逻辑代码中插入一条自己需要的埋点代码进行数据上报。这样的埋点技术可以根据业务需求精准埋点,但是也带来了一个问题:埋点管理问题”
“无埋点技术”
“无埋点技术的好处是,通过引入SDK,接下来就会自动完成埋点,这样就可以规避很多人工错误。”
“实际上在对业务数据要求高的场景下,无埋点技术还是有一些缺点的:
·采集的标准化使非标准化采集成为不可能;
·只能监控部分事件,并不能上报所有事件信息;
·由于目前App开发的复杂性上升,无埋点技术并不能兼容所有的场景;
·标准化上报导致很多业务无效的信息也进行了上报,大量的无效信息上报在流量大的场景下会带来巨大的流量及处理资源的浪费;
·无法获取业务逻辑内的信息跟踪。”
·采集的标准化使非标准化采集成为不可能;
·只能监控部分事件,并不能上报所有事件信息;
·由于目前App开发的复杂性上升,无埋点技术并不能兼容所有的场景;
·标准化上报导致很多业务无效的信息也进行了上报,大量的无效信息上报在流量大的场景下会带来巨大的流量及处理资源的浪费;
·无法获取业务逻辑内的信息跟踪。”
“埋点技术的选择”
“·公司刚启动,技术人员少,人员流动大,公司初步扩张中,尚未进入精细化运营阶段。只要符合其中一点,就可以选择无埋点技术。
·项目在天使阶段之后的融资阶段,业务复杂度高,App应用的技术多样。符合这些点中的一点,就不要用无埋点技术了。当然,在融资阶段,使用私有化部署的无埋点技术也还是可以的。
·公司流量巨大,业务复杂度高。当公司进入这个阶段的时候,就需要有埋点和无埋点技术联合使用。对无埋点技术也要进行一定的修改,上报阶段要通过后台配置项进行配置上报。
·项目在天使阶段之后的融资阶段,业务复杂度高,App应用的技术多样。符合这些点中的一点,就不要用无埋点技术了。当然,在融资阶段,使用私有化部署的无埋点技术也还是可以的。
·公司流量巨大,业务复杂度高。当公司进入这个阶段的时候,就需要有埋点和无埋点技术联合使用。对无埋点技术也要进行一定的修改,上报阶段要通过后台配置项进行配置上报。
数据中台
数据中台是什么
“跨业务体系数据中台全景图
“数据中台技术架构图”
“One Data, One Entity, One Service
“一个比较好的数据中台组织结构至少应该包含企业的唯一数据仓库层、唯一的数据指标体系共享层、公共数据营销层。只有这样才能完成数据价值最大化的战略目标。在中台的战略下,非统一的数据中台组织结构都是不合适的组织结构。”
“数据中台的产品形态”
统一指标平台
“统一指标平台的意义:在全公司内进行唯一的数据掌控、业绩对比及效果评估,是业务数据治乱的起点。”
“一个完整的指标包括指标名称、计算标准、计算代码、依赖的数据库表、库表结构定义,以及库表和生产系统对应关系说明文档。
“于是一个公司内的统一指标平台应运而生。它既包括指标BI、指标查询、口径说明的前台展示部分,也包括认证、权限、SQL维护的系统模块,还包括数据底层开发。
“统一指标平台不仅要给用户提供界面展示,同时要对外提供接口级服务,让前台业务可以快速搭建业务需要的BI系统。”
统一标签平台
“统一标签平台是公司对业务侧提供数据包服务的统一平台。业务侧可以利用统一标签平台进行标签的选取或组合,获取数据包。
“指标的目的在于度量,而标签的目的在于分类,二者区别明显。同时,指标一般输出的是一个结果数据或数据列表,又或者是排行榜信息,而标签更多的是一个数据的集合;指标输出的是直接的结果,而标签返回的主要是数据包。”
“统一标签平台的意义:全域的统一标签平台可以最大可能地进行数据打通,为公司的降本增效、营销增长和价值发现等服务提供最基础的数据支撑。
可视化报表平台
“可视化报表平台真正的意义都在于,最简单地满足业务的诉求。
“中台的可视化报表平台有以下几个比较重要的特征。
·平台化:基于SaaS操作平台,所有业务人员都可以通过统一的平台查看报表。
·业务化:数据报表需要沉淀各业务线的数据诉求,能够反映各业务线的成本、业绩、运营“及营销效果等。
·快速响应:分两个方面,一是研发侧,要有分层开发的架构,同时提供组件化的支持;二是业务侧,能够在成熟的平台上快速进行简单的报表搭建和数据分析。
可视化报表平台的意义:能够对业务数据化进行支撑,并在一定程度上支持业务部门的独立数据分析。”
·平台化:基于SaaS操作平台,所有业务人员都可以通过统一的平台查看报表。
·业务化:数据报表需要沉淀各业务线的数据诉求,能够反映各业务线的成本、业绩、运营“及营销效果等。
·快速响应:分两个方面,一是研发侧,要有分层开发的架构,同时提供组件化的支持;二是业务侧,能够在成熟的平台上快速进行简单的报表搭建和数据分析。
可视化报表平台的意义:能够对业务数据化进行支撑,并在一定程度上支持业务部门的独立数据分析。”
智慧营销平台
“智慧营销平台的前提是全域的数据打通”
“智慧营销平台的意义:提供丰富的数据模型,能够支撑企业的各个业务线进行全域的营销活动,实现企业基于数据的业务增长,让企业的资源可以统一调配及资源利用最大化。”
数据指标体系
“什么是数据指标”
“数据指标有别于传统意义上的统计指标,它是通过对数据进行分析得到的一个汇总结果,是将业务单元精分和量化后的度量值,使得业务目标可描述、可度量、可拆解。”
指标的构成
“指标由维度、汇总方式和量度组成”
“维度是指从哪些角度衡量,是看待事物的视角与方向,决定了根据不同角度去衡量指标。汇总方式是指用哪些方法衡量,是统计汇总数据的方式。而量度主要是明确事物的具体目标是什么,是对一个物理量的测定,也用来明确数据的计量单位。
指标的构成
“什么是指标体系”
“体系化的本质是将数据指标系统性地组织起来,具体会按照业务模型、按标准对指标不同的属性分类及分层。”
“数据指标体系是对业务指标体系化的汇总,用来明确指标的口径、维度、指标取数逻辑等信息,并能快速获取到指标的相关信息。
“数据指标体系的价值主要体现在全面支持决策、指导业务运营、驱动用户增长,同时统一统计口径”
“数据指标体系的价值”
“数据指标的分类”
指标的类型
“纯从技术角度对指标进行分类,指标的主要类型有基础指标、复合指标和派生指标
“指标的主要类型”
“基础指标等同原子指标,主要是指不能再拆解的指标,通常表达业务实体原子量化属性的且不可再分的概念集合,如订单数、DAU
“复合指标是建立在基础指标之上,通过一定运算规则形成的计算指标集合,如ARPU值、人均阅读章节数。
“派生指标是指基础指标或复合指标与维度成员、统计属性、管理属性等相结合产生的指标。派生指标=一个原子指标+时间周期修饰词+其他修饰词,即派生指标是对原子指标业务统计范围的圈定。
“数据指标的类型”
“根据日常业务及需求的需要将数据指标分为埋点数据、业务数据、财务数据、复合数据这几大类”
“数据指标的类型”
“数据指标体系建设的方法与步骤
“数据指标体系建设的方法”
北极星指标
AARRR
GSM模型
“数据指标体系建设的步骤”
“数据指标体系建设的步骤
“A/B测试系统搭建”
“A/B测试,也叫A/B试验、对比试验,是一种将试验对象随机分组并针对不同组对象给予不同的变量刺激,然后采集试验数据,运用统计学上的假设检验来判断不同变量对试验效果的影响是否显著的科学试验方法。A/B测试并不是只能有两组试验,ABC测试、甚至是ABCD…N测试,这些都可以称作A/B测试。一般来说,A代表对照组,B、C、D等为试验组,试验组可以分为多组并给予不同的刺激,可以是不同变量或者一个变量的不同实例,比如”
“A/B测试特点”.
“·先验性:A/B测试其实是一种“先验”的试验体系,属于预测型结论,与“后验”的归纳型结论差别巨大。所有统计分析都是后验的,只能解释,A/B测试是先验的,能直接对业务产品进行干预和影响。
·科学性:通过严格的随机算法将相似特征的用户均匀分配到试验组中,确保每个组别的用户特征的相似性,从而避免出现数据偏差,使得试验的结果更有代表性。
“·严谨性:A/B测试是一种科学的评估手段,其试验结果需要通过统计学的假设检验进行验证,有着深厚的概率统计学理论的支撑。
·成效性:可以以较低的成本在小范围内进行测试,试错成本较低,而测试有效方案可以快速通过全量用户覆盖,实现收益最大化。
·并行性:A/B测试可以将两个或两个以上的方案同时在线试验,这样做的好处在于不仅保证了每个版本所处环境的一致性,便于更加科学客观地对比优劣,而且还节省了验证的时间,无须在验证完一个版本之后再测试另一个。
·持续性:A/B测试是一套持续提升改变的进化体系,并不是一次性或偶尔的,通过持续的测试可以从试验中学习最优选择
·科学性:通过严格的随机算法将相似特征的用户均匀分配到试验组中,确保每个组别的用户特征的相似性,从而避免出现数据偏差,使得试验的结果更有代表性。
“·严谨性:A/B测试是一种科学的评估手段,其试验结果需要通过统计学的假设检验进行验证,有着深厚的概率统计学理论的支撑。
·成效性:可以以较低的成本在小范围内进行测试,试错成本较低,而测试有效方案可以快速通过全量用户覆盖,实现收益最大化。
·并行性:A/B测试可以将两个或两个以上的方案同时在线试验,这样做的好处在于不仅保证了每个版本所处环境的一致性,便于更加科学客观地对比优劣,而且还节省了验证的时间,无须在验证完一个版本之后再测试另一个。
·持续性:A/B测试是一套持续提升改变的进化体系,并不是一次性或偶尔的,通过持续的测试可以从试验中学习最优选择
“A/B测试的应用场景大致可以分为界面试验、功能试验、算法试验、人群试验四个类别。
“A/B测试流程”
“A/B测试系统设计
“A/B测试系统就是一套能将A/B测试方法标准化的工具,通过产品化后,可以降低用户使用门槛,提高A/B测试迭代速度,规范试验流程,减少人为操作过程中所犯的错误,还可以沉淀不同的数据和策略。”
“一个完整的A/B测试系统至少需要有试验管理、分流模块、业务接入、数据采集和结果分析这五个模块”
1.试验管理
“试验管理就是一个A/B试验配置后台,通过页面与用户交互引导用户完成试验关键参数配置,并允许用户对试验进行管理。方便用户快捷地创建A/B测试试验,增加新的A/B测试分组,调整A/B测试方案各个组的比例,让A/B测试运行起来。试验管理模块对实时性要求最高,需要在用户操作调整确定后,实现线上试验随即变更。
2.分流模块
“分流模块也叫流量分配模块,这个模块根据试验配置信息在用户请求服务时将用户分配给不同的试验组别。可以说分流模块是A/B测试最核心的模块,一个A/B测试系统设计的好坏关键看分流算法及策略是否优秀。好的A/B分流模块可以让流量分配得均匀随机,同时具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力,并且保证分组的均匀性和一致性。分流模块相当于一个路由器,所有的请求进入分流模块后根据用户唯一ID以及其他参数,通过系统的随机化算法,按照给定的配比将流量(用户)分为A、B两组(或者多组)
“(1)常用用户唯一ID选择”
“一般来说,通用分流服务的用户唯一ID会根据不同终端采用不同的用户标识,目前通用做法为Web端(含PC及App端的H5)采用CookieID,App端采用设备ID(对于设备ID,不同操作系统有各自生成的算法,一般来说iOS会用IDFA,安卓采用MAC地址+AndroidID+IMEI),小程序端采用OpenID。如果需要做到多端联动,还需要通过用户的注册ID等其他信息进行ID之间的强打通(ID-Mapping),建立平台真正的统一用户标识。”
(2)通用Hash算法
“Hash算法即散列算法,它并不是一种算法,而是一族算法,是密码学中一种单向不可逆加密算法。目前比较通用的Hash算法有MD5、SHA、Murmur等,通过一个函数将明文随机均匀分布到算法设计的多维空间中,空间维度越多,算法越复杂,也越难破解。如果有技术实力,可以根据密码学知识设计自己的Hash算法,具体可以查看密码学相关知识。
“目前在A/B测试中应用比较多的是通过Murmur算法将用户的唯一标识以及试验层layerid作为参数传入进行分组。这样既保证了用户分组的随机性,同时保证了多个层之间的正交关系。”
“常见流量分配策略对比”
3.业务接入
“一般通过提供一个A/B测试SDK或者A/B测试RESTful接口的形式供业务方使用。接入模块需要做到高效易用,最好能够适用于产品上所有类型的A/B测试优化。
(1)分离URL试验”
“分离URL试验最终会在试验配置完成后生成两个不同URL,对应两个不同版本的页面。这种接入方式的优点是实现简单,数据采集也比较容易,正常的系统日志即可实现数据采集,但是需要做两套试验页面,对前端资源占用比较大。特“别是在做同一个页面的多变量试验时,工作量会显著增大。
(2)编程代码试验
“编程代码试验是通过在同一个页面内设计实验,但是会通过代码控制页面的展示,这种方式对系统复杂度有更高的要求,在试验配置完成后,需要生成相应的控制和埋点代码,并将代码复制埋入试验页面。由于是通过代码控制页面展示,数据采集需要有所调整,将试验参数也作为埋点采集的数据点。”
(3)可视化试验
“可视化试验是前面两种方式的结合,最主要的作用是降低了设计门槛。可视化试验在生成基础页面后,通过可视化页面编辑修改变量并保存后就可以生成不同试验版本,试验的参数通过URL参数带入。”
4.数据采集
“行为数据打点和数据收集通过记录用户在A/B测试模块中的行为,将用户的行为收集到数据中心,为最终确定新的优化点是否有效提供原始数据。”
5.结果分析
“对上传的日志进行数据清洗和数据分析,最后通过报表的形式进行展示。将采集的数据通过报表或可视化的形式展示出来,并给出效力、置信区间等指标(如果有样本选取过小,还应提示最小样本量)。另外,最好支持各类效果评估指标的扩展,可以将指标计算通用化、模块化,方便试验人员快速上线A/B测试,根据不同产品及A/B测试案例选择合适的指标。具体的效果评估指标需要读者根据自己公司及行业特点、产品形态、功能点等来定义,指标要方便量化,并能够直接或者间接与产品体验、用户增长、商业变现联系起来。
“A/B测试系统设计方案”
流程设计
“根据A/B测试的一般流程设计出A/B测试系统的流程,因为A/B测试系统其实就是将A/B测试固化的工具。”
1)系统登录
“需要有用户及权限管理功能,可以基于公司的OLAP系统或者公用的统一权限平台接入,一般企业内常用公司邮箱账户作为登录名,以免公司内部账户和权限管理不一致,特别是因员工离职或换岗带来的权限变更。”
“2)填写项目信息”
“项目信息包含项目名称、试验目的及试验假设等相关信息。项目信息一定要清晰填写,以保证其他用户能通过项目信息全面了解试验目的和试验方案,一般来说,在线下沟通并确定好业务的需求才填写相关信息。.
“3)选择OEC指标”
“在系统设计OEC指标时一定要多与业务方沟通,确定当前业务最核心的目标是什么,一定要将业务最为关心的指标包含在内,而且指标模块要有扩展性,在设计系统时留出接口,为后期扩展提供便利。
“4)确定试验方式”
“确定试验用来探索哪个因素对目标产生的影响,”
“5)设置各组占比”
“根据选择的变量,创建变量的变化,并分配各组的用户比例”
6)控制试验
“在试验创建成功后,对试验进行控制,可以修改未启动的试验、启动创建的试验、停止异常试验、克隆其他试验等。试验控制相当于用开关直接控制分流模块,决定是否让用户参与试验。开启试验后,网站或App的用户会被随机分配到控制组和试验组,用户每一步的操作都会被记录采集、计算和比较,以确定对照组和试验组在每一项改变上的表现。
“7)采集试验数据”
“试验开始后,我们需要持续采集各个版本的访问用户的行为,”
“8)分析试验结果,生成试验报告”
“9)持续迭代
原型设计
(1)试验概览
“试验概览类似于系统的dashboard,方便试验人员快速了解系统目前的运行状态,主要包括试验概览、流量的概览”
(2)试验管理
(3)创建试验
(4)试验执行
(5)试验报告
数据管理
数据的类型
“企业级的数据管理一般涉及三大类型的数据集:主数据、业务数据和元数据。”
“·主数据是用来描述企业核心业务实体的数据,如客户、合作伙伴、员工、产品、物料单、账户等。
·业务数据是用来描述主数据之间在某一时间点产生的某种数量关系,如交易订单表、视频流量表等。
·元数据是用以描述数据及其环境的结构化信息,便于查找、理解、使用和管理数据,如数据字典、建表语句等。”
·业务数据是用来描述主数据之间在某一时间点产生的某种数量关系,如交易订单表、视频流量表等。
·元数据是用以描述数据及其环境的结构化信息,便于查找、理解、使用和管理数据,如数据字典、建表语句等。”
1.主数据
“主数据是用来描述企业核心业务实体的数据,而不同的业务实体数据会以维表的形式存储在数据仓库中,每一张维表包含多个字段,用来辅助描述该实体的属性特点。主数据有一个比较明显的特质是缓慢变化,“也就是主数据的变化频率会比交易类数据低很多”
2.业务数据
“业务数据描述某一时间点不同业务实体之间产生的某种数量关系,如交易金额、交易数量等,这样就能把业务实体对象和发生的事实关联“一起,所以一般我们会称业务数据为事实表。
事实表会以多个字段存储在数据仓库中,其中主要包含事实的主键、主数据的外键、时间点信息、数量信息等。相比主数据,业务数据的变化频率非常快,而且数据量巨大,比如淘宝的交易订单,可能一秒就会产生上千万条业务数据。
事实表会以多个字段存储在数据仓库中,其中主要包含事实的主键、主数据的外键、时间点信息、数量信息等。相比主数据,业务数据的变化频率非常快,而且数据量巨大,比如淘宝的交易订单,可能一秒就会产生上千万条业务数据。
3.元数据
“元数据是和业务非强相关的一种数据,它是描述数据结构、数据类型、数据存储位置等信息的一种数据形态的总称。就好比我们把交易流水记录到笔记本上,而第一页就是一个交易目录,这个目录记录着一系列汇总和索引信息,能够帮助我们迅速定位到我们需要的数据。
“总结一下,这些数据集的主要用途如下:
·元数据是用来定位和理解业务数据的字典;
“·业务数据存储着核心的交易内容;
·主数据是用于提取辅助描述信息的数据结构。
·元数据是用来定位和理解业务数据的字典;
“·业务数据存储着核心的交易内容;
·主数据是用于提取辅助描述信息的数据结构。
“我们管理的是主数据和元数据,因为主数据和元数据都是业务系统可以维护的、缓慢变化的维度。”
主数据管理
“主数据管理四要素”
“·梳理好主数据的范围边界及定义标准;
·确认业务规则,对齐业务口径;
·明确人员、部门的权限及职责范围;
·要有一套企业级的主数据平台,便于主数据的统一管理和维护。
·确认业务规则,对齐业务口径;
·明确人员、部门的权限及职责范围;
·要有一套企业级的主数据平台,便于主数据的统一管理和维护。
“这四要素分别对应着主数据平台的实体模型、业务定义及流程、人员职责与权限、主数据“平台及填报系统的工具易用性。”
“业务输入即指业务专家梳理出来的业务知识,它是设计整个主数据模型的蓝图,是所有设计实施人员的知识产出,其重要性不言而喻”
“主数据管理的设计蓝图主要包含以下部分。
·主数据的编码规范:用于统一主数据的核心编码及校验查重逻辑。
·数据清洗规则:业务系统之间的数据映射转换规则、大规模业务主数据接入的业务逻辑前置条件。
“·业务流程管理规范:主数据订阅、分发、增删改冻等操作流程和审批流程。
·主数据填报规范:主数据所需填报字段以及字段级别的属性约束规则、校验逻辑等。”
·主数据的编码规范:用于统一主数据的核心编码及校验查重逻辑。
·数据清洗规则:业务系统之间的数据映射转换规则、大规模业务主数据接入的业务逻辑前置条件。
“·业务流程管理规范:主数据订阅、分发、增删改冻等操作流程和审批流程。
·主数据填报规范:主数据所需填报字段以及字段级别的属性约束规则、校验逻辑等。”
元数据管理
“元数据本质是描述性的标签,描述了数据、实体、业务以及它们之间的关系。”
“元数据本质上是一个相对的概念,在上面的例子中,我们认为书名、作者、出版社等是“书”这个实体的元数据,这些元数据是用来描述“书”这个实体的,但如果把实体换成“书名”,那么元数据的内容就发生了变化,元数据不再是描述“书”这个实体了,而是“书名”这个实体
“元数据的相对性举例”
“元数据编码框架”
子主题
“·元数据内容:这一层是最贴近底层描述的语义层,对现实实体进行描述,通常包括术语、主题词表、本体、分类、数据元素、代码集等。
·元数据描述语言:向上一层是交换方式的描述,这一层通过规范化的元数据描述语言对实体概念进行描述,通常包括数据结构、元数据schema、结构化命名协议、语法原则、描述语言等。
·元数据描述框架:再向上抽象一层是形式化表示层,主要是通过元数据描述框架对元数据进行建模,包括元对象基础设施(Meta Object Facility,MOF)、资源描述框架(Resource Description Framework,RDF)等。”
·元数据描述语言:向上一层是交换方式的描述,这一层通过规范化的元数据描述语言对实体概念进行描述,通常包括数据结构、元数据schema、结构化命名协议、语法原则、描述语言等。
·元数据描述框架:再向上抽象一层是形式化表示层,主要是通过元数据描述框架对元数据进行建模,包括元对象基础设施(Meta Object Facility,MOF)、资源描述框架(Resource Description Framework,RDF)等。”
“这三个层次逐层抽象,最底层描述的是概念层级的数据内容,上一层是表示通过什么方式或者什么语言来描述这样的概念,再抽象一层表示用怎样的框架将描述语言组织起来,从而对现实的概念进行一定程度的泛化和抽象。
数据服务
数据服务
“数据产品架构图
“数据赋能问题有两种数据服务解决方案:基于标准指标的数据服务和基于Hive表的数据服务。”
“数据服务通过数据API将数据部门的海量数据开放出去,所以数据服务是数据API的生产工厂与管理空间。数据服务的核心是生产数据API与下游应用调用API,这其中涉及监控、管理、权限校验、限流等数据管理模块,完成数据赋能的闭环。”
“数据服务的核心定位是作为公司内的数据管理与出口平台。”
“在数据链路上,数据服务处于数据开发——数据消费的中间层”
“数据服务可以分为两种模块:基于标准指标的数据服务和基于Hive表的数据服务”
“在“基于标准指标的数据服务”模块中,我们会了解到数据对外透出的两种模式。
“·数据服务以指标为核心构成的API服务来服务下游应用用户,即基于标准指标制作一致、标准、准确、稳定的数据API。
·数据服务以更加灵活、个性化的方式将数据能力开放给应用,即基于标准指标构建标准指标池,服务下游应用。”
·数据服务以更加灵活、个性化的方式将数据能力开放给应用,即基于标准指标构建标准指标池,服务下游应用。”
“在“基于Hive表的数据服务”模块中,我们尝试探索数据服务另一种更加灵活的方式,即通过“构建逻辑与物理分层模型解放效率,
让用户快速获取想要的数据。“基于Hive表的数据服务”有两种模式。
让用户快速获取想要的数据。“基于Hive表的数据服务”有两种模式。
“·可视化模式,即小白模式。通过可视化选择的方式让用户选择Hive表中的字段,然后把选择的字段作为数据API的入参与出参。
·自定义SQL模式,即脚本模式。通过自定义SQL设置数据API的入参与出参。”
·自定义SQL模式,即脚本模式。通过自定义SQL设置数据API的入参与出参。”
数据产品架构图
“基于标准指标的数据服务”的核心产品价值就是打破这种烟囱式开发,将指标提前构建成“API,放进API市场,用户申请权限后就能直接调用。这样一次开发多次使用的方式将极大提高数据消费效率。”
“基于Hive表的数据服务”模块会根据数仓建设的DWD层或者DM层Hive表,通过将物理表与逻辑表分层的方式将字段抽离出来,维护一个庞大的字段池或者指标池,而业务方可以根据所需选择的字段构建逻辑上的二维表,这样将会大大减少业务方对数仓的直接建表需求。数据服务在提升数仓开发效率的同时也提高了业务方的效率”
“数据服务的利益相关者主要分为三大类:数据产生者、应用级数据消费者和用户级数据消费者。”
“基于标准指标的数据服务”
“基于标准指标的数据服务的核心就在于基于标准指标制作一致、标准、准确、稳定的数据API,通过产品层面的一致性校验与选表规则以及强大的计算能力来保障数据内容的准确性与一致性,即利用统一指标平台定义好的指标通过不同的耦合方式生成标准数据API。然后通过API调用的方式供下游消费,完成内容定义——内容计算&内容传输——内容消费的全链路。”
API服务
“在API的角度上,API开发—API测试—API发布—API被申请权限—API调用构成API服务的完整流程。”
“API服务的用户路径”
指标池服务
““基于Hive表的数据服务”
“数据服务的核心是通过API的形式将数据开放出去,基于标准指标的模式能保证数据内容的一致性、准确性和安全性,但是用户往往还有一些更加灵活的需求,比如想通过写SQL获取数据,然后封装成API以供调用。
这种需求的本质是用户通过读取Hive表,将Hive表字段设置为API的入参与出参,在不保证数据内容质量的情况下创建一个API。
这种方式会有两种模式,一种是可视化模式,一种是开放平台自定义SQL模式。我们简单介绍一下两种基于Hive表数据服务创建API的方式”
这种需求的本质是用户通过读取Hive表,将Hive表字段设置为API的入参与出参,在不保证数据内容质量的情况下创建一个API。
这种方式会有两种模式,一种是可视化模式,一种是开放平台自定义SQL模式。我们简单介绍一下两种基于Hive表数据服务创建API的方式”
可视化模式
“可视化模式,即小白模式用户,用户不用写SQL,可以通过选择Hive表和字段设置创建API。常规理解是,用户首先通过选择数据来源、数据源名称、数据表的方式获取到Hive表,待系统读取Hive表中的字段后,用户再对展示的字段进行基本属性设置、入参设置、出参设置以及一些其他和指标一样的设置,就创建完成了一个API。之后走正常的测试—发布—申请—调用的流程。”
“开放平台自定义SQL模式”
“开放平台自定义SQL模式,即用户通过写SQL获取Hive表中的字段,然后创建生成API。”
策略产品经理
“策略产品经理的定义”
“依托新技术的架构,以策略输出为核心,以指标的达成为目标的产品经理。”
“略产品经理的思维体系”
“1.了解架构,懂原理,不深究技术实现”
“推荐的技术架构,至少有召回、排序、精排及策略四层”
“2.需要面向用户和面向后台的产品综合思维”
“3.以数据为基础,以数据指标为目标”
“策略产品经理常用思维方式和分析方法”
“把复杂的问题变简单,从琐碎的问题中提炼规律,从当前状态预判事态发展,这是策略产品经理日常思考问题的原则。这些过程分别对应着几种处理问题的思路,“分类”“下钻”“量化”“抽象”“极限”和“理想态”,这也是策略中最常用的几种方法。”
“问题分析思路图”
“策略产品经理常用的分析方法”
“session即会话,是指在指定的时间段内在网站上发生的一系列互动
“session分析是一种专业的数据分析,把用户单点行为串联成一个整体,在此基础上进行分析,解决用户分析中的“线”型难题
“session分析是一种专业的数据分析,把用户单点行为串联成一个整体,在此基础上进行分析,解决用户分析中的“线”型难题
“DCG(Discounted Cumulative Gain)打分法又名主观评测法,是策略里独有的打分方法,对应到策略产品思维方式里就是量化思维,其目的是将难以直接量化的评估维度,例如排序的合理性、用户满意度等,通过打分的形式汇总最终结果,方便对比和评估。”
“badcase分析并非策略中独有,这是最典型、最常用的分析方法。这种方法是通过线上遇到的具体问题的例子,反向分析这个问题出现的原因,以点带面,找到可以优化提升的通用方案。”
“query分析作为一种分析方法,从用户主动表达的查询词入手,了解用户的需求分布情况,再根据用户的query完成查询,通过逐个分析的方式,根据经验和数据,分析每个query结果可能存在的问题。
用户画像
概述
用户画像
“用户画像(简称“画像”)的定义并不复杂,系统通过用户自行上传或埋点上报收集记录了用户的大量信息,为便于各业务应用,将这些信息进行沉淀、加工和抽象,形成一个以用户标志为主key的标签树,用于全面刻画用户的属性和行为信息,这就是用户画像。
“用户画像是一个标签树的结构,这个标签树是多层级、多维度组织的,设计的时候将末级标签作为最细粒度的刻画维度,末级标签对应的标签值就是用户信息在维度下的属性,标签值会通过采集、挖掘等方式计算生成。”
“用户画像是一个多层级的标签树,但层级并不是固定不变的,具体长度根据标签实际情况确定,可长可短,但建议总长度不要超过5级,复杂的层级对于管理和理解都有较大的成本和难度。
“末级标签并不是固定的某一级标签,而是指每行标签最末端的标签。
“标签值是末级标签的属性值,是用来描述末级标签的信息字段。标签值的类型有很多种,文本、数字、省市结构或者空间坐标都可以成为标签值。标签值的格式也不是固定不变的,离散型还是连续型,数字格式需要保留到小数点后几位,这些都是需要产品经理定义好的”
标签的类型
“照末级标签生产方式的不同,画像的标签可以划分为四种类型:直采型、统计型、挖掘型和预测型。
“1)直采型
顾名思义,直采型就是直接采集的用户标签,直接从用户基础信息表内取到的用户信息,不需要统计和计算。
顾名思义,直采型就是直接采集的用户标签,直接从用户基础信息表内取到的用户信息,不需要统计和计算。
“2)统计型
统计型是利用用户日志数据,按照一定的规则进行简单统计的标签。这种标签只要需求和规“则确定,加工速度非常快
统计型是利用用户日志数据,按照一定的规则进行简单统计的标签。这种标签只要需求和规“则确定,加工速度非常快
“(3)挖掘型
挖掘型属于算法标签,利用用户行为数据或者文本数据,结合业务规则进行算法加工,输出对应的属性值或分值。如有必要,对分值进行归一化处理。”
挖掘型属于算法标签,利用用户行为数据或者文本数据,结合业务规则进行算法加工,输出对应的属性值或分值。如有必要,对分值进行归一化处理。”
“(4)预测型
预测型标签也是算法标签的一种,其原理与挖掘型标签相似,区别在于预测型重点应用于典型的预测场景,例如用户的流失概率。除了输出常规的标签值,还需要跟一定的预警和自动策略结合。”
预测型标签也是算法标签的一种,其原理与挖掘型标签相似,区别在于预测型重点应用于典型的预测场景,例如用户的流失概率。除了输出常规的标签值,还需要跟一定的预警和自动策略结合。”
“标签生命周期管理
“根据是否需要更新,可以将标签简单划分为两大类:静态标签和动态标签。”
“标签是否需要按照什么方式以什么频次更新什么时间的数据。这也是标签管理的重要一环。”
“用户画像从0到100的构建思路”
“用户画像从0到1的构建思路
“画像通常从8个维度组织标签,分别为基本属性、平台属性、行为属性、产品偏好、兴趣偏好、敏感度、消费属性、用户生命周期及用户价值。”
“用户画像整体架构示例”
“用户画像从1到100的构建思路”
“用户画像的主要目的有以下3个:
·用于用户信息的统计,建立对产品、对用户的基本认知;
·用于用户定向营销,利用人群圈选投放物料;
·用于算法,沉淀用户特征,供模型使用。”
·用于用户信息的统计,建立对产品、对用户的基本认知;
·用于用户定向营销,利用人群圈选投放物料;
·用于算法,沉淀用户特征,供模型使用。”
“用户标签的生产流程”
“用户标签的生产流程
“一个用户标签的制作流程整体如下。
1)标签定义:给出标签的定义,即发生什么行为的用户可以打上这个标签。
2)用户行为获取:探究不同的用户行为的获取难度,包括怎么获取数据、怎么处理数据。
3)模型设计:经过分析,确定了哪些行为之后,就可以进行模型的设计。
4)标签计算:对原始用户行为数据进行计算,生成标签。
5)标签评估:对生产的标签进行评估,看准确率、覆盖率等指标是否达到预期。”
1)标签定义:给出标签的定义,即发生什么行为的用户可以打上这个标签。
2)用户行为获取:探究不同的用户行为的获取难度,包括怎么获取数据、怎么处理数据。
3)模型设计:经过分析,确定了哪些行为之后,就可以进行模型的设计。
4)标签计算:对原始用户行为数据进行计算,生成标签。
5)标签评估:对生产的标签进行评估,看准确率、覆盖率等指标是否达到预期。”
“一个完整的用户行为(session)包含5个要素:用户、时间、接触点、内容和操作。要把这5个要素都获取到。”
“用户画像的效果验收”
“整个效果验证分为离线部分和线上部分,线上试验的方法大家都比较清楚,就是经典的A/B测试”
“离线验收主要分为算法指标验收、分布验证、交叉验证和抽样评测四种方案。”
1.算法指标验收
“算法指标是对算法能力的评测,例如机器学习,常用指标为AUC、AUC提升率、召回率及准确率四大指标。AUC是算法的常用指标;提升率则是跟之前的迭代对比,评估本次的提升幅度;召回率和准确率是算法基础指标,用以评估标签的覆盖情况和准确情况”
2.分布验证
“分布验证是算法标签的过程验证方法,一个算法标签做完,输出结果是海量的“用户标识–分值”对,如何验证这些“用户标识–分值”和合理性呢,方法是选取待校验的标签和标签值,再选取最能影响用户在该标签分值的一个单点行为,比较分值和行为在用户轴上的分布情况。”
3.交叉验证
“交叉验证的前提:用已经验证过的正确标签和新标签做交叉,得到较为综合的用户特征,再根据经验判断新标签是否合理。”
4.抽样评测
“具体方案为,根据需要随机抽样或者抽取头部用户样本,与线上一定时间窗口行为统计数据做对比,辅助人工评测,标注合理的样本数量,来统计准确率。”
标签的MVP流程
做好标签系统的MVP测试机制
“MVP是指最小可行性产品,本质是为了加快迭代速度,以便获取认知。”
“对于标签来说,在MVP阶段,需要获取的认知包括以下几类。”
“·市场认知。产品经理想要知道某一类标签有没有用户点击,会不会带来后续的购买,商业价值如何。”
“·标签规则认知。不同的用户行为代表不同的意向,比如看汽车贷款文章比看汽车文章更能表明用户的买车意图。如何将这些用户行为用规则组合成用户标签,也需要产品经理进行MVP测试。
“测试算法效果。算法工程师想要知道算法开发的方向对不对,也需要用户行为反馈,所以也会采用MVP的方式。这种方式与小流量A/B测试的区别是,小流量A/B测试需要算法被开发好后上线测试,而MVP指算法工程师为了测试自己的想法,不一定非要把算法开发好,不管用什么方法,能够离线把用户圈定就可以。”
“标签的MVP流程
“1)产品经理和业务人员商定符合该标签的用户特征。
“2)人工设定提取具有上述特征用户的规则。
“3)将规则用SQL/其他语言写出来,去数据库取对应的用户ID,做成用户包。”
“4)利用MVP测试的工具,将用户包投到线上,看数据效果。
“5)如果效果好,产品经理就会列入产品需求,提给研发人员,进行需求排期;如果效果不好,就继续更换用户特征,进行线上测试。”
标签的MVP工具
“可以看到整个标签体系中的标签非常多,随时都有不同的用户包在线上测试,所以要有MVP工具,也就是一个用户包投放的功能”
“用户包投放的功能
“用户包投放的基本功能有以下两个。”
上传用户包:产品经理可以上传自己生成的用户ID。
·用户包管理:展现用户包列表,产品经理可以进行投放、暂停、删除等管理操作。”
上传用户包:产品经理可以上传自己生成的用户ID。
·用户包管理:展现用户包列表,产品经理可以进行投放、暂停、删除等管理操作。”
0 条评论
下一页