购买频次（Frequency），广为人知的RFM模型里面的F说的就是ta 购买频次是指用户在一定时期内（一周/一个月/半年）的消费频率。 一般说来，用户的购买行为在一定时间内是有一定的规律性的，购买频次就是衡量用户购买行为的一项重要指标，它的高低取决于用户的使用频次。用户购买频次高，反映了企业提供的产品 or服务是有一定的吸引力的，直观上看，购买频次越高表示用户越忠诚。很多企业的用户激励机制都基于这个指标来制定，第一次购买后还想要用户第二次购买，第三次购买。。。总之，F越高越好！  通常，F值的提升会带来销售额M的增长，注意，这里说的是“通常”，你懂的，不靠谱的运营是肯定存在的。。。举个栗子： 小A现在是一家连锁便利店的店长，门店商圈范围内有1000个顾客（占比门店整体顾客数80%）每个月会到小A店里消费1次，按照门店过去6个月的平均客单价30来算，这部分顾客一个月贡献的销售额是：1000*30客单价=30000元；加上另外20%高频次顾客的销售额，小A觉得这一个月7w的销售额，有点对不起公司给他发的工资，而且小A发现，那20%的高频顾客贡献了门店57%的销售额。小A暗下决心，准备通过提升门店服务来提升销售额，这个时候，小A有两个选择： ①开拓更多的新客，比如通过提升服务，让老客自发介绍邻居来店里消费； ②增加老客的购买频次，让那些一个月只来消费一次的顾客，通过优质贴心的服务，来两次甚至三次； 思考至此，干就对了！小A一顿操作猛如虎，人间已过1月+，在某个夜深人静的夜晚，小A复盘数据一看，真提升了：这部分之前只交易一次的老客中，有38%这个月到店里消费了2次，有10%这个月消费了3次。这时，这部分顾客一个月消费的频次就从原来的1000人次变成了：1000人次+380人次+200人次=1580人次，销售额也相应提升到了47400元。键盘一顿噼里啪啦后，小A心中狂喜。。。 随后几个月，小A按照这个策(tao)略(lu）执行，老客以及老客带来的新客（们）的购买频次都有所增长，门店业绩也实现了超预期增长。终于，小A出圈了，应总部邀请给各个门店店长分享增长心得及技巧，复盘整个增长过程，小A发现自己做对了三步： 1、方向正确：以提升销售额为目标，通过拆解销售额=会员数×客单价，客单价=单次交易额×交易频次，确定了靠“提升频次带动销售”的策略； 2、顾客分层：精准识别出了不同频次区间的顾客，锁定了重点，即提升那些平均一个月只交易一次的顾客； 3、执行到位：再好的策略在差的执行力下都是浮云； 1和3就不展开了，说起来得1万字。。。这篇站在数据分析师老K的角度说说怎么帮小A区分不同频次区间的顾客，走起~ 现有一张便利店的交易明细表，内含交易日期、订单号、会员编码、订单金额等信息，样例如下： 小A需求：识别只交易一次的顾客 老K思考过程：我们公司这业态，只算交易一次的顾客么？那怎么对比？不对比怎么衡量交易一次的是好还是差？我给了只交易的一次的数据，这Y看后肯定还得问我要其它频次的人群数据。。。 故，老K把需求转化成了这样：求每月购买次数为1次、2次、3次、4-5次、5次以上的客户分别有多少？再送Y一个贡献的销售额及占比 这种题型，DEF函数仍是最优解。按照惯例，重温《戏说DEF函数》以及函数语法： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)  然后我们再来看看老K怎么用DEF函数实现的~  Step1  导入数据： 打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据）  Step 2  指标计算，分两步走：第一步计算出每个会员的购买频次；第二步再根据购买频次分组 ①计算出每个会员的购买频次，添加计算字段：DEF(COUNTD_AGG(订单号),会员编码)即可 ②将计算字段“每个会员的购买频次”从指标转化为维度 然后再根据1次、2次、3次、4-5次、6次及以上分组 知识点：DEF函数支持转化为“维度字段”，DEF_ADD&DEF_SUB均不支持此功能；  Step 3   制作仪表板，此处通过分组表展示： ①选择分组表 ②将已转化为维度的“每个会员的购买频次”拖入维度栏，重命名为“频次区间” ③将会员数量COUNTD_AGG(会员编码)拖入指标框两次，一个用于计算会员数，一个用于计算占比 ④将会员的交易额拖入指标框两次，一个用于计算交易额，一个用于计算占比      当然，想看得更直观，用柱状图会更合适而且美观，这部分不是重点，感兴趣的同学可自行尝试~  小结  通过以上过程，老K帮助小A区分出了只交易一次的顾客，并通过对比的方法，为业务策略落地提供了数据支持。 这是分类思维的一个应用场景，常见的还有：RFM、分层分析、矩阵分析、维度分析等，上篇分组后求平均《【DEF函数应用】之均值计算》其实也是这个思路，还有常听说的“物以类聚，人以群分”。。。 分类是结构化思维的底层逻辑，是我们分析很多问题的常见用法。之所以常见，是因为这种方式可以把信息归纳得井然有序，并且我们可以通过分类①获取新的信息②变换分类规则可以获得不同的信息；你在工作、生活中有遇到哪些分类的应用场景？来，咱们评论区一起聊聊~ 好了，今天就酱紫啦，回见~      我是BI实战，关注我，带你在FineBI的世界飞

最近做专案报告，一个函数2年前实现过，找了很久没找到是在哪个分析里用的，不得不重新写。找了半天没找到的时候，就突然冒出一个想法，给自己做一个函数&复杂计算 备忘录吧~ 遂有此篇   暂时想到了下面这些，后续会慢慢加入更多，如果对你也恰好有用，欢迎收藏。   日期函数 本期 / 同期 / 格式转换 / 日期加减计算 ----------------可上下滚动查看更多------------------ 自定义月份周期 上月28号至本月27号： IF(DAY(日期)= 28||DAY(日期)= 29||DAY(日期)= 30||DAY(日期)= 31,DATEDELTA(日期,5),日期) 年月日-去除时分秒：DATE(YEAR(日期),MONTH(日期),DAY(日期))   本期（今年）年初：DATE(YEAR(日期),1,1) 同期（去年）年初：DATE(YEAR(日期)-1,1,1) 同期（去年）年末：DATE(YEAR(日期)-1,12,31) 同期（去年）年至今：DATE(YEAR(日期)-1,MONTH(日期),DAY(日期))     本期（今年）月初：DATE(YEAR(日期),MONTH(日期),1) 同期（去年）月初：DATE(YEAR(日期)-1,MONTH(日期),1) 同期（去年）月末：DATE(YEAR(日期)-1,MONTH(日期),DAYSOFMONTH(日期)) 同期（去年）月末+1天：DATE(YEAR(日期)-1,MONTH(日期)+1,1)   同期（去年）：YEARDELTA(TODAY(),-1) 环期（上月）：MONTHDELTA(TODAY(),-1) 日期转文本：FORMAT(日期,"YYYY-MM") 文本转日期：TODATE(日期值,"YYYY-MM") 日期值转为日期：TODATE(日期值) 日期转为日期值：DAYVALUE(日期)   时间差：DATESUBDATE(大日期,小日期,"D")  -- "s/S"为秒、"m/M"为分钟、"h/H"为小时、"d/D"为天、"w/W"为周     排名 动态 / 静态 最简单的方式：用仪表板的快速计算（升序、降序排名）   门店排名（依据销售达成，动态排序，随仪表板维度的变化而变化）： RANK_ANLS(销售达成,0,"desc")   门店排名（依据销售达成，静态排序，不随仪表板维度的变化而变化）： DEF(COUNTD_AGG(门店名)+1,门店名,(DEF(SUM_AGG(销售额),门店名)/DEF(AVG_AGG(门店销售额目标),门店名)) > EARLIER(DEF(SUM_AGG(销售额),门店名)/DEF(AVG_AGG(门店销售额目标),门店名)))     字符串函数 截取 / 查找  按照分隔符截取： ① 指定字符仅出现一次 指定字符前的内容：LEFT(字段,FIND("-",字段)-1) 指定字符后的内容：RIGHT(字段,LEN(字段)-FIND("-",字段)) ② 指定字符出现多次（字符多次出现，取最后一个） 指定字符前的内容： LEFT(字段,LEN(字段)-LEN(INDEXOF(SPLIT(字段,"_"),LEN(SPLIT(字段,"_"))-1))-1) 指定字符后的内容：INDEXOF(SPLIT(字段,"_"),LEN(SPLIT(字段,"_"))-1)   指定字符替换：REPLACE(字段,"-","_")   分析函数 移动平均 / 复购率  移动平均（12个月）： DEF(AVG_AGG(DEF(SUM_AGG(销售额),DATE(YEAR(订单日期),MONTH(订单日期),1))),DATE(YEAR(订单日期),MONTH(订单日期),1),)   移动平均（参数版）： DEF(AVG_AGG(DEF(SUM_AGG(交易额),交易日期)),交易日期,)   复购率： SUM_AGG(DEF_ADD(COUNTD_AGG(订单号),会员码)>=2)/COUNTD_AGG(会员码)    

零售行业出现退单是非常常见的事情，比如，买了双鞋子，女朋友不喜欢，怎么办？要么退掉，要么换一双。 不管是退掉还是换一双，对应到零售商家的订单表内，就是一笔销售订单（正向），另外再加一笔或者多笔退单（负向，多笔是指一笔订单多次退货，比如原订单买了三双袜子，一双鞋，一件上衣，鞋子女朋友不喜欢，退一单。过了两天，发现上衣有质量问题，又退一单）。 退单以及其对应的正单不参与销售统计，是最基本的要求，所以很多销售明细表内其实也包含退单，这样在做销售额、销售件数求和时，正负抵消也没什么影响。 但是如果涉及订单数、会员数、复购率、购买频次等指标的计算，退单就有影响了，会直接导致数据统计不准确。举个栗子： 问：某销售明细表内总计20笔订单，其中包含2笔退单，那正常的订单有多少笔？这是在求订单数。 答：16或17笔。 为什么？因为2笔退单对应的有正单，总共需要剔掉3或4笔（不理解为什么可能是3的，回看本篇第二段）。 剔除退单，一个看似简单的需求，处理起来远比想象中复杂，这个复杂主要体现在企业数据的呈现方式： 比如，退单因为各种各样的业务原因，没有关联到原订单 比如，退单出现在销售明细表中，和正单混在一起 。。。等等，退单关联不到原单的问题，要做的是优化业务流程，没数据，巧妇难为无米之炊~   但是正退单混合出现在销售明细中，想要剔除退单计算各种指标，是有解决方案的： 1、将正退单混合的销售明细表拆成正单、退单两类，分别单独成表（需要有退单对应的原单单号） 2、使用FineBI主题模型，将退单（下文为：退货明细表）和正单（下文为：销售明细表）N:N关联，连接条件为：销售明细表的「订单号」对应退单表的「原订单号」 3、Over N:N为什么可以实现？ 我们通过计算「剔除退单的订单数」和「剔除退单的会员数」两个指标，一起来看~  FineBI的N:N 1 Part.1 数据导入 弹出【选择数据】框，将Excel数据导入。   数据样例（注意，销售明细表的「订单号」是存在重复的，退货明细表内的「原订单号」也是存在重复的，关注BI实战公众号，后台回复“资料包”可下载数据样例） 销售明细表： 退货明细表：   2 Part.2 模型构建 模型视图内，关系选择N:N，连接依据选用销售明细表的「订单号」以及退货明细表的「原订单号」   3 Part.3 指标计算 1. 添加计算字段： 订单数-剔退单：DEF_ADD(COUNTD_AGG(订单号),,ISNULL(原订单号)) 会员数-剔退单：DEF_ADD(COUNTD_AGG(会员id),,ISNULL(会员id)) DEF函数学习，见《戏说DEF函数》   2. 添加组件，看下计算结果：     不够直观对不对？我们把销售明细表以及退货明细表中订单数和会员数计算出来做个对比： 在销售明细表中添加计算字段： 在退货明细表中添加计算字段： 看下对比结果： 会员数14022-42 ≠ 13985 ，但这个结果是对的，猜猜原因哦~   搞不懂为什么N:N能算对的同学，移步上一篇《笛卡尔积 vs FineBI主题模型的N:N》，内含FineBI主题模型N:N计算步骤的详细拆解     小结   继续强调FineBI的主题模型合并逻辑： 只有分析字段和关联字段参与主题模型的合并 执行先聚合再合并 强烈建议拿例子去练手，会对以上的计算逻辑理解更深刻。   好了，今天就酱紫，回见~

