简介这套基于 Python 的微信公众号数据分析系统源码适合需要系统采集公众号文章数据、分析阅读量与点赞量趋势的开发者或运营人员。项目通过清博大数据 API 实现按关键词、公众号及日期范围检索覆盖最近 10 个月历史数据既可查看单个公众号的实时排名也可统计指定时段内的文章总数、阅读总数、点赞总数与预估粉丝数。用户登录验证、用户信息查询、用户名校验以及微信分组的添加/删除等配套功能使系统具备基本的账号权限与分组管理能力。压缩包共 1055 个文件以 1032 个 class 编译产物为主另有 6 个 Python 脚本及 JS、PHP、Java 等辅助源码配置方面包含 XML/YML、Properties 等文件并附 Markdown 说明文档整体仅 1.3MB便于快速部署学习。已有 332 人学习下载适合用于掌握第三方 API 对接、数据统计逻辑和 Web 系统开发实践。1. 一个公众号后台的“手抄统计表”就是这套系统要干掉的东西运营公众号的人应该都有过这种体验每周想看看哪篇文章涨粉多、哪个时间段发文打开率高只能去公众平台后台一个数字一个数字地抄再贴进 Excel 手工做透视表。这个标题给的是一套 Python 源码——基于 Python 的微信公众号数据分析系统核心不是爬站抓别人数据而是把你自己公众号后台的历史数据定时拉下来清洗入库然后自动算阅读趋势、粉丝净增、最佳发布时间最后生成图表和报告。新手拿过去能直接跑出第一张统计图有 Python 基础的人则能改采集口径、加自己的分析维度。这篇文章就照着“这是什么 → 怎么做 → 参数怎么调 → 坑在哪”的顺序把整套东西拆开讲透。2. 拆开这套公众号数据分析系统整体架构与数据获取路径拿到一个 zip 源码包第一件事不是急着跑 main.py而是看它把“数据获取、存储、分析、展示”这四件事分别放在哪。公众号数据分析系统看着复杂但绝大多数 Python 实现都逃不开一个固定骨架采集端负责登录公众平台后台并把数据导出成结构化记录存储端用 SQLite 或 MySQL 接住历史数据分析端用 Pandas 算指标最后再用 matplotlib 或 pyecharts 画图、python-docx 出报告。理解这个分层之后你会发现标题里的“系统”其实并没有多神秘不过是把这四个环节用 Python 串成了几个脚本。2.1 源码包里的常见骨架四个模块各自该干什么我见过很多类似的源码包目录结构五花八门但承担职责大差不差。一个清晰的公众号数据分析系统源码里至少要有这么几块collector采集端负责模拟登录微信公众平台调用后台的接口把文章列表、阅读量、粉丝数据拉回来。这一层最容易出问题因为公众平台随时可能改接口参数或加验证。storage存储端定义数据库表把采集到的数据去重后写入 SQLite。SQLite 的好处是零配置文件即库适合个人公众号的数据量。analyser分析端读库里的数据用 Pandas 做分组统计。常见分析项包括「7 天内阅读量变化曲线」「头条 vs 次条的打开率对比」「新增关注与取消关注的趋势」「最佳发文时段」。render展示端把分析结果转成图片或 Word 报告。对个人运营者来说一张保存到本地的柱状图比一个 Web 界面更实用因为不增加维护成本。拿到源码后我一般先按这四层去对号入座哪个目录负责什么一目了然。如果发现某个 zip 里所有代码都堆在一个文件里那说明作者没有做工程化这种“系统”改起来会非常痛苦——加一个指标可能要动到采集端的登录逻辑这不是你想要的代码结构。2.2 数据从哪来后台接口、手动导出两条路径怎么选这套系统的数据来源有两个层次先分清楚比写代码更重要。第一条路径是后台接口。微信公众平台的后台是网页应用所有表格数据都是通过 XHR 接口拉取的。只要登录态有效你的 Python 脚本可以直接请求后台的数据接口拿到 JSON 再解析。这里的难点是公众平台有滑动验证和扫码确认纯 requests 模拟很难一次通过。常见的做法有两种一种是 selenium 驱动浏览器完成扫码登录后把 cookie 和 token 保存下来给 requests 用另一种是直接在浏览器开发者工具里手动复制后端接口返回的 JSON存成文件后离线分析。后一种适合数据量小、不追求自动化的场景。第二条路径是后台导出 Excel。公众平台的“内容分析”和“用户分析”页面自带导出表格功能但导出的是 xlsx 文件。此时脚本的定位不是“采集”而是“读文件 清洗入库”。对新手来说这条路最稳妥因为不涉及登录态、验证码这些玄学问题跑通概率接近百分之百。标题里的系统若带导出解析模块通常也是围绕这两条路径写的。表格化对比一下更直观路径自动化程度难度适合场景requests 模拟接口高可定时跑高需处理验证码与 token做长期趋势监控selenium cookie 注入高但需本机有浏览器中兼顾自动化与稳定性手动导出 xlsx 再解析低人工介入低每周/每月分析一次我给第一次跑源码的人的建议是先走手动导出路线把分析逻辑跑通确认指标算得对再回头搞自动登录。否则一上来就卡在验证码上脚本没跑起来分析功能再强也看不到效果。这个顺序能帮你把“数据分析”和“抓取”两个难点分开解决入门体验会舒服很多。2.3 建库与同步SQLite 里的三张核心表怎么设计不管数据来自接口还是 Excel最后都要落进数据库。公众号数据分析系统里最常用的库是 SQLite因为一个 .db 文件就能装下你几年的文章数据不需要额外安装数据库服务。建表逻辑我一般这样设计第一张表存文章基础信息字段包括 article_id文章唯一标识、title、publish_time、read_num、like_num、comment_num。其中 article_id 要从链接里解析不能用自增 ID否则更新数据时会重复插入。第二张表存粉丝变化记录字段包括 date、new_follow、cancel_follow、total_follow。第三张表存采集日志记录每次同步的起止时间、成功条数方便排查定时任务为什么没跑。下面是一段在 Python 源码里非常常见的建表逻辑import sqlite3 conn sqlite3.connect(wechat_analysis.db) cur conn.cursor() cur.execute( CREATE TABLE IF NOT EXISTS article_stats ( article_id TEXT PRIMARY KEY, title TEXT, publish_time TEXT, read_num INTEGER DEFAULT 0, like_num INTEGER DEFAULT 0, comment_num INTEGER DEFAULT 0, update_time TEXT ) ) cur.execute( CREATE TABLE IF NOT EXISTS follower_daily ( date TEXT PRIMARY KEY, new_follow INTEGER DEFAULT 0, cancel_follow INTEGER DEFAULT 0, total_follow INTEGER DEFAULT 0 ) ) conn.commit() conn.close()建表的关键点在两个地方一是 article_id 设为主键意味着同一篇文章重复采集时不会产生两行脏数据方向对了二是 follower_daily 用 date 做主键一天只保留一条粉丝记录。这样后面的分析代码里做 group by 时天然不会因为重复数据导致曲线出现毛刺。update_time 字段是我建议保留的因为阅读量不是一次性定死的文章发出 24 小时内数字会明显上涨有 update_time 才能做“最后一次更新是什么时候”的追溯。数据同步逻辑则简单得多拉回来的文章列表逐条执行 INSERT OR REPLACE即主键存在就更新不存在就插入。这样每次同步都是一次幂等操作不会因为中途断开产生半截数据。3. 从“每天盯着阅读量”到“看明白什么值得写”核心分析维度拆解把数据采回来、存进库只是这套系统的地基。真正让公众号数据分析系统值回票价的是分析层——它要把后台那些冰冷的计数器变成能指导选题和运营决策的结论。以下三个分析维度是我认为源码里最应该有的缺了任何一个这套系统都只能算“报表工具”算不上“分析系统”。3.1 内容热度分析阅读曲线、衰减率与头条效果阅读量不是一个静止数字。一篇文章发出后 1 小时、12 小时、48 小时的数据变化能反映出用户打开习惯和转发节奏。所以分析层第一件事是算“阅读生命周期曲线”把每篇文章的阅读量按时间拉出来。这里我常用的一种处理是把发布时间换算成“发布后第几小时”然后按小时聚合平均阅读量。代码逻辑不复杂但效果非常直观import pandas as pd df pd.read_sql_query(SELECT publish_time, read_num FROM article_stats, conn) df[publish_time] pd.to_datetime(df[publish_time]) now pd.Timestamp.now() # 计算每篇文章发布至今的小时数用于归一化对比 df[age_hours] (now - df[publish_time]).dt.total_seconds() / 3600 df[read_per_hour] df[read_num] / df[age_hours] # 只看发布超过 72 小时的文章排除还在涨的“进行时”数据 mature df[df[age_hours] 72].copy() mature[publish_hour] mature[publish_time].dt.hour # 按小时分组看哪个时段发出的文章最终平均阅读量最高 hourly mature.groupby(publish_hour)[read_num].mean().sort_values(ascendingFalse) print(hourly.head(5))这段代码里最容易调错的参数是 age_hours 的阈值。72 小时是我个人常用的一个值因为公众号文章的热度在 3 天后基本稳定再往后增长很有限。如果你的公众号是垂直领域用户看到文章的时间可能更晚可以把阈值放宽到 168 小时一整周。算清楚这个参数你得到的最佳发布时间才有参考意义。头条和次条的对比也是内容分析的重点。很多公众号存在“头条打开率高、次条没人看”的现象。分析时只需要给 article_stats 表加一列 position标记头条和次条然后按日聚合对比即可。如果源码里没有这一层自己加也非常简单不影响其他逻辑。3.2 粉丝增长归因新增关注从哪来、取关在什么时间点爆发粉丝数是最容易让人焦虑的指标也最容易被误读。今天的净增是 50看起来很美好但如果新增是 80、取关是 30和新增 50、取关 0 是完完全全两种运营状态。源码系统里对这块的常规处理是分两拆来源分析和流失时间点分析。来源分析依赖公众平台后台“用户增长”页面导出的来源类型——公众号搜索、扫二维码、图文内链接、名片分享等。落到数据库里就是 follower_daily 表加一列 source 字段。有了来源字段后你就能回答“最近涨粉是靠哪篇文章带来的”。这里的坑是公众平台的来源统计只保留最近一段时间过期数据拿不到所以同步频率最好是每日一次不要攒一个月再批量导。取关时间点分析则需要结合文章发布时间看。我见过最典型的一类问题每周五发行业干货周六取关数就峰起。不看数据时完全不会意识到这两件事相关。实现上可以把取关数据按星期几聚合再和发文时间表做对齐就能看出“每次发完某类文章的第二天取关比例是否显著上升”。这类分析不需要复杂的算法Pandas 的 groupby 加个 merge 就能完成但非常见源码里未必给全尤其是取关按星期几聚合这种视角通常需要自己写。3.3 内容关键词偏好从标题里挖用户真正买单的话题标题是公众号数据分析系统里最容易做、也最容易被跳过的一个分析维度。把文章标题切词统计高频词再和高阅读量文章做交叉对比很快就能看出你的用户喜欢什么类型的选题词。这里我推荐直接对标题做 jieba 分词然后按词频排序。更进一步的做法是计算每个词对应的文章平均阅读量这样比单纯看词频更有价值——某个词出现很多次可能只说明你爱写并不能说明用户爱看。import jieba from collections import defaultdict titles df[title].tolist() word_read defaultdict(list) for title, read_num in zip(titles, df[read_num]): for word in jieba.cut(title): # 过滤单字词和纯标点避免分词结果太碎 if len(word) 2 and not word.isspace(): word_read[word].append(read_num) word_avg {word: sum(vals) / len(vals) for word, vals in word_read.items()} top_words sorted(word_avg.items(), keylambda x: x[1], reverseTrue)[:20]这段代码输出的不是词频榜而是“平均阅读量榜”。你会发现有些热搜词频率很高但平均阅读量一般那说明你已经过度消费这类选题了用户的打开意愿在下降相反低频但高阅读的词才是值得继续深挖的方向。注意分词的时候去掉单字词否则“的”“了”这类字会占着位置干扰结果。4. 让分析结果变成能直接汇报的东西可视化与自动化报告数据分析系统跑到第三步库里有数据、分析脚本能输出指标但如果你还要靠复制粘贴这些数字去做周报这套系统的价值就打折了一半。所以完整源码里一定会包含可视化模块和报告生成模块——分析结果要能直接变成图片和 Word 文档而无需在 Excel 里重新排版。4.1 折线图和柱状图怎么选matplotlib 打底pyecharts 补交互图表库的选择因人而异但公众号数据分析场景有个规律需要放进报告里的静态图用 matplotlib需要发到群里让人点着看的交互图用 pyecharts。matplotlib 的优点是到处都能跑输出 PNG 图片后可以直接插进 Word 或飞书文档缺点是不支持交互pyecharts 基于 ECharts生成的 HTML 图表可以缩放、悬停看数值适合做数据分析看板但部署和依赖相对重。阅读趋势这种时间序列图matplotlib 几行就能画出不错的效果import matplotlib.pyplot as plt # 按日聚合总阅读量 daily article_df.groupby(article_df[publish_time].dt.date)[read_num].sum() plt.figure(figsize(10, 4)) plt.plot(daily.index, daily.values, markero, linewidth1.5) plt.title(Daily Total Read Volume) plt.xlabel(Date) plt.ylabel(Reads) # 保存为高分辨率图片后续插入 Word 报告 plt.savefig(daily_reads.png, dpi200, bbox_inchestight)这里的 dpi 参数值得专门提一下。如果你只是本地看一眼dpi 100 就够但最终要插进周报或发给老板看dpi 建议至少 200否则图片放大后会明显发虚。bbox_inchestight 的作用是裁掉图周围的空白边距避免存出来的图四周留白太多。这两处都是新手最容易忽略但效果立竿见影的参数。4.2 一键生成 Word 周报python-docx 把图表和分析结论装进同一个文件标题相关热搜里经常出现“保存 word”这个需求可见把分析结果输出成 Word 是很多人都想要的。用 python-docx 组装一份周报难度不高但要注意文档结构的设计先给结论再放图表最后挂数据明细。运营者看周报不是看数据是看“下周该做什么”这个顺序决定了报告的可读性。from docx import Document from docx.shared import Inches doc Document() doc.add_heading(公众号周报, level0) doc.add_heading(核心结论, level1) doc.add_paragraph(本周最佳发布时间集中在 21:00 前后头条平均阅读量较上周提升 12%。) doc.add_paragraph(建议下周将干货类内容调整至工作日晚上发布并减少周末早间推送。) doc.add_heading(阅读趋势, level1) doc.add_picture(daily_reads.png, widthInches(5.5)) doc.save(weekly_report.docx)这段代码是报告模块的骨架实际源码里通常还会加表格、多章节、样式定制。但核心动作只有两个add_picture 插图表、add_paragraph 插结论。我自己用这招最顺手的地方在于分析结论是 Python 算出来之后直接拼进字符串的也就是说每次跑出来的报告内容会随着数据变化而变化而不是手动写好一句万金油文案。做到这一点报告的自动化才是完整的。4.3 定时任务让脚本每天自己跑一次定时执行是系统从“能用”到“好用”的分水岭。源码包里通常会有 run.py 或 main.py 作为入口配合 Windows 任务计划程序或 Linux cron就能做到每天凌晨自动同步数据、早上自动生成报告。Windows 上的任务计划程序是普通运营者最常接触的配置上有个细节特别容易翻车触发器默认只在用户登录时才运行但很多人设置了“每天凌晨 1 点”发现不执行就是因为电脑在那个时间点处于锁屏或睡眠状态。解决方法是把任务计划程序的触发器设置为“不管用户是否登录都运行”并且取消“只有在计算机使用交流电源时才启动此任务”之类的省电相关勾选项。另外脚本逻辑里要保证采集失败时能自动重试否则某天网络抖动就会留下一整天的数据空洞。5. 运行这套系统常见的五个坑现象、原因与解决任何公众号数据分析系统源代码本身往往不是最大的门槛跑起来之后遇到的环境问题才是。下面这五个坑是我反复踩过、也看别人反复踩的每一条都按“现象 → 原因 → 解决”的方式写清楚希望能省下你去搜索引擎里大海捞针的时间。5.1 下载的 Excel 打开后中文乱码现象用 Pandas 读取公众平台导出的 xlsx 文件时一切正常但用 Excel 打开另存后的 CSV 文件中文全是乱码。原因Pandas 默认用 UTF-8 编码写 CSV而 Windows 版 Excel 默认用 GBK 解析。UTF-8 编码的文件在 GBK 解码下必然乱码。解决在 to_csv 时显式指定编码为encodingutf-8-sig。这个编码会在文件开头写入 BOM 标记Excel 识别到 BOM 后就会用 UTF-8 去解码。注意不是utf-8而是utf-8-sig。df.to_csv(article_stats.csv, indexFalse, encodingutf-8-sig)5.2 阅读量全是 0误以为采集失败现象采集脚本正常跑完数据库里也有文章记录但 read_num 字段全部是 0。原因公众号后台对一小部分低阅读量文章做了“隐藏”处理接口返回的阅读量就是 0不是你的解析逻辑写错了。解决采集时把接口返回的原始 JSON 完整存到一张 raw_data 表里而不是只存解析后的字段。哪天发现数据异常能翻原始报文排查不至于对着数据库猜问题。同时在采集逻辑里加一个读取状态判断如果大量文章阅读量都是 0大概率是接口逻辑变了而不是文章真的没人看。5.3 定时任务不执行或执行两遍现象任务计划程序设置了每天凌晨 1 点运行结果连续几天没产出报告有时候又一天产出两份。原因不执行通常是因为电脑休眠或任务配置里勾了“仅在用户登录时运行”执行两遍是因为上一次运行还没结束下一次触发时间就到了两个进程同时跑都在写同一个数据库。解决给脚本加一个单实例锁用文件锁或数据库锁均可同时把任务计划程序的“如果任务正在运行则不启动新实例”改成默认或“停止现有实例”。临时排查时可以看任务计划程序的“上次运行结果”代码0x0 代表成功其他代码需要查表对应。5.4 登录态失效导致批量导出抓到登录页现象某天采集脚本突然返回大量 HTML 而不是 JSON解析报错数据库里充满了垃圾记录。原因公众平台登录态有一定的有效期过期后接口请求会被重定向到登录页而脚本还在按正常逻辑解析返回内容。解决在每个接口请求后加一个状态校验检测返回内容里是否有“登录”关键词或重定向响应头一旦命中立刻暂停任务并发送通知。不要用“捕获异常后继续跑”的策略因为这种情况下异常往往不会抛出而是静默产生脏数据。5.5 文章数据对不上翻页与 offset 的细节现象数据库里的文章总数比公众平台后台看到的文章数少一截而且总是缺中间一段。原因后台文章列表接口是分页加载的每次请求最多返回 20 条翻页参数通常是 offset 或 page。如果翻页逻辑只在当前页数据量为 0 时结束而某页数据量恰好不满 20 条就可能少翻一页。解决翻页的终止条件应该是“返回列表为空”而不是“返回条数小于每页条数”。同时写一个翻页 debug 模式打印每次请求的 page、offset、返回条数跑一次就能确认翻页边界在哪里。6. 从跑通到用起来给自己定三个关键指标源码能跑通只是这套系统价值的开始。真正让它对你有用是要从中提炼出几个能指导行动的指标。我自己的做法是不过度追求指标数量只盯三个头条转化率、发布时间稳定性、取关与内容的关联性。头条转化率是指头条文章的阅读量除以公众号粉丝数。这个数字能反映标题和内容对订阅用户的吸引力。看它的波峰波谷你会比看绝对值更能捕捉到用户口味的变化。发布时间稳定性则是看每周是否在固定时间点发文用户会形成阅读习惯时间戳的规律性往往比具体发哪个时段更重要因为“雷打不动”本身就是一种读者期望管理。取关与内容的关联性则需要把第 3 章的做法用起来每次取关数据出现脉冲时回去看看前一天发了什么几次之后就能找到规律。另外一个很实用的进阶做法是把脚本采集的维度扩展到历史文章的评论内容。评论是用户主动表达的信号比阅读量的被动统计更有价值。把评论按情绪极性拆分正面评论多的选题方向保留负面评论多的及时调整。这个功能不需要改架构只需要在 collector 模块加一个评论采集函数库里加一张 comment 表分析模块里做一次简单的极性判断即可。等你把这套流程跑顺你会发现自己已经不再每天焦虑打开率而是每周固定看一眼报告然后针对性地调整下周内容和时间安排。这大概就是数据分析系统比“看后台”真正多出来的那点价值——把感觉变成判断。希望帮到你。本文还有配套的精品资源点击获取