用户行为分析平台的出现完全是为了满足产品研发团队对数据分析简单、灵活、高频、快速的实际需求，直接面向数据驱动、增长营销、智能运营的集成数据分析平台。

相比传统数仓复杂的数据分层和数据模型，用户行为分析平台建模的思想虽然也源自维度建模，但将整个数据模型进行了极大的简化。降低了数据使用者对数据的理解门槛。在数据质量和数据实时性上也因为模型本身的简洁得到了有效的保证。

相比传统BI，数据源相对分散，数据使用过于灵活，用户行为分析平台统一了数据来源（统一的用户行为数据上报），根据实际产品运营研发团队对数据分析的要求提炼出了数据的特定使用模式（事件分析，留存分析，漏斗分析，分布分析，路径分析等等）。源自产品运营研发团队实际工作的分析方法，自然使得产品运营研发人员在使用数据时更加的得心应手，能够将目光聚焦于具体数据分析和使用本身。

用户行为分析平台从数据上报到数据可用可以做到分钟级。数据虽然并非实时，但是对于满足产品运营研发团队的数据分析已经足够了，完全满足数据驱动的要求。对于分析的场景，其实完全没有必要追求实时，够用才是最好的，没必要去承担实时系统的高成本。另一方面基于离线数仓的天级数据对于一个数据驱动的团队来说又完全不够。量变引起质变，只有足够快的出图速度才能达到连贯的数据思维。

用户行为分析平台完全基于用户行为数据的上报，分析的也是用户行为数据。缺失业务数据库中的数据。于是针对一些业务数据库中的数据无法有效分析。不过不断进化的用户行为分析平台允许用户自行上报一些维表数据补充部分业务数据的缺失。但仍然的，一些业务数据库相关的累计数据或者状态数据，分析起来仍然不方便。但是剩下这些搞不定的分析真的不多了。只需要稍微再针对这些数据做一些BI报表即可。

用户行为分析平台尽可能用最少的资源最低的成本最简单的逻辑最快的速度满足产品运营研发团队最多的数据分析需求。让团队中的每个人都能轻松玩转数据。这就是它巨大的价值。

对于中小公司，如果开始考虑搭建自己的数据体系，务必优先考虑搭建用户行为分析平台。对于中小公司的业务体量而言，真正可以称之为大数据的可能只有用户行为数据，业务数据库中的数据总体来说不会太大，这就更凸显了用户行为分析平台的价值。市面上也有着一批优秀的第三方公司提供基于SaaS或者私有化部署的用户行为分析平台。国内的比如：GrowingIO，神策以及字节跳动火山引擎的DataFinder；国外的比如：Mixpanel。虽然Google Analytics和Firebase Analytics是来自于巨头的产品，但其实做的不太好，所以也不太推荐。

用户行为分析平台的数据模型

用户行为分析平台的数据模型并没有统一的命名，有些称之为事件模型，有些称之为事件-用户模型。但核心要素就是用户（User）和事件（Event）。对应着基于用户标识的行为事件埋点上报，以及最终分析性数据库中存储的事件宽表和用户宽表。这样一个数据模型也决定了最终的数据分析的核心就是围绕着用户和事件展开的。

显然的，就像一句完整的话是由主-谓-宾构成的，用户产生的行为事件必然包含一个目标，将其称之为物品（Item）。早期用户行为分析平台并未太关注物品（Item）。导致物品相关的维度分析存在缺失。但随着用户行为分析平台不断的发展完善，物品（Item）也被纳入其中，成为数据模型的重要补充。在用户行为分析平台中与之对应的是相关的物品（Item）维度表。

目前，一个完善的用户行为分析平台的数据模型就是由：用户（User）-- 事件（Event）-- 物品（Item），这三个核心要素组成。随着用户行为事件的上报，系统尽可能快速的将上报事件数据解析为对应的事件表、用户表以及物品维度表的字段，供下游数据分析使用。同时，用户表中的一些属性字段以及一些物品维度表也可以通过专门的同步机制，从业务数据库中同步相应的数据，比如用户等级表，商品信息表，帖子状态表等等。用户行为分析平台通常由一张事件表、一张用户表和N张物品维度表组成。

用户行为分析平台数据上报一般采用json格式，一条典型的数据上报格式如下：event_name为事件名称，local_time_ms为事件发生的时间；user为触发事件的用户以及相应的用户信息，用于关联用户表；params为事件包含的属性信息；item为与事件相关的物品信息，用于关联物品（Item）维度表。

{
    "user": {
        "user_id": "0001",      
        "device_id": "asdf123",            
        "app_version": "9.13.5",
        "network_type": "wifi",
        "platform": "Android"
    },
    "params": {
                "author_id": "809654",
                "article_type": "video",
          "view_list": "main"
    },
    "items":{
        "article": [{
            "id": "789"
        }]
    },
    "event_name": "like_article",
    "app_id": "4567",
    "app_name": "buybuy",
    "local_time_ms": 1671593592638
}