BI的数据模型就是通过关系相互连接的一组表。这组表里面有事实表、维度表，通过关系把他们连在一起。 两个不同表之间存在以下3种关系类型：一对一（1 : 1），一对多（1 : N），多对多（N : N）。 1:1 & 1:N很容易理解，但N:N就复杂多了，理解起来没那么直观。 N:N关系的基础理论来自于集合论。在集合论中，可以将实体看作集合，实体之间的关系可以看作集合之间的关系。N:N关系可以通过两个集合之间的笛卡尔积来表示。 笛卡尔积： 指由两个集合中的每个元素组成的每一对有序元素构成的集合。例如，S={1, 2}，T={a, b}，则它们的笛卡尔积为{(1,a),(1,b),(2,a),(2,b)}。这个集合中每个元素都是一个有序对，表示S和T之间的所有可能的对应关系。因此，通过两个集合之间的笛卡尔积，可以表示两个集合之间的多对多关系。 在数据建模中，N:N关系的建模，我们天然的认为会发生数据膨胀，导致多条重复数据出现，最终会影响统计结果。这么认为其实没错，SQL中多对多的JOIN连接，确实会导致数据膨胀。为了避免这个问题，常规的做法就是使用桥表，将N:N转化为两个1:N后再进行join连接，这个处理方法也通用于BI的N:N关系处理。   23年4月份，FineBI 发布了“主题模型”功能，除了让数据准备更简单、多表分析更高效外，还能更加友好的支持 N:N 计算场景。可以说是大大的减少了N:N场景的计算准备工作量，但随之而来的就是高度抽象的合并&计算逻辑，大大的增加了理解成本。 能够深度理解主题模型计算原理的人可能会使用后发出惊呼：wow，太棒了！ 不能够理解主题模型计算原理的人，可能就会“想用却不敢用”，因为搞不清楚用了之后哪里会暴雷。 所以今天想拆解下FineBI的N:N计算步骤，把抽象的计算过程具体化一些，便于大家理解。 我们通过一个案例来看：  需求背景： BYD是一家日用品仓储超市，主要经营纸巾、洗衣液等相关产品，每年2月、6月、7月和11月是超市的固定大促月，基本可以享受全年最低价，另外，为了方便顾客，超市提供一项寄存服务，比如，7月付款买10箱纸巾（预售单），后续用到的月份再来提货，用几箱提货几箱即可，也允许一笔订单提多个预售单的货（提货单），对那些家中存在空间有限的顾客来说，这是一项完美的服务。所以每到大促月，很多顾客会选择寄存。   Tom是这家连锁超市的运营经理，近期他在分析经营数据的时候发现，超市预售的业绩越来越高，就想了解下预售提货的数据，所以向数据部提了如下需求： 1、2023年超市每月的预售件数、提货件数是多少，还有多少未提？ 2、哪些会员还未提货完成，分别还有多少未提件数？     这个需求听起来很简单，但如果深入了解业务过程，你就不会认为简单了。 最大的障碍点在于：超市允许一笔订单多次提货，也允许一笔订单提多个预售单的货。 什么意思呢？翻译成关系就是： 一笔预售订单多次提货 ，即1笔预售单，对应多个提货单（1：N），这个简单 一笔提货单提多个预售单的货 即 1笔提货单，对应多个预售单（1：N），这个简单 但是，关键是但是，算未提得合在一起看，然后。。。就成了N:N。就不简单了。 不过幸好，FineBI6.0的主题模型支持N:N，我们来看看这个需求怎么通过主题模型实现~ FineBI N:N 1 Part.1 数据导入 弹出【选择数据】框，将Excel数据导入。 数据如下， 预售单： 提货单： P.S.为了便于理解，数据做了简化处理，但请注意预售单的「订单ID」是存在重复的，提货单表内的「关联预售单号」也是存在重复的。   2 Part.2 模型构建 模型视图内，关系选择N:N，连接依据选用预售表的「订单ID」以及提货表的「关联预售单号」   3 Part.3 指标计算 1. 计算每月的未提数量，添加计算字段，未提数量 = SUM_AGG(销售数量)-SUM_AGG(提货数量)   2. 然后将预售表的「订单日期」拖入维度栏，将预售表的「销售数量」、提货表的「提货数量」、上一步的计算字段「未提数量」拖入指标栏即可。   3. ok了，如此简单，算对了没有？敢不敢用？ 回到Part1的数据仔细看看，算一下。发现没错！ 怎么样？惊喜么？   4. 继续算每个会员还有多少未提。 继续验证下数据对不对，可以放大图片，口算下结果。 完美！！   5. 到这里，Tom的这个需求就完成了，一切都很完美。 然而，当我们想进一步知道每个会员是什么产品没提货的时候，异常出现了。下图红框的部分，客户实际上是没有提货数据的，然の，此处却有计数。 为什么会有计数？ 答：这个模型的合并依据是预售表的「订单ID」以及提货表的「关联预售单号」，而且分析维度是站在预售表的角度看的。模型在用连接字段合并的时候，优先保证预售表的数据完整，而后开始调用「订单ID」这个连接条件，如果出现一笔订单中多个单品，数据就会出错。比如下图：   6. 怎么办呢？ 答：联合关联，多字段合为一个字段来唯一标识一行记录。就是把合并依据从预售表的「订单ID」以及提货表的「关联预售单号」，调整为预售表的「订单ID+产品ID」以及提货表的「关联预售单号+产品ID」，在数据处理阶段新增列合并订单ID和产品ID即可。 合并界面如下： 模型的连接关系字段调整为合并后的字段 计算结果：   一切又回到了完美！ N:N计算步骤拆解 为了方便理解，我们拆解下计算步骤，把抽象的计算过程稍微具象化一点。依每月未提件数的组件举例： 每月的预售数量、提货数量、未提数量结果如下： 主题模型的计算过程： 1. 识别分析字段和关联字段 此例中分析字段为预售表中的「年月」 关联字段为预售表的「订单ID」、提货表的「关联预售单号」。 2. 计算预售表中每月的预售数量，分析维度为「年月」、「订单ID」，聚合结果为SUM(预售数量)   3. 计算提货表中每月的提货数量，分析维度为「关联预售单号」，聚合结果为SUM(提货数量)   4. 依据预售表的「订单ID」、提货表的「关联预售单号」关联字段合并   5. 依据「年月」进行聚合。 比如，2月有两笔订单，计算这两笔订单的合计预售件数，提货件数。其它月份依次类推。   小结   FineBI的主题模型合并逻辑： 只有分析字段和关联字段参与模型的合并计算 先聚合，再合并 如果类比到SQL的JOIN连接，这个计算过程就是通过两个子查询得到的：聚合的子查询a  JOIN 聚合的子查询b。 相比较来说，FineBI通过主题模型实现还更便捷呢！   拿例子去练手吧，多换几个分析字段观察下计算结果。会对主题模型的合并逻辑理解的更深刻。   好了，今天就酱紫，回见~

维度建模是数据仓库大师Ralph Kimball提出的一种用于数据仓库的建模技术。用于设计数据仓库和BI系统。它以事实表（记录交易事实的表，比如订单明细表）和维度表（提供分析维度的表，比如门店表、商品表）为中心，用于分析和报告业务指标。 维度建模流程，在《数据模型(一)：基础概念篇》一文中第三部分有做框架介绍。 本篇重点探讨建模技术：星型模型和雪花模型 星 型 模 型      星型模型的名称来源于它的物理结构形状，通常用一颗中心的事实表连接着多个辐射状的维度表，这种结构形状非常类似于一颗星星，因此就被称为星型模型。 在星型模型中，事实表是数据模型中最为关键和核心的表，存储了具体的业务事实数据，如订单明细表，含销售额、订购数量等。维度表则包含了与业务事实相关的属性信息，如商品、门店、客户等。事实表与维度表之间通过共享的主键进行连接，构成了一个类似于星星的模型结构，从而方便进行多维分析。 如下图：   订单表为事实表，会员、商品、门店、渠道等均为维度表，维度表与事实表1：N建立关系；   雪 花 模 型   雪花模型的名称也来源于它的物理结构形状，可以认为是星型模型的扩展。它在星型模型的基础上进行了维度表的规范化拆分，从而使维度表也出现了层次化。在雪花模型中，维度表被拆分成更多的表，当有一个或多个维度表没有直接连接到事实表上，而是通过主维度表连接到事实表上时，就形成了类似于雪花的模型外观，因此得名为雪花模型。 如下图： 订单表为事实表，除第一层直接与事实表建立1：N关系的会员、商品、门店、渠道等主维度表外，还存在城市、付费会员、品牌、品类等第二层维度表，与第一层的主维度表存在1：N的关系；   星型模型  VS 雪花模型 1 星型模型 / 优劣势&适用场景 优点1 可读性较好 结构简单，易于理解和使用，很容易组合出各种查询，对非计算机专业人员也比较友好，不用考虑很多正规化的因素（比如各种范式），设计与实现都比较简单 优点2 查询性能高 由于一些维度表已经预先进行了合并，因此不需要过多的join操作，那么关联查询效率就会更高 缺点  数据冗余较高 由于一些维度表已经预先进行了合并，就会造成数据的冗余存储，占用了更多的空间（如在门店维度表中，存在省份江苏 的城市 南京、苏州 两条记录，那么省份 的信息就存储了两次，即存在冗余） 适用场景 指标分析 销售分析：假设公司想要进行销售数据的分析，包括按产品、地区、时间等维度进行销售额和销售数量的统计。使用星型模型，可以将事实表和维度表以星型结构组织，以快速查询和分析销售数据。   客户关系管理（CRM）：在CRM系统中，需要跟踪和分析客户相关的信息，如客户信息、订单历史、服务记录等。通过使用星型模型，将事实表与客户、产品、订单等维度表连接，可以轻松地进行客户分析和个性化的客户关系管理。   库存管理：对于具有复杂库存结构的企业，星型模型可以帮助跟踪和分析库存数据。将事实表与产品、仓库、供应商等维度表连接，可以快速了解各个维度上的库存状况，以便进行库存优化和供应链管理。 2 雪花模型 / 优劣势&适用场景 优点1 数据冗余低 规范化拆分&存储，减少了冗余数据，提高数据一致性和准确性，且节省存储空间 优点2 灵活性和扩展性高 更大的灵活性和扩展性，可处理更复杂的层次结构和多级关系 缺点1 查询性能相对较低 需要更多的join来执行查询（join操作在数据量大的时候很耗时），性能较差 缺点2 可读性 高度结构化的数据，建模时有一定的复杂度，可理解性差。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期模型的维护和管理相对复杂 适用场景 维度分析 组织架构分析：在大型组织中，雇员的层次结构和关系可能非常复杂。通过使用雪花模型，可以将雇员信息按照部门、职位、层级等维度进行规范化拆分，以支持组织架构的深入分析和人力资源管理。   财务报表分析：财务报表通常涉及多个维度，如时间、地区、账目等。使用雪花模型，可以将维度表进行规范化拆分，以支持复杂的财务分析和报表生成，更好地了解公司的财务状况和趋势。   产品分类分析：在零售行业或其他需要对产品进行分类和分析的场景中，使用雪花模型可以将产品维度表进行规范化拆分，以支持更灵活的产品分类和分析需求，帮助企业进行市场细分和销售策略制定。   小结 以上列出的是一些典型的优劣势，实际应用中应根据具体情况进行评估和选择。根据业务需求和数据特点，可以综合考虑这些因素，选择最适合的模型进行数据建模。 无论选择星型模型还是雪花模型，最重要的是将模型与实际业务需求相匹配，并根据具体情况进行调整和优化。   模型的选择，没有最好，只有合适~     好了，今天就酱紫，回见~

