如何给自己的网站做一次全面的流量分析

为什么你要做一次流量分析#

我的个人网站 joyehuang.me 上线于 2026 年 2 月。上线后的头几个月，我对流量的全部认知就是 Vercel 后台那个曲线图——偶尔打开看一眼，涨了高兴一下，跌了叹口气，然后关掉。

直到 8 月，我把 Vercel Web Analytics 的 API 翻出来，把上线至今（2 月到 8 月）的全量数据拉下来做了一次系统分析，才发现几个后台一眼根本看不出来的事实：

• 7 月历史峰值 7,286 访客，是上线当月的 214 倍；8 月（截至 25 日）回落 59%，即使按日均口径也少了近一半
• 8 月回落时 Vercel 里 Google 来源从 1,187 跌到 45、跌了 96%；但 GSC 官方账本显示搜索点击 7→8 月持平（69→68）——跌的是统计标签，不是搜索排名
• 站点 70% 以上的内容流量由 Agent 面试主题撑着，其余文章长尾有限
• /404 页面一个月有 393 个访客，其中约 29% 来自搜索引擎——旧 URL 迁移后没做重定向，正在白白漏掉搜索流量

这四条，每一条都直接改变了我对网站接下来该做什么的判断。如果只看后台曲线，我能看到的只有”7 月很高、8 月跌了”，而看不到为什么、以及该怪谁。

所以这篇文章想回答的问题是：对一个个人网站，怎么把”看一眼曲线”升级成一次真正全面的流量分析？下面是我实践过的一套完整方法——数据源怎么选、五步分析框架、六个我亲自踩过的数据质量坑、以及怎么把数据变成行动。全部以我自己站点的真实数据为案例。

第一步：把数据源搞清楚#

做分析之前先明确你有什么。我的工具链是三层：

1. Vercel Web Analytics（主体）

Vercel 免费档的 Web Analytics 自带 PV/UV、referrer、设备、浏览器、地区，以及自定义事件（页面里的 JS 手动上报）。它的短板也明确：UTM 聚合属于 Plus/Enterprise 付费能力（我用 API 查直接返回 402）；数据只能按天/页面/来源等维度聚合，没有会话时长、跳出率、滚动深度。

2. Analytics API 直查（关键）

后台 UI 只能看聚合图，真正的分析能力在 API。三个公开端点覆盖了所有需求：

• /v1/query/web-analytics/visits/count —— 历史总量（pageviews / visitors）
• /v1/query/web-analytics/visits/aggregate —— 按日、页面、路由、来源、国家、设备、浏览器、系统、环境聚合
• /v1/query/web-analytics/events/aggregate —— 按事件名及 eventData 属性聚合自定义事件

用已登录的 vercel CLI 以用户身份调用即可，只读、不改任何线上配置。这一步是整个方法论的分水岭：有了 API，你才能做逐月时间序列、上线以来的全量回溯、以及后面要讲的自动化月报——这些都是后台 UI 做不到的。

3. Waline wl_counter（交叉验证）

我的博客评论用的是 Waline，它的 wl_counter 表里存着每篇文章的真实浏览量。拿它和 Analytics 的单篇数据对照，可以验证两边口径是否一致。实测（都是浏览量口径）：入门指南 5,098 vs 5,084、模拟面试 2,455 vs 2,453——吻合，说明两套数据都可信。

一个通用建议：永远找第二数据源做交叉验证。单凭一个统计系统，你无法区分”数据是这样”和”统计脚本以为是这样”。

4. Google Search Console（渠道归因的官方账本）

GSC 的 Search Analytics API 和前三者看的不是一个层面：Vercel 只知道”上一个页面标着 google”，GSC 知道”你的页面在搜索结果里到底有多少曝光、多少点击、排第几”（OAuth 授权一次，之后脚本全自动查询）。本文所有渠道归因类的结论，最终都要拿到它这里对一次账——第三节会看到这个习惯救了我一次。

第二步：五步分析框架#

数据在手之后，我按五个层次逐层往下看。

1. 时间序列：找拐点，再归因#

把上线至今逐月拉出来：

• 2 月上线 34 访客 → 3 月有内容 +1123% → 5 月入门指南发布 +212% → 6 月稳定爬坡 → 7 月峰值 7,286 访客 / 17,735 PV → 8 月（截至 25 日）回落到 3,003 访客，日均 120，只有 7 月日均 235 的一半