以上示例为一条给视频内容点赞的用户行为数据。通过这条数据上报我们可以多维度的分析”内容点赞“这个事件，不同网络环境下给视频内容的点赞情况，比如不同内容类型的点赞情况等等。但一旦我们要分析内容的点赞总量或者我们想分析帖子状态信息（审核是否通过），仅仅通过行为数据的上报是很困难的，这时就要关联物品维度表中相关的内容属性。

用户行为分析平台的系统架构

下图展示的是神策的用户行为分析平台系统架构，以此为例，可以看到用户行为分析平台的整体技术架构大致可以分为以下几个部分：

1. 数据采集子系统。这块儿以前端后端的数据采集SDK为主，用来提供用户行为数据的采集功能和上报功能。因为用户行为分析平台天然包含了数据采集模块儿，有时候会有同学直接把用户行为分析平台叫做数据采集工具。
2. 数据接入子模块。用户行为数据通过Http请求进行上报，由Nginx作为数据接收端将用户行为数据写入日志。用Flume或者Logstash这类工具从日志读取数据并写入消息队列Kafka，供下游读取并处理。
3. 数据导入与存储模块。Spark或者Flink从Kafka中读取数据进行ETL之后写入存储。神策的OLAP模块使用的是Parquet+Kudu+Impala的模式，存储和查询分离。GrowingIO早期是使用HBase自研了一套OLAP引擎，后面重构之后采用的是ClickHouse。字节火山引擎的DataFinder从一开始就是使用自研的ByteHouse作为OLAP引擎，ByteHouse是基于ClickHouse的魔改版本。
4. 最后就是各种数据应用模块。包括数据可视化分析，智能运营等等。

整个系统架构摒弃了传统数仓的多层分层架构，数据接入之后以最短路径进入OLAP存储成大宽表。提升数据实时性的同时也降低了中间环节出错的可能性，尽量提升数据质量。

用户行为分析平台的数据能力

用户细查

上报的是用户行为数据，自然地，如果按照时间线展开每个用户的行为事件，就能够清晰的还原用户使用网站或者应用的行为细节以及所处的环境。能够帮助理解特定用的户行为以及定位线上问题。

用户细查需要包含的最基本功能就是能够按照用户ID或者设备ID搜索到该用户，并且展示该用户的基本用户属性信息。同时能够查询特定时间范围内的该用户的行为事件。如果做的更细致一些，可以提供更丰富的过滤条件，比如：可以选择需要包含的事件或者不想要包含的事件。

用户分群

用户分群是精细化运营的重要支撑手段之一，产品运营同学可以基于细分后的用户群开展用户画像、精细化分析、精准触达等工作。用户行为分析平台利用上报的用户行为数据以及用户属性相关的数据，可以非常容易的根据具体的行为事件和用户属性创建规则将用户进行分群，并固化下来。固化下来的用户分群不仅可以选择具体的用户进行用户细查，也可以作为目标用户进行事件分析，留存分析，漏斗分析等一系列的数据分析工作。

用户分群也可以通过直接上传用户ID列表文件形成分群，让分群方式更加灵活。

事件分析

事件分析应该是用户行为分析平台使用最广泛的功能。事件分析是针对特定事件特定目标用户的某一指标的分析。事件分析的大致步骤：

1. 选择想要分析的事件。例如：”内容点赞“事件。
2. 选择想要分析的指标。例如：”内容点赞“事件量，”内容点赞“事件人数，”内容点赞“事件人均次数等等。对于一些包含数值信息的事件，比如“下单”事件，还可以选择按照“下单金额”求和，求平均，求最大最小值等等。
3. 对事件增加过滤条件：对事件属性或者属性的组合进行相应的过滤，选择想要分析的特定属性条件。比如：通过过滤选择”内容类型”为“视频”，“内容出现位置”为“推荐列表”的”内容点赞“事件。
4. 选择目标用户：比如：目标用户为“新用户”或者使用其它用户属性来筛选。甚至可以做到更为复杂的用户圈选，比如：“过去30天访问过7天以上并且关注了3个以上up主的用户”

针对以上这样一个条件组合生成最终指标的可视化图表。实际中还可以做多个事件指标的计算，不同属性维度的对比展示，不同用户群组的对比展示等等。

留存分析

留存基本是产品运营最关注的指标之一。留存分析可以通过方便的选择起始事件和回访事件生成针对目标用户成留存曲线和留存率变化图。

