冯俊晨-火花思维数据分析体系建设和实战分享

火花思维数据分析体系 建设和实战分享 DataFun,2024 分享内容 痛在哪里 自研系统的局限性 方案选型 为什么我们选择了火山引擎 运营策略 如何将工具潜力变成业务能力 未来展望 大模型时代的数据分析长什么样？ 痛在哪里 自研系统的局限性 BI系统必须要会写SQL才能做分析 行为日志系统的分析效率低下 自研团队的”鸡肋”处境 前端能力不足，v1未实现实时交互式分析，选择了保存SQL为图表的MVP方案 限制了只有会SQL的分析师才能创建和修改图表，降低了响应速度 技术架构上选择了presto+redis缓存 这个架构不支持高性能维度表查询，P95达到30秒以上，使用体验较差 数据结构上选择了一个可视化图表对应一个 SQL（或者一个物化视图） 复用性差，例如日表、周表、月表得维护3段 SQL 以页面ID和行为ID作为最细粒度，导致点位爆炸 据称抖音app的点位数量在6000个左右，火花点位在1w以上 没有自助测试验证机制，拉长了协作链条 产品经理和分析师不能参与测试环境验证，而QA无法验证埋点的分析意图，特别是某些关键属性的错漏 缺乏交互式分析机制，只能写SQL串联埋点 叠加两个问题，生产效率很低，分析师特别不愿意去分析行为日志。 2个产品，2前端3后端2测试的产研团队给旧系统打补丁成本太高 开发全新系统人力又不足 为什么选择火山引擎 BI系统 可视化分析 图表类型：丰富度不如superset，但是常见图表都有配置 格式自定义程度：表格格式化能力不如FineBI，但是远强于superset上卷/下钻：与FineBI和superset相似 查询性能：同等配置下查询性能最好，但是用户直观体验相差无几 辅助分析：选型时未认真比较的组件。表格的汇总/同环比计算高频使用 数据预处理 接入数据源种类：比superset丰富、与FineBI相似，飞书生态加分 调度系统：选型时未认真比较的组件。要考虑和调度系统对接和批量重跑可视化建模：独特优势，对于非分析师非常友好。 智能归因分析 火山引擎独门绝技，当时选型的决定性因素。 对于指标的异动，利用同一个数据集里维度进行自动归因分析，并按照维度变量的差异度进行排序 对于加法指标（DAU），几乎替代分析师工作对于乘法指标（平均用时），极大节约分析师时间对于除法指标（转化率），只有参考意义 归因分析（加法） 归因分析（乘法） 行为数据分析系统 可视化分析 常用行为分析组件：与神策差不多单人细查与分群分析：与神策差不多固化套件：逊于神策的行业模版 数据治理 埋点管理平台：神策自身不带管理平台，不具备治理能力神策生态中有三方平台，提供可视化点位管理 可视化测试环境：与神策差不多 点位生命周期管理：火山独特功能，但是实际使用价值不是很大 ABTest系统 动态分流系统（多臂老虎机），在国内生态里只有火山引擎提供该功能。这是当时选型的决定性因素 简而言之，动态分流下，实验组和对照组的流量分配比例不固定，如果实验组效果好，会自动扩量；如果效果不好，会自动缩量。 这样一方面可以保护业务结果，降低实验风险；另一方面节约实验时间，特别有利于小流量实验 动态实验支持小流量增长尝试 静态实验 动态实验 有点小贵 但很好用 运营策略 如何将工具潜力变成业务能力 数据分析产品是一个需求驱动的内容平台 业务痛点决定解决方案的形式提高内容生产的效率 更“高级”的形式不一定是更有效的解决方案 为什么“表格”是流量最高的图表形式为什么归因分析无法在火花落地 创造看数的需求是比提高产数的效率更重要 为什么行为分析系统日活提不上来 对于专业数据分析人员，提高生产效率 主要靠系统本身的能力对于分析的助力更重要 对于非专业分析人员，降低生产门槛 重视培训，更重视工作坊 做好业务核心场景的数据集市，控制数据集的认知复杂度 成功案例：为设计插上数据的翅膀 助力朋友圈有效分享率提升12% 第一阶段：深度介入数据管线和看板第二阶段：鼓励设计人员自己进行可视化分析 打通设计素材标签和行为日志，构建海报物料选择、展示和转化的指标宽表 根据设计团队提供的分析思路进行数据看板的构建，兼顾周报、月报的监控需求和根据设计元素进行deepdive的分析需求 设计人员在定期汇报的异动分析时有了新的问题，新的设计实验验证有了新的问题 通过培训和工作坊，逐步提高设计团队自问自答的能力 成功案例：后服务团队数据管理工作台 助力业务团队超额完成GMV目标5% 第一阶段：从搬运到分析 第二阶段：定制数据集 背景：每个地区有一个数据运营，数据运营主要工作职能（之一）是下载表格，然后根据管理架构进行分拆 可视化建模+行列权限使得数据运营可以让一线管理者直接下载相关数据，极大解放了数据运营的生产效率 数据运营将数据搬运的时间拿来做策略效果分析 政策变化多，活动周期短，难以依靠分析师更新数据宽表 可视化建模/自定义SQL临时应急，一个具备初级SQL能力的同学可以解决大部分业务需求 长期固定的观察项目才提出数据宽表需求 未来展望 直接产出业务洞见 人人都可以有一个分析师助手 我们需要的不是更快的可视化分析，而是更快的业务洞察 OLAP不会是LLM时代的版本答案 面向大模型的元数据治理 从数据集市到问题集合 业务的抽象建模、企业知识和元数据管理一定会沉淀在企业内部 OLAP时代是维度建模，LLM时代该怎么建模？MetricsLayer？ THANKYOU VisitOurWebsite： https:www.huohua.cn