上一篇提及了在BI里面，常用维度建模。本篇结合FineBI重点聊聊集合运算。   维度建模和集合运算是两个不同领域的概念，但在数据分析中常常同时出现，有一定的关联性。 他们的关系是： 维度建模时，数据操作和查询过程中常常会应用集合运算来处理和整合数据集。 最主要的区别： 维度建模主要关注数据模型的构建和维护，提供了对数据进行切片和分析的维度标准；而集合运算则强调对数据集合进行运算和操作，用于数据的筛选、合并、分割等。   举个栗子： 假设我们有一个包含销售订单数据的数据包，包括了维度表（例如产品维度、会员维度、门店维度）和事实表（例如销售数量、销售额等）。   在这个场景中，维度建模用于构建数据模型，以便于对销售数据进行分析和报告。   首先，维度建模通过设计和关联维度表和事实表，将销售数据进行整合。例如，通过与产品维度表的关联，可以获取每个产品的销售数量和销售额。通过与会员维度表的关联，可以对不同的会员进行销售贡献分析。通过与地区维度表的关联，可以获取不同地区的销售数据。   然后，在使用维度建模进行数据分析和报告时，常常需要进行数据筛选和操作。这时，集合运算就可以发挥作用。例如，会员分析中，通过运用集合运算中的交集操作，可以筛选出同时在两家门店均有交易的会员有哪些；通过并集操作，可以合并多个不同门店交易的会员进行总体分析；通过差集操作，可以找出未在指定门店交易的会员有哪些。 数据处理整合，概括来说只有两类，即上下合并 和 左右合并。前者多用于多组数据的上下追加合并，后者重点针对不同类型的数据，通过关联依据，将其连接到一起，可以理解为横向合并，这种连接数据的方式可以延伸出交并差运算。 图解上下合并：   FineBI的上下追加（BI针对导入数据，有自动合并功能，导入后系统会自动检测，符合条件的话不需要手工做上下追加）：   图解左右合并 以及 交并差集合运算： FineBI的左右合并：   从FineBI的界面可以看出，合并方式展示了常见的4种： 左合并、右合并、交集合并、并集合并 这四种基本合并方式，可以满足大部分的连接运算需求，少数的复杂业务需求需要使用差集运算（交集或并集后，再做减法） 下面举例展示： 表A：   打开FineBI6.0，在tab【我的分析】中新建分析主题。 数据导入：弹出【选择数据】框，将表A和表B数据导入 交集 需求1：求在SZ01和DS07两家门店均有交易的会员是哪些？ 思路：SZ01和DS07交易会员的交集 在FineBI中，我们通过自助数据集来更直观的呈现： 1.1 数据集①：表A不做处理 1.2 数据集②：用表B合并表A，合并依据为“会员id”，合并方式选择“交集合并” 并集 需求2：求在SZ01和DS07两家门店有过交易的会员是哪些？ 思路：SZ01和DS07交易会员的并集 2.1 数据集①：表A不做处理 2.2 数据集②：用表B合并表A，合并依据为“会员id”，合并方式选择“并集合并” 差集 需求3：求仅在SZ01门店有过交易的会员是哪些？ 思路：求差集，SZ01交易会员 剔除 DS07交易会员 3.1 数据集①：表A不做处理 3.2 数据集②：用表B合并表A，合并依据为“会员id”，合并方式选择“右合并” 3.3 过滤表B中“下单门店”为空的行   需求4：求仅在SZ01门店以及仅在DS07有过交易的会员是哪些？ 思路：求差集，SZ01和DS07交易会员的并集 剔除 SZ01和DS07交易会员的交集 4.1 数据集①：表A不做处理 4.2 数据集②：用表B合并表A，合并依据为“会员id”，合并方式选择“并集合并” 4.3 过滤表B中“下单门店”为空的行 或者 表A中“下单门店1”为空的行   小结 左右合并与集合运算的交并差相互关联。   需要注意的是，BI在数据集里面的合并，都是行级别的合并，所以在合并的时候，「合并依据」字段需要特别注意，1:1或者1:N的合并不会导致数据膨胀，但是N:N的合并（即「合并依据」字段存在重复值）会进行笛卡尔运算，导致数据膨胀。BI会自动检测「合并依据」是否重复，并给出提示。若确实需要笛卡尔来实现某种业务场景的计算，请注意膨胀系数不要超过5，否则为了不影响系统的稳定性，BI会主动打断更新。   另外需要注意的一点就是「合并依据」出现NULL时，NULL之间不互相匹配。 其实「合并依据」出现NULL是非常不严谨的，我们要尽量避免。若实在无法避免，且需要对它们进行匹配，需要对其进行特殊处理，比如：单独赋值。   好了，今天就酱紫，回见~

现实中我们经常听到各种各样的模型，比如数学模型、算法模型、数据模型等等，还有最近大火的AI大模型。 甚至，领导们也会经常说：你们建个模型测算一下呀~ 似乎听起来只要能跟模型产生联系，就会给人一种高大上、专业的感觉。 那么究竟什么是【模型】呢？ 模型是对现实客观事物的一种抽象表示，可以是虚拟的描述，也可以是实体模型。比如售楼处的沙盘，就是模型的一种。   那什么是【数据模型】呢？ 数据模型是通过数据、数据关系和数据属性对现实世界、业务逻辑进行抽象和简化描述，它用于理解、表示和组织数据元素，是现实世界、业务逻辑在数据层面的投影。有助于揭示业务现象背后的规律，还可以帮助预测未来趋势和做出决策。 Part.01 模型的基本概念 学习数据模型，需要了解一些基本概念，包括但不限于如下这些： 1.实体（Entity） 现实世界中的具体对象、事物或概念，可以是人、物、事件等。在数据模型中，实体用于表示数据的基本单位。 2.属性（Attribute）： 实体具有的特征或性质，用于描述实体的特征。例如，对于一个“学生”实体，其属性可以是姓名、年龄、性别等。 3.关系（Relationship）： 实体之间的联系或连接，描述实体之间的相关性和依赖关系。例如，一个“学生”实体和一个“课程”实体之间存在关系，表示学生选修了某门课程。 两个不同实体集之间存在以下3种关系类型。 一对一（1 : 1），指实体集a中的一个实体最多只与实体集b中的一个实体相联系。 一对多（1 : N），指实体集a中的一个实体可与实体集b中的多个实体相联系。 多对多（N : N），指实体集a中的多个实体可与实体集b中的多个实体相联系。 4.实体关系图（Entity-Relationship Diagram，ERD）： 基于实体和关系构建的图形表示，用于可视化数据模型的结构。ERD通过图形符号表示实体、属性和关系之间的联系。 5.主键（Primary Key）： 实体中用于唯一标识每个实体实例的属性或属性组合。主键用于确保实体实例之间的唯一性。 6.外键（Foreign Key）： 表示实体之间的关联关系，指向另一个实体的主键。外键用于建立表与表之间的关联，实现数据的一致性和完整性。 7.范式（Normalization）： 数据库设计中的一种规范化过程，用于确保数据的高效性和可靠性。范式通过分解数据，消除冗余和数据依赖，提高数据库的性能和可维护性。 Part.02 常见数据建模方法 1.关系型数据模型： 关系型数据模型是最常见和广泛使用的数据模型之一。它将数据组织成二维表格形式，其中表格由行和列组成，行表示数据的记录，列表示记录中的属性。关系型数据模型使用关系（Relationship）来描述不同表之间的联系和依赖关系，通过主键（Primary Key）和外键（Foreign Key）来建立表与表之间的关联。关系型数据库常见的代表是SQL（Structured Query Language）数据库，如MySQL和Oracle。   2.实体-关系模型： 实体-关系模型是一种基于实体（Entity）和关系（Relationship）的数据模型。它通过实体描述真实世界的对象或概念，用属性（Attribute）描述实体的特征，通过关系描述实体之间的关联。实体-关系模型以ER图（Entity-Relationship Diagram）的形式可视化，使用图形符号表示实体、属性和关系之间的联系。ER模型的关键概念包括实体、属性、关系、主键和外键，这些概念用于描述和建模数据之间的逻辑关系。   3.维度建模： 是数据仓库大师Ralph Kimball提出的一种用于数据仓库（Data Warehouse）的建模技术。用于设计数据仓库（Data Warehouse）和商业智能（Business Intelligence）系统。它以事实表（Fact Table）和维度表（Dimension Table）为中心，用于分析和报告业务指标。   在维度建模中，事实表包含事实（Facts）和度量（Measures），描述业务事实的数值或数量。维度表包含描述事实的上下文信息，如时间维度、产品维度、地理位置维度等，用于为事实提供详细的分析维度。维度建模通过将数据转化为多维结构，提供了更强大和灵活的分析能力，以支持数据分析和决策支持。 Part.03 维度建模流程 在BI里面，常用维度建模。在将业务需求和数据转化为合适的数据模型时，通常有以下流程： 1.定义业务需求： 了解业务需求是维度建模的第一步。通过和业务相关的人员交流，澄清需求、目标和数据要求。这样能够更好地把握数据建模的方向和重点。 2.定义维度和度量： 通过业务需求确定需要的维度和度量。维度可以是时间、产品、客户等描述业务特征的数据，而度量是需要分析和决策的业务指标或数据值，如销售额、订单数量等。 3.设计事实表（Fact Table）： 事实表是维度建模中最核心的数据结构之一。它通过与多个维度表（Dimension Tables）进行关联建立起来，并存储度量信息。事实表常常是按照业务事件或时间周期进行组织，如销售事实表、订单事实表等。 4.设计维度表（Dimension Tables）： 维度表是描述维度数据的数据结构，与事实表进行关联。在设计维度表时需要确定维度的层次结构、属性、关系等信息。常见的维度包括时间维度、产品维度、客户维度等。 5.建立模型： 在此步骤中，建立维度表和事实表之间的逻辑关系，创建完整的维度模型。在维度模型中，事实表是一个中心的数据集合，与多个维度表之间形成关联。 星型模式（Star Schema）和雪花模式（Snowflake Schema）：  星型模式是维度建模中最常用的数据结构之一，它采用了一个中心的事实表（Fact Table）与多个维度表（Dimension Tables）的关联结构，形成一个类似星星的图形。模式简单、易于理解和使用，适用于大多数数据分析场景。 而雪花模式是星型模式的扩展，它在维度表之间建立了更多的关联关系，形成像雪花一样的图形。雪花模式用于复杂的维度结构，能够提供更精细的维度分析能力。 6.优化性能： 优化性能是维度建模流程的最后一步。在此步骤中进行模型优化、索引优化、数据加载和更新等工作，以提高查询性能、系统效率，提升用户体验。   文末彩蛋 本篇纯理论，可能略显晦涩，但这是理解数据模型的基础~ 读到这里的同学，私信我，送199元课程优惠券，免费学习~ 限3张哈~

