GA4 高级配置实战：事件追踪与转化漏斗完整指南

2023 年 7 月 1 日，Google 彻底关闭了 Universal Analytics 的数据收集。那天早上打开后台，看着 UA 报表里戛然而止的数据线，我脑子里只有一件事：GA4 这玩意儿到底该怎么用？

如果你跟我一样，从 UA 迁移过来后只配了个基础代码，看着 GA4 界面一脸懵——别慌，你不是一个人。很多站长都在”裸奔”：页面浏览有人看，但用户点击了什么按钮、读了多少文章、在哪个步骤流失，这些真正有价值的数据，一个都没抓到。

这篇文章不讲 GA4 是什么，讲点实在的：怎么用事件追踪看清用户行为，怎么用转化漏斗找到流失点，以及——如果你有深度分析需求——怎么把数据导到 BigQuery 自己写 SQL 查询。咱们从三种事件类型开始。

一、GA4 事件追踪的三种类型

GA4 的核心逻辑跟 UA 完全不同。UA 是”会话 + 页面浏览”模型，GA4 是”一切皆事件”。

这句话你可能听过很多次，但到底意味着什么？简单说：页面浏览是事件，按钮点击是事件，视频播放是事件，滚动到页面底部也是事件。所有用户行为，在 GA4 里都是独立的”事件”记录。

但事件不是随便建的。Google 把事件分成了三类，各有各的用法和限制。

1. 自动事件（Enhanced Measurement）：开箱即用

这是 GA4 给的”免费午餐”。创建数据流的时候，默认就开启了 Enhanced Measurement，自动追踪 7 种交互：

• 页面浏览（page_view）
• 滚动（scroll）——但只追踪 90% 滚动深度
• 出站点击（click）
• 站内搜索（search）
• 视频互动（video_start、video_progress、video_complete）
• 文件下载（file_download）
• 表单互动（form_start、form_submit）

听起来挺全的，对吧？但这里有个坑：滚动追踪只记录用户滑到页面 90% 的时候。如果你想知道有多少人读完了文章，或者想在 50%、75% 这些节点追踪阅读进度，Enhanced Measurement 做不到——得自己用 GTM 配。

我的建议：Enhanced Measurement 保持开启，但别太指望它。它给你的是基础数据，真正有价值的用户行为，还是得自己动手。

2. 推荐事件：跟着 Google 的剧本走

Google 为不同行业预定义了一套”推荐事件”。比如电商有 add_to_cart、begin_checkout、purchase，内容站点有 sign_up、login、share。

推荐事件的好处是：用了正确的事件名和参数，GA4 会自动生成对应的报告。比如你用了 purchase 事件，GA4 能自动生成对应的报告。

但注意，推荐事件不会自动触发。你仍然需要在网站上添加代码（或者用 GTM 配置），只是事件名和参数要严格按 Google 的规范来。

举个例子，博客站点常用的推荐事件：

事件名	触发场景	关键参数
sign_up	用户注册成功	method（注册方式）
login	用户登录成功	method（登录方式）
share	用户分享内容	content_type、item_id

我在自己的博客上配置了 sign_up 事件追踪订阅行为。一开始事件名写成了 signUp（驼峰命名），结果 GA4 压根不认——推荐事件必须用 snake_case，一个字母都不能错。

3. 自定义事件：想追踪啥都行，但有代价

当你需要的追踪行为不在 Google 的推荐列表里，就得自己定义事件了。比如我想追踪”用户读完一篇文章”，定义了 article_read_complete 事件。

自定义事件的自由度很高，但也有几个限制：

1. 参数上限：每个事件最多 25 个自定义参数。Simo Ahava（GA4 领域的权威）实测过，超出 25 个参数的数据仍可导出到 BigQuery，但在 GA4 原生报告里会被忽略。

2. 命名规范：只能用字母、数字、下划线，必须以字母开头。建议用 snake_case，跟推荐事件保持一致。

3. 报告延迟：自定义事件配置后，报告可能需要 24-48 小时才会在 GA4 里显示。别以为配错了，先等等。

配置优先级：一个简单决策树

如果不确定该用哪种事件类型，按这个顺序来：

