直接答案：要在 GA4 中分析 Bing 与 AI 带来的访问，先进入“报告 → 获取 → 流量获取”，把主维度切换为会话来源/媒介或会话默认渠道组。Bing 自然搜索通常显示为类似 bing / organic 并归入 Organic Search；自 2026 年 5 月 13 日起，被 Google Analytics 识别的 ChatGPT、Gemini、Claude 等 AI 助手引荐会使用 ai-assistant 媒介、AI Assistant 渠道和 (ai-assistant) 广告系列名称。然后添加“落地页”作为次级维度，比较参与会话、关键事件和内容去向。
不过，GA4 看不到 AI 回答中没有产生点击的引用，也不能可靠记录搜索引擎和 AI 机器人的抓取。Bing 的搜索展现、查询与点击应在 Bing Webmaster Tools Search Performance 查看；Microsoft Copilot、Bing AI 摘要和部分合作体验中的引用、被引页面与 grounding queries，应在 AI Performance 查看；机器人请求、状态码和缓存命中则看服务器日志。把这三类工具混在一起，最容易得出“没有 GA4 会话，所以 AI 没引用”之类的错误结论。
本文按 2026 年 7 月 19 日可访问的 Google 与 Microsoft 官方资料复核，面向不投放广告、主要依靠自然搜索和内容推荐的中文网站。它不会教你制造虚假 UTM、把所有 Direct 都算成 AI，或承诺安装代码后排名自动上升；目标是建立可以复查的流量与内容决策体系。
GA4、Bing Webmaster Tools 和服务器日志各回答什么？
衡量之前先把用户旅程拆开。一个页面可能被 Bing 抓取、在搜索结果出现、在 Copilot 回答中被引用，但用户没有点击；也可能用户从聊天应用复制链接后打开，来源信息在跳转中丢失，最终在 GA4 里变成 Direct。每一层都有不同的可观察范围。
| 问题 | 首选工具 | 能看到 | 看不到或不能证明 |
|---|---|---|---|
| 页面是否被 Bing 搜索展示并获得点击 | Bing Search Performance | 查询、页面、展现、点击、CTR、Web/Chat 等来源 | 用户进入站点后的深读、注册和下载 |
| 页面是否在 Microsoft AI 回答中被引用 | Bing AI Performance | 总引用、平均被引页面、被引 URL、grounding query 样本与趋势 | 引用位置、权威等级或每次回答中的排序 |
| 用户点击进入后做了什么 | GA4 | 会话来源、渠道、落地页、参与、事件与关键事件 | 没有点击的 AI 引用、机器人抓取和完整搜索曝光 |
| 谁抓取了页面、请求是否失败 | 服务器/CDN 日志 | User-Agent、IP、时间、URL、状态码、传输量 | 仅凭 User-Agent 不能证明内容被采用或用户身份 |
| 内容改动后搜索表现是否变化 | Bing + GA4 联合 | 被发现、被点击和点击后质量的连续证据 | 单次波动不能证明因果，需要时间窗口和对照 |
Microsoft 的 AI Performance 公测公告明确说明：Total Citations 表示内容作为来源出现的次数，Average Cited Pages 是每天平均被引用的独立页面数；这些聚合数据不代表排名、权威性或某一页面在单次答案中的作用。Grounding queries 也只是引用活动的样本。正确用途是发现哪些主题已被采用、哪些页面需要补清晰度和证据，而不是把引用次数包装成“AI 权威评分”。
2026 年 GA4 的 AI Assistant 渠道发生了什么变化？
Google Analytics 官方更新日志记录，2026 年 5 月 13 日新增 AI Assistant 流量测量：当 referrer 匹配 GA4 识别的 AI 助手时，媒介自动赋值为 ai-assistant，默认渠道组归入 AI Assistant，广告系列显示 (ai-assistant)。官方举例包括 ChatGPT、Gemini 与 Claude。
| 你在报告中看到的值 | 含义 | 正确读法 | 不要推断 |
|---|---|---|---|
| AI Assistant | 会话符合 GA4 当前默认渠道规则 | 在流量获取中展开来源/媒介和落地页 | 不等于所有 AI 访问都被识别 |
| ai-assistant | GA4 为已识别 AI 引荐分配的媒介 | 与 organic、referral、email 等比较访问质量 | 不等于 AI 抓取或训练数据访问 |
| (ai-assistant) | 该类来源的系统广告系列名称 | 用于筛选和交叉核验 | 不代表你投放了广告 |
| bing / organic | 通常为 Bing 自然搜索带来的会话 | 结合 Bing 查询和页面报告复核 | 不能从 GA4 还原所有搜索词 |
| (direct) / (none) | GA4 没有清晰来源信息 | 检查跳转、短链、标签、Consent 和 UTM | 不能直接全部归因给 AI |
| referral | 来自其他站点或尚未单列的引荐 | 展开 Session source 查具体域名 | 不能仅凭渠道名判断来源质量 |
默认渠道规则会更新，AI 产品的域名、应用内浏览器和跳转方式也会变化。因此最稳妥的工作方法不是只盯一行“AI Assistant”，而是同时保存会话来源/媒介、会话渠道组和落地页。如果某个新 AI 服务仍落入 Referral，先核验真实来源域名和样本，不要急着把带有 “ai” 字符的所有域名都归到 AI。
还需要创建自定义 AI 渠道组吗？
原生 AI Assistant 渠道已经解决了大部分基础需求，但自定义渠道仍有两个用途：补充你确认过、尚未被默认规则覆盖的 AI 引荐域名；或者把不同 AI 来源按编辑团队自己的分析口径分组。GA4 自定义渠道组文档专门提供了 AI assistants 示例，并要求把新渠道放在 Referrals 上方，必要时也可放在 Organic Search 上方。
| 方案 | 适合情况 | 优点 | 风险与控制 |
|---|---|---|---|
| 只用默认 AI Assistant | 刚开始衡量、流量不多 | 零维护，规则由 GA4 更新 | 新域名或丢失 referrer 的访问可能不完整 |
| 默认渠道 + 来源明细 | 多数内容站 | 能发现 Referral、Direct 和异常来源 | 需要固定周报口径，避免人工误判 |
| 自定义 AI 渠道组 | 已有稳定样本和明确域名清单 | 可追溯应用自己的分类规则，且自定义组可回溯应用于报告 | 正则过宽会误收普通域名；名单要定期更新 |
| 修改 Primary channel group | 组织已批准长期统一口径 | 未来报告使用可编辑的主渠道定义 | 只影响设置后的主渠道记录，变更前应留版本与负责人 |
官方示例给出了一条覆盖多种 AI 服务的正则，但其中包含较宽的匹配片段。不要不经测试直接复制到生产属性。应先在探索中导出最近 30～90 天的 Session source，建立“已确认域名 → 预期渠道”测试表；使用完整域名或经过转义的后缀规则；让 AI 渠道位于 Referral 之前；保存规则版本和日期；每月查看新增来源与误分类。标准属性最多可创建 2 个自定义渠道组，每组 50 个渠道，编辑需要属性级 Editor 或更高权限。
如何正确区分 User acquisition、Traffic acquisition 与归因？
很多“GA4 数据不一致”其实是选错了范围。GA4 来源维度范围说明把来源分为首次用户、会话和事件三种。它们回答的是不同问题，同一个用户先从 Bing 来、隔天从 ChatGPT 回访并完成注册，三个报告出现不同来源完全可能是正确结果。
| 业务问题 | 使用维度 | 报告 | 例子 |
|---|---|---|---|
| 新用户第一次是如何发现网站的 | First user source / medium | User acquisition | 用户首次从 bing / organic 进入 |
| 本周每次访问从哪里开始 | Session source / medium | Traffic acquisition | 同一用户本周从 chatgpt / ai-assistant 回访 |
| 哪个渠道获得关键事件贡献 | Source / Medium（事件范围） | 归因、模型比较、关键事件路径 | 注册前经过 Bing 和 AI 两次触点 |
| 哪篇页面接住了 AI 或 Bing 访问 | Session source / medium + Landing page | 流量获取或探索 | 比较不同落地页的参与会话与关键事件 |
| 某来源带来的用户后来是否回访 | First user + cohort/探索 | 用户获取与探索 | 首次 Bing 用户 7/28 日回访情况 |
对于“AI 和 Bing 本周带来了多少有效访问”这个问题，优先用会话范围。对于“最初获客渠道是什么”，用 First user。只有当你明确标记了关键事件，并需要分配贡献时，才进入事件范围和归因报告。不要把 User acquisition 的用户数和 Traffic acquisition 的会话数直接相减，它们既不是同一实体，也不是同一时间归属逻辑。
从零安装 GA4，最小可靠步骤是什么？
GA4 官方设置指南建议创建属性和 Web 数据流，再通过 CMS 集成、Google tag 或 Google Tag Manager 安装。Measurement ID 通常以 G- 开头。代码装上并不代表数据正确，必须用 Realtime 和 DebugView 验证真实事件、来源和 Consent。
| 步骤 | 操作 | 通过证据 | 常见故障 |
|---|---|---|---|
| 1 属性结构 | 一个连续用户旅程通常使用一个属性和合适的数据流 | 域名、时区、币种、负责人记录明确 | 同一站点重复建流导致重复或割裂数据 |
| 2 安装标签 | 选 CMS、gtag 或 GTM 中一种主路径 | 页面源代码或 Tag Assistant 只发现预期配置 | 主题、插件和 GTM 同时注入造成双计数 |
| 3 实时验证 | 从可控设备打开页面并执行动作 | Realtime 在约 30 分钟内开始收到数据 | 缓存、Consent、广告拦截、错误 ID |
| 4 DebugView | 检查 page_view、scroll、click 和自定义事件参数 | 每个动作只触发一次，参数与命名符合设计 | 重复监听、单页应用路由未处理 |
| 5 流量卫生 | 配置内部流量、跨域与不需要的引荐 | 员工访问不污染主分析；跨域不会自我引荐 | 支付域、自有子域或短链变成 referral |
| 6 隐私 | Consent、数据保留、数据遮盖与权限复核 | 拒绝场景符合政策，URL/事件不含 PII | 把邮箱、手机号放进 URL、UTM 或事件参数 |
Google 说明数据收集可能需要最多约 30 分钟才开始，应使用 Realtime 验证。标准报告不是实时审计日志：数据新鲜度文档指出，标准处理可能需要 24～48 小时，迟到数据还可能在之后补入。因此上午改稿、下午看到会话变化，不能立即断言是改稿产生的结果。
中文内容站应该记录哪些事件？
事件的目标不是“尽可能多”，而是把读者从落地到获得价值的路径表达清楚。GA4 的增强型衡量可以在不改页面代码的情况下收集页面浏览、滚动、出站点击、站内搜索和文件下载等事件；例如官方出站点击教程说明，启用增强型衡量后，跨到其他域名的链接可触发 click，已配置跨域衡量的域名除外。
| 用户动作 | 建议事件 | 是否标为关键事件 | 用途与注意 |
|---|---|---|---|
| 打开文章 | page_view | 通常否 | 衡量落地与浏览基数，防止重复注入 |
| 首次滚动到约 90% | scroll（增强型衡量） | 通常否 | 只是一种深读信号，不等于理解或满意 |
| 点击官方来源 | click + link_domain/link_url | 通常否 | 判断证据链是否被使用，避免发送含 PII 的 URL |
| 站内搜索 | view_search_results | 通常否 | 发现读者没有在当前页面获得的答案 |
| 下载模板或资料 | file_download | 视业务目标 | 确认文件类型和重复下载口径 |
| 提交明确咨询 | generate_lead | 通常是 | 只发送非敏感业务参数，不发送姓名、电话或邮箱 |
| 完成账号注册 | sign_up | 通常是 | 用 method 等非身份参数，不传用户名 |
| 达到自定义有效阅读条件 | 自定义事件，如 article_engaged | 谨慎 | 必须先写清时间、滚动与交互条件，并在 DebugView 验证 |
Google 对 key event 与 conversion 的说明把“对业务重要的事件”称为关键事件，conversion 更侧重广告活动衡量。没有广告的内容站也可以使用关键事件，但不应把 page_view、scroll 和每个普通点击全部标记为关键事件。否则关键事件率失去区分力，运营者只会得到一排看似增长、实际无法决策的数字。
如何做一张真正有用的 Bing 与 AI 流量报告？
建议建立两张报告：第一张回答“谁带来会话”，第二张回答“落地后是否解决问题”。如果数据量还小，按周而不是按天复盘，避免一个用户或一次爬虫误差改变结论。
| 报告 | 维度 | 指标 | 筛选 | 要做的决定 |
|---|---|---|---|---|
| 渠道质量 | Session default channel group → Session source/medium | 会话、参与会话、参与率、关键事件、每会话事件数 | Organic Search、AI Assistant、Referral、Direct | 哪个来源值得继续服务，哪里存在分类异常 |
| 落地页质量 | Landing page + Session source/medium | 会话、参与率、scroll、出站 click、关键事件 | Bing、AI Assistant 与确认过的 AI 来源 | 哪篇文章接住需求，哪篇需要补直接答案 |
| 站内缺口 | Search term / page path | view_search_results、后续页面、退出 | 来自目标渠道的会话 | 应该补 FAQ、术语、对比还是新专题 |
| 搜索可见性 | Bing query + page | 展现、点击、CTR、平均位置 | Web/Chat、日期和国家地区 | 标题与摘要是否匹配查询意图 |
| AI 引用 | Grounding query + cited page | 引用次数、被引页面、趋势 | 时间与 URL | 强化已有证据主题，减少重复与歧义 |
Bing Search Performance 的官方帮助说明，Web 与 Chat 来源可记录点击、展现、CTR 和平均位置，页面与查询可以互相下钻。AI Performance 则是引用层。把它们和 GA4 落地页报告按 URL 对齐，就能区分四种情况：有展现无点击；有引用无点击；有点击但低参与；有点击且完成关键事件。每一种都对应不同内容动作。
为什么 AI 或 Bing 流量会变成 Direct？
GA4 的 Direct 官方说明把 (direct) / (none)定义为没有清晰引荐来源的访问。它可能来自手输网址或书签，也可能因应用、隐私设置、跳转链、短链接、缺失 UTM、标签加载失败或 referrer 丢失而出现。Direct 是“来源未知”，不是一个可以随意重新命名的渠道。
| 现象 | 可能原因 | 核验方法 | 处理 |
|---|---|---|---|
| AI 活动后 Direct 上升 | 聊天应用没有传递 referrer，或用户复制链接 | 比较落地页、时间、服务器日志与 AI Performance；仍不能精确归因 | 保留为 Direct，并在结论中写明不确定性 |
| Bing 点击有记录，GA4 会话偏少 | Consent 拒绝、拦截器、标签未加载或口径不同 | 检查 Consent、Tag Assistant、状态码和时间窗口 | 修标签与合规流程，不强行补数 |
| 自有支付域显示 referral | 跨域或不需要的引荐未配置 | 查看 Session source 与跳转链 | 按官方流程配置 cross-domain / unwanted referrals |
| 大量 Unassigned 或 (not set) | 手工 UTM 不规范、标签或事件范围错误 | 审计 source/medium 命名与维度范围 | 统一 UTM 字典，修复标签后观察新数据 |
| 同一会话出现自我引荐 | 子域、协议或跨域配置不一致 | 浏览完整路径并检查 cookie/域配置 | 修复跨域，不在报告里事后覆盖 |
对于你能控制的邮件、社交账号、电子书和合作链接，应使用一致的 UTM；对于 Bing 自然结果和 AI 平台自然引荐，不要为了“好看”给站内链接加 UTM，也不要改写系统识别的 organic 或 ai-assistant。UTM 只用于可控活动，并且不能包含个人信息。
Consent、广告拦截和数据建模会怎样影响结论？
GA4 Consent signal 文档明确举例：如果用户拒绝 analytics cookies，Google Analytics 标签不会跟踪其站内活动。不同地区、Consent 实现和浏览器环境会让“点击数”和“GA4 会话数”天然不完全相等。启用 Consent Mode 或建模也不意味着可以忽略法律义务、用户选择或数据不确定性。
| 影响因素 | 数据表现 | 报告写法 | 不能做 |
|---|---|---|---|
| 用户拒绝 analytics_storage | 活动可能不被标签记录 | 说明 GA4 是可观察样本，不代表每个点击 | 绕过 Consent 强行追踪 |
| 广告/分析拦截器 | 浏览器不发送 GA 请求 | 与第一方日志和站长平台做趋势比较 | 把差额全部归因给某一来源 |
| 建模数据 | 部分指标可能由模型补充并在之后更新 | 使用数据质量提示和稳定窗口 | 把模型值说成逐用户实测 |
| 24～48 小时处理 | 标准报告晚于 Realtime，历史值可能补充 | 固定周报截点并注明数据截止时间 | 用当天未完成数据判定改稿成败 |
| 抽样/阈值/高基数 | 探索与标准报告可能显示不同精度 | 保留口径、日期、维度和数据质量图标 | 只截一个数字而不说明范围 |
如果网站面向多个司法辖区，应让合格的法律与隐私负责人确定 Consent 方案。技术团队的职责是确保实现与已批准政策一致：默认状态、更新时机、标签行为、数据保留和撤回都可测试。本文不是法律意见。
如何避免把个人信息送进 GA4？
Google 的 PII 最佳实践要求不得向 Analytics 传送可被 Google 识别为个人身份的信息，包括邮箱、手机号等。风险不只在表单字段：页面 URL、标题、查询参数、站内搜索词、UTM、自定义维度和事件参数都可能意外携带身份信息。
| 入口 | 高风险例子 | 安全做法 | 验证 |
|---|---|---|---|
| URL / 查询参数 | ?email=user@example.com |
改用短期、不可反推身份的内部状态；配置数据遮盖 | 查看 DebugView 与网络请求 |
| 事件参数 | phone、full_name、raw_prompt | 只发事件类别、页面类型、匿名业务状态 | 维护事件参数白名单 |
| 站内搜索 | 用户搜索手机号、姓名、订单号 | 在发送前过滤/屏蔽敏感模式 | 定期审查 search_term 样本 |
| UTM | utm_campaign 中写客户邮箱 | 使用活动代号与渠道字典 | 发布前自动检查链接 |
| User-ID | 直接使用邮箱或公开用户名 | 仅使用符合政策、不可直接识别的内部 ID | 权限与数据流审计 |
| Measurement Protocol | 服务端把完整客户记录发送到 GA | 只补充允许的事件与匿名参数 | 先用验证端点和测试属性 |
Measurement Protocol 适合把离线或服务器事件补充到现有 Web/App 数据流，但官方开发者文档明确把它定位为对 gtag、GTM 或 Firebase 收集的补充，不是完整替代。纯服务端实现可能只得到部分报告能力。接入前应使用验证工具、定义去重键和时间范围，绝不能因为“服务端看不到浏览器限制”就绕过 Consent。
如何把数据变成文章优化动作？
报告的终点不是截图，而是明确“改哪一页、改什么、为什么、何时复核”。每周选 3～5 个 URL，优先处理已经有展现、引用或点击，但没有很好完成搜索意图的页面。一次只改变一个主要变量，例如补直接答案、增加官方证据、修标题，或者增加到下一步教程的内链。
| 观察组合 | 更可能的问题 | 优先动作 | 复核指标 |
|---|---|---|---|
| 展现高、CTR 低 | 标题/摘要与查询意图不匹配，或结果竞争强 | 核对查询，改成准确直接的标题与开头，不制造夸张承诺 | Bing CTR、会话与同查询位置 |
| AI 引用有、点击少 | 内容可被采用，但答案已在 AI 中完成或引用入口弱 | 补充可执行模板、原始证据、计算器或深度步骤 | 引用趋势、AI Assistant/Direct 落地会话 |
| 点击有、参与低 | 首屏没回答问题、加载/移动端体验差或内容错配 | 重写直接答案，修 Core Web Vitals、目录和移动端 | 参与会话、scroll、下一页、关键事件 |
| 参与高、关键事件低 | 下一步不清晰，或关键事件定义不适合 | 增加真实下一步、工具/教程内链，复核事件设计 | 出站 click、站内下一页、generate_lead 等 |
| Bing 点击多、GA4 少 | 标签、Consent、拦截或时间口径差异 | 先排技术与口径，不先改文章 | Realtime、日志、稳定期会话 |
| 同意图多 URL 分散 | 重复内容彼此竞争 | 选主 URL 深度重写，其他页面 301 或按证据处置 | 主 URL 展现、引用、内链与索引状态 |
在兰塞 AI 的内容流程中，能进入首页推荐的不是“最近更新”或“访问最多”，而是已经完成来源核验、独立价值、图片许可、内外链、桌面/移动端实页 QA 和编辑复核的 A/B 级页面。GA4 只能帮助发现机会，不能替代事实核验与人工责任。关于大模型隐私边界可参考大模型训练数据提取与隐私防护和ChatGPT 2023 数据泄露事件复盘；自动化事件与错误恢复可继续阅读Make 生产级自动化指南与n8n 自托管与生产验收指南。
每周复盘模板
下面的表不要求购买额外工具。固定同一时区、相同 7/28 天窗口和数据截止时间，保留原始导出。流量很小时只写事实，不计算看似精确但样本不足的提升百分比。
| 字段 | 填写内容 | 数据来源 | 责任人 |
|---|---|---|---|
| 页面与主意图 | URL、目标查询、读者要完成的任务 | 编辑简报 | 内容编辑 |
| Bing 可见性 | 查询、展现、点击、CTR、Web/Chat | Search Performance | SEO/运营 |
| AI 可见性 | 引用数、被引 URL、grounding query 样本 | AI Performance | SEO/编辑 |
| 落地质量 | Session source/medium、参与会话、scroll、下一页 | GA4 | 分析人员 |
| 业务结果 | 已定义的关键事件与率，注明分母 | GA4/业务系统 | 业务负责人 |
| 技术健康 | 状态码、速度、标签、Consent、异常请求 | 日志/浏览器测试 | 技术负责人 |
| 本周单一改动 | 改什么、假设、版本、发布日期 | 变更记录 | 执行人 |
| 复核日期 | 至少等待处理窗口和足够样本后再判断 | 周报日历 | 编辑负责人 |
常见问题
GA4 能看到 ChatGPT 在答案里引用了我的文章吗？
不能。GA4 可以记录用户从被识别的 AI 助手点击进入后的会话，但没有点击就没有一次普通站内会话。Microsoft 生态的引用应看 Bing Webmaster Tools AI Performance；其他平台是否提供发布者数据取决于其当前产品。
Bing AI Chat 的点击会算 Organic Search 还是 AI Assistant？
取决于实际引荐信息和 GA4 当前渠道规则。不要只看渠道名：同时查看 Session source/medium、Landing page，并与 Bing Search Performance 的 Web/Chat 来源交叉核验。不同系统的归类和处理时间不完全一致。
为什么 GA4 看不到搜索关键词？
GA4 的来源报告主要回答渠道、来源/媒介与落地行为，不提供完整自然搜索查询。Bing 查询用 Bing Webmaster Tools Search Performance；Google 查询用 Search Console。再把查询层与 GA4 的落地页和事件层按 URL、日期对齐。
应该把 scroll 标记为关键事件吗？
通常不需要。scroll 是参与信号，不一定代表用户解决问题或产生业务价值。更适合作为诊断指标；注册、明确咨询、完成下载等真正重要且定义稳定的动作才考虑标为关键事件。
GA4 数据和 Bing 点击数对不上，哪个是错的？
未必有一个错。Bing 统计搜索/聊天点击，GA4 需要页面执行标签并受 Consent、拦截、网络、会话规则和处理时间影响。先统一日期、时区、URL、来源和数据截止时间，再检查标签与日志；不要强求两个不同口径逐条相等。
自定义 AI 渠道正则应该多久更新？
建议每月至少查看一次新来源，产品发布或域名变化时额外复核。更新前用历史 Session source 样本测试误收和漏收，记录正则版本、修改人和生效日期。原生 AI Assistant 已满足需求时，不要为了“更高级”增加维护成本。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 19 日复核。旧稿仍以“Tracking ID”、泛化人口统计与 Universal Analytics 迁移为主，未区分首次用户、会话和事件范围，也没有说明 2026 年新增的 AI Assistant 渠道、Bing AI Performance、Consent、Direct、PII 与数据处理延迟。本次重写删除无法复核的泛化收益与“完整掌握用户”暗示，依据 Google Analytics 与 Microsoft Bing 官方资料建立“引用/曝光—点击—站内行为—关键事件”的分层测量方法；同意图旧稿 89796 仅在本页通过实页质量验收后合并。本站的来源、更新与纠错原则见关于本站与编辑规范。
主要来源与核验日期
- Google Analytics 更新日志：2026-05-13 AI Assistant 渠道、媒介和广告系列值；
- Custom channel groups：AI assistants 示例、顺序、回溯与属性限制；
- Traffic-source dimension scopes：First user、Session 与事件范围；
- Set up Analytics与Outbound clicks：安装、Realtime 与增强型衡量；
- Direct / none、Consent signal与PII 最佳实践：来源缺失、同意与隐私边界；
- Bing Search Performance：查询、页面、Web/Chat 展现与点击；
- Bing AI Performance 公测公告：引用、被引页面、grounding queries 与解释边界。
资料复核日期：2026 年 7 月 19 日。GA4 渠道规则、识别来源、界面、数据限制和 Bing AI Performance 公测能力可能变化；实施前应重新打开官方页面并用自己的属性与日志验证。