问 为什么实际的业务场景中需要动态分析？ 1、业务环境和需求不断变化，静态的分析经常不能满足实际分析的需要。 2、业务管理越来越依赖于数据。通过动态分析，可以多维度观察数据，有利于将业务数据转化为有价值的信息，帮助企业更客观了解现状，从而做出更加科学、合理的决策。   问 BI如何实现动态分析？ 在BI领域，实现动态分析的方法有多种，比如创建交互式的数据仪表板、数据筛选和过滤、数据钻取等，如果给动态分析评级的话，上述这种方式算是初级动态分析，那有中、高级么？答案是肯定的！ 「参数」就是中高级动态分析实现的一个入口，在FineBI中，可以使用「参数」，以筛选器的形式来控制变量，与其他指标进行交互，通过调节「参数」指标的大小来观察数据（指标的聚合结果）的变化，进而完成动态分析。   问 什么是参数？  参数，从概念上讲，是一个可变字段（变量）。 如果从“字段”这个角度看的话，参数可使用的范围应该是：维度、指标、筛选器。 那理想中仪表板的样子就应该是：加入参数后，通过切换字段参数，便捷实现仪表板的全部动态化。   问 FineBI的参数是什么样的？ 目前FineBI对参数的支持，还在传值阶段（支持文本、值、时间静态赋值后传值），最主要的目的是做筛选过滤，也可参与计算（计算能力还有待加强）。 FineBI支持的参数类型有如下三种： 其含义分别是： 1、文本：可以看做是 维度的枚举值（注意，非字段，是字段维度的枚举值），主要用于筛选 2、数值：参与指标计算的值，也可用于筛选 3、时间：主要用于筛选   问 FineBI的参数怎么用？ 具体实现路径是： 第一步：组件内新增参数 第二步：仪表板过滤组件中绑定参数 最终通过筛选器对目标组件进行传值   FineBI中有三个地方可以使用参数，他们各自分工不同： 1、计算字段中使用参数，主要用于指标的计算，如下截图： 2、字段过滤绑定参数，主要用于仪表板筛选，如下截图：  3、明细过滤绑定参数，主要用于指标明细筛选，如下截图：     FineBI利用参数进行动态分析的案例 关于参数的使用，此前已有几篇微信推文，介绍了常见的应用场景。 可关注公众号 点击查看：  销售预测模型 与 FineBI   Yes！移动平均 v2.0 - 传参   TOP N占比 – N是多少，你说了算~   占比计算 v2.0 - 自定义传参      FineBI参数的使用限制与突破技巧 1、参数暂时不支持单独作为字段拖入组件中使用。 突破技巧：将参数放入计算字段 举例：新增计算字段，直接将参数放入即可（按照这个逻辑，此处可以举一反三，当然也可以放进公式计算）   2、明细过滤、字段过滤绑定参数需要具备匹配关系，即文本值 对 文本参数，数值 对 数值参数，日期值 对 日期参数，如果文本字段的过滤设置前N项，则绑定参数字段为数值参数。 没必要突破限制，规范使用字段类型是数据分析师的基本素养   3、一个过滤组件支持绑定多个参数字段；同一个仪表板同一个组件参数只能被一个过滤组件绑定一次，绑定过后显示灰化 突破技巧：同类型的参数根据需要建多个，通过命名做区分就ok了   FineBI的参数目前还不够强大，还有蛮多可以优化的地方，比如： 1、在过滤器中，参数只能在数值下拉过滤器中使用，区间滑块等不能用； 2、在警戒线中、预警界面，参数不能使用； 3、参数不能绑定字段，不能在仪表板实现切换维度或者指标；动态坐标轴、全动态图表、动态矩阵；   不过，按照FineBI目前的迭代速度，相信在不久的将来，参数功能会更强大~ 期待   好了，今天就酱紫啦，回见~     我是BI实战，关注我，带你在FineBI的世界飞

以自然年为财年的企业，通常会在第四季度开启新一年的规划，各个业务线开始定明年的目标、规划明年的费比，我们姑且简称为预算吧。 制定预算是企业管理的重要措施之一，可以帮助企业明确总体发展战略和经营目标、优化资源配置，建立绩效评估体系，促进企业的全面管理。 而销售预测是预算制定中一个关键的环节，准确的销售预测可以帮助企业估算即将销售产品或服务产生的收入情况，从而确定合理的销售目标，这样更有助于销售人员、销售负责人、企业经营者和投资人的期望目标达成一致。 上面的160字，摘自网络，属于给了碗汤但没给勺的那种~ 下面，简单聊聊“勺”的问题~ 有个段子是这么说的：“掐指一算，明年多挣5000万”。这个段子，妙在“掐指”，难在“一算”，听起来很简单的样子，但在真实的业务环境中，要做到高质量的销售预测，其实是很难的一件事情，为什么难？因为影响销售的因子太多，需要考虑的因素也非常多，而且，不同的行业、渠道有较大的差异。所以，我们必须要有具体的业务场景和假设前提，所以，下面的预测模型，是在具体的业务场景下，明确了假设前提后展开的讨论。 业务背景： 某500强品牌企业下的BU，主营业务为办公用品的生产销售，销售主要依赖经销商，分散在全国各个区域，占比销售业绩的90%。还有自己的电商平台，销售占比约10%。   现销售负责人需要预测明年的销售额来制定年度目标以及费用预算。问：如何预测？   假设前提： 1、不考虑外部市场环境巨变（比如疫情黑天鹅、竞争对手）及内部经营战略巨大调整（比如企业转型、收购兼并、大客户流失等），企业明年的销售额是在历史同期销售的基础上，增长或下跌幅度相对稳定。 2、历史数据来源准确可靠、维度齐全。 · 预测方法 基于企业性质（经销商为主，且企业已经处于完全竞争的博弈阶段，市场份额基本定型，且销售波动有规律可循），选择时间序列模型，从客户角度做预测更合适。 · 具体思路 历史销售数据（标杆年*0.35 + 年滚动*0.65）*增长率，融入业务经验（客户数、客户价值允许业务自主调参），对未来销售进行预测。 此种方法业务逻辑相对清晰，参数设置简单。   初版销售预测可视化效果如下图： 1、可以自由选取需求对标的标杆年份 2、期望增长率和客户数预测可以自由调整 然后我们再来看看FineBI怎么实现这个需求~ 01   数 据 导 入 打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据），数据样例： 02   新 建 参 数 & 指 标 第一步：建参数 1、  建四个参数：标杆年&预测年（时间类型）、增长%指标&客户数（数值类型），如下图： 2、  新建仪表板，增加两个时间过滤组件，两个数值下拉组件，将四个参数与组件绑定： 设置参考下图： 2.1举例，标杆年（时间过滤组件）： 2.2 举例，客户数（数值过滤组件） 第二步：增加指标计算 1、复制“销售额”指标，重命名为“销售额-预测年”后增加过滤条件如下图，过滤条件绑定参数“p_预测年” 2、复制“销售额”指标，重命名为“销售额-标杆年”后增加过滤条件如下图，过滤条件绑定参数“p_标杆年” 3、复制“销售额”指标，重命名为“销售额-标杆年同期”后增加过滤条件如下图，过滤条件绑定参数“p_标杆年” 4、添加计算字段，标杆年的销售额同比， SUM_AGG(销售额-标杆年)/SUM_AGG(销售额-标杆年同期)-1 5、复制“客户ID”字段后转化为指标，重命名为“客户数-预测年”后增加过滤条件如下图，过滤条件绑定参数“p_预测年” 6、复制“客户ID”字段后转化为指标，重命名为“客户数-标杆年”后增加过滤条件如下图，过滤条件绑定参数“p_标杆年” 7、添加计算字段，计算预测年份（可在仪表板上的参数范围内自由筛选）往前滚动一年的移动平均值，此处需要注意，年月日要处理成年月再计算   DEF(AVG_AGG(DEF(SUM_AGG(销售额),DATE(YEAR(订单日期),MONTH(订单日期),1))),DATE(YEAR(订单日期),MONTH(订单日期),1),) 8、添加计算字段，计算销售预测   (SUM_AGG(DEF_ADD(SUM_AGG(移动平均-12M),,))*0.65+SUM_AGG(销售额-标杆年)*0.35)*(1+p_增长%指标/100) 9、添加计算字段，计算客户价值预测 10、添加计算字段，计算单个客户价值（DEF_ADD(SUM_AGG(销售额),客户ID)），OK后转化为维度 03   制 作 仪 表 板 此处通过指标卡&分组表展示： 1、回到仪表板，再新建6个指标卡，设置如下：      1.1标杆年的 销售额、客户数、客户价值         1.2预测年的 销售额、客户价值 2、指标卡ok后，再来设置“客户价值区间”这个分组表，设置如下：      2.1 标杆年的 客户价值区间      2.2 预测年的 客户价值区间 其它仪表板美化不再赘述，最终效果如下： 小 结   FineBI实现预测模型最大的难点在绑定参数计算指标（本篇第二部分），另外就是仪表板可以呈现出的效果和想象中有一定的差距，不过没关系，先有再优，V2版本就在不远处~   好了，今天就酱紫啦，回见~

同环比是业务经营分析中常用的对比指标，对比的时间颗粒度因为业务场景的不同有一定的差异，常用的日期颗粒度有日、周、月、季、年。 有时候我们不需要这些固定的日期区间，比如促销分析中，通常需要根据促销档期看销售情况~ 元旦假期，公司的促销排期安排在2019/12/31~2020/1/4，促销结束后，区域经理需了解 促销活动期间销售额以及同环比数据（本期指：19/12/31~20/1/4；同期指：18/12/31~19/1/4；环期指：19/12/26~19/12/30）。 这种业务场景，通过BI仪表板添加筛选器来自定义计算指定日期的同环比，是通用的解决方案。 这种需求，在FineBI中如何实现呢？一起来看看~ 01   数 据 导 入   打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据）   02   新 建 参 数 & 指 标 要计算筛选的可以动态变化的指定日期的同环比，需要使用参数来实现动态赋值。 1）添加组件后，再添加参数，参数类型选择 - 时间，如下图所示： 2）计算同环比需要提前计算出「本期：当前时间段销售额」、「同期：去年同时间段销售额」、「环期：上一时间段销售额」三个指标。这三个指标都需要绑定刚创建的参数，如下图： ① 新增“本期”指标：     1.1 复制销售额指标     1.2 将指标重命名为 “本期” ，点击“明细过滤”后，弹出如下设置框，设置日期范围筛选 “参数” 的 “同一步长” 。   ② 比照上述步骤，新增 “同期” 指标 ，设置日期范围筛选 “参数” 的 “1年前同一步长” 。 ③ 比照上述步骤，新增 “环期” 指标，设置日期范围筛选 “参数” 的 “同一步长的上一区间”  此处的知识点：明细过滤时，搞清楚“步长”  3）计算同比、环比（注意分母为0的情况），公式如下： 同比：IF(ISNULL(SUM_AGG(同期)),“”, SUM_AGG (本期) / SUM_AGG (同期) -1) 环比：IF(ISNULL(SUM_AGG(环期)),“”, SUM_AGG (本期) / SUM_AGG (环期) -1)   03   制 作 分 组 表 & 仪 表 板   1）制作组件： 添加组件，选择分组表后，将【产品类别】拖入维度，【本期】、【同期】、【环期】、【同比】、【环比】拖入指标。 仔细一看，这。。。数字对么？？ლ(′◉❥◉｀ლ)，嘿嘿，不着急，咱继续看下一步！   2）制作仪表板： ① 新建仪表板，左上角“添加组件”，把上一步做好的分组表拖入仪表板； ② 新建过滤组件，将 “日期区间”  过滤器拖入仪表板，做如下设置： ③ 日期筛选后，结果如下：   检验下数据对不对？！ 嘿嘿~是对的啦！！ 为演示方便，我用的表格，对美观有要求的同学，可以采用其它图类展示方式，这部分不是本文的重点，不再赘述啦，感兴趣的同学可自行尝试~ 小 结 小oaix 根据自定义筛选日期计算同环比，新建参数以及复制指标后设置明细过滤，是重点和难点，多多练习，其实不难滴~   好了，今天就酱紫啦，回见~

