★ FEATURED ARTICLE 上个月帮一个做淘宝店群的朋友复盘大促数据他甩给我一份从后台导出的用户行为明细整整185万行。他的原话是“Excel已经打不开了你看着办。”我用Power BI把这份数据啃了下来做了一整套用户行为漏斗分析从数据清洗到模型搭建从DAX指标定义到异常归因排查前后折腾了一周。整个过程踩了不少坑也沉淀出一套可以复用的打法。这篇就把我的处理过程完整拆一遍包括每一步的操作逻辑、DAX公式、可视化设计以及一次真实的转化率异常排查案例。如果你手里正好也有类似的电商行为数据想用Power BI做用户分析这篇文章应该能帮你少走很多弯路。1. 为什么挑Power BI啃电商行为日志一场真实的复盘1.1 一份185万行的后台导出文件Excel已经顶不住了朋友当时的问题其实不复杂想知道用户从进店浏览到最终支付每一步到底流失了多少人哪些商品引流能力强但转化差凌晨进店的用户和晚上逛店用户的购买意图有什么差异。这些问题用Excel也能回答一部分但当他拖了一个数据透视表、电脑风扇开始狂转之后我们就知道这条路走不通了。185万行的行为明细Excel单表能承载的极限大概在104万行左右。就算你用Power Query或者删减列强行打开后面做透视表、多条件计数、按日期切片每一步都是一场折磨。更别说后期要给运营同事交付一个可以自己筛选、点两下就能看到答案的看板Excel做出来的表格发过去对方往往不知道怎么操作最后又变成“你再帮我导个数”。Power BI在这里的定位就非常清晰它能处理比Excel大一个量级的明细数据能通过DAX精确复现业务口径还能把成果发布成网页或App让团队里每个人都用浏览器自行交互查看。我这次就是拿Power BI完整走了一遍淘宝用户行为分析下文的每一步都是基于我这次实操的完整记录既有可以直接照抄的公式也有我踩过之后才明白的教训。1.2 选型对比Excel、Python、Power BI的三角取舍我知道有人会问为什么不用Pythonpandas处理几百万行数据确实秒开画图也灵活但问题出在分析完成之后的交付环节。你用matplotlib或plotly画了一堆图表发给店长和运营他们能看懂但想让他们自己切换日期、筛选类目、查看某个商品的数据就还得回来找你重新跑一遍脚本。Python适合做探索性分析和建模不适合做持续迭代的自助式分析。Power BI的强项正好补上这个短板数据模型压缩之后185万行行为表在内存里跑得很轻松拖拽生成的可视化天然支持交互筛选DAX可以精确处理业务上那些绕来绕去的口径。所以我的通常建议是一锤子买卖的数据处理用Python团队需要反复查看、动态筛选的分析用Power BIExcel留给简单汇总和临时看数。至于Tableau我承认它的图表美观度更好但在国内电商分析场景里Power BI的普及度更高而且和Excel同属微软生态业务团队从Excel切换过来的学习成本非常低。这也是我这次坚持用Power BI的原因之一。工具没有绝对好坏关键是匹配场景这次的场景就是典型的“多人协作、反复筛选、业务口径复杂”没有比Power BI更合适的了。1.3 本次分析的数据基础字段说明与分析周期为了让你能照着操作我先交代这次数据的具体情况。数据源于某淘宝店铺后台导出的用户行为日志已脱敏基于常见的用户行为数据集结构整理。分析周期是2025年1月1日到2025年2月28日共59天累计185.6万行行为明细涉及3.2万用户、1500个商品、70个类目。字段名类型说明user_id文本脱敏后的用户IDitem_id文本商品IDcategory_id文本商品类目IDbehavior_type文本行为类型pv浏览、fav收藏、cart加购、buy支付event_time日期时间行为发生的时间source文本流量来源直通车、自然搜索、活动页、淘宝客等item_price数字商品成交单价仅buy行为有值quantity数字购买数量仅buy行为有值行为分布方面pv约160.2万次fav约8.1万次cart约12.4万次buy约4.9万次整体浏览到支付转化率约为3.05%。这里要特别提醒行为表里的“浏览”是事件级明细同一个用户短时间内反复点开同一个商品会产生多条记录后面算口径时如果不处理去重指标会被严重放大。这一点在第三章我会展开讲。2. 数据清洗与模型搭建拿到原始日志后的第一道坎2.1 先处理四种脏数据不然后面全是错数原始数据拿到手直接建模肯定不行。我第一次检查就发现了四类典型问题这里逐一说明你遇到类似数据时可以对照着处理。第一类是重复记录。因为埋点上报重试个别行为被记录了两份。比如同一个user_id对同一个item_id在同一秒内出现了两条完全相同的pv记录。这种情况我直接用Power Query的“删除重复行”功能按关键列去重user_id、item_id、behavior_type、event_time四个字段完全一致才删不是简单按整行去重。这一步删掉了大约3700条重复记录。第二类是空值和异常ID。user_id为空的有42条item_id为空的有十几条这类数据直接过滤掉。因为后面按用户维度做DISTINCTCOUNT时空值会让去重统计失真按商品维度分析时空商品ID也会变成一堆无意义的“未知商品”。第三类是未来时间戳。数据里出现了少量event_time在数据导出日期之后的情况显然是埋点时间读取异常。我按分析周期边界把它们过滤掉了只保留1月1日到2月28日之间的记录。第四类是行为类型取值不规范。字段里同时出现了“buy”、“purchase”、“pay”三种写法实际上都是支付。我在Power Query里做了一步替换值把非标准的取值统一映射成标准枚举pv、fav、cart、buy。四步做完数据从185.6万行降到了约183万行。别小看这2万多行的差异很多人在Power BI里做出的漏斗数字对不上业务后台十有八九就是脏数据没处理干净。清洗这一步决定了后续所有指标的地基地基歪了后面盖的楼越高偏差越大。2.2 日期维度表必须自己建别用自动日期层级很多Power BI新手会直接拖行为表里的event_time到可视化画布上因为系统会自动生成一个日期层级“年”“月”“日”好像就这么有了看起来非常方便。但我强烈建议不要这么用至少在这个场景下不要。原因有两个。第一自动日期层级是Power BI在后台为每个日期列隐式生成的隐藏表它会自动对事实表做分组计算数据量一大性能下降非常明显。第二自动层级里没有“星期几”“是否周末”“第几周”这些业务分析需要的字段你后面想看周末和工作日转化率差异会发现自己根本无从下手。我在这个项目里使用的是标准日期表写法日期表 ADDCOLUMNS( CALENDAR(DATE(2025,1,1), DATE(2025,2,28)), 年, YEAR([Date]), 月, FORMAT([Date], YYYY-MM), 日, DAY([Date]), 星期名称, FORMAT([Date], AAAA), 星期数, WEEKDAY([Date], 2), 周序号, WEEKNUM([Date]), 是否周末, IF(WEEKDAY([Date], 2) 6, 是, 否) )建好之后在“表工具”里点击“标记为日期表”把Date列标记上再和事实表的event_time建立一对多关系。这样后面所有时间智能函数比如TOTALMTD、SAMEPERIODLASTYEAR才能正常工作。这一步属于典型的“省事一时爽后面火葬场”。如果你一直依赖自动日期层级建议从下一个项目开始手动建日期表跑通一次之后会发现查询速度和模型灵活性都有明显提升。2.3 星型模型设计事实表与维度表怎么拆数据清洗完成后下一步是建模。建模的核心原则就一句话把明细行为作为事实表把用于筛选和分组的属性拆成独立的维度表通过关系连接成一个星型模型。我这次拆了三张维度表第一张是商品维度表包含item_id、标题、类目、价格带、上架时间等静态属性。商品维度的好处是商品改名或类目调整时只用维护一张小表不用回到行为明细里去逐行改。更关键的是商品层面的分析比如爆款排行、类目转化对比都依赖这张表的关联。第二张是用户维度表包含user_id、会员等级、注册时间、城市等属性。从行为表里用SUMMARIZE去重用户得到基础的用户列表再加入这些静态属性。这里要点是用户维度表不要放行为聚合字段比如“总购买金额”这类字段应该用度量值动态计算放到表里会导致刷新时数据不一致。第三张就是刚才说的日期表。三张维度表分别和事实表建立一对多关系筛选方向都是单向Single。有人为了图方便会把关系设置成双向筛选我这里明确不建议双向筛选在小型模型里看起来没问题数据量和计算复杂度上来以后会导致不可预测的筛选传递排查问题非常痛苦。模型建好之后我在Power BI的“模型视图”里检查了一遍关系的基数确认所有维度表到事实表都是一对多且没有出现多对多关系。多对多关系在这个场景里几乎意味着模型设计出了问题建议从一开始就避免。2.4 会话归属给行为数据补一个分析维度这个项目里还有一个容易被忽略的维度会话。淘宝后台导出的数据里通常没有严格的session_id但用户行为分析绕不开“会话”这个概念——用户进店后连续操作的一段时间算一次会话。没有会话维度你就没法回答“平均一次进店产生几次浏览”“从进店到支付平均耗时多久”这类问题。我处理会话的方式是在Power Query里做的思路是按user_id分组按event_time升序排列计算每条记录和上一条记录的时间差如果时间差超过30分钟就视为一次新会话的开始。然后对所有“新会话起点”做累加生成一个会话序号配合user_id拼接成完整的会话ID。这个过程直接用M语言写会比较绕涉及逐行递归。我的建议是数据量不大在Power Query里用分组索引加填充也能实现数据量大最好在数据源头用SQL窗口函数提前算好。会话维度建好之后可以大幅扩展分析场景比如会话级漏斗、会话平均时长、跳出率分析后面很多高阶分析都要用到它。3. 漏斗口径与DAX度量值转化率不是简单除一下3.1 行为口径定义先想清楚“一个人”还是“一次会话”做淘宝用户行为分析绕不开四个行为类型浏览pv、收藏fav、加购cart、支付buy。看起来很简单但实际定义口径时很容易踩坑。第一个坑是去重问题。同一个用户一天内反复浏览同一个商品生成10条pv记录那么算“浏览人数”时到底算1个人还是10次浏览我的建议是人数类指标一律按user_id去重次数类指标按明细行数计算。两者都要保留因为业务含义不同——浏览人数反映覆盖广度浏览次数反映用户深度兴趣。第二个坑是用户粒度与会话粒度的差异。比如某个用户在一次会话里浏览了8个商品最后只支付了其中1个在用户粒度上这个用户的“浏览到支付转化率”是100%他买了但在会话粒度上这8个商品里只有1个完成转化商品维度的转化率是12.5%。两个口径都有业务意义前者看用户购买意愿后者看商品承接能力所以我做漏斗时两个都会算而不是只给一个数。第三个坑是支付行为与商品维度的匹配。一个订单里可能包含多个商品行为明细里的buy行为是商品级别的支付记录这意味着同一笔订单会有多条支付明细。如果按DISTINCTCOUNT(user_id)算支付人数同一用户在同一天买多件商品只算1个人这是合理的但如果算支付次数或商品销量就需要按具体明细行计数不能去重。口径不提前定义清楚后面做任何对比都是自说自话。3.2 核心DAX度量值完整拆解与说明下面我把这次建模用到的主要度量值逐一给出来并说明每个公式为什么这样写。首先是四个基础行为人数浏览用户数浏览用户数 CALCULATE( DISTINCTCOUNT(行为表[user_id]), 行为表[behavior_type] pv )收藏用户数、加购用户数、支付用户数结构完全一致只是把behavior_type的筛选条件换成fav、cart、buy。这里没必要为每个行为写一段重复的DAX直接复制改条件就行。接着是支付金额GMV CALCULATE( SUMX( 行为表, 行为表[item_price] * 行为表[quantity] ), 行为表[behavior_type] buy )这里用SUMX而不是SUM是因为金额需要逐行计算单价乘以数量SUMX会对行为表逐行迭代求和。在数据量大时SUMX或许会有一点性能压力但对于183万行的表这个计算量完全可以接受。然后是转化率指标最基础的两个浏览到支付转化率 DIVIDE( [支付用户数], [浏览用户数] )加购到支付转化率 DIVIDE( [支付用户数], [加购用户数] )这里用DIVIDE而不是直接用除号原因是DIVIDE在分母为0或BLANK时能安全返回BLANK或第三参数不会报错也会保持筛选上下文的一致性。这是DAX里一个很小但很重要的习惯。还有一个常被问到的指标人均浏览商品数这个指标能反映用户逛店的深度人均浏览商品数 DIVIDE( CALCULATE( COUNTROWS(行为表), 行为表[behavior_type] pv ), [浏览用户数] )如果还想看人均浏览多少个不同商品去重后的商品数把分子改成CALCULATE( DISTINCTCOUNT(行为表[item_id]), 行为表[behavior_type] pv )这两个指标的差异很有价值——人均浏览商品次数高但去重商品数低说明用户反复看同一批商品犹豫不决反过来则说明用户逛得很广但深度不够。这种细节洞察正是业务方最爱在周会上讨论的东西。3.3 漏斗可视化一个原生漏斗图加一张矩阵DAX写完之后落地到可视化我用了三个核心视觉对象。第一个是原生漏斗图横轴依次是浏览人数、收藏人数、加购人数、支付人数。漏斗图的好处是流失梯度一目了然但要注意的是Power BI原生漏斗图的数值格式需要手动设置不然显示出来是一堆科学计数法或者特别长的数字。第二个是矩阵表格行是行为类型维度列放类目或流量来源值放人数、次数、金额、转化率。矩阵是最适合多维度交叉对比的视觉对象排障时我大量依赖它。比如我要看“直通车来源的加购到支付转化率”把source放到列behavior_type放到行值放对应度量值几秒钟就能得到答案。第三个是转化率瀑布图按浏览→收藏→加购→支付逐步展示每一步的绝对流失人数和相对流失率。瀑布图的价值在于它能同时呈现“整体漏斗形态”和“每一步流失的绝对值”给业务展示时冲击力很强。这里有一个布置建议把日期切片器、来源切片器、类目切片器统一放在页面上方所有图表共用这一组切片器。因为我设置了正确的模型关系点击切片器后所有视觉对象会同步联动不需要额外配置。如果你发现某个视觉对象不想被某个切片器影响可以右键选择“编辑交互”把交互改成不影响即可。这个细节在复杂页面布局里非常实用。4. 三类高阶分析场景从“看数”到“洞察”4.1 全天行为节奏为什么凌晨进来的用户转化更高基础漏斗搭好后我开始尝试回答一个业务方很关心的问题什么时段进来的用户质量最高我在日期表之外单独建了一个“小时”维度的度量方式。通常做法是在行为表里添加一个计算列“小时 HOUR(行为表[event_time])”但前面说过计算列会占用模型空间。我这次因为只有183万行加一列影响不大但更规范的做法是用日期表关联后写一个基于event_time的度量值或者直接在可视化里用event_time的小时作为轴。计算每个小时的浏览人数、支付人数、转化率之后结果非常有意思晚上20点到23点是流量高峰浏览人数和加购人数都是全天最高的但支付转化率的最高点却出现在凌晨0点到2点这个时段支付转化率比晚间高峰高出将近一倍。这其实符合电商用户的典型行为模式白天和晚上八九点是“逛”的心态用户可能是在通勤、摸鱼、睡前刷手机看到感兴趣的商品先加购收藏真正下单反而在夜深人静、购物冲动沉淀之后。所以凌晨进来的人虽然少但都是带着明确购买意图来的。这个结论直接影响了运营对直通车分时段出价的策略调整可以说数据分析的价值在这一刻就体现出来了。4.2 商品与类目下钻找到真正驱动大盘的爆款逻辑漏斗和时段分析解决的是“整体情况如何”但业务方还非常关心“哪些商品在贡献大盘”。我用了一个商品贡献度矩阵来做下钻。具体思路是用矩阵把商品ID放到行值放浏览人数、加购人数、支付人数、支付转化率、GMV再按GMV降序排列。配合“TopN筛选器”只看贡献最大的前20个或前50个商品。结果发现了一个很典型的电商现象头部20个商品贡献了整体45%的GMV但其中有两个商品的加购到支付转化率只有大盘平均的一半。也就是说这两个商品有很强的“引流力”但“转化承接力”明显偏弱。进一步下钻到类目维度后发现问题更具体这两个商品都属于同一个类目而这个类目有一个共同特征——SKU比较重、规格复杂用户在下单前往往需要反复对比。业务方看到这个结果后立刻就知道该优化详情页的规格对比模块了。这种“先看整体再下钻到商品最后归因到类目属性”的分析路径比一开始就盯着全量数据看要高效得多。Power BI的交互筛选能力在这里被充分用上了从矩阵点进商品详情再点进类目一路钻取全程没有写一句新DAX。4.3 RFM用户分层在Power BI里复刻经典模型商品层面搞清楚之后我把视角切回用户用RFM模型做用户分层。RFM是电商运营里非常经典的分析框架RRecency最近一次购买距今天数FFrequency购买频次MMonetary购买金额。RFM三个维度组合可以把用户划分成重要价值客户、重要保持客户、重要发展客户、重要挽留客户等多个层级。在Power BI里落地RFM时我用了“新建参数”功能。在“建模”选项卡下选择“新建参数”分别创建R阈值、F阈值、M阈值三个数值范围参数比如R阈值范围是1到90天F阈值范围是1到10次M阈值范围是100到5000元。Power BI会自动生成切片器和对应的单值度量值方便后续动态调整阈值。然后在用户维度表上写三个计算列分别是每名用户的最近购买天数、购买次数、购买总金额。以购买总金额为例用户购买总金额 CALCULATE( SUMX(行为表, 行为表[item_price] * 行为表[quantity]), 行为表[behavior_type] buy )接下来写一个分层的计算列核心逻辑是用SWITCH嵌套判断R、F、M是否达到阈值用户层级 SWITCH( TRUE(), 最近购买天数 [R阈值值] 购买次数 [F阈值值] 用户购买总金额 [M阈值值], 重要价值客户, 最近购买天数 [R阈值值] 购买次数 [F阈值值] 用户购买总金额 [M阈值值], 重要保持客户, 最近购买天数 [R阈值值] 购买次数 [F阈值值], 唤回客户, 最近购买天数 [R阈值值] 购买次数 [F阈值值], 新晋用户, 沉默用户 )注意这里的相邻判断有优先级SWITCH会从上到下匹配第一个为TRUE的分支所以顺序不要随便乱调。分层结果出来后我用矩阵展示每个层级的用户数、人数占比、GMV贡献占比。实测下来最典型的一个结果是重要价值客户虽然只占用户总数的6.8%却贡献了超过40%的GMV。这就是业务上常说的“二八法则”在用户侧的体现运营的重点应该放在维护这类高价值用户上而不是一味拉新。5. 一次真实的转化率异常排查从指标异动到业务归因5.1 现象某主力渠道的支付转化率连续三天从5.8%跌到3.9%模型和看板交付给运营之后第二周运营同事就发现了一个异常直通车来源的支付转化率在2月中旬连续三天下滑从5.8%一路跌到3.9%整体大盘的支付转化率也被拉低了0.6个百分点。业务方当时的直觉是“是不是详情页改版改坏了”但事实上改版已经在两周前完成改版初期并没有出现转化率下降。我听到这个直觉时并没有直接否定而是建议先用数据做层层拆解。这类异常排查最忌讳的就是业务方给出一个结论数据分析跟着写一堆支撑这个结论的材料。正确的做法是先不预设原因按数据维度一层层剥离让异动自己“现形”。5.2 排查链路渠道拆解、时间拆解、行为拆解三步走我的排查逻辑通常分三步。第一步渠道拆解。把支付转化率的下降幅度按source维度拆开查看是不是直通车独有的问题还是大盘普跌。用矩阵把source放到行、日期放到列值放支付转化率结果很快显示自然搜索、淘宝客、活动页的转化率基本平稳只有直通车渠道在下跌而且下跌幅度和整体异常程度高度吻合。这基本确认了问题出在直通车流量本身。第二步时间拆解。把直通车渠道的浏览人数、支付人数、转化率放到同一个折线图里按天查看。发现一个奇怪的现象浏览人数不降反升从每天的约9000人涨到了1.8万人但支付人数没有同步增加转化率自然被稀释了。也就是说进来的流量更多了但质量变差了。第三步行为拆解。针对直通车来源的用户按新老用户分组看浏览、收藏、加购、支付四个环节的转化差异。结果发现新增用户占比从平时的30%左右突然涨到62%而这批新用户的浏览到加购转化率只有老用户的三分之一加购到支付转化率也明显偏低。说白了进来的这批人大部分逛完就走了既不收藏也不加购更谈不上支付。5.3 归因结果与可落地的运营动作数据拆到这里原因已经很清晰了直通车在2月中旬做了一轮人群投放调整人群包定向明显放宽引入了大量泛流量。这些用户对店铺和商品没有认知基础进店后缺乏信任感行为链路的每一步都在流失。转化率下降不是商品或详情页的问题而是流量结构变化导致的。运营拿到这个结论之后做了两件事一是把人群定向从“广泛匹配”改回“核心人群相似人群”收窄流量入口二是针对不可避免的泛流量在落地页增加了一个新客专享券的弹窗试图用优惠把低意向用户拦下来。调整后三天直通车渠道的支付转化率回到了5.4%虽然没完全恢复但趋势已经止跌。这个案例给我最大的启发是异常指标排查不能只盯着结果数字要学会把“结果指标”拆成“过程指标”再叠加维度去定位问题环节。支付转化率跌了得先知道是哪个渠道跌、哪个时段跌、哪类用户跌、哪个行为环节流失加剧。Power BI的交互钻取在这一过程中发挥的作用远比一张写死的Excel统计表大。6. 报表性能优化与发布踩坑记录6.1 183万行数据为什么会卡常见性能杀手一开始这套报表其实是有点卡的切换筛选器要等好几秒尤其是点击“全部商品”那个切片器时整个页面都要转圈。183万行在Power BI里绝对不算大卡顿完全是因为模型设计不合理。排查下来最大的性能杀手有三个。第一个是自动日期层级没有关闭Power BI后台为event_time生成了多套隐藏日期表每次筛选都在做多余计算。第二个是事实表上加了太多计算列包括“年”“月”“小时”“行为类型中文名”等这些字段应该在维度表或度量值里解决而不是塞进事实表。第三个是我在一开始给关系设置了双向筛选导致筛选器在模型间反复传递计算量成倍增长。这三件事解决之后报表的响应速度提升了至少三倍。如果你也遇到Power BI卡顿建议先按这三个方向自查大概率能解决80%的问题。6.2 优化清单我实测有效的七个动作我把这次实际执行且验证有效的优化动作整理成了一份清单供你参考。关闭自动日期层级在“文件→选项→当前文件→数据加载→时间智能”里取消勾选“自动日期/时间”。删除事实表上的冗余计算列能用度量值替代的不要存成列确实需要存的放到维度表里。单向筛选关系所有维度表到事实表的关系方向保持Single不要开双向。用日期表并标记时间智能函数要依赖正确标记的日期表否则部分聚合会走全表扫描。精简可视化单页视觉对象数量控制在8个以内超出的放到书签或分页里。限制Tooltip和钻取字段不必要的钻取字段会在后台生成额外聚合能关就关。定期用DAX Studio检查慢查询定位到具体是哪个度量值开销最大再针对性地重写。其中DAX Studio这个工具值得多说一句它是免费的可以直接连接Power BI模型执行查询、查看执行计划和耗时。排查性能问题时光靠肉眼看页面加载时间很难定位根源用DAX Studio跑一遍瓶颈一目了然。6.3 发布、刷新与行级别权限报表做完之后需要交付给团队使用这里涉及发布、刷新和权限管理三件事。发布本身很简单在Power BI Desktop里点击“发布”选择一个工作区即可。但要注意免费版账户只能把报表发布到个人工作区别人无法查看如果是要团队协作至少需要Power BI Pro许可证并且发布到一个共享工作区。数据刷新方面如果你的数据源是本地的Excel或者CSV文件发布之后要刷新数据必须安装并配置Power BI Gateway个人网关。如果没有网关数据只能停留在发布那一刻不会自动更新。我当时就是在这里卡了半天以为发布之后数据就会自动跟着源文件更新实际上完全不是这么回事。如果你的数据源是数据库或云端服务配置网关之后还需要在数据集设置里配置计划刷新时间并输入数据源凭据。这里有一个坑如果表里有敏感信息凭据建议使用专用账号不要混用个人账号避免离职后数据源连接失败。权限方面这个项目和日常运营数据一样不能让所有同事都能看到全部商品和金额数据所以我用行级别安全RLS做了行级权限控制。步骤是在Power BI Desktop的“建模”选项卡下点击“管理角色”新建一个角色然后写DAX表达式限制行范围。比如按照流量来源限制了运营只能看自己负责渠道的数据[source] LOOKUPVALUE(渠道负责人表[渠道], 渠道负责人表[负责人], USERPRINCIPALNAME())意思是当前登录用户的邮箱匹配到渠道负责人表里的负责人只返回他负责的那些渠道的行。发布后在Power BI服务中进入数据集→安全把对应的测试账号和真实账号分配到该角色下即可。注意RLS只对查看报表的人生效对报表编辑者和数据集拥有者不生效。最后再分享一点个人体会。做完这个项目我最大的感受是Power BI只是一个放大器真正的功夫在数据清洗、口径定义和业务理解上。同样的数据口径定义清楚的人能做出让业务方认可的看板口径含糊的人只能做出一堆让人越看越糊涂的图表。如果你也准备拿Power BI啃电商行为数据建议先从一个小类目、一个月的明细开始跑通从清洗到发布的全流程再逐步扩大到全量数据。这条路我替你走过一遍了照着走不会太折腾。
阅读完成 · 觉得有帮助？