1. 先看 Enhanced Measurement 有没有——开箱即用，能省则省
2. 再看推荐事件列表——跟着规范走，报告自动生成
3. 实在没有才自定义——自由度高，但维护成本也高

说实话，大部分博客站点用 Enhanced Measurement + 几个推荐事件就够了。自定义事件是给那些有深度分析需求的人准备的。

二、事件追踪实战配置

懂了三种事件类型的区别，接下来就是动手配置了。

配置 GA4 事件有两种主流方式：用 Google Tag Manager（GTM），或者直接在网页里写 gtag.js 代码。我建议用 GTM——虽然学习成本高一点，但后期维护方便多了，改个触发条件不用重新部署代码。

用 GTM 配置 GA4 事件：四步走

假设你要追踪”博客文章阅读完成”这个行为，完整流程是这样的：

第一步：创建 GA4 Event Tag

打开 GTM，新建一个 Tag，类型选择 Google Analytics: GA4 Event。填入你的 Measurement ID，事件名称填 article_read_complete。

第二步：配置 Trigger

这一步是告诉 GTM：“什么时候触发这个事件？”

对于”阅读完成”，我习惯用滚动触发：用户滚动到页面 90% 时触发。新建一个 Trigger，类型选 Scroll Depth，设置 Vertical Scroll Depths 为 90%。

但这里有个细节：如果你的博客有”阅读进度条”之类的功能，可能会和 GTM 的滚动追踪冲突。我之前踩过这个坑——页面顶部有个进度条，结果滚动事件疯狂触发，数据全是噪音。解决方案是加个限制：同一个用户同一篇文章只触发一次。

第三步：添加 Event Parameters

参数是事件的”灵魂”。光知道有人读完了文章不够，你得知道是哪篇文章、什么分类、作者是谁。

在 Tag 配置里添加 Event Parameters：

参数名	值	说明
article_title	{{Page Title}}	文章标题
article_category	{{Custom JS Variable}}	文章分类（需自己写 JS 提取）
reading_time	{{Custom JS Variable}}	预估阅读时长

参数值的类型要保持一致。如果 reading_time 填的是数字，就一直是数字；别一会儿填 5，一会儿填 "5分钟"——GA4 会把这两个当成不同的参数处理。

第四步：Debug 验证

配置完别急着发布。用 GTM 的 Preview 模式测试一下：打开你的博客页面，滚动到 90%，看看 GA4 DebugView 里有没有收到事件。

DebugView 在 GA4 后台的 Configure > DebugView 里开启。如果没看到事件，检查 Trigger 条件是不是写错了；如果事件收到了但参数没值，检查 Variable 配置。

不想用 GTM？gtag.js 直接配置

如果你博客用的是静态生成器（比如 Astro、Hugo），不想引入 GTM 的复杂性，直接写 gtag.js 代码也行。