曲线本身没有信息量，拐点的归因才有。3 月的跳变对应开始持续发文；5 月对应 Agent 入门指南发布。7 月的爆发，我原本的解读是入门指南被 Google 收录后冲上前排——“5 月发布、6 月爬坡、7 月爆发”像极了新站文章的排名爬升周期。但 GSC 的数据推翻了这个解释：搜索曝光的峰值在 6 月（14,375 次），7 月已回落到 9,591，全月搜索点击只有 69 次。7 月那 7,286 个访客的主引擎不是 Google 搜索，结合渠道结构（无 referrer 占九成）更可能是微信、社区的转发传播——这次归因差点把功劳记错账本。

再往下一层用周粒度看回落速度：7 月 24–30 日那周访客环比 -34.6%，但 PV 只 -4.7%，人均浏览反而从 1.83 升到 2.66。这说明传播高峰退潮后留下的核心读者浏览更深——流量在跌，读者质量在涨。这种结论只有分层数据能给。

2. 渠道结构：先搞懂”无来源”是什么#

8 月的渠道结构：直接/无 referrer 占 96%，cn.bing + bing 合计是国内主战场，GitHub、豆包、ChatGPT 也已有零星自然流量。Google 在 Vercel 标签里 7 月曾占 16%、8 月崩到几乎为零——这条先记住，第三步要用 GSC 翻案。

曝光在 6 月见顶后回落，点击基本平稳。

这里有个几乎所有站点分析都会遇到的坑：“无 referrer”不等于”直接访问”。我的站 7 月有 89.9% 的 PV 没有 referrer，但其中大量来自微信、飞书、聊天软件内打开——这些场景浏览器会抹掉来源。把它解释成”品牌直访”会严重高估自己。

渠道分析真正的价值在交叉。Vercel 标签口径下，模拟面试中文版 666 名”Google 访客” + 英文版 334 名，两页合计占全站 Google 流量的 82.4%——表面看，搜索流量高度集中在一个主题上。但拿 GSC 一对账，这个”Google”要打引号：GSC 显示 7 月全月真实搜索点击只有 69 次，和 Vercel 标的 1,187 个”Google 访客”差了 17 倍——标签里混进了 Discover、News、Images 这类非搜索来源。GSC 自己给出的画面是：搜索曝光高度集中在面试主题（query 维度清一色”agent 开发面经 / agent 开发面试”），而曝光最高的英文笔记页月曝光 2,400+、平均排位 7.0，CTR 却只有 0.2%——英文页有曝光、没点击，缺的不是排名，而是值得点进去的标题和摘要。

3. 内容矩阵：单篇 vs 主题簇#

逐篇看全量数据：入门指南 4,270 访客单篇第一（注意这是访客口径，和上文 Waline 对照用的 5,098 浏览量不是同一个指标）；算上它，5 篇 Agent 面试主题（入门指南/复盘/模拟面试/心态/onboarding）合计约 7,000+ 访客，占内容流量 70%+；OpenHarness 教程（开源项目引流）1,415 访客，稳定第二梯队；而 Transformer 原理四部曲每篇只有 76–134 访客，全站垫底。

单篇数字只告诉你哪篇好，矩阵视角才告诉你为什么好、以及怎么复制。Agent 面试主题跑出来不是偶然：它同时命中”可搜索的刚需关键词 + 第一人称实战叙事 + 对求职者有直接用处”三个条件；Transformer 四部曲是早期作品，偏教科书式原理讲解，三个条件一个都不占。这个对比就是我的选题公式来源——判断内容方向，看真实浏览量 + 自己真正做过的东西 + 选题是否命中搜索刚需。

4. 转化漏斗：自定义事件才是行为真相#

PV 只能证明”来了”，自定义事件才能证明”做了什么”。我的站埋了报名、外链点击、终端命令等事件，其中最完整的一个漏斗是 7 月上线的 /agent-teams 活动页：

• 964 名访客，153 人打开报名表（15.9%），91 人成功提交（9.4%），打开到提交转化 59.5%

