Google Analytics

Google Analytics 是 Google 面向网站和应用的数字分析平台，当前主流程围绕 GA4 的事件模型展开。它可以把页面访问、互动、来源、关键业务动作和收入整理成报告，帮助团队观察用户旅程与营销效果；但 Analytics 不是服务器日志，也不是自动生成精确用户画像的工具，报告数字会受同意、隐私阈值、处理延迟和属性设置影响。

先把账号、媒体资源和数据流接起来

1. 确定管理层级：创建或选择 Analytics 账号，再建立对应的媒体资源（Property）；团队协作前先确定谁负责管理员、编辑和只读访问。
2. 选择数据流：网站使用 Web 数据流，原生应用分别配置 Android 或 iOS 数据流。不要把测试站、生产站和不同品牌混到一个流里再靠报表过滤。
3. 安装采集代码：按官方向导部署 Google tag，或通过 Google Tag Manager 管理标签；上线前确认同意信号、跨域、子域和登录路径的测量方案。
4. 验证最小事件：用 DebugView、实时报告和浏览器网络请求检查 page_view、会话及一个可复现的自定义事件，再开始设计复杂漏斗。

接入成功只代表数据能到达属性，不代表所有历史访问都会补回，也不代表每个浏览器、地区或拒绝同意的用户都能被完整测量。发布前应把测试流量、内部访问和真实生产数据分开识别。

用事件描述用户做了什么

事件本身回答“发生了什么”，关键事件回答“哪些发生值得业务关注”。例如表单点击不一定等于有效线索，购买事件还要核对订单状态、金额、币种和退款逻辑。事件设计完成后，用 DebugView 和测试订单验证参数，再让内容和投放团队使用报告。

按问题选择报告，而不是只看首页数字

• 获取：观察用户从哪些渠道、来源和媒介进入；UTM 命名、自动标记和跨域配置错误会改变归因结果。
• 参与：查看页面与屏幕、事件、落地页、站内搜索和路径，重点关注对业务有解释力的互动而不是事件总量。
• 留存：对产品或会员业务分析回访、活跃和 cohort；新访客占比高并不自动代表内容质量更好。
• 收入：核对电商事件、金额、币种、退款和订单去重，再把 Analytics 报表与支付系统对账。
• 探索：用 Explorations 自定义漏斗、路径、分群和细分，先写清楚问题、时间范围、维度和指标，再保存可复用的探索。

标准报告适合持续监控，探索适合临时分析和验证假设。报告中的用户、会话、事件和关键事件采用不同计数口径；把它们直接相加或与广告平台的点击数对比，通常会得到看似矛盾的结果。

数据延迟与口径差异要先排查

Google 当前说明，部分归因结果会在事件记录后继续调整，迟到数据也可能随后进入报告；标准报告与探索分析并非始终同步。因此日报或投放复盘应注明导出时间，避免把尚未完成处理的数字当作最终结果。

排查时固定属性、日期、时区、过滤器和 URL 集合，保存报告截图或导出时间。若要评估内容或 SEO 变化，可把 Analytics 的入口与转化和 Google Search Console 的查询、展示、点击及索引数据按日期对齐，而不是混用指标名称。

把隐私、权限和数据保留放进上线清单

• 先确认收集目的、地区同意要求、Consent Mode 或其他同意实现，并让拒绝同意的路径按业务要求降级。
• 不要把姓名、邮箱、电话、身份证、完整订单备注或其他可直接识别个人的信息作为 URL、事件参数或用户属性发送。
• 按最小权限分配管理员、编辑、分析和查看者角色，定期清理离职账号、服务账号与第三方关联。
• 在属性层面审查数据保留、用户删除、数据共享、Google signals、广告个性化和跨产品链接；这些设置会改变可用数据。
• 把 Analytics 报告与支付、CRM、服务器日志或 Matomo（原名 Piwik） 的口径差异记录下来，不能把一个工具的用户 ID 当作全站统一身份。

标准 Analytics 与 Analytics 360 的服务等级、企业支持和部分能力不同，功能名称、保留选项和政策会更新。涉及医疗、金融、儿童或跨境数据时，应让法务和隐私负责人根据适用法规审查配置，本文不替代合规意见。

从一次接入走向可复用的测量计划

建议为每个关键事件记录名称、触发条件、参数、数据来源、去重方式、负责人和验证日期；为每个报告记录问题、筛选条件、口径和行动。这样，Analytics 才能从“装了统计代码”变成可复盘的测量系统。若要自动化拉取或连接数据仓库，应再查当前 Google Analytics Data API 的权限、配额和字段文档，并为版本变更与数据延迟保留缓冲。

官网：https://marketingplatform.google.com/about/analytics/