简介面向微信公众号运营与数据分析场景此zip代码包提供一套基于Python的公众号数据分析系统通过调用清博大数据API获取文章数据。系统支持按关键词、公众号名称和日期范围检索可获取标题、摘要、阅读量、点赞量等指标并能统计指定公众号的文章总数、阅读总数、点赞总数及预估粉丝数同时包含用户登录验证与微信分组管理功能。压缩包内共含1055个文件包体大小约1.3MB主体为1032个class字节码文件辅以6个Python脚本、3个JavaScript文件及XML/YML/Markdown等配置与说明文档适合有一定Python基础、希望了解外部API对接与数据统计实现的学习者参考。当前已有332人学习下载。通过阅读源码与配置可了解公众号数据从API请求、解析到统计展示的完整链路并掌握用户与分组模块的常见实现方式。1. 微信公众号数据分析系统到底在分析什么做公众号运营的人都有这个体验每天打开后台看一眼阅读量看到涨了就安心跌了就焦虑但真要问“哪类文章跑得好、为什么好、下个月该写什么”后台那几张报表根本答不上来。后台给的是结果不是归因。这套基于 Python 的微信公众号数据分析系统干的事就是把公众号的历史文章、阅读表现、标题和正文文本全部抓下来落进本地数据库再用 pandas 和文本分析手段做交叉统计——你会发现“晚上 9 点发的教程类比下午 3 点发的行业新闻平均阅读高 40%”这种原来只能靠感觉的结论变成了一张张可以照着排期的报表。适合三类人自己运营公众号、需要定期做竞品分析的新媒体团队以及想用一个完整小项目把 Python 数据分析链路串起来的开发者。2. 系统选型与架构Python 源码工程为什么这么拆2.1 技术选型为什么是 Python SQLite而不是爬虫框架朋友圈里聊起公众号数据分析第一反应往往是 Scrapy 或者 Node.js。Scrapy 确实是个成熟的爬虫框架但对于这个场景我基本不推荐。公众号的数据量级哪怕你分析一百个公众号、每个号存三年文章也就是几万条记录Scrapy 的异步调度、中间件、Pipeline 在这里全是多余的结构调试起来反而多一层负担。Node.js 配 cheerio 做抓取很顺手但到了统计阶段你会发现数据处理生态跟 pandas 完全没法比。这个系统的核心工作量在后端的清洗与分析不是在前端的抓取并发量。Python 这边选型很固定requests 负责 HTTP 请求BeautifulSoup 做 HTML 解析pandas 做聚合统计jieba 做中文分词SQLite 做存储。SQLite 单独说一下很多人在项目一开始就上 MySQL对个人运营场景来说这是过度设计。SQLite 单文件、零配置、支持标准 SQL几万条数据做 GROUP BY 也就是毫秒级而且整个数据库就是一个.db文件备份、迁移、共享都极其省事。等到哪天数据量大到 SQLite 扛不住——那说明你已经做大了到时候再迁 MySQL成本也就一个导出导入。pip install requests beautifulsoup4 pandas jieba pyecharts这六个库覆盖了从抓取到可视化全链路。如果你用的是 Linux 服务器注意 Python 版本至少 3.8pandas 2.x 对 3.7 及以下版本已经不再支持。本地开发建议直接用 venv 隔离环境别往系统 Python 里塞包——这是我在生产服务器上踩过的坑系统 Python 被搞乱之后yum 和系统脚本都会遭殃。2.2 模块划分与数据流采集、清洗、存储、分析、展示整个系统的数据流是一条直线但每一段之间我都刻意做了解耦。采集模块只负责把原始 HTML 和 JSON 抓下来存成两种东西原文快照和解析后的结构化记录。清洗模块把正文里的标签、脚本、样式剥掉得到纯文本。分析模块读结构化数据产出统计报表和中间结果。展示模块负责把结果变成图表。解耦的意义在于微信端的页面结构经常调整抓取逻辑需要频繁修但只要清洗和分析的输入输出格式不变修采集不影响下游。模块职责关键依赖产物collector抓取文章列表与正文 HTMLrequestsraw_html 表 article 表cleaner正文清洗、去重、字段规整BeautifulSoupclean_article 表analyzer传播趋势、爆款归因、文本挖掘pandas, jiebastats 表 CSV 文件reporter可视化报表与日报生成pyechartsHTML 报表这里有一个容易被新手忽略的设计点为什么要单独存一份 raw_html因为微信正文的很多信息——比如封面图、原文链接、阅读原文跳转地址——在清洗后会被丢掉而分析阶段可能临时需要新的字段。如果你只存清洗后的文本到时候想提取封面图就得重新抓一遍甚至原文已经被删了就彻底没了。存一份原始快照相当于给数据上了后悔药磁盘多占几百 MB 完全值得。数据表的设计也按这个思路拆。article 表是主表字段包括 msg_id消息 ID微信针对每篇文章生成的唯一标识、biz公众号唯一标识、title、digest、cover_img_url、publish_time、reading_num、like_num、content_text。raw_html 表则不做任何结构化处理就存抓回来的 HTML 原文和 URL。两个表通过 msg_id 关联。把这层结构定下来后面所有分析逻辑都在 clean_article 上做永远不需要回看原始 HTML。2.3 工程骨架一个能跑的目录结构和环境准备一个清晰的目录结构能让你三个月后回来看代码时少叹气。我一般按功能拆目录而不是按爬虫惯例拆 spider/middleware/pipeline。公众号数据分析的场景简单直接按数据流拆最直观。wechat_analysis/ ├── config.py # 全局配置数据库路径、请求头、延时参数 ├── database.py # SQLite 连接与建表语句 ├── collector/ │ ├── __init__.py │ ├── article_list.py # 抓取文章列表 │ └── article_detail.py # 抓取正文详情 ├── cleaner/ │ ├── __init__.py │ └── content_cleaner.py # 正文清洗 ├── analyzer/ │ ├── __init__.py │ ├── trend.py # 传播趋势分析 │ ├── attribution.py # 爆款归因分析 │ └── text_mining.py # 文本挖掘 ├── reporter/ │ ├── __init__.py │ └── charts.py # 图表生成 └── main.py # 主入口串联全流程config.py 是整个系统里最值得花时间的文件。请求头必须伪装成真实浏览器的 User-Agent否则微信的接口很快会识别出你是脚本。延时参数请求间隔是硬性的风控防线抓详情页的时候每篇间隔 2 到 5 秒随机化这个区间不能省。database.py 里有一件必须做的事给 msg_id 加 UNIQUE 约束。微信后台的文章列表接口在翻页时会出现重复数据而且同一篇文章可能在多个列表里出现如果数据库层面不加唯一索引后续去重会麻烦得多。建表时直接写死唯一索引等于在最底层把重复数据的口子堵住。3. 数据采集用 Python 把公众号历史文章捞回来3.1 采集入口选择自己账号和竞品账号走两条路公众号文章的采集入口很多人第一反应是搜狗微信搜索但这个入口在最近两年基本已经废了——搜索结果的动态加载和频繁验证码让自动化变得极不可靠。实际可用的是两条路分场景选。自己的公众号走公众平台后台的素材管理接口。登录 mp.weixin.qq.com 之后后台有一个「超链接」功能编辑图文消息时插入超链接可以搜索到全网公众号的历史文章前端会调用一个cgi-bin/appmsgpublish的接口返回 JSON 格式的文章列表。这个接口需要登录后的 cookie 和 token但它是微信官方自己的前端接口数据干净、结构稳定而且不需要处理任何加密参数是所有方案里最省心的。竞品账号的情况麻烦一些。微信没有开放的公众号文章查询 API对竞品号的数据获取目前常见的做法是通过公众号主页的profile?key...页面拿到__biz参数再调用appmsg接口逐篇拉取。这个方案能跑但有两个前提一是你需要有一个能正常访问微信文章的 cookie二是单账号的访问频率必须控制得很低。我不建议在这个方向上花太多精力更合理的做法是拿自己的号把系统跑通分析思路验证有价值之后再谨慎扩展到竞品。# collector/article_list.py import requests import json import time import random def fetch_article_list(cookie, token, biz, offset0, count10): url https://mp.weixin.qq.com/cgi-bin/appmsgpublish params { sub: list, search_field: null, begin: str(offset), count: str(count), query: , token: token, lang: zh_CN, f: json, ajax: 1, biz: biz, } headers { Cookie: cookie, User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://mp.weixin.qq.com/, } resp requests.get(url, paramsparams, headersheaders, timeout15) data resp.json() if data.get(publish_page) is None: raise ValueError(接口返回异常检查 cookie/token 是否过期) return data这段代码的核心在params里的两个参数begin是分页偏移count是每页数量。公众平台接口的单页上限是 10你传 20 也只会返回 10 条所以分页循环里每次固定步长 10。biz参数是公众号的唯一 ID从公众号主页 URL 里的__biz字段拿形如MzIxMjEwNTY3NQ是一段 Base64 编码的字符串。token则是登录后台后从页面里取到的动态令牌会过期长时间运行必须做自动续期——最简单的方法是定期手动更新 cookie 和 token写死在配置文件里跑批前检查一下有效期。3.2 文章列表与详情分离先拿到元数据再按需抓正文列表接口拿到的数据结构里每篇文章只包含标题、摘要、封面图、发布时间和msg_id不包含正文字段。抓取策略上我强烈建议先全量取列表把文章的元数据落库正文抓取单独走一个队列。这样可以避免一次请求里既拿列表又拿正文导致的超时和风控问题也能在正文抓取失败时单独重试不影响已经拿到的元数据。# collector/article_list.py def save_article_list(data, db): items data[publish_page][publish_list] for item in items: for article in item.get(article_list, []): record { msg_id: article[msg_id], biz: article[biz], title: article[title], digest: article.get(digest, ), cover_img_url: article.get(cover, ), publish_time: article[update_time], url: article[url], } db.execute( INSERT OR IGNORE INTO article (msg_id, biz, title, digest, cover_img_url, publish_time, url) VALUES (:msg_id, :biz, :title, :digest, :cover_img_url, :publish_time, :url), record, )INSERT OR IGNORE是这段代码最重要的细节配合数据库层面对msg_id的唯一索引重复翻页不会产生重复数据。publish_time存的是 Unix 时间戳不要在采集阶段就转成字符串——时间格式化放在分析阶段做避免时区混乱。把 URL 存下来也很重要后续如果需要补抓正文直接用这个 URL 发起请求不需要再回列表接口查找。正文抓取的逻辑更简单携带同一个 cookie 请求文章 URL返回的 HTML 里直接包含正文。但这里有一个值得一提的坑——公众号正文页的 HTML 结构里正文内容在一个idjs_content的 div 里而页面其他部分还包含评论区、推荐阅读、公众号名片等模块必须精确限定解析范围。# collector/article_detail.py def fetch_article_content(url, cookie): headers { Cookie: cookie, User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0, } resp requests.get(url, headersheaders, timeout15) resp.encoding utf-8 return resp.text # cleaner/content_cleaner.py from bs4 import BeautifulSoup def parse_content(html): soup BeautifulSoup(html, html.parser) content_div soup.find(div, idjs_content) if content_div is None: return None, [] # 正文里的图片># analyzer/trend.py import pandas as pd def weekly_trend(clean_df): df clean_df.copy() df[publish_time] pd.to_datetime(df[publish_time], units) df[week] df[publish_time].dt.to_period(W) weekly df.groupby(week).agg( article_count(msg_id, count), avg_reading(reading_num, mean), median_reading(reading_num, median), total_likes(like_num, sum), ).reset_index() weekly[week_start] weekly[week].dt.start_time return weeklydt.to_period(W)是 pandas 里按周聚合的经典写法它会返回一个Period对象后续可以直接用start_time拿到每周的开始日期。聚合指标里我同时算了均值和中位数这是因为公众号阅读量的分布极其偏斜——一篇爆款文章的阅读可能是日常的十倍均值会被拉高中位数更能反映常规表现。如果你发现均值和中位数的差距在扩大说明账号的内容方差变大爆款不稳定这本身就是一个值得关注的风险信号。这些聚合结果可以直接落库到一个weekly_stats表用于后续的报表展示。注意时间字段统一转成 datetime 类型再入库SQLite 原生不认识 pandas 的 Period 对象。4.2 爆款文章归因标题长度、发布时间和关键词归因分析是这个系统最有价值的部分。做法是把文章按阅读量分成几档比如前 10% 定义为爆款然后对比爆款组和非爆款组在不同维度上的差异。以下代码实现标题长度与发布时间的分布对比。# analyzer/attribution.py def hit_analysis(clean_df): df clean_df.copy() df[is_hit] df[reading_num] df[reading_num].quantile(0.9) df[title_len] df[title].str.len() df[hour] pd.to_datetime(df[publish_time], units).dt.hour print( 标题长度对比 ) print(df.groupby(is_hit)[title_len].agg([mean, median])) print(\n 发布时段对比 ) cross pd.crosstab(df[hour], df[is_hit], normalizecolumns) print(cross) print(\n 关键词对比 ) hit_titles .join(df[df[is_hit]][title]) normal_titles .join(df[~df[is_hit]][title]) return hit_titles, normal_titlesquantile(0.9)直接取阅读量的 90 分位数作为爆款线比固定阈值更合理——不同体量的号爆款标准完全不同用分位数天然适配账号自身的成长阶段。crosstab生成的是一个小时维度的条件分布表每一列加起来是 100%横向对比就能看出来爆款文章更集中在哪个时段发布。这套分析跑完之后你得到的是一份可以参考的选题排期建议而不是事后诸葛亮的报告。我见过有团队拿这个分析结果反过来指导编辑标题控制在 18 到 24 字之间、正文配图不少于 5 张、发布时间固定在晚上 8 点到 10 点。这就是归因分析真正的落地方式。4.3 文本挖掘jieba 分词找主题标签标题和正文的文本挖掘用 jieba 分词加 TF-IDF 提取关键词就够了。正文按段落分词然后合并每篇文章的关键词可以做一个简单的主题画像。# analyzer/text_mining.py import jieba import jieba.analyse def extract_tags(text, top_k10): # 基于 TF-IDF 算法的关键词提取 tags jieba.analyse.extract_tags( text, topKtop_k, withWeightTrue, allowPOS(ns, n, vn, v, nz), ) return tags def batch_keywords(clean_df): results [] for _, row in clean_df.iterrows(): tags extract_tags(row[content_text], top_k10) results.append({ msg_id: row[msg_id], title: row[title], keywords: [t[0] for t in tags], }) return pd.DataFrame(results)allowPOS是 jieba.analyse 里容易被忽视但非常关键的参数。它限定了参与关键词提取的词性只保留地名、名词、动名词、动词和专有名词把「的」「了」「我们」这类无意义的词直接过滤掉。不设这个参数的话提取出来的关键词里会混入大量虚词主题画像就废了。withWeightTrue返回权重值表示该词在这篇文章里的 TF-IDF 得分可以用它做后续的标签云权重。文本挖掘的方向可以延伸把每篇文章的 Top 关键词存下来再统计关键词出现的频率就能看出这个账号长期在写哪些主题。更进一步选取高频关键词做共现矩阵可以看出主题之间的关联——比如「Python」和「爬虫」经常出现在同一篇文章里这在做选题规划时是有参考价值的。5. 避坑指南公众号数据分析系统最容易翻车的 5 个场景5.1 唯一索引没建统计数据翻倍现象跑完报表发现文章总数是后台显示数量的将近两倍单篇阅读量的总和也对不上。原因公众号后台的列表接口在翻页时存在大量重复记录。一篇文章既可能出现在「已群发」列表里也可能出现在素材列表里msg_id相同但其他字段略有差异。如果建表时没加唯一索引重复数据就长驱直入库中后续所有聚合统计全被带偏。解决建表语句里给msg_id加UNIQUE约束写入时用INSERT OR IGNORE。已经混入的重复数据执行一次去重清理DELETE FROM article WHERE rowid NOT IN ( SELECT MIN(rowid) FROM article GROUP BY msg_id );这条 SQL 按msg_id分组保留最小 rowid其余的全删。注意先备份再执行。数据库层面的约束是最后一道防线采集端也要做一层判断——同一轮任务里维护一个已处理 msg_id 的内存集合双保险。5.2 阅读量和点赞数全是 0接口返回空值现象文章数据和正文都抓到了但reading_num和like_num字段全是 0爆款归因分析直接失去意义。原因公众号文章列表接口返回的 JSON 里阅读量和点赞数不是稳定字段。已群发的文章会在appmsgpublish接口里返回但部分历史文章尤其是通过旧版接口发布的压根不带这两个字段。另外点赞数在微信里改版成「在看」之后接口字段名也变过。解决把reading_num和like_num的缺失值统一填充为None而不是 0分析阶段再决定是剔除还是用中位数填充。粗暴填 0 的结果是把所有缺失样本归入低阅读档爆款阈值被拉低整个归因分析失真。正确做法是df[reading_num] df[reading_num].replace(0, pd.NA) df df.dropna(subset[reading_num])如果缺失比例超过 20%建议检查是不是列表接口选错了。素材列表接口和已发布列表接口返回的字段覆盖范围不同优先用appmsgpublish接口它的字段最全。5.3 正文清洗后段落全挤在一起现象get_text()拿到的正文没有段落分隔一句话里混着多个原本独立的段落分词和关键词提取的结果带上了一层噪声。原因get_text()的默认行为是不保留原始 HTML 的换行结构。公众号正文的段落是p标签get_text()不会自动给段落之间加分隔符所有p里的文字被直接拼接。解决使用separator参数并且针对p和br/分别处理text content_div.get_text(separator\n, stripTrue)separator\n会在每一个标签边界处插入换行符。段落间距会变成正常的阅读格式后续的 jieba 分词也能正确识别句子边界。如果发现某些正文里\n过多还可以在清洗阶段把连续三个以上的换行符合并成一个。5.4 发布时间时区错位周一的数据永远比实际少现象按星期聚合之后周一发布的数据明显少于其他日子而周日的偏多。原因公众号后台展示的时间是北京时间而接口返回的update_time是 Unix 时间戳本身没有时区属性。如果你的服务器设置了 UTC 时区直接用datetime.fromtimestamp()转换得到的是 UTC 时间和北京时间差了 8 小时——北京周一凌晨发布的一篇文章在 UTC 时间还是周日。解决分析代码里统一指定时区再格式化from datetime import datetime, timezone, timedelta beijing_tz timezone(timedelta(hours8)) df[publish_dt] pd.to_datetime(df[publish_time], units, utcTrue) df[publish_dt] df[publish_dt].dt.tz_convert(beijing_tz)存储层面建议统一存 Unix 时间戳分析时再转换。这样即使换服务器、换时区原始数据不会产生歧义。这是做时间序列分析最容易踩的坑也是最难发现的——数据确实没丢只是看起来缺了。5.5 任务中断后从零开始浪费时间还容易触发风控现象抓了 300 篇文章程序因为网络超时或 Cookie 过期中断重启后又从头开始抓浪费时间不说重复请求还加重了被风控的概率。原因抓取任务没有做断点续传设计。采集循环里拿到的offset只存在于内存中程序一重启就丢失。解决在任务表里记录已抓取的 msg_id 集合done_ids set(db.query(SELECT msg_id FROM article WHERE msg_id IS NOT NULL)) # 列表遍历时跳过已存在的记录 for item in publish_list: if item[msg_id] in done_ids: continue process(item)原理是每次都从数据库里已有的 msg_id 构建一个集合跳过的部分自然不需要重新请求。这样重启之后程序能自动从上次的断点续跑。加上前面提到的随机延时整个采集任务可以在无人值守的情况下挂机跑完。6. 从数据到报表把分析结果变成一张能看的图6.1 用 pyecharts 生成趋势图和词云分析做完了最终要给运营看结果。pyecharts 是目前最顺手的 Python 可视化库生成的 HTML 可以在浏览器直接打开不需要装任何其他东西。核心代码逻辑如下# reporter/charts.py from pyecharts.charts import Line, Bar from pyecharts import options as opts def render_weekly_trend(weekly_df, output_pathreport.html): line Line() line.add_xaxis(weekly_df[week_start].astype(str).tolist()) line.add_yaxis( 平均阅读量, weekly_df[avg_reading].round(0).tolist(), is_smoothTrue, ) line.set_global_opts( title_optsopts.TitleOpts(title公众号周度阅读趋势), yaxis_optsopts.AxisOpts(name阅读量), ) line.render(output_path)render会生成一个独立的 HTML 文件包含渲染好的图表。多个图表可以直接串联成一个 HTML 报表尤其是那些需要长期追踪的指标。pyecharts 默认的渲染机制保证了图表是矢量输出放大不模糊在运营周报里直接截图就能用。6.2 进阶方向把文章标题与关键词对接知识库还有一个值得做的扩展把清洗后的正文文章转成 Markdown 格式接入你日常使用的知识库工具。公众号文章散落在后台通过这套系统把历史文章清洗成干净的文本后可以按「标题 发布时间 关键词 正文」的结构导出让沉淀的内容变成可检索的资产。这也是我最近在推进的方向——公众号文章和知识库打通之后选题查资料不用再翻聊天记录和历史消息直接检索本地库就能找到相关文章。做这套系统最深的体会是数据的价值不在于你存了多少而在于你能不能把「感觉」变成「数字」。公众号后台只告诉你结果而把榜单、爆款、侥幸和翻车的原因沉淀成自己的方法论答案是找出来的不是猜出来的。希望帮到你。本文还有配套的精品资源点击获取