留存曲线是指针对一群特定的目标用户由其次日留存，2日留存，3日留存，4日留存……构成的随时间逐渐衰减的曲线。从留存率曲线中可以观察一群用户留存衰减的情况。

留存率变化图是指由每天用户的次日（也可以是7日，14日等）留存构成的次日留存率曲线。从留存率变化图中我们可以观察随着时间的推移次日留存变化的曲线。是产品运营做增长最重要的图表之一。

我们通常意义下的用户留存，指的是全量用户针对全量事件的留存，起始事件是任意事件，回访事件也是任意事件。新用户留存，就是把目标用户设定为新用户，起始事件和回访事件设置为任意事件的留存。

之所以需要能够任意设置留存的起始事件和回访事件，是因为我们同样会关注某一些特定事件的留存。比如：买过了再买的复购率，比如某些功能模块的留存率，来了又来。

留存分析同样可以选择需要的目标用户群进行留存分析。方便产品运营进行精细化的用户运营。

留存分析有可能还包含一个关联属性的设置。关联属性用于让起始事件和回访事件的某个属性值保持一致，常用于活动名称、页面标题或商品名称等。

漏斗分析

漏斗分析主要用来分析用户在流程中每一步的转化情况。典型的分析场景比如：我们会分析新用户打开APP到注册登录进入主页面这一重要留存每个步骤的转化情况。亦或：电商场景下，用户浏览商品到加入购物车到提交订单完成支付这一系列动作每一步的转化情况。

漏斗分析首先要设计漏斗：根据需要分析的流程选择每一步的转化事件，以及转化周期。转化周期是指事件与事件之间转化的时间间隔。然后同样的，可以选择特定目标用户群，针对特定群体的用户进行转化分析。

漏斗分析最终会给出流程中每一步之间的转化率漏斗，从中可以分析出核心的转化问题存在于哪个环节之中。同时也可以获取到具体流失用户的用户ID，将相应的流失用户生成用户分群，做进一步的流式用户分析。

同样，漏斗分析也可以设置关联属性。

漏斗分析不仅可以分析事件之间的转化率。也可以生成某一转化率随时间变化的转化趋势图，类似留存率变化图。另外，事件转化的时间间隔也可以生成基于转化周期的分布分析图。

分布分析

分布分析指的是事件在整体或某一维度下，按照计算结果划分出一些区间，查看对应人数在各区间内的分布情况。分布分析有很多种类，比如按事件发生频次查看人数分布、按属性值计算结果查看人数分布、按一段时间内累计发生的时长或天数查看人数分布等。

分布分析在使用时通常需要自定义分布区间。自动划分的分布区间往往并不能符合我们实际的分析需要。

分布分析在用户行为分析平台的使用过程中需要注意的是，它一定是针对人的分布。这一点是对数据理解不够深入的产品运营同学在使用时经常忽视的一个问题，总是试图在用户行为分析平台做非人的分布分析。之所以一定是对人的分布，还是因为用户行为分析平台所选择的事件-用户模型所致。

路径分析

路径分析多少有点类似漏斗分析。漏斗分析往往用于分析明确的转化路径，但在一些情况下路径分叉比较多，想要从整体上把控用户的流向，这时候路径分析就会起到作用。而且路径分析展示的是连续的用户行为，可能会出现A事件后接着是B事件，然后又回到A事件的情况。

路径分析第一步是设置起始事件或者终止事件。起始事件用于分析用从这个事件开始用户去到了哪里。终止事件用于分析用户从哪里来到这个事件。

第二步是设置N个想要分析的用户可能流向的事件或者排除不想分析的事件。在探索分析或者对用户流向不清楚的时候，刚开始通常也可以不设置具体的事件，默认包含全部埋点事件。这样就可以有个用户流向的全貌展示，之后再选择关注的事件进行相应分析或者配合漏斗分析。

LTV分析

LTV是指用户生命周期价值(life time value)。通过分析用户从开始进入应用到最终流失全生命周期的消费数据，衡量单个用户的平均价值，进而帮助产品运营了解产品营收情况以及确立拉新成本上限。

LTV的计算规则如下：用户进入应用第n天的人均LTV称为LTVn，LTVn = 新用户同期群在随后n天内花费的总金额 $\div$ 该同期群用户数。

同期群（cohort）的含义是在规定时间内对具有共同行为特征的用户群。新用户同期群通常指在同一时间段（同一天，或者同一星期等）开始使用应用的新用户的总体。

通过计算第0天，第1天，第2天，第3天……的LTVn绘制成相应的LTV趋势图。LTV趋势图是一个逐步上升然后趋缓最终水平的一条曲线。因为用户进入应用后开始消费，随着消费增加LTV的值越来越大，但是用户也会随着时间逐步流失，直到某天的该新用户同期群的用户全部流失掉，LTV的值将保持恒定不再增加。