接近 10% 的访客提交率，验证了”明确任务 + 具体时间窗口 + 低摩擦报名”这个结构是有效的，后续活动页应该复用而不是另起炉灶。

反例也很有价值：首页弹窗 700 次交互里 575 次是关闭（82.1%），外链点击只覆盖约 4.1% 的首页访客——它是”容易被关掉的公告”，不是引流入口。没有事件数据，这种”看起来在推广、实际在打扰”的设计会一直存活下去。

5. 受众画像：验证你的受众假设#

设备：Desktop 80.2%、Windows 58%、Chrome + Edge 合计约 78%——典型的工程师/技术求职受众，验证了站点定位。但移动端仍有五分之一浏览，不能忽略阅读体验。地区：中国大陆 40.6%、美国 19.8%、日本 12%、新加坡 9.7%——海外已占多数。

画像这层要注意解释边界：地区分布会被云网络、代理、跨区访问污染，海外占比不能直接等同海外真人读者规模；访客数在页面/来源/事件分组之间会重叠，各行不能简单相加。画像数据用来做方向判断足够，做精确审计不够。

第三步：数据质量审计（最容易跳过、最不该跳过）#

这一步是我认为整套方法里最值钱的部分——分析结论的可靠性上限，取决于数据质量。我的站点分析里发现六个真实存在的问题，逐个说：

坑 1：404 无法归因原始 URL。 7 月 /404 有 393 访客、420 次浏览，而 6 月只有 24 名——异常明显。原因大概率是 7 月 2 日知识内容从 /archive/... 迁到 /notes/... 没做重定向，约 29% 的 404 浏览来自搜索引擎。但 Analytics 只返回 /404 这个路径，还原不出每一个具体的坏链接。修复方式：补 /archive/:path* → /notes/:path* 的中英文 301 重定向（注意别误伤表示年份归档的复数路径 /archives），同时埋一个只记录原始 pathname 的安全 404 事件，用于确认剩余坏链。

坑 2：终端埋点泄漏用户自由输入。 我的站点有个交互式终端彩蛋，事件契约本要求不上传自由输入，但代码会把用户输入的第一个词直接写进 command 字段。结果 Analytics 里已经出现自然语言和任意输入——386 次命令里 110 次是 unknown_command（28.5%）。这既是隐私问题也是数据污染问题。修复：未知输入统一记成 command: unknown，需要分析时只上报低基数的 input_kind 或长度区间。

坑 3：事件归因字段失效。 article_contact_reveal 事件有 184 名访客，但绝大多数事件的 article_slug 都是 post——因为取 slug 的代码取的是 pathname 最后一段，而文章 URL 恰好都以 /post 结尾。184 个人的联系方式展示，无法判断来自哪篇文章。这类 bug 静默运行，数据照常上报、只是全错，唯一发现方法是定期抽查事件明细。

坑 4：事件口径中途切换。 7 月中途短暂上线三套新版 intro 动画，完成事件从 intro_cta_click 换成了 intro_complete，随后又回滚。结果整月只有 31 次 intro_complete——不是完成率低，是口径换过。跨期对比之前，先确认统计口径本身没变过，否则你会对着噪声找原因。

坑 5：能力边界不等于数据不存在。 UTM 聚合查了返回 402（付费能力），不代表 UTM 没意义，只代表这个工具链给不了。另外几个新埋的事件还没登记进事件契约文档——事件清单和代码漂移了。建议把”事件契约文档”当作代码的一部分来维护。

坑 6：来源标签不等于渠道本身。Vercel 的 “google” 标签 7 月记了 1,187 个访客，GSC 官方账本同月只有 69 次搜索点击——差 17 倍，多出来的部分是 Discover / News / Images 和其他 google 域名的跳转。同一个”来自 Google”，浏览器上报的 referrer 和 Google 自己统计的搜索点击是两码事，含义能差一个数量级。浏览量可以拿计数器交叉验证口径，渠道归因要拿渠道方的官方账本验证（Google 看 GSC、必应看 Bing 站长工具）——准备据此做渠道决策的数字，先对一次账。

一次全面的流量分析，产出应该有两份：一份是发现（上一节），一份是数据质量修复清单（这一节）。只做前者，你下一轮分析还是站在同样的流沙上。

第四步：从数据到决策#

数据收集和审计都做完之后，最后一步是把发现收敛成诊断和行动。