我们在日常生活中经常会遇到这种情况，看到某些报告里面说“去年人均月收入超过 2 万元”。看完这个数据之后，很多人会有如下感叹：           调侃之余，我们不防想想，为啥很多人觉得拖后腿？ 回答这个问题，我们先搞搞清楚啥是平均值？从数学上来说，平均值有多种，比如算术平均值、几何平均值、加权平均值等。 我们日常生活中提到的平均值都默认是“算术平均值”，也就是“一组数据中，数据之和÷数据个数”。这个计算so easy，小学就会啦~ 举个栗子：某高级小学班，有5个同学，数学的成绩分别是18，32，72，60，98，求班级数学平均分？ 求解：这组数据的算术平均值是 (18+32+72+60+98)/5=56 请问：56 这个平均值能代表同学们的平均水平么？ NO!NO!NO! so，有的时候，平均值并不能代表整体水平。因为平均值的计算样本是total，非常容易受到极端值的影响，比如 把你的年薪和马爸爸平均。。。 那什么情况平均值才有价值呢？ 答：数据呈均匀分布或者正态分布的情况下平均值才会有意义。 然而，并不是所有的数据都是均匀分布，那又该怎么办呢？ 再答：求均值前，先分组。比如，A公司今年年初至今，A品牌的人均贡献增长超过了50%，想了解下是哪一部分会员引领了人均贡献增长？我们继续用一个上一篇《【DEF函数应用】之占比计算》的数据，算算看~ 交易明细表如下，内含交易日期、交易商品品牌（A/B/C/D/E/F等）、交易会员等级（品牌D_VIP/品牌J_VIP/普通会员 等）、交易金额等信息，样例如下： 求：不同会员等级在各个品牌的平均交易额，以及品牌的平均交易额 结果如下图： 这种题型，DEF函数是最优解。按照惯例，先温习函数语法： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)  然后我们再来看看DEF函数的具体实现步骤，follow me~    Step1  导入数据： 打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据）  Step 2  指标计算，此处划重点 添加组件后，添加两个计算字段 1、不同会员等级在各个品牌的平均交易额 2、品牌的平均交易额   此处的知识点：DEF_SUB的第二参数维度，可以忽略组件的维度  Step 3   制作仪表板 选择自定义图表 将【品牌】、【会员等级】拖入横轴，【不同会员等级在各个品牌的平均交易额】、【品牌的平均交易额】拖入纵轴 再将【品牌的平均交易额】的图形类型设置为“线”，指标基础表就完成了           当然，对美观有要求的同学，可以继续设置颜色、轴标签的文本方向等细节，这部分不是本文的重点，不再赘述啦，感兴趣的同学可自行尝试~  小结一下下          通过举例，我们了解了分组后求均值的计算过程。实际业务场景中，均值是一个很常见的计算指标，使用的时候，要注意其陷阱，它很容易受到极端数据的影响，很多选秀节目里最后计算分数时要去掉一个最高分和一个最低分，就是这个道理。整体平均值要在数据均匀分布或者正态分布下才会有意义。据此，我们引出了先分组再求均值的解决方案，但其实，先分组再求均值也并不能解决所有难题，因为还有著名的辛普森悖论。。。关于辛普森悖论，这篇就抛砖引玉，有兴趣的同学可以自行检索学习，或者，也可以点个赞，集齐30个赞，我们就单独聊聊。           好了，今天就酱紫啦，回见~           我是BI实战，关注我，带你在FineBI的世界飞

占比计算，此前有四篇推文： 1nd：【DEF系列_01】占比计算_1-我的帆软 (fanruan.com) 解决的是 常规的指标计算问题 2nd：【DEF系列_01】占比计算_v2.0 自定义传参-我的帆软 (fanruan.com) 3nd：【DEF系列_01】占比计算_TOP N占比-N是多少，你说了算-我的帆软 (fanruan.com) 4nd：【DEF系列_01】占比计算之横向占比-我的帆软 (fanruan.com) 解决的是 相对（动态）、横向占比的计算问题，即可通过筛选器定义不同维度 今天是第五篇，聊聊FineBI的父行占比计算问题。   效果图如下： 计算的是各个品牌不同会员等级的贡献占比是多少？合计的展示有三种形式： ①  筛选后的占比（品牌A / 筛选品牌合计） ②  整体占比（品牌A / Total） ③ 品牌合计行展示为100% FineBI如何实现呢？下面逐步来看~   FineBI计算父行占比 1 Part.1 数据准备 打开FineBI6.0，在tab【我的分析】中新建分析主题。 需要先导入数据，弹出【选择数据】框，将Excel数据导入 数据样例，销售明细表：   2 Part.2 组件&仪表板呈现 指标计算： 添加计算字段，用于计算不同等级的销售占比： 占比筛选品牌 = DEF_ADD(SUM_AGG(${交易额}),${品牌}) / DEF(SUM_AGG(${交易额}),,DEF(COUNTD_AGG(${品牌})+1,${品牌},DEF(SUM_AGG(${交易额}),${品牌})>EARLIER(DEF(SUM_AGG(${交易额}),${品牌}))) <= ${品牌排序})   这地方看不懂的，回看 【DEF系列_01】DEF应用之占比计算_3-我的帆软 (fanruan.com) 组件制作： ① 选择分组表， ② 维度拖入【品牌、会员等级】 ③ 指标拖入【销售额、销售额（快速计算选择组内占比，二次计算默认勾选）】 ④ 复制一个销售额指标-销售额1，拖入【销售额1（快速计算选择组内占比，二次计算去掉勾选）】 数据看起来貌似不太对？ 不急~ 拖到仪表板上再看哦~ ⑤ 指标拖入【计算字段-占比筛选品牌（快速计算选择组内占比，二次计算默认勾选）】   仪表板呈现 添加过滤组件topN（需绑定参数） 这地方看不懂的，回看 TOP N占比 – N是多少，你说了算~   而后，再添加组件至仪表板，最终效果：         好了，今天就酱紫，回见~ 关注《BI实战》，私信我可领案例数据，动手练起来吧~

占比计算，此前有三篇推文： 1nd：【DEF系列_01】占比计算_1-我的帆软 (fanruan.com) 解决的是 常规的指标计算问题 2nd：【DEF系列_01】占比计算_v2.0 自定义传参-我的帆软 (fanruan.com) 3nd：【DEF系列_01】占比计算_TOP N占比-N是多少，你说了算-我的帆软 (fanruan.com) 解决的是 相对（动态）占比的计算问题，即可通过筛选器定义不同维度 近期混迹社群，想了解下大家遇到的比较多的问题有哪些，发现占比计算还是蛮多人有困惑，今天再来一篇，聊聊FineBI的横向占比计算问题。   效果图如下： 计算的是各个品牌不同的交易月份，销售额是由哪些等级的会员贡献的？不同会员等级的贡献占比是多少？   （6.0.15以后版本才有表头指标名称分组功能） FineBI如何实现呢？下面逐步来看~   FineBI计算占比 1 Part.1 数据准备 打开FineBI6.0，在tab【我的分析】中新建分析主题。 需要先导入数据，弹出【选择数据】框，将Excel数据导入 数据样例，销售明细表： 2 Part.2 组件&仪表板呈现 指标计算： 添加计算字段，用于计算不同等级的销售占比： 占比-横向（会员等级）= SUM_AGG(交易额)/SUM_AGG(DEF_SUB(SUM_AGG(交易额),会员等级)) DEF_SUB的第二参数选择【会员等级】字段，意在忽略列维度的会员等级字段，不了解原理的，回看 戏说DEF-我的帆软 (fanruan.com) 组件制作： 选择交叉表， 行维度拖入【品牌、交易时间】，日期调整为年月展示 列维度拖入【会员等级】 指标拖入【销售额、占比-横向（会员等级）】   仪表板呈现 添加过滤组件，会员等级   而后，再添加交叉表组件至仪表板，最终效果：     小结 占比的计算，总结下来，无非下面几种： ① 常规的占比计算：指标占比、组内占比（最简单的方法就是通过BI的快速计算实现） ② 维度占比 ③ 横向计算占比 ④ 父行占比（父行显示100%）-这个下篇再说   但占比难搞在，业务需求复杂，需要变换不同的行维度和列维度计算时，行、列、父行、父列等概念混淆在一起，分析师自己把自己给绕晕了，这个时候，建议回去看看Excel的透视表，搞清楚Excel里面的各种值展示方式，类比来看，BI能实现的的占比计算简直太简单啦~     好了，今天就酱紫，回见~ 关注《BI实战》，私信我领案例数据，动手练起来吧~