// 在页面加载完成后执行
window.addEventListener('load', function() {
  // 滚动到 90% 时触发
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

这段代码干的事跟 GTM 配置一样：滚动到 90% 时发送 article_read_complete 事件。区别是，代码写死在页面里，以后改起来要重新部署。

常见坑点（都是我踩过的）

坑一：事件命名不规范

articleReadComplete、article-read-complete、article_read_complete——这三个在 GA4 里是三个不同的事件。推荐全部用 snake_case，跟 Google 官方保持一致。

坑二：参数值类型不一致

今天传 reading_time: 5，明天传 reading_time: "5 minutes"，后天传 reading_time: true。GA4 会把这三个当成三个不同的参数，报告里乱成一锅粥。

坑三：Consent Mode v2 导致事件被过滤

如果你的网站面向欧盟用户，启用了 Google Consent Mode v2，用户拒绝 Cookie 的话，部分事件可能不会发送。这不算错误，但报告数据会”缩水”——别以为配置有问题。

坑四：事件名称和参数名称用了保留字

page_view、session_start、first_visit 是 GA4 的保留事件名，别拿来当自定义事件用。参数名也有保留字列表，配置前查一下官方文档。

博客站点实战示例

针对博客场景，我整理了几个常用的事件配置：

行为	事件名	关键参数
文章阅读完成	article_read_complete	article_title、category、author
评论提交	comment_submit	article_title、comment_length
订阅按钮点击	newsletter_click	button_location、article_title
目录导航点击	toc_click	section_title、article_title

这些事件配置完，你就能在 GA4 里看到用户在博客上的真实行为了。接下来，该分析这些行为数据了——这就需要转化漏斗。

三、转化漏斗配置与分析

事件追踪配置好了，接下来该回答一个核心问题：用户从”第一次来”到”完成你的目标行为”，中间流失了多少人？

这就是转化漏斗要解决的问题。

GA4 的 Funnel Exploration 报告比 UA 强太多。UA 的漏斗报告固定死板，GA4 可以自定义每个步骤、添加细分对比、分析流失时间——基本上把付费工具的功能搬进了免费版。

创建第一个转化漏斗

打开 GA4，进入 Explore > Funnel Exploration。你会看到一个空白的漏斗模板。

第一步是定义”漏斗步骤”。最多可以定义 10 步，但实际用起来，博客站点通常 4-5 步就够了。

举个博客订阅漏斗的例子：

1. 第一步：文章页面浏览（event: page_view，条件：page_location 包含 /posts/）
2. 第二步：访问订阅页（event: page_view，条件：page_location 包含 /subscribe）
3. 第三步：提交订阅表单（event: newsletter_signup）
4. 第四步：确认邮件打开（event: email_opened）——这个需要邮件系统配合追踪

定义步骤的时候，有个技巧：每一步的条件尽量简单明确。复杂的条件组合会让漏斗数据变得难以解读。

漏斗分析：找到流失点

漏斗配置好后，你会看到每一步的转化率和流失人数。

假设我的博客订阅漏斗数据是这样的：

步骤	用户数	转化率（从上一步）
文章页面浏览	10000	-
访问订阅页	800	8%
提交订阅表单	240	30%
确认邮件打开	180	75%

一眼就能看出来：第一个流失点是”文章页面 → 订阅页”，只有 8% 的用户会去订阅页。这说明订阅入口不够显眼，或者订阅页面的入口位置不对。

第二个流失点是”订阅页 → 提交表单”，30% 的转化率。这可能是表单太长、或者订阅价值不够明确。

找到流失点后，下一步是——对比细分数据，看看流失有没有规律。

细分对比：找出”谁”在流失

Funnel Exploration 支持添加细分（Segments），对比不同用户群体的转化差异。

常用的细分维度：

• 新用户 vs 回访用户：新用户转化率通常更低，因为他们不了解你的内容价值
• 移动端 vs PC端：移动端表单填写体验往往更差
• 来源渠道：搜索引擎来的用户 vs 社交媒体来的用户

举个例子，我对比新用户和回访用户的订阅漏斗：

步骤	新用户转化率	回访用户转化率
文章页面 → 订阅页	5%	15%
订阅页 → 提交表单	25%	40%

回访用户每一步转化率都更高——这很正常，他们已经认可你的内容。但新用户的”文章页面 → 订阅页”只有 5%，说明新用户根本没注意到订阅入口。

针对这个发现，我在文章末尾加了一个醒眼的订阅卡片，新用户转化率从 5% 提到了 12%。

Open Funnel：分析用户路径多样性

Funnel Exploration 默认是”线性漏斗”：用户必须按顺序完成每一步，才会被计入转化。

但实际用户行为没那么规矩。有些用户可能跳过订阅页，直接在文章底部提交订阅；有些用户可能打开确认邮件后，又回到文章页面再读一遍。

GA4 提供了一个”Open Funnel”模式：不强制顺序，只要用户完成了某个步骤，就算进入那个步骤。

Open Funnel 能帮你发现”非典型路径”，有 15% 的订阅用户是从文章底部直接提交的，根本没去过专门的订阅页。这说明文章底部的订阅入口比专门的订阅页更有效——我应该把更多精力花在调整文章底部的订阅体验，而不是订阅页。

漏斗分析的几个常见误区

误区一：只看最终转化率

从第一步到最后一步的”总转化率”当然重要，但中间步骤的流失点才是改进的关键。别只盯着”1.8% 的用户完成了订阅”，要看”哪一步流失了 92% 的用户”。

误区二：忽略时间维度

Funnel Exploration 可以设置”转化时间”——用户从第一步到完成最后一步花了多久。如果你的漏斗是”阅读 → 订购 → 支付”，用户从阅读到支付花了 7 天，说明决策周期长，可能需要加强信任建设或增加催付触达。

误区三：数据太少就分析

漏斗分析需要足够的数据量。如果某个步骤只有几十个用户，转化率的波动会很大，结论可能不靠谱。建议数据量达到几百以上再做深度分析。

四、BigQuery 数据导出实战

前面讲的都在 GA4 界面里操作。但 GA4 原生报告有个限制：数据量大的时候会抽样。比如你的博客有 50 万月活用户，GA4 报告可能只基于 10% 的数据样本生成。

抽样不是坏事——它能提高报告加载速度。但如果你要做精确的转化率分析、或者想组合十几个维度看数据，抽样结果就不靠谱了。

这时候，BigQuery 导出就是你的救星。

BigQuery 导出配置：三步搞定

BigQuery 是 Google 的数据仓库服务。把 GA4 数据导出到 BigQuery，你就能用 SQL 查询全量数据，不受抽样限制。

配置步骤很简单：

第一步：创建 BigQuery 项目

在 Google Cloud Console 创建一个项目，启用 BigQuery API。新用户有免费额度：每月 10GB 存储、1TB 查询处理量，对于博客站点绰绰有余。

第二步：在 GA4 里配置导出

打开 GA4 Admin，找到 BigQuery Linking。点击 Link，选择你的 BigQuery 项目，然后选择导出频率：

• Daily：每天导出一次前一天的数据
• Streaming：实时导出（几小时内就能看到当天数据）

我建议两个都开。Daily 导出数据结构更稳定，适合做长期分析；Streaming 导出适合看当天的实时数据。

第三步：等待数据开始流动

配置完成后，GA4 会在 24 小时内开始导出数据。但有个坑要注意：BigQuery 导出没有历史回填。你今天配置，只能从今天开始拿到数据，过去两年的 GA4 数据不会自动倒进来。

所以，如果你有深度分析需求，尽早配置 BigQuery 导出。别等到需要历史数据的时候才发现——已经来不及了。

BigQuery 数据结构：一眼看懂

GA4 导出到 BigQuery 的数据，每天是一个表，表名格式是 events_YYYYMMDD。比如 events_20260429 存的是 2026 年 4 月 29 日的事件数据。

每条记录就是一个事件，字段包括：

字段	说明
event_name	事件名称（如 page_view、article_read_complete）
event_timestamp	事件发生时间（微秒级 Unix 时间戳）
user_pseudo_id	用户匿名 ID（同一用户的跨设备识别）
event_params	事件参数（嵌套结构，需要用 SQL 展开）
geo	地理位置（国家、城市）
device	设备信息（浏览器、操作系统、设备类别）

这里有个新手容易卡住的地方：event_params 是嵌套字段，不是简单的列。要查参数值，得用 UNNEST 展开。

几个实用的 SQL 查询

查询某事件的用户数：

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

这段 SQL 计算的是：4 月份有多少独立用户完成了文章阅读。

查询某事件参数的分布：

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

这段 SQL 展开了 event_params，统计不同文章分类的阅读完成用户数。

BigQuery vs GA4 原生报告：什么时候用哪个？

场景	用 GA4 原生报告	用 BigQuery
快速查看每日流量	是	-
查看转化漏斗	是	-
组合超过 4 个维度分析	-	是
精确计算转化率（无抽样）	-	是
导出数据给其他工具（Looker、Python）	-	是
实时监控（当天数据）	是（Streaming）	是（Streaming）

简单说：日常看报告用 GA4 界面，深度分析用 BigQuery。

BigQuery 的成本控制

BigQuery 按查询处理的数据量收费。博客站点数据量不大，成本通常可控，但也要注意几个节省技巧：

1. 用 _TABLE_SUFFIX 限制日期范围：别查全表，只查你需要的日期
2. 用 WHERE 条件过滤：越早过滤，处理的数据越少
3. 创建物化视图：频繁查询的数据可以预聚合

我的博客每月数据量大概 1GB，查询量不超过 100GB/月——完全在免费额度内。大站点可能需要关注成本，但中小博客不用担心。

五、GA4 vs UA：迁移者必须知道的差异

如果你是从 UA 迁移过来的老站长，这一章专门写给你的。

GA4 和 UA 的差异不只是界面换了换，底层逻辑完全变了。很多”理所当然”的概念，在 GA4 里要么不存在，要么定义改了。

事件模型 vs 会话模型

UA 的核心是”会话”：用户来了，逛了一圈，离开——这是一个会话。一个会话里可能有多个页面浏览、多个事件。

GA4 的核心是”事件”：每个用户行为都是独立的原子单位。会话变成了事件的集合，而不是分析的起点。

这意味着什么？

在 UA 里，你习惯看”会话数”、“每次会话的页面浏览数”。在 GA4 里，这些概念被”事件数”、“用户数”替代了。

GA4 仍然有”会话”的概念，但它不再强调会话，而是强调”用户旅程”。一个用户可能在上午打开你的博客，下午又回来——在 UA 里这是两个会话，在 GA4 里这只是一个用户的多次访问。

Engagement Rate vs Bounce Rate

UA 的”跳出率”（Bounce Rate）是很多站长的执念：跳出率越低越好，说明用户留住了。

但在 GA4 里，跳出率没了。取而代之的是”互动率”（Engagement Rate）。

为什么？因为 UA 的跳出率定义有问题：用户只看了一个页面就离开，算是”跳出”。但如果用户只看了一个页面，读了 10 分钟，认真把文章看完了——UA 仍然算这是”跳出”。

GA4 的互动率定义更合理：用户在你的网站上停留超过 10 秒、或者发生了至少一个转化事件、或者浏览了超过 2 个页面，就算”有互动”。互动率 = 有互动的会话 / 总会话数。

所以，别拿 GA4 的互动率和 UA 的跳出率直接对比。它们不是相反的概念，而是不同的衡量标准。

Data Streams vs Views

UA 有”视图”（Views）的概念：你可以创建多个视图，每个视图有不同的过滤器。比如一个视图只看国内流量，另一个视图排除内部 IP。

GA4 没有视图了。取而代之的是”数据流”（Data Streams）：Web、iOS App、Android App 各一个数据流。

过滤功能怎么办？GA4 用”Property Filters”替代——但功能比 UA 的视图过滤弱很多。只能过滤内部流量、垃圾流量，没法像 UA 那样创建多个”看不同数据”的视图。

如果你习惯用 UA 的视图做多维度数据隔离，迁移到 GA4 后需要重新规划数据架构。要么用 BigQuery 导出后自己过滤，要么用 Looker Studio 创建多个报告视图。

UA Goal 需要重新映射

UA 的”目标”（Goals）在 GA4 里变成了”转化事件”（Conversion Events）。

配置方式也变了。UA Goal 可以是”访问某个页面”、“停留超过 X 分钟”、“触发某个事件”。GA4 的转化事件只能是”某个事件发生”——你想追踪页面访问作为转化，需要先配置一个 page_view 事件，再把 page_view 标记为转化。

迁移的时候，把 UA Goals 一个个列出来，重新映射成 GA4 的转化事件。这个过程繁琐但必要——否则历史转化数据没法延续。

写在最后

说了这么多，其实就四件事：

1. 事件追踪：搞清楚三种类型（自动、推荐、自定义），按优先级配置
2. 转化漏斗：找到流失点，对比细分数据，用 Open Funnel 发现非典型路径
3. BigQuery 导出：有深度分析需求就早点配，历史数据没法回填
4. 迁移心态：别拿 UA 的指标硬套 GA4，适应新逻辑

如果你读完这篇文章，能立即做一件事，我建议是：打开 GA4，检查 Enhanced Measurement 有没有开启，然后创建一个 3-4 步的转化漏斗，分析你的博客订阅流程。

数据不会自己告诉你答案，但会告诉你问题在哪。剩下的，就是想办法解决问题了。

---

参考资料

• Set up events | Google Analytics | Google for Developers — GA4 官方事件配置文档
• Recommended events - Analytics Help — 推荐事件列表
• Enhanced measurement events - Analytics Help — 自动事件说明
• Funnel Exploration Report in GA4 - Analytics Mania — 漏斗报告详解
• GA4 BigQuery Export Schema Tutorial - Optimize Smart — BigQuery 导出教程

配置 GA4 事件追踪和转化漏斗

从零开始配置 GA4 事件追踪，创建转化漏斗分析用户行为

⏱️ 预计耗时: 60 分钟

1. 1

   步骤1: 开启 Enhanced Measurement 自动事件

   在 GA4 后台进入 Admin > Data Streams > 选择你的数据流，确保 Enhanced Measurement 已开启。默认追踪 7 种交互：页面浏览、滚动、出站点击、站内搜索、视频互动、文件下载、表单互动。
2. 2

   步骤2: 配置推荐事件或自定义事件

   根据追踪需求选择事件类型：
   
   • 推荐：博客用 sign_up、login、share 等推荐事件
   • 自定义：article_read_complete、newsletter_click 等自定义事件
   • 命名规范：统一使用 snake_case，避免驼峰或连字符
3. 3

   步骤3: 用 GTM 配置事件触发器

   在 GTM 中：
   
   1. 创建 GA4 Event Tag，填写 Measurement ID
   2. 配置 Trigger（如 Scroll Depth 90%）
   3. 添加 Event Parameters（article_title、category 等）
   4. 用 Preview 模式测试验证
4. 4

   步骤4: 创建转化漏斗

   在 GA4 进入 Explore > Funnel Exploration：
   
   • 定义 4-5 个漏斗步骤
   • 每步条件尽量简单明确
   • 使用细分对比新用户 vs 回访用户
   • 开启 Open Funnel 发现非典型路径
5. 5

   步骤5: 配置 BigQuery 导出（可选）

   在 GA4 Admin > BigQuery Linking 中：
   
   • 关联 BigQuery 项目
   • 开启 Daily 和 Streaming 导出
   • 等待 24 小时数据开始流动
   • 注意：历史数据无法回填

常见问题

GA4 事件追踪的三种类型有什么区别？

三种类型分别是：Enhanced Measurement（自动事件，开箱即用但功能有限）、推荐事件（按 Google 规范配置，自动生成报告）、自定义事件（自由度高但需维护）。配置优先级：先用自动事件，再用推荐事件，最后才自定义。

GA4 的互动率和 UA 的跳出率有什么区别？

UA 的跳出率有缺陷：用户认真读完一篇文章也算跳出。GA4 的互动率更合理：停留超过 10 秒、或发生转化事件、或浏览超过 2 个页面就算有互动。两者不是相反的概念，无法直接对比。

转化漏斗分析需要多少数据量才靠谱？

建议每个步骤至少几百个用户。数据量太少（几十个用户）时，转化率波动大，结论可能不靠谱。可以先运行一段时间积累数据，再做深度分析。

BigQuery 导出收费吗？博客站点成本如何？

BigQuery 按查询数据量收费，新用户每月有 10GB 存储 + 1TB 查询的免费额度。博客站点月数据量约 1GB，查询量通常不超过 100GB/月，完全在免费额度内。大站点可能需要关注成本。

GA4 配置后多久能看到数据？

Enhanced Measurement 实时生效，推荐事件和自定义事件可能需要 24-48 小时才在报告中显示。BigQuery 导出配置后 24 小时内开始，但历史数据无法回填——所以有需求要尽早配置。

事件参数命名有什么规范？

只能用字母、数字、下划线，必须字母开头。统一使用 snake_case（如 article_read_complete），避免驼峰（articleReadComplete）或连字符（article-read-complete）。每个事件最多 25 个自定义参数。

从 UA 迁移到 GA4，需要重新配置什么？

需要重新配置：1) UA Goals 映射为 GA4 转化事件；2) 自定义维度和指标需重新定义；3) 视图功能被 Property Filters 替代（功能更弱）；4) 报表需在 Explore 中重建。建议保留 UA 历史数据访问权限，用于对比分析。

22 分钟阅读 · 发布于: 2026年4月29日 · 修改于: 2026年4月29日