我的站点诊断最后收敛成一句话：当前流量 = 单篇爆款 × 单点传播，结构性脆弱。5 个月 214 倍的成长性是真的，但撑起流量的是一篇入门指南 + 一波不可归因的社交传播，而本该最稳定的搜索引擎实际只贡献每月两位数的点击（GSC 实测，峰值 87 次）——任何一环变化（8 月已经验证了一次），流量就塌方。

对应的结构性改法，按优先级：

• P0 治本——单爆款变内容矩阵：把入门指南系列化（工具链实操 / 记忆架构 / RAG 实战 / 比赛复盘承接篇），主题簇内互链，把单篇权重扩散成整站权重；每篇新文带 2–3 个内链指向爆款
• P1 治标——渠道多元化：cn.bing 站长工具（国内主战场是必应不是百度）、给 AI 平台做”可被引用”的结构化内容（AI 引擎已经在给我的站送流量了，虽然每月只有个位数）。GSC 还揭示了搜索的真实体量：全站搜索点击月峰值只有 87 次（6 月）——搜索不是会流失的存量资产，而是未开发的增量；排进 GSC 的 query 全部卡在排位 8–17 位（结果第 2 页上沿），每个都是”内容已在、差一口气进首页”的机会
• P2 搜索侧放大：给排位 8–15、月曝光上百的页面批量优化 title / meta description——英文笔记页已有月 2,400+ 曝光、排位 7.0 但 CTR 仅 0.2%，是现成的免费曝光池，吃点击率比等排名爬升快得多；爆款出英文版照做，但验证指标从”英文页获得流量”改为”高曝光页 CTR 提升”
• P3 SEO 基建：Article schema、内链推荐、结构化摘要
• P4 监控自动化：把这条 API 链路做成每月自动抓取的月报（下一节）

注意这个顺序的逻辑：先修数据质量（上一节那份修复清单，其中 404 重定向优先级最高），再做内容动作——否则你做的每个改动都无法度量效果。另外，“验证指标”要和行动一起定：比如修重定向的验证指标是 /404 日浏览回落 + 旧 URL 返回 301，做内容集群的验证指标是更多 landing page 获得稳定 Google 流量。没有验证指标的改进项，等于没有立项。

第五步：自动化月报#

手工分析做一次就够了，持续的价值靠自动化。方法很简单：把第二节那三个 API 端点封装成脚本，用 launchd（或 cron）每月固定时间跑一次，产出逐月对比、来源变化、TOP 页面、异常检测（比如某渠道环比跌幅超阈值）。

这样做有两个附带收益：

1. 拐点归因不再靠回忆。8 月 Google 崩盘的先兆其实在 7 月下旬那周就出现了，如果周环比跌幅超阈值能被自动标红，就能早两周去 Search Console 排查
2. 数据本身成为内容素材库。这次全量分析本身就成了一篇博客——你的流量数据是少数几个”既真实、又只有你有”的选题来源

方法总结#

把整篇文章压缩成一张操作清单：

1. 接 API：Web Analytics 三个端点直查，别只看后台 UI
2. 找第二数据源：浏览量拿计数器交叉验证；渠道归因拿渠道方官方账本（GSC / Bing 站长工具）对账
3. 五层递进：时间序列找拐点归因 → 渠道结构（先搞懂”无来源”）→ 内容矩阵（单篇 vs 主题簇）→ 转化漏斗（自定义事件）→ 受众画像（注意解释边界）
4. 审计数据质量：404 归因、自由输入泄漏、归因字段失效、口径切换、能力边界、来源标签≠渠道——发现的问题本身也是产出
5. 收敛成诊断 + 行动：一句话结构性诊断，行动按优先级排，每条带验证指标
6. 自动化月报：让分析变成持续资产而不是一次性动作

最后说一个做完全部分析之后最大的感受：流量分析的目的不是让数字变好看，而是让你对”接下来该做什么”的每一次判断都有依据。8 月那次 -59% 的回落，如果发生在半年前，我的反应大概是焦虑然后发篇新文章碰运气；现在它变成了一条明确的诊断——渠道单一且脆弱——以及一条对应的行动——多元化渠道、内容集群化。焦虑和数据驱动之间，差的只是这一套动作。