写在前面： 3月，在樱花浪漫的季节，应帆软之邀参加智库年会，浅浅分享了些《数据团队成长之路：从报表体系到价值创造》方面的拙见，引发了不少共鸣。也分享给大家~ 今天我们聊的课题是数据团队成长，数据团队归属在企业，那么这个问题就有一个天然的框架，就是：在企业里面，数据团队怎么成长？ 我们先忘掉“数据团队”这个主语，思考一下自己的职业，怎么样才算有发展，有成长？这个问法似乎没那么直观，我换个问法，就是，如果一个人在职场有成长、有发展，通常的结果是什么？ 这个问题，每个人的答案可能有所不同，但主流答案大概率会是：升职、加薪。 好，我们现在再把主语“数据团队”加回来，即，数据团队在企业里有成长、有发展，通常的结果是什么？ 我心目中的答案是：成为企业的核心团队，且团队能够适配企业阶段，有节奏的壮大 那么，问题又来了？怎么能达成这个结果？ 这个问题就变成了，目标有了，实现路径是什么？ 说实话，我努力了多年，关于这个问题，目前仍在不断思考、追寻和迭代。只不过，这一路的追寻，迭代，还算有些许进步，由此产生了一些我个人觉得还算不错的新体验和经验，分享给大家。 分享主要分为四个部分： 1、我所经历的数据团队发展的几个阶段 2、不同的阶段所面临的挑战以及我对于这些挑战的思考 3、为什么走向价值创造的探索 4、实现路径分享和反思     数据团队发展的几个阶段： 1、萌芽阶段，特征就是boss身体力行+兼职的数据分析人员 企业规模较小，没有招专业数据分析师的必要，但是这个时候仍然需要做数据分析。常见的模式基本上是老板自己在做分析＋一个辅助人员，也可以说是兼职数据分析师。通过数据分析，老板对公司的业务发展能有很清晰的认识，非常有利于去快速做一些重要的决策。比如我最近辅导的一个设计师品牌店，她们是没有分析师的，但是老板自己觉得不做分析不行，就会带领团队先在Excel搞点小规模的数据分析，慢慢发现Excel没办法满足他们的需求了，买了帆软的另一款产品开始搭看板，依然是老板亲自带，选一位合适的员工兼职做这个事情。 2、企业发展到一定阶段，通常会出现专业的数据分析人员，这个阶段的特征就是：excel报表满天飞 我个人是从这个阶段进入数据分析领域的。那时候，公司还没有专门的数据分析团队，连数据仓库都没有，更别提大数据平台、数据中台了，我也是光杆司令一个，归属在市场部，专门负责报表取数，只有一个订单系统，导出EXCEL，做成各种各样的Excel报表为业务部门提供支撑。 做了一年多，报表越来越多，做不过来了，终于我有了小助手，成了两人团队的数据主管。那时候我们服务的对象是市场部的老大和财务部门，市场部主要基于我们提供的数据做营销推广和跟踪分析，还有就是帮助财务部做预算相关的报表和追踪，每个月要更新的报表大概20个左右。 3、数据团队发展到中级阶段，小型数据分析团队出现了，主要做数据验证、报表体系及可视化 我个人第三个阶段的转变来自换了一家公司。终于，我到了一个有数仓、有BI，看起来像是正规军的数据团队，而且这个数据团队还有不同的分工 企业里面不同的组织分工，对数据团队的定义可能有所不同，以我们公司的两个团队为例，数据开发团队归属在技术部，负责系统底层的数据架构搭建、数据清洗、数据库运维等工作，而我们数据分析团队归在业务线，主要应对业务端、管理层需求的数据报表、临时取数、或专案分析需求等数据支撑，维持公司的正常运作。 4、业务人员的自助分析，数据团队走向价值创造 报表体系建设到一定阶段，我突然意识到仅靠我们这小团队没办法兼顾整个集团的数据需求，而且，大家都陷入无穷无尽的取数、开发报表循环里，也感觉不到自己的成长。我开始意识到，我们要跳出现在的惯性，数据团队不仅仅是做数据报表，更重要的是将数据分析转化为实际的商业价值。 之后，就开始了数据团队价值创造的探索   面临的挑战与思考 一步步走来，每个阶段都会面临一些挑战，比如：   第一阶段，最大的痛点：业绩体量太小，养不起专职的数据分析师。 第二阶段，终于，养得起专门的数据分析师了，最大挑战成了报表及时性和准确性，Excel手工做表，各种函数&VBA用的贼溜，依然力不从心。 第三阶段： 数据验证和报表体系是我浸润其中，最有感触的一个阶段： 每天都在处理临时需求，跑sql语句，验证业务方的想法； 每月都在写月报、周报，长篇大论的一封邮件，发出去之后基本是石沉大海； 时不时的要开发报表，三天两头改展示字段 这个阶段，我经历了3年左右，从一开始的完成一个复杂需求和报表很开心，觉得很有成长，慢慢的到：觉得只做报表取数很low，但报表取数又是我们的立身之本，又爱又恨。 所以我一直就在思考，做什么能够超越报表取数，做出来不一样的东西。 然后我们找到了三种玩法：数据可视化、精确营销、专案分析。   数据可视化 数据可视化的本质其实是视觉体验，我们当时整天琢磨着怎么样做一个炫酷的仪表板，向业务展现数据，联动、下钻齐上阵，最终，这个尝试以失败告终。最大的原因是大家看习惯了Excel式的报表，对我们的各种图形不仅不感冒，还反馈做的太花里胡哨。导致的结果就是，BI的仪表板上80%以上都是表格组件。 另外，公司的高层们看习惯了Excel表，BI报表向上推广的道路走的异常艰难。 精准营销 我们考虑怎样通过数据计算，精准锁定客户，然后通过标签，让门店更精准触达用户。比如，我们重点推广某个品牌，会通过历史交易，以及产品的常规用量，去计算顾客大概什么时间吃完，该复购了。系统给这波人打上标签，让门店去精准转化。 这个动作，就是在给精准营销加入数据计算的能力。数据团队在这一方面，溶于了公司的业务流程，成了营销环节中的一个重要节点。这个玩法，还算比较成功的。 专案分析 专题分析的起因其实来自于高层，报表体系逐步走向成熟，我们习惯的数据呈现开始遭遇挑战：你们要主动创新，不能只呈现数据报表，还要分析数据，否则这一堆报表的意义是什么？！这是来自高层的警告 彼时，被挑战的应对方案就是：努力的找常规报表中的异常数字，看有没有可能发展成为专题报告，至少要体现出数据团队的主动性。 这个方案的结果最终演变成了：团队的编制没有理由增加，常规的数据验证、报表体系还要继续搭建，大家只能挤出来点时间和精力做专案分析，苦不堪言。而且，单靠数据团队的主动性，基本上决定了专案分析的结果不会太理想。   到这个阶段，我已经在公司待了将近三年。三年，似乎是一个坎，这个坎来自于原本不会的已经做到得心应手，从不会到会的满足感已经没有了，剩下的只剩对于重复的厌烦，于是，我开始思索自己的数据职业生涯，开始意识到，团队的天花板并不是团队的某个人，而是管理者自己。 然后我就开始时不时的问自己： 我自己的数据分析职业生涯的终局在哪里？ 数据分析团队的发展、成长的终局在哪里？   回到最开始的那个问题的答案： 升职、加薪 成为企业的核心团队，且团队能够适配企业阶段，有节奏的壮大   那么，怎么实现呢？ 走向价值创造的探索 从个人职业生涯发展的角度看： 不同的成长阶段，对应了不同的价值影响： 当你是一个普通分析师的时候，和你对话的通常是终端业务 当你是一个高级分析师的时候，和你对话的通常是企业中层的管理者 当你到分析专家的时候，和你对话的基本就是高层了 和你对话的人的level，通常决定了你的价值影响。 所以呢？ 搞清楚：我在为谁？贡献什么核心价值？团队在为谁？贡献什么核心价值？ 这个问题非常重要！！   我把自己一路走来的经历带入这个问题，发现：一直以来，我都在和业务方打交道，我把这些不同类型的业务人员、中层管理人员当成了我的核心用户，帮他们出报表、做问题验证，每天忙忙碌碌，加班加点做的都是一些琐碎事务。他们每个人关心的就是自己的一亩三分地，要看的数据和报表也是他们自己所负责的范围。所谓的屁股决定脑袋，虽然粗俗，但很有道理。 我想实现个人认知水平的提升以及团队成长为公司的核心团队，关注业务终端用户的需求明显不太可能，甚至定位到中层管理人员都不一定能实现，所以至少要把我们服务的用户定位在高层，甚至是老板，更甚者，是“公司”，才有可能实现。   那要思考的事情就变成了： 高层、老板关心什么问题？ 我们能不能搞定这些问题？如果能搞定这个问题，团队可以获得的价值回报是什么？ 企业的使命、愿景、价值观是什么？ 战略目标是什么？ 服务于战略的落地策略是什么？ 我们能不能先在落地策略上找到分析的机会点？又能不能通过不断地分析影响策略？   至此，我把数据团队的价值创造问题聚焦在了：将数据分析转化为实际的商业价值 通过数据分析和洞察，为企业提供决策增量、优化业务流程等，进而实现企业的战略目标和商业价值最大化。   实现路径分享与反思 说到企业的使命愿景、价值观，有的同学可能就要问了，数据分析团队为什么要去了解企业使命愿景、价值观，这种听起来这么虚无缥缈的东西呢？ 关注企业的使命愿景、价值观以及战略目标对数据分析团队实现价值创造具有重要的意义，主要体现在以下几个方面： 对齐工作方向：企业的使命、愿景、价值观以及战略目标是组织的核心理念和长期发展方向。通过了解并与之保持一致，数据分析团队可以确保他们的工作与企业的整体战略方向保持一致，从而避免偏离重点，集中精力和资源在最有价值的项目上。 优先级排序：了解企业战略目标可以帮助数据分析团队确定优先级，并将工作重点放在对实现这些目标最有帮助的项目上。这有助于提高工作效率，确保团队的努力真正对企业产生重大影响。 量化价值：经营规划通常是定量的，如收入增长、市场份额扩大、客户满意度提高等。通过了解这些目标，数据分析团队可以将其工作转化为可量化的结果。 提升团队影响力：通过将自己的工作与企业战略目标紧密联系起来，数据分析团队可以增强其在组织中的影响力和地位。他们能够更好地向企业领导和其他部门展示他们的价值，并成为推动业务发展和决策制定的重要参与者。 其次，理解企业使命，拆解年度经营规划，思考【分析价值】实现路径 由战略规划和经营规划 我们就知道了重点和优先级是什么，由此，我们把精力放到了三个重点项目上， ① 公司旗下品牌的专案分析，目标是通过数据分析贡献决策增量 ② 优化自动配货算法，这是在优化经营效率 ③ 建快递费用测算模型，优化快递费用，降本增效   为此，优化数据团队分工   ① 开放BI的设计权限，推动业务相关人员实现自助分析。 ② 数据团队这仅有的一小撮人也分成两个小组：一组继续负责临时的问题验证和复杂报表的搭建，兼顾业务人员的BI培训；另一组负责专案的研究分析。 正式进入对“研究分析”的资源投入，也意味着，我们迈入了数据团队发展的一个新的阶段。   研究分析这三个专案的成功，我们摸索出了一条数据文化在经营规划落地策略上的推进形式 通过逐步演进来实现： 聚焦重点业务场景，快速产出结果，打造标杆 利用标杆效应，扩散至其它主要业务场景，且不断迭代 倒逼落后业务场景，促使其加速赶上 随着越来越多专案项目的落地，部门壮大的问题似乎是顺理成章的事情 距离开始所说的： 我心目中的：成为企业的核心团队，且团队能够适配企业阶段，有节奏的壮大 其实还有一定的距离，但这个距离已经不再是遥不可及     数据团队的价值创造之路，任重而道远～ 以上为演讲稿全文  

占比计算的2.0版本 见 《【DEF系列_01】DEF应用之占比计算_2-我的帆软 (fanruan.com)》，直播课，有同学提问了另一个占比计算场景：   如何用DEF函数计算TOP10占总体的占比？   TOP N占比有两种常见计算逻辑： TOP N占比整体 TOP N占比自己 举个栗子： 某直播电商公司旗下现在有50个品牌在销售： 老板想知道每个品牌的销售 vs公司整体业绩的占比是多少？so easy，A品牌销售÷公司整体销售*100%就ok了。 那如果老板想知道 TOP10的占比怎么办呢？依然so easy，前面每个品牌占比都算过了，把销售排名前10的品牌筛选出来就哦了呀~ 再如果，老板只关注TOP 10品牌，想知道每个品牌在TOP10的销售中的占比，那又该怎么算呢？！ 老板的第二个需求就是TOP N占比整体，第三个需求就是 TOP N占比自己   FineBI的帮助文档有一个举例也能解决这个问题，见：求前六名分别占前六总和的占比：https://help.fanruan.com/finebi/doc-view-823.html   答同学提问，想要用DEF函数算，今天来个升级版~   按照惯例，先温习函数语法，参见《戏说DEF-我的帆软 (fanruan.com)》： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)    然后我们再来看看FineBI怎么实现老板的第二个/第三个需求~   01   数 据 导 入   打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据） 2023.5.28 DEF应用_数据源.xlsx (83.34 K)     02   新 建 参 数 & 指 标   第一步：建参数-品牌排序（数值类型），如下图：   第二步：指标计算，不废话，直接上公式 ①某TOP品牌占比整体：   DEF_ADD(SUM_AGG(交易额),品牌)/DEF(SUM_AGG(交易额))   ②某TOP品牌占比筛选出来的TOP N品牌   DEF_ADD(SUM_AGG(交易额),品牌) / DEF(SUM_AGG(交易额),,DEF(COUNTD_AGG(品牌)+1,品牌,DEF(SUM_AGG(交易额),品牌)>EARLIER(DEF(SUM_AGG(交易额),品牌))) <= 品牌排序) 上述公式，分母DEF函数的第三参数，有进行二次DEF嵌套，目的是对品牌进行排序（依据销售额聚合）；   万金油排序公式（可依据自己的需求，修改维度即可）   DEF(COUNTD_AGG(品牌)+1,品牌,DEF(SUM_AGG(交易额),品牌)>EARLIER(DEF(SUM_AGG(交易额),品牌)))   03   制 作 仪 表 板   此处通过分组表展示： ①新建仪表板，在仪表板内新建一个过滤组件（展示类型：文本下拉），绑定参数且设置自定义值，设置如下：   ②回到组件界面，选择分组表，将 “品牌”拖入维度栏，下拉框选择“过滤”，给品牌维度设置过滤条件（依据交易额，筛选最大的N个，N通过“品牌排序”参数控制）；     ③将计算好的指标 拖入指标框即可，如下图： 咦？没数据？！ 不急，拖进仪表板看看~   ④ 组件放入仪表板，自定义筛选，结果变化如下： 小 结   DEF做复杂的占比计算，最大的难点在第三参数的筛选，想清楚筛选条件和逻辑很重要；   此计算场景，帮助文档的解决方案，也可以升级为通过参数控制TOP N，调整品牌的过滤条件，绑定参数即可，如下图：   好了，今天就酱紫啦，回见~   我是BI实战（张丹洁），关注我，带你在FineBI的世界飞