同样类似留存分析中的留存率变化图，LTV分析不仅可以展示LTV趋势图，可以展示具体某一个LTVn的LTV对比图，用于分析随时间推移的不同同期群的LTVn的变化情况。

LTV的概念还可以进一步抽象化。不一定特指用户生命周期的消费。LTV计算的分子，可以抽象为同期群的任意数值度量。比如：可以考察用户生命周期人均获得的金币量，用户生命周期人均的阅读量等等。

用户行为分析平台的高级能力

基于以上的分析能力，产品运营研发团队能够解决绝大多数数据分析需求。但这并未发挥出用户行为分析平台的全部潜力。

SQL分析

上面提到的基本的分析能力都是确定套路的分析方法。虽然足够高频，但也存在不够灵活的缺陷。用户行为分析平台的事件-用户模型本身是由事件宽表、用户宽表以及若干的维度表组成的。开放基于这些表的SQL查询，自然能够获得更灵活的分析能力。

可能普通产品运营同学不具备足够的SQL能力，SQL分析更多的是提供给数据分析师以及研发同学使用。SQL的结果同样也可以固化为相应的分析报表提供给产品运营同学使用。

在实际工作中，数据产品经理或者数据分析师也会经常性的利用SQL分析来分析问题保障数据质量。毕竟，只有通过SQL分析系才能完整明确的看到数据表中真实存储的原始数据。不断提升数据质量才是业务部门愿意使用数据平台的基础。

智能运营

产品运营在日常工作中通常都会希望通过各种方式触达用户。比如给用户发送短信，推送消息，发放礼券等等。触达的逻辑通常是在特定的时机给满足某些条件的用户进行相应的”推送“。这里有两个关键点，一个是特定时机，一个是满足条件的用户。以往，这样一个逻辑通常需要产品运营提出需求，开发同学写代码来实现。但是基于用户行为分析平台，这样一套逻辑似乎并不需要每次都有开发介入。

所谓满足条件的用户实际上对应着用户行为分析平台的用户分群功能。所谓特定时机可以是特定事件的触发，也可以是特定用户路径，或者是一些组合逻辑。不管怎样，最基本的用户行为事件已经上传进入了用户行为分析平台。用户行为分析平台需要实现一套流程画布系统来编辑触发的逻辑。比如一个简单的逻辑：针对一周内的新用户，如果进入了商品购买页面，就给他们发放一张8折券。一周内的新用户可以利用用户分群功能圈选出来，每天自动更新。进入商品购买页面，直接利用用户行为上报的事件进行触发。最后需要实现发放优惠券的逻辑。

礼券系统应该是一个独立的与其它系统解耦的后端服务系统。对外应该有提供通过RPC或者http的接口调用服务。那么用户行为分析平台应当提供一个推送通道管理的界面，用于注册推送调用的接口，实际上就是我们通常所说的Webhook。针对礼券接口的例子，就应该是在用户行为分析平台的推送通道管理界面注册一个调用礼券发放礼券的接口。推送通道管理的界面可以注册不同的推送通道，比如消息推送，短息推送，私聊消息，弹窗，礼券发放等等。

一旦完成这样一套智能运营系统，运营人员即可自行编辑相关的逻辑，完成自动化的用户触达能力，实现个性化的用户运营。同时极大的降低了开发人员的参与，提升了运营的效率。

数据开放

正如上文提到过的，有些同学会把用户行为分析平台称之为数据采集系统。显然的，能够全量准实时获取到用户行为数据的用户行为分析系统一定是可以对外提供数据的。

用户行为分析平台对外开放数据可以存在于4个不同的阶段：

1. 最原始的数据。用户行为数据上报到用户行为分析系统之后，在ETL之前会位于Kafka消息队列之中。这些都是最原始的未经加工过的数据。如果对外开放Kafka中存储原始数据的Topic的订阅能力，外部系统就可以以最快速度消费到最原始的用户行为数据。
2. 经过ETL之后的数据。用户行为分析系统会对用户上报的行为数据进行ETL处理。经过ETL处理之后未落表之前，这些数据可以推入一个旁路的Kafka消息队列通道。将这个通道对外开发。则外部系统可以获取到相对实时，同时数据质量不错的用户行为数据。
3. 落表之后的数据。用户行为数据最终会落到事件表中。可以直接对外开放事件表的访问权限。当然，落表数据往往数据延时会更大，提供的数据往往也是数据片段，例如若干特定事件。订阅这些特定数据的方式通常也是通过Webhook。
4. 统计数据。产品运营已经在用户行为分析平台上制作了相应的事件分析表，漏斗分析表，分布分析表等等数据表。这些数据表都可以开放给外部系统进行订阅。这些数据的数据量相对较小，可以直接通过Http请求获取。