从零搭建微信公众号数据分析体系：模型调优篇
28
2023-09
从零搭建微信公众号数据分析体系：模型调优篇
看板的框架已经有了，接下来的工作就是让这个模型的效果变好一点，更加适配实际使用的需求~
LEARN MORE
图片由海艺AI绘制
前情回顾
从零大家数据分析看板系列已经到第5期了，现实中的时间周期已经拉了一个多月了。所以先对前面的内容做一个小的回顾:
准备篇 中，分析了这个项目的可行性和必要的背景，算是立了这个项目吧。主题确认之后就开始了调研，先看看别人都是怎么做得，再决定我要怎么做。前期准备工作全部ready之后，就开始了数据建模，从数据入库开始做起的那种。终于，在上周，一个看板预搭建好了。
于是有读者私信了这么一个问题：
一个好问题，没有度量值直接拖拉拽，确实是会有隐患的，不过这种隐患在这个阶段还不是特别重要。后续等模型彻底确定下来之后，确实需要再考虑创建度量值来避免不必要的隐患吧~
除此之外，还有一些其他可以实现同样功能的技术路径，可以考虑在这一条技术实现路径全部写完之后去可能的分岔。比如把数据导入本地数据库，其实可以用power query做平替，数据库建表时的建模工具，也可以改成用AI来实现，看板也可以用fine bi来实现之类的。甚至说，还可以用excel从头拉到尾……这些分支可以后续慢慢来。
不过略微悲伤的一点是，这个号开不了评论的功能，目测以后也不会有评论的功能了。据说微信公众号现在已经不会新开评论的功能了，之前开过的会有，但是新号就没了。
数据调整
我们暂时先抛开可能的隐患（放到最后一个部分来讲吧），在上期已经搭建出来的描述性统计的基础上，我们可以预设几个结论和猜想。接下来，我们就要根据这些预设和猜想对数据进行调整了。
首先，根据面板的情况，可以得出这么一个结论：
6月之前的数据其实没有分析的价值
虽然说从原则上来看，数据越完整越好，我能拿到的数据其实是不少的，但是真正对于分析来说有价值的 数据其实从6月才开始。我们可以看这张图，不难发现6月之前的数据其实是四舍五入毫无波动的。
如果是真实的企业业务场景，我可能会和需求方确认一下，这个业务大概是什么时间开始策划、什么时间验证业务逻辑通过，什么时间开始大规模投入资源的。然后和我的数据做相互印证，判断一下数据中有没有离谱的骚操作。比如发现业务早期的数据也偏高，就可以询问一下业务部门，早期业务是怎么运转的，系统中的数据有没有可能是出于某些原因直接批量造出来的数据。
是的，企业正常的业务逻辑都不会一开始就all in 一件事，刚开始的时候肯定是处于各种试错的状态，来回改策略，直到某一种策略被验证方向大概率没问题了，才会开始大规模的投入资源。而这种试错，对于我们数分狗来说往往是比较难熬的，因为在前期不断试错的过程中，数分狗作为支持的角色，工作的体感是非常糟糕的——需求方不停地再改。在这种阶段，我一般建议大家不用太考虑后续的兼容、自动化之类的问题，怎么快怎么来，因为早晚要改。
这个项目嘛，因为都是我自己做得，所以我不需要任何沟通，答案就在我脑子里：我是6.18发布的创作计划，真正的业务是从6.19开始的。因此，根据这一结论的调整，就是修改数据拉取的日期，太早期的数据就不放在看板中了。
鼠标移动到任意表的最右侧，可以看到这样的提示：
直接点击任意表右侧的三个点，展开更多选项，就可以回到power query的界面进行查询的编辑了。
这里有两种操作方式，第一种方式是直接在power query中进行修改：
看到这个截图是不是瞬间就明白了，毫无难度，简直有手就会。根本不需要做太多的解释和说明。所以说，power query本身其实没有太大的难度，新手小白也完全不用担心学不会。
第二种操作就是直接修改数据库的SQL语句来实现。在已经写好了一部分的情况下，我们可以这样来修改：
点击查询设置最右侧的这个像齿轮一样的东西：
在弹出的弹框中输入SQL语句，直接把6月18日之前的数据过滤掉：
大家是不是都会下意识地这样写SQL？然而这里我要说，在看板里千万不要写select *，因为会有一种隐患叫做开发加了字段没告诉你。遇到这种真的需要写select * 的场景，宁可一个一个字段罗列出来，也不要写select * ，毕竟你永远无法保证自己会不会遇到坑爹的猪队友。
然而那么多字段一个个全部罗列出来也很麻烦对不对，这里再教一个离谱但是好用的办法。
在navicat的右下角，有这么一个按钮：
点击一下，就可以展开表相关信息的窗口了。没错，这就是建表语句了：
然后用替换大法快速生成一个select 罗列所有字段的SQL语句出来。
虽然依然麻烦，但是速度至少要比一个一个字段手写罗列要快得多吧。
对自己有信心的同学可以直接把SQL贴进power bi中运行一下看看。对自己没有信心的朋友们也可以先在navicat中跑一下试试。这里要提的一点是，如果SQL语句在navicat中运行的时长超过了五分钟（当然，网络原因要排除在外），就先考虑优化SQL语句了，这种SQL到了power bi server中非常容易引起刷新报错，报错原因就是慢SQL。
把整理好的SQL贴进来，点击确定：
这时我们就会发现，power query中有一个报警感叹号冒了出来：
并且当我们点击这里的时候就会发现有一个报错：
这是为什么呢？作为一个技术贴，这里当然要教大家怎么看问题出在哪里了，而不是单纯告诉大家这种问题如何处理。
点击这里的高级编辑器：
我们可以看到这样一串代码：
这就是传说中的M语言了。不少新手都表示M语言好难学，实际上，在99%的实际场景中，我们是不需要去写M语言代码的，常用的操作其实都能通过鼠标点点点去实现。对于这个事情，我们要用反向思维去思考，既然我们鼠标点击的动作能够自动生成代码，那么我想要知道代码是怎么写的，其实只需要用鼠标点一遍，然后再去看生成的代码是什么样的就可以了。这里就不做M语言的语法规则的延展了，后续可以在power query实现的这个分支中来讲一下。
根据这段代码，我们可以看到，报错的这一行代码实现的内容是访问schema=dbo中item=7days_content的内容并展开所有的data。这里的schema和item具体是什么意思其实我也解释不清楚，大家可以理解为shcema就是database，item就是table。
本次改写后，显然我们已经在SQL中指定了要访问的数据表，自然不存在要展开获取某个表的需求了，所以这里的代码，我们直接删除就行。删除同样是两种方式，直接在高级编辑器中删除M code或者在页面直接点击X号进行删除。
其他三张表的操作类似，把所有用到的数据都做一次过滤，让看板只留下我需要看到内容。当然，也可以直接完全新建一个新的pbix文件，省得来回改，直接做一个新的完事。
这里一定要提的一点是，在实操中，这个环节需要处理的任务还包括清洗脏数据——把数据先拉进BI看板看一眼是最容易发现脏数据的，什么空值啊，异常值啊，简简单单拉个图表出来最容易发现了。
作为数分狗，对工具的定位不要那么死，谁说BI工具就是拿来做看板展示的？数据可视化的目的是为了让我们更好地从数据中发现问题，而不是单纯的做个图为了好看。当我们用看板的方式来做数据的清洗和识别异常值，效率其实是非常高的，拖拉拽的方式或许粗暴，但是真的能发现问题。
页面调整
在上一步对数据的调整完毕后，页面变成了这样：
这样的数据呈现其实完全不会让人挖掘到什么隐含的内容在里面——什么都有，但是又好像什么都没有。不用着急，这里我讲一个我习惯的分析挖掘思路，不一定对，也不一定是一个“可以被复刻”的路径，但应该能够大家带来一些参考。
类似在Excel表中的“4sheet”法（我应该只在直播课中讲过这个方法，没有写过相关的文章，后续慢慢出），搭建一个分析式的看板也有固定的套路，类似小时候写作文，我们就叫做“总分总”法吧：
第一步把能有的数据都放在一起大致看一下数据的概况，根据实际情况进行调整（修改/清洗/补充）；然后根据不同的主题对数据进行单独的详细分析；最后把有关联的、能分析出结论的内容整理在单独的页面中。
第一个“总”其实已经做完了，那就是把手头有的数据一股脑地都堆在这里，看个大概，并对相关的数据做出调整/清洗或补充。
接下来就是“分”了，按照相关主题，制作单独的分析页面。在这个案例中，确定主题的拆分其实是非常容易的，因为有现成的模板给我去参考，这个模板就是：
哪有什么难度啊，现成的就是。只不过呢，对我而言只有内容分析和用户分析是值得去看的，后面几个对我来说没什么意义——本来就没有内容，无法分析。所以细分的分析页面已经确定了两个，内容分析和用户分析。除此之外呢，老粉都知道，我的内容都是周更的，所有对于合集内容对我而言也是一个要分析的地方。这么一来，三个主题就已经确认好了。我们来创建一下分析页面：
技术操作上来说其实没什么难度，和excel中新建sheet是完全一样的操作。就不细说了，没意思。
到了这一步，多少就讲究一点点颜值吧。对于一个分析型的面板来说，不求视觉效果有多么惊艳，不丑就行。什么叫不丑的设计，最简单的道理——该对齐的对齐，该一致的一致，整齐的就是美观的。对于整齐这一条，最简单实现方法就是全都用默认的，都是默认的，绝对整齐。然而PBI默认的这一套方案，确实不那么好看。而不好看的根源在于，这一套其实不符合一般情况下中国式图表的审美。
以这个图表来说，大家有没有一种总觉得哪里有问题，但是又说不上来哪里丑的感觉？那么我说这么几条大家想想：①中国人习惯于标题居中而不是靠左；②对于“显而易见”的坐标轴，我们不习惯有轴标题；③中式审美不习惯图表和背景色完全融合在一起；④中国人的图表标题习惯命名为XX情况而不是XX内容
基于上面几点，我们对图表进行微调，大家再感受一下：
对于图表的颜色之类的，大家可以在这个地方选择一个自己喜欢的配色方案。如果没有满意的配色方案，也可以选择去主题库里翻翻别人的模板，抄一下也行。
当然，如果公司有标准的配色方案的话，也是可以把公司标准的配色方案整理成json文件直接导入的。这种操作相对来说比较冷门，就不做介绍了。但是出于分析的角度来说，一般不建议大家在主题和配色上花费太多的精力，直接选一个自己觉得满意的配色方案就行了。这是分析数据，不是做视觉效果，能看得过去就行了，出结论远比好看重要！
这里直接来一个调整后的页面效果：
虽然和好看俩字不沾边，但是起码不丑吧，也能满足简单的探索分析需求吧。虽然这里其实有写两个简单的度量值，但绝大多数的呈现都是用了工具本身自带的默认功能，这些功能虽然不建议在给用户呈现的看板上用（对用户来说交互过去复杂，就一个年月日的上下钻取就能搞蒙大片用户），但是对于纯分析需求来说非常好用，比如这个平均值线：
这里我们可以很清晰的看到，日平均值是5个：
向上钻取之后就可以清楚的看到，月平均值是109个：
而启用深化模式点击8月之后就可以看到，8月的均值是7个：
而9月的均值是9个：
对于分析需求来说，这个功能简直太棒了，趋势一目了然，但是这个交互，对于没有BI基础的用户来说是极不友好的。直接用默认的这些东西，就坐等用户天天问问问题吧。
其他的三个页面都是类似的，就不做一一展示了。然而细心的朋友们或许发现了一个新的问题——这数据怎么才到9月8号的？因为我没刷新呀！
怎么解决这个问题呢？简单，直接点刷新就可以了！
至于数据库里的数据是怎么更新的，目前为止还是手动导入的。虽然自动导入库的办法也有无数个，但是现在还没开始做呢~
这周的内容量相对来说是比较多的。尽管我很努力地想把思路和技术在这里都讲明白了，但还是有一大块硬骨头完全没有讲，那就是dax。虽然一开始在设计这个系列的时候完全不想涉及任何和dax有关的内容，但是确实有不少人问我dax。
不出意外的话，这个系列下次和大家见面就是十一小长假之后了，下一期来讲讲dax相关的内容。