占比计算的1.0版本 见 《【DEF系列_01】DEF应用之占比计算_1-我的帆软 (fanruan.com)》，当时的需求是：D品牌业务想知道自己负责品牌的市场份额，以及付费会员（品牌D_VIP）的贡献情况。所以呢，当时直接用DEF函数把数据的选取范围框定在品牌D和品牌D_VIP等级上了。 这需求搞定没几天， J品牌的负责人也找来了，说他们也想要看类似的数据，而且，想要自定义选时间段查看~ 最开始听到这个新需求，内心十万只草泥马奔腾而过，咋想的那么美，还想自定义筛选时间？！而且，我严重怀疑：这帮品牌经理，表面是竞争关系，私下经常互通有无，哼！！ 凉了J品牌经理几天，后来在一个有奶茶、有咖啡、有蛋糕的美好下午，就那么一瞬间，参数功能浮现在脑海，咦，这需求，是不是参数就能实现？！ 灵光乍现，说干就干，随即就开始了测试，几亿脑细胞阵亡后，终于让我给倒腾出来了！ 话不多说，2.0版本来了，公式还是那个公式，筛选条件却不是那个筛选条件了！ 再重复一遍需求   指标A： 交易某品牌（Eg.品牌J）且是本品牌的付费会员（Eg.品牌J_VIP） vs 所有交易某品牌（Eg.品牌J） 的会员数&交易额的占比 指标B： 交易某品牌的会员 vs 所有交易会员 的会员数&交易额的占比   日期、品牌、会员等级要可以自由筛选（这里才是重点和难点！！）   按照惯例，先温习 戏说DEF-我的帆软 (fanruan.com) 函数语法： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)  然后我们再来看看FineBI怎么实现这个需求~   01   数 据 导 入 打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据） 2023.5.28 DEF应用_数据源.xlsx (83.34 K) 02   新 建 参 数 & 指 标 第一步： 建四个参数：开始时间（时间类型）、结束时间（时间类型）、品牌（文本类型）、会员等级（文本类型），如下图： 第二步：指标计算，不废话，直接上公式 ①   参数 - 会员占比 品牌会员交易某品牌   DEF_ADD(COUNTD_AGG(会员编码),,)/DEF_ADD(COUNTD_AGG(会员编码),,) ② 参数 - 会员占比 品牌占整体   DEF_ADD(COUNTD_AGG(会员编码),,)/DEF_ADD(COUNTD_AGG(会员编码),,) ③ 参数 - 销售占比 品牌会员交易某品牌   DEF_ADD(SUM_AGG(交易额),,)/DEF_ADD(SUM_AGG(交易额),,) ④ 参数 - 销售占比 品牌占整体   DEF_ADD(SUM_AGG(交易额),,)/DEF_ADD(SUM_AGG(交易额),,) 03   制 作 仪 表 板 此处通过分组表展示： ①    选择分组表 ②    将 “交易日期”拖入维度栏，修改为“年月”的展示方式，将上文计算好的四个指标 拖入指标框即可，如下图：   咦？没数据？！不急，建一个仪表板 ③    在仪表板内新建三个过滤组件，分别为：日期区间、品牌、会员等级，设置如下： 举例：时间参数设置 ④ 组件放入仪表板，自定义筛选，结果变化如下：   小 结   我总结没用，得你动手练！ 好了，今天就酱紫啦，回见~ 我是BI实战（张丹洁），关注我，带你在FineBI的世界飞

占比，即比率，简单点说呢，就是两数相比所得的值。举栗，大家一起吃瓜，总共10块，你一个人吃了8块，你吃的瓜的占比是 8/10=80%。 你个吃货，毁灭吧！！！ 那复杂点说呢...... 还是两数相比所得的值。只不过，这两个数的获取过程有点曲折。 比如下面这个需求，D品牌业务想知道自己负责品牌的市场份额，以及付费会员的贡献情况： 现有数据： 一张交易明细表，内含交易日期、交易商品品牌（A/B/C/D/E/F等）、交易会员等级（品牌D_VIP/品牌J_VIP/普通会员 等）、交易金额等信息，样例如下： 求： A：品牌D_VIP会员交易D品牌的会员 vs 交易D品牌 的会员数&交易额的占比 B：交易D品牌的会员 vs 所有交易会员 的会员数&交易额的占比 (⊙o⊙)… 这个需求，在FineBI5.0里面，可以通过 复制2个指标，对指标进行明细过滤后，再新增计算字段 - 两个指标相除 来实现。 FineBI6.0因为DEF函数的出现，这个事情变的简单了很多   先回顾下DEF函数的语法： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)    然后我们再来看看DEF函数的具体实现步骤，走起~  Step1  导入数据： 打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据）    Step 2  指标计算，此处划重点 添加组件后，添加计算字段计算需求A的会员数占比计算 函数拆解：                 /* 第一步：计算会员等级为品牌D_VIP且交易了品牌D的会员有多少个*/DEF(COUNTD_AGG(会员编码),,)/* 第二步：计算交易了品牌D的会员有多少个*/DEF(COUNTD_AGG(会员编码),,)/* 第三步：*/第一步/第二步 注意：DEF有第三参数但第二参数为空时，第二参数用“”表示，省略会计算错误 比照会员数占比计算销售额占比，将DEF的第一参数COUNTD_AGG(会员编码)换成SUM_AGG(交易额)）即可 计算结果： 验证下数据对不对，会员占比：28÷175= 16%，销售额占比：56530÷187829=30.1%，完全正确 再来添加计算字段计算需求B的会员数占比，D品牌的会员数以及金额同上一个需求的第二步DEF(COUNTD_AGG(会员编码),,)，只需要再计算所有交易会员的会员数以及金额即可，DEF(COUNTD_AGG(会员编码)) & DEF(SUM_AGG(交易额))，如下：   DEF函数第二参数和第三参数为空，可以计算total会员数与交易额 整体计算结果： 以上需求，在FineBI6.0里面，新建了4个计算字段完成了计算，如果用5.0版本，需要添加12个计算字段才能逐步算出，这，，方便了不是一点半点呀~ 当然，这个需求还可以继续做延伸，比如，如果需要算到月度，该怎么算？如果不止品牌D的付费会员，需求是批量计算不同等级付费会员的贡献，又该怎么算？？开动开动小脑袋瓜，算起来吧~  小结一下下   以上举例，我们了解了复杂占比的计算过程，但占比的计算其实是具有通用性的，无论多复杂的筛选后计算，最终就是计算两数相比所得的值（除法运算） 常用的场景还有同环比（用的最多，没有之一）、达成率、增长率、同期群等等，都是一个逻辑，但这些指标，又幻化出来了无数的业务场景。。。现在想想，小学就学到的＋－×÷，是能解决至少90%的业务指标计算问题的，so，小学毕业当老板不是没道理呀，学的多，不如用的好，ye~   好了，今天就酱紫啦，回见~  

