[{"data":1,"prerenderedAt":264},["ShallowReactive",2],{"blog-baidu-tongji-vs-ga4-diff":3,"blog-prev-baidu-tongji-vs-ga4-diff":89,"blog-next-baidu-tongji-vs-ga4-diff":164},{"id":4,"title":5,"author":6,"body":7,"canonical":73,"category":74,"cover":73,"date":75,"description":76,"draft":77,"extension":78,"keywords":73,"meta":79,"navigation":80,"noindex":77,"ogImage":73,"path":81,"seo":82,"seoDescription":73,"seoTitle":73,"stem":83,"tags":84,"updated":73,"__hash__":88},"blog\u002Fblog\u002Fbaidu-tongji-vs-ga4-diff.md","百度统计和 GA4 的流量差 30%，问题常在这四处","元析智能",{"type":8,"value":9,"toc":63},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60],[11,12,13],"p",{},"百度统计显示 1.2 万次访问、GA4 只有 8600，这种差距是正常的；不正常的是你花一周去找谁在说谎。两个工具的统计口径天生不同，差异只能解释，不能调平。2025 年 9 月我们给一个站做过完整对账，差异主要来自四处。",[15,16,17],"h2",{"id":17},"时区先错位",[11,19,20],{},"百度统计默认东八区。GA4 的媒体资源时区在建资源时设定，很多人选了 UTC，或者干脆没留意默认值。跨过 0 点的那部分流量会算到不同日期，做周对比时，光这一项就能吃掉一半差异。先去 GA4 管理后台把时区改成 Asia\u002FShanghai，再比数据。",[15,22,23],{"id":23},"过滤规则不对称",[11,25,26],{},"GA4 没配内部流量过滤，办公室 IP、测试机的访问全算进去；百度统计如果开了排除 IP，同一批人又不算。反过来，广告拦截插件对 GA4 的 gtag 脚本影响更大，大约 10% 到 20% 的访客不会上报。",[15,28,29],{"id":29},"会话和归因逻辑不同",[11,31,32],{},"百度统计会话默认 30 分钟，GA4 也能设。真正的区别在来源归因：GA4 按 last non-direct 处理，用户先搜索进来、第二天直接访问，仍可能记成 organic；百度统计记成直接访问。评估 SEO 效果时，这个差异会让自然搜索看起来更好。",[15,34,35],{"id":35},"站内跳转被算成推荐流量",[11,37,38],{},"支付回调、帮助中心子域、带参数的站内链接，在 GA4 里经常触发 self-referral，多出一条来源；百度统计基本没这个问题。处理办法是把这些域加进不需要的推荐流量列表，一次配好，后面不用管。",[15,40,41],{"id":41},"我们自己的口径",[11,43,44],{},"海外站以 GA4 为主口径，国内落地页看百度统计，报告里写一句口径不同、不做互相校验。别花时间把两个数字调平，调不平。要判断 SEO 有没有起效，只盯一个工具里有机搜索的落地页和转化事件，趋势对了就够了。",[15,46,47],{"id":47},"对账时我们固定做三件事",[11,49,50],{},"第一，两个工具都切到东八区，取自然月 1 日到月底的数据，避开跨日边界。",[11,52,53],{},"第二，GA4 里导出渠道组为 Organic Search 的会话数，百度统计里导出搜索引擎来源的访问次数，只看这两个数，别看总访问量。",[11,55,56],{},"第三，把差异按落地页拆开，看是哪些页面差得多。通常首页和产品页差 10% 以内，博客文章页能差 30% 以上，因为文章页的访客更多装了拦截插件。",[11,58,59],{},"做完这三步，剩下的差距基本都有解释。写进报告就一句话：两工具口径不同，本站以 GA4 为准。列两个数字让客户自己算，比解剖差异更累。",[11,61,62],{},"上个月还有客户问，能不能用两个工具的平均值当真实流量。不能。平均值只是把两个偏差混在一起，误差不会抵消，只会更难解释。2025 年 9 月那次对账之后，我把这句话变成了报告模板里的固定一行。",{"title":64,"searchDepth":65,"depth":65,"links":66},"",2,[67,68,69,70,71,72],{"id":17,"depth":65,"text":17},{"id":23,"depth":65,"text":23},{"id":29,"depth":65,"text":29},{"id":35,"depth":65,"text":35},{"id":41,"depth":65,"text":41},{"id":47,"depth":65,"text":47},null,"工具评测","2025-09-20","两个统计工具口径天生不同，差 20% 到 40% 都正常。我们做过一次完整对账，差异集中在时区、过滤规则、会话归因和站内引流四个地方，查完就不用再纠结谁在说谎。",false,"md",{},true,"\u002Fblog\u002Fbaidu-tongji-vs-ga4-diff",{"title":5,"description":76},"blog\u002Fbaidu-tongji-vs-ga4-diff",[85,86,87],"百度统计","GA4","数据口径","6ytRWfa-wJoyzx9q6AYF-UwBp6xdkRWjnZLY5A4zCTU",{"id":90,"title":91,"author":6,"body":92,"canonical":73,"category":74,"cover":73,"date":153,"description":154,"draft":77,"extension":78,"keywords":73,"meta":155,"navigation":80,"noindex":77,"ogImage":73,"path":156,"seo":157,"seoDescription":73,"seoTitle":73,"stem":158,"tags":159,"updated":73,"__hash__":163},"blog\u002Fblog\u002Fbaidu-search-resource-platform-tools.md","百度搜索资源平台 8 个入口，我们每周只看 5 个",{"type":8,"value":93,"toc":146},[94,97,101,104,107,111,114,117,121,124,127,131,134,137,140,143],[11,95,96],{},"百度搜索资源平台有 8 个常用入口，我们每周固定只看 5 个：抓取诊断、索引量、流量与关键词、普通收录、死链提交。剩下 3 个（站点属性、安全检测、站点改版）出事才点。每天 20 分钟，够用。",[15,98,100],{"id":99},"抓取诊断每周抓-4-个页面","抓取诊断：每周抓 4 个页面",[11,102,103],{},"抓取诊断是唯一能让你看到\"百度眼里的页面长什么样\"的工具。我们每周对首页和 3 个核心栏目各抓一次，重点看两件事：HTTP 状态码，和抓取到的 HTML 里有多少条内链。",[11,105,106],{},"上个月抓一个客户站，百度拿到的首页只有 7 个链接，实际页面 40 多个——导航用 JS 渲染，百度没执行。这种问题不看抓取诊断永远发现不了。频率不用高，一周一次，每次 4 个页面。",[15,108,110],{"id":109},"索引量看趋势不看绝对值","索引量：看趋势，不看绝对值",[11,112,113],{},"索引量给的是百度索引里你这个站的页面数。绝对值和 site: 结果对不上是正常的，我们不纠结这个数准不准，只看一周内的变化。",[11,115,116],{},"我们的线是：一周跌 15% 以上开始排查，跌 30% 以上当天查。今年 6 月一个客户站索引量从 1.2 万掉到 7600，查下来是改版时把栏目页 URL 全换了，没做 301。",[15,118,120],{"id":119},"流量与关键词区分排名掉和需求掉","流量与关键词：区分排名掉和需求掉",[11,122,123],{},"这个工具的价值是拆开看展现和点击。一个词展现没变、点击掉一半，是标题或描述不够吸引人；展现掉了，才是排名掉了。",[11,125,126],{},"我们给客户做月度报告就用这个逻辑，比笼统说\"流量跌了 20%\"清楚得多。上季度一个词展现 4.2 万、点击 3100，点击率 7.4%，改标题后点击率到 11.6%，排名一点没动。",[15,128,130],{"id":129},"普通收录每天不超过-30-条","普通收录：每天不超过 30 条",[11,132,133],{},"普通收录有配额，很多站把配额当任务，每天提交满。我们的用法是只提交当天新增、且确认有搜索需求的页面，一天不超过 30 条。",[11,135,136],{},"判断\"有没有需求\"用一个笨办法：把标题扔进百度搜一下，看下拉和相关搜索有没有同类词。没有的词，收了也不会有展现。我们内部有张表，记录每次提交后一周的收录结果，三个月复盘一次：提交了没收录是内容问题，提交就被拒是抓取问题。",[15,138,139],{"id":139},"死链提交与我们的判断",[11,141,142],{},"死链提交要打包成 txt，一行一条，每周提交一次。这件事的价值不是\"让百度删掉死链\"，是避免死链拖累整站抓取评价。我们见过一个站 3000 条死链没处理，抓取频次三周掉了 40%。",[11,144,145],{},"平台数据是\"百度视角\"，和你自己统计工具的数对不上是常态，别拿两个数互相校准。它的用途是找异常，不是复盘业绩。真要复盘，还是得看自己的日志和排名监测。",{"title":64,"searchDepth":65,"depth":65,"links":147},[148,149,150,151,152],{"id":99,"depth":65,"text":100},{"id":109,"depth":65,"text":110},{"id":119,"depth":65,"text":120},{"id":129,"depth":65,"text":130},{"id":139,"depth":65,"text":139},"2025-09-19","平台功能不少，真正影响收录和排名判断的只有几个。我们每周固定看 5 个入口，每个看什么数据、哪些数字是噪音、哪 3 个后台工具出了事才点，一次说清楚。平台后台的数字，和你自己统计里的数对不上是正常的。",{},"\u002Fblog\u002Fbaidu-search-resource-platform-tools",{"title":91,"description":154},"blog\u002Fbaidu-search-resource-platform-tools",[160,161,162],"百度搜索资源平台","站点后台","数据监测","t1RMK7aF17T-YyNZ_0Sa7yAhZnYbqSJ8LxMSmFpmSd8",{"id":165,"title":166,"author":6,"body":167,"canonical":73,"category":252,"cover":73,"date":253,"description":254,"draft":77,"extension":78,"keywords":73,"meta":255,"navigation":80,"noindex":77,"ogImage":73,"path":256,"seo":257,"seoDescription":73,"seoTitle":73,"stem":258,"tags":259,"updated":73,"__hash__":263},"blog\u002Fblog\u002Flcp-metric-vs-user-wait.md","LCP 一点二秒客户还说卡，我们查到了指标外的问题",{"type":8,"value":168,"toc":246},[169,172,176,179,182,195,198,201,204,213,216,219,222,225,228,231,234,237,240,243],[11,170,171],{},"上个月一个 B2B 数据工具客户找我们，说后台打开\"特别慢\"，可 PageSpeed 跑出来 LCP 1.3 秒，三项指标全绿。我们跟了 20 个真实用户的操作录屏，问题不在渲染，在于他们要等 2.4 秒才看到数据。Core Web Vitals 测的是\"画出来\"，不是\"能不能用\"。",[15,173,175],{"id":174},"骨架屏把-lcp-做漂亮了","骨架屏把 LCP 做漂亮了",[11,177,178],{},"这个产品的首屏是仪表盘。骨架屏 0.3 秒就出现了，LCP 元素被记为骨架屏里的标题文字，所以 1.3 秒这个数很好看。但真正的报表数据来自一个 2.4 秒才返回的接口，用户盯着骨架屏转圈，感受就是慢。",[11,180,181],{},"同类情况还有三种：",[183,184,185,189,192],"ul",{},[186,187,188],"li",{},"图片用渐进式加载，LCP 记的是低清图首次渲染的时间",[186,190,191],{},"按钮渲染出来了，JS 还没加载完，点了没反应，这属于 INP 的范畴",[186,193,194],{},"字体 swap 后文字重绘，LCP 记的是第一次绘制",[11,196,197],{},"指标没坏，只是它衡量的是\"页面出现了\"，不是\"页面能用了\"。",[15,199,200],{"id":200},"我们补了两条自建埋点",[11,202,203],{},"从今年 3 月开始，我们给客户站加两条埋点，用 PerformanceObserver 加自定义打点：",[205,206,207,210],"ol",{},[186,208,209],{},"首屏关键数据到位时间：接口 resolve 到第一次渲染完成的间隔",[186,211,212],{},"首次可用交互时间：用户第一个真实点击得到响应的时刻",[11,214,215],{},"这两个数不需要精确到毫秒，能看出量级就够。上面那个客户，数据到位时间 P75 是 2.6 秒，LCP 的 P75 是 1.4 秒。差出来的这 1.2 秒，就是用户嘴里那个\"慢\"。",[15,217,218],{"id":218},"别拿分数当体验的替代品",[11,220,221],{},"我的立场很直接：PSI 分数是给外人看的，真实用户指标是给自己看的。B2B 软件站如果只盯 LCP、INP、CLS 三个数，会漏掉一整类问题——数据链路的等待。",[11,223,224],{},"SaaS 后台、控制台、数据看板这类产品，用户对\"多久能用\"的敏感度远高于\"多久能看见\"。这类站的性能优化，接口和渲染必须一起看，单测前端没有意义。",[11,226,227],{},"怎么查：抽 20 个真实用户会话录屏，找\"页面已加载但用户停顿超过 2 秒才开始操作\"的片段。这类片段占比超过三成，就别再修 LCP 了，去查接口和首屏数据编排。",[11,229,230],{},"顺带说下取舍：给首屏数据做串行请求还是并行，很多团队为了页面的视觉顺序选择串行，代价就是可用时间翻倍。我们的做法是并行拉取、按视觉顺序渲染，宁可多一次请求，也不让用户在骨架屏上等。",[15,232,233],{"id":233},"两个常被问到的问题",[11,235,236],{},"Q：这种站还要不要做 Core Web Vitals？",[11,238,239],{},"要做，但别把它当验收标准。LCP、INP、CLS 是及格线，及格之后用户满不满意，取决于数据什么时候到。我们的做法是两套指标并列看，谁差修谁。",[11,241,242],{},"Q：怎么跟不懂技术的老板解释这件事？",[11,244,245],{},"别讲指标定义，讲他的使用场景。我就问了一句：你早上打开后台，看到表格出来能用，需要几秒？他想了想说三四秒。然后我把 2.6 秒的数据放到他面前，他就明白了。用户感知的时间，才是要优化的那个数。",{"title":64,"searchDepth":65,"depth":65,"links":247},[248,249,250,251],{"id":174,"depth":65,"text":175},{"id":200,"depth":65,"text":200},{"id":218,"depth":65,"text":218},{"id":233,"depth":65,"text":233},"技术SEO","2025-09-22","一个 B2B 数据工具的 LCP 只有 1.2 秒，用户却抱怨打开很慢。原因是骨架屏先渲染、真实数据 2.4 秒才回来。我们补了两条自建埋点，才把用户嘴里的\"慢\"量化出来。",{},"\u002Fblog\u002Flcp-metric-vs-user-wait",{"title":166,"description":254},"blog\u002Flcp-metric-vs-user-wait",[260,261,262],"LCP","真实用户指标","SaaS 性能","U_--kaAL7I71n3S3whQR3cskX0TPt2vwP7Xk3Qn9S6Q",1794088112245]