1、选手介绍 团队名称：探索者 团队介绍：            Dana，LeZ数据分析师，BI探索型分析爱好者。            athlonk7，LeZ前数据分析师，一位老朋友，一位误入AI歧途的中年人。 团队组成：LeZ数据分析师 2、参赛初衷 公司现在使用的BI还是5版本，6版本只是在本地星星点点的使用，希望借大赛的机会逼自己系统练习一把，探索下6版本的新功能和现有的业务报表是否能更好的结合。 数据分析是一个不断进化的领域，如果沉浸在自己的小世界里，不与外界交流，很快就会落后一大截。希望通过比赛，能够和同行交流心得，切磋技艺。学习下其它朋友们是如何解决问题、如何优化算法、如何为企业创造价值的。 同时，比赛更是一个学习的过程。我们想要看看自己在这个领域的真正实力，也想知道自己与其他选手相比，到底差距在哪里。 二、作品介绍 1、业务背景及需求 当疫情散去，2023年的景象并不如人们所预期的那样充满希望。企业和个人面临着更多挑战。在这种背景下，“降本增效”成为了每个人耳边的常态，也成为了每家企业努力追求的目标。 我们是探索者，LeZ数据分析师，LeZ是一家专注于玩具零售的公司。在东莞、厦门和深圳拥有11家直营门店。为了拓展业务领域，公司在2022年底收购了另一家玩具渠道商，这使我们成功进入了澳门、珠海、福州的市场，并在电商平台上开设了7家店铺。现在，公司总共有34家门店，其中包括27家线下店和7家电商店。 23年年初，公司完成了系统整合。从1-4月的销售数据来看，一切似乎都在朝着正确的方向发展。但在4月底的公司月度经营探讨会议上，我们从高层的讲话中明显感受到了一股紧迫感。外部环境的压力逐渐显现，公司需要更快地调整策略来应对。。为了响应“降本增效”的呼声，公司内部经过了多次的讨论和争议，最终锁定了两个关键点。 需求： 首先，是优化各职能部门的报表。这听起来可能不是一个技术性的改进，但背后的意义却远超我们的想象。传统的报表编制经常需要几个部门联合，消耗大量的时间和人力资源。而且，手工制作的报表往往伴随着误差，这对于决策层来说，是一个巨大的风险。通过将这些报表上系统、自动化，我们不仅可以确保数据的准确性，还可以大大缩短报表的编制时间，使员工可以将更多的时间和精力投入到更有价值的工作中。对人力成本的优化也有一定的帮助作用。 第二点，上线重点商品计划，这是一个直指LeZ公司核心业务的决策。玩具市场瞬息万变，每一款新玩具的上市，都可能引发一个新的市场趋势。如何在这种环境下，确保公司的产品始终领先于市场，是我们一直在思考的问题。只有通过优化产品结构，将重点放在那些市场需求强烈、利润空间大的商品上，LeZ公司才有望在激烈的竞争中占据有利位置。 2、分析思路 3、数据来源及处理 3-1、数据源说明：企业数据脱敏处理 3-2、数据清洗示例：            使用python建立了新旧名称的映射表字典，通过逐行读写数据，完成对商品名的批量处理（如下图示例，脱敏商品信息）                 4、数据字段 与 数据处理 4-1、数据架构：               4-2、字段：                  ①事实表：订单明细表：                                      ②维度表：                   A. 商品信息表：                                       B. 门店信息表：                                       C. 会员信息表（会员基础信息表、付费会员表，共两张表）：                                                           ③ 目标表：                    A. 门店月度目标：                                        B. 品牌月度目标                     5、可视化报告 重点商品专案报告            重点商品专案计划出来后，第一步是选品，为此我们建了一个选品模型，如下图：                        Part1 - 选品模型           1-1 选品矩阵：           依据品牌的年度份额和毛利率对每个品牌划分区间，份额和毛利率双增长，且毛利高于大盘34%的品牌优先纳入候选商品池。          从选品矩阵图中可发现，Vtech市场份额最高，但其份额从21年的32%下降至23年的25%，且其毛利率仅31%，低于大盘平均的34%，故未选中。综合来看，Toys、Purple Plume、Quick Joy三个品牌提升空更大。           1-2 商品毛利ABC           从ABC分析看，截止4/30，Toys、Purple Plume、Quick Joy三个品牌毛利额合计已基本与Vtech持平，若后期作为重点品牌运营，投入更多的促销资源，毛利额大概率可以赶超Vtech。           综上，选品结果：Toys、Purple Plume、Quick Joy                     P.S 品牌份额的计算使用DEF函数，先用DEF_ADD计算出每个品牌的销售额，第二步计算当月所有的销售额，相除即为品牌份额。                DEF_ADD(SUM_AGG(${销售额}),${品牌}) / DEF(SUM_AGG(${销售额}),YEAR(${交易日期}))                品牌毛利率的计算逻辑：                DEF_ADD(SUM_AGG(${毛利额})/SUM_AGG(${销售额}),)                                 选品结束后，需要逐月分析专案效果，经与业务人员探讨&综合公司的重点指标，故制作了如下专案报表模板，月更即可。                            Part2 - 专案效果分析                2-1 专案运营后，各品牌的销售和毛利达成均在110%，完成较为出色。再各品牌的份额是否有提升？从数据结果看，                Toys从5月起，份额维持在16%-17%，在整个大盘增长的情况下，份额可以从4月份的15%继续攀升，足以说明此品牌的增长颇佳。                Purple Plume从5月起，份额维持在9%，4月份这个数字是8%。Quick Joy从5月起，份额维持在11%，4月份这个数字是9%。均达预期！                                               2-2 从毛利额及会员拆至月看，5月&6月增长明显，拆至周的角度看（可跳转查看），22周（5/28-6/3）6/1儿童节出现了爆发增长。               2-3 综合新老客 & 复购率的维度看，复购情况并不理想，说明较多的销售贡献来自人数的增长，开拓更多的新客有力的支撑了销售和毛利的达标。                                               专案分析最终仪表板呈现：                 日报模块            日报，数据解读不是核心，重点有三个：            ① 展示高层关注的重点指标（销售、毛利、达成）            ② 自动化发送（FineBI的定时调度）            ③ 数据预警             在设计之初，我们的初心是：通过参数来实现自定义筛选日期，展示出对应的销售额、毛利额、及其对应的同环比。甚至达成进度的警戒线就是日期进度动态实现，用以对比当前达成和日期进度的差距，             奈何建了一堆指标之后，发现通篇用参数，很难实现。比如，日期区间一旦筛选，用参数算的日期进度就算错了，识别不出来区间日期。                           探索失败，乖乖回到原路。。。           先看 ① 重点指标             指标卡展示，辅助图形（哭脸、箭头等）来展示销售、毛利、达成。                        跨表维度计算指标，设计了主题模型建模（星型模型），在设计门店、商品维度的展示时，可以直接跨表选字段，                            可视化亮点：仅展示排名靠前、以及靠后的门店，但排序数字正常（1/2/3。。。32/33/34）                           第一步：计算固定排序，如下图： DEF函数多层嵌套。             DEF(COUNTD_AGG(${门店名})+1,${门店名},(DEF(SUM_AGG(${销售额}),${门店名})/DEF(AVG_AGG(${门店销售额目标}),${门店名})) > EARLIER(DEF(SUM_AGG(${销售额}),${门店名})/             DEF(AVG_AGG(${门店销售额目标}),${门店名})))             计算结果是1.2.3。。。                           第二步：相对于要展示的%，DEF的固定排序数字过大。需要除以10000，将其调整为0.0001。其它如下图设置即可。                                     ② 自动化发送（FineBI的定时调度）                                                                                      ③ 数据预警（每日定时邮件）                                        P.S. 预警值的设置只能是常量，没办法根据日期进度做运算。                                           日报最终仪表板呈现：                   三、参赛总结 1、FineBI工具 那些优点 ① 不得不提的DEF函数，在仪表板算指标是真的方便呀~ ② 新增计算字段可以整个分析通用，比5.0的只能在单个组件用方便多啦~ ③ 主题模型建关系后跨表选字段赞； 那些不便，那些想做，但实现不了的 ① 组件并排展示，仪表板需要的组件比较多时，组件和仪表板来回切真麻烦呀~ ② 树标签没办法自适应 现有的模式： 想要的格式，但筛选项显示不出来 ③ 通过时间参数控制整个仪表板的筛选，比如日期进度、自定义同环比、警戒线，但实现不了 举例：日期进度，是用参数计算的，一旦日期区间选择两个，这里的进度就计算错误了。 ④ 预警值的设置只能是常量，没办法根据指标做运算。 2、参赛心理路程 在大赛即将结束的时候，我们才决定参赛，高压、仓促，连续一周的挑灯夜战，几乎到了崩溃的边缘，好几次，我默默问自己：要不要放弃？ 心说：放弃算了！ 大脑说：不要放弃！扛过去！ 几番拉扯中，大脑战胜了心。继续挑灯夜战，一路探索。 探索着探索着，发现我给自己挖了个大坑（见“哪些想做，但实现不了的”），随后，给自己了一个忠告：紧急时刻，千万不要搞创新，否则很容易死翘翘。。。忠告完毕，乖乖切回稳定模式。结果，临近交稿的最后一天，又忍不住在探索新功能。。。 这个心理路程，又让我反思了两点： 1、论目标的重要性！ 2、要过程还是要结果？ 心脑大战又开始上演。。。 但感触最深的应该是不到最后一刻，绝不放弃，所以，才有了今天的作品。 在我们还在努力完成作品的时候，陆陆续续看到论坛上上传了很多优秀的作品，对比各位大神，我们的作品似乎没那么优秀，但就像跑马拉松，此刻对我们来说，重点不是跑进top，而是，我们在各种挑战下，坚持跑到了终点…

DEF函数是FineBI 6.0家族诞生的一个全新函数，DEF，define的缩写，意思是 你想要的指标，我都能定义。DEF家积极响应国家政策，有三个娃：哥哥DEF、妹妹DEF_ADD、弟弟DEF_SUB。先介绍下这三个牛娃： DEF(聚合指标, , )  DEF_ADD(聚合指标,,)  DEF_SUB(聚合指标,,)  单看外观，是不是发现他们三个长一样？都是三个参数，参数一是聚合指标，参数二是维度，参数三是过滤条件 但其实他们各有所长：   DEF 函数使用 ，计算聚合指标值。组件中「分析区域」中拖入的维度不影响函数的计算结果，即 DEF 只关注自己指定的维度，外界的维度与我何干？！（哥哥个性） DEF_ADD 函数使用「分析区域的维度」+「指定维度」，计算聚合指标值。即组件中「分析区域中维度」的增减会影响函数结果。妹妹不仅有小我，还在不断的与外界互动中定义自我（绝对是混社会的一把好手） DEF_SUB 函数使用「分析区域的维度」-「指定维度」，计算聚合指标。即组件中「分析区域中维度」的增减会影响计算结果。但DEF_SUB 函数的维度是用来“忽略”分析区域中的维度的，怎么说呢。。就是当DEF_SUB 函数指定的有维度A的时候，若分析区域中刚好也有这个A维度，那。。。抱歉，A维度请自觉Say goodbye（狭路相逢DEF_SUB完胜，打败你，与你无关，弟弟威武） 为了更好的理解这兄妹三个，我们通过举例来做对比：   模拟数据源样表如下： 日期 城市 订单号 会员号  销售额   件数  23/1/5 上海 A0158 C_0098 2,568 7 23/1/6 上海 A0159 C_0099 456 3 23/1/7 苏州 A0190 C_0190 50 1 23/1/8 上海 A0161 C_0109 4,573 12 23/1/9 重庆 A0162 C_0104 2,868 8 目标：通过计算不同城市的去重会员数来看DEF在实际应用中的差异 插个话。。。FineBI 6.0之后版本有两个位置可以使用DEF函数：     分析主题 ->> 数据集；仪表板 ->> 组件中创建计算字段 此处举例我们使用第二种，即在仪表板中通过创建字段来使用。 走起~  Step1  打开FineBI6.0，在tab【我的分析】中新建分析主题，弹出【选择数据】框，将Excel数据导入（当然，当前工程上有数据的话，可以直接调用工程上的数据）  Step 2  数据导入完毕，咱直接调用，毕竟，今天的主角是DEF，数据处理的过程不重要~ 先建组件-->添加计算字段，下图示例为 DEF(COUNTD_AGG(会员编码))，计算total会员数 其它公式如下（第三维度的添加会加大理解难度，暂且不加）：                     DEF_ADD(COUNTD_AGG(会员编码))DEF_SUB(COUNTD_AGG(会员编码))DEF(COUNTD_AGG(会员编码),城市)DEF_ADD(COUNTD_AGG(会员编码),城市)DEF_SUB(COUNTD_AGG(会员编码),城市)DEF(COUNTD_AGG(会员编码),)DEF_ADD(COUNTD_AGG(会员编码),)DEF_SUB(COUNTD_AGG(会员编码),)  Step 3  接下来，重点来了~ 我们来新建4个组件，对比下不同维度下公式的差异（总计会员数是5814人，公式在表头，每个组件的第一个公式COUNTD_AGG是标杆值）： 组件a. DEF三个函数的第二参数不指定维度，组件不拖入维度，计算结果： 三个公式计算均为自动聚合的总计人数5814； 组件b. DEF三个函数的第二参数不指定维度，组件拖入维度【城市】： DEF_ADD & DEF_SUB 两个函数会受到组件维度【城市】的影响，计算结果为每个城市的会员数； DEF则不受 组件维度【城市】的影响，计算的是总计人数5814； 组件c.  DEF三个函数的第二参数指定维度【城市】，组件拖入维度【城市】： DEF 函数会受到第二参数指定维度【城市】的影响，计算结果为每个城市的会员数； DEF_ADD函数会受到组件维度【城市】 以及第二参数指定维度【城市】的影响，计算结果为每个城市的会员数； DEF_SUB则忽略组件维度【城市】的影响，计算的是总计人数5814； c_1. DEF三个函数的第二参数指定维度【城市】，组件拖入维度【销售日期】： DEF 函数会受到第二参数指定维度【城市】的影响，计算结果为每个城市的合计会员数5814，组件维度【销售日期】对计算结果没有影响； DEF_ADD函数会受到组件维度【销售日期】 以及第二参数指定维度【城市】的影响，计算结果为每月、每个城市的会员数的合计（之所以和标杆值一致，是因为数据源内本身没有存在城市间的重叠会员）； DEF_SUB函数会受到组件维度【销售日期】，忽略第二参数指定维度【城市】的影响，计算的是每月的会员数，下图2会看的更直观（之所以和标杆值一致，是因为数据源内本身没有存在城市间的重叠会员）； 组件d. DEF三个函数的第二参数指定维度【城市、销售日期】，组件拖入维度【城市】： DEF 函数会受到第二参数指定维度【城市、销售日期】的影响，计算结果为每个城市、每月的会员数合计（注意观察和标杆值的不同）； DEF_ADD函数会受到组件维度【城市】 以及第二参数指定维度【城市、销售日期】的影响，计算结果为每月、每个城市的会员数合计（注意观察和标杆值的不同）； DEF_SUB则忽略组件维度【城市】的影响，计算的是每月人数的合计5814（注意，第二参数指定的【销售日期】维度相当于多余的维度，对结果无影响）； (⊙o⊙)…对比完毕，小结一下，争取前后呼应： 哥哥DEF ：只关注自己指定的维度，外界的维度跟他没关系； 我就是我，不一样的烟火 妹妹DEF_ADD：不仅关注自己指定的维度，还和组件中的维度互动，然后重新定义自我； 我与世界合二为一 弟弟DEF_SUB：我的维度就是用来PK组件维度的，绝对完胜； 不服来战   就酱紫~下次说说怎么在实际的业务场景中使用DEF，回见~   本文经授权，转自公众号：BI实战