GA4报告中page_path等维度的路径特殊字符能否不做URL编码？

问题原因 #

出现编码差异不是埋点上报错误：Debug视图、实时报告读取的是采集到的原始事件值，不会做二次URL转码；但GA4内置的page path and screen class维度在标准报告的加工链路里，会对非路径段的特殊字符做强制URL编码，#作为锚点分隔符会被默认转成%23，这个是标准报告的内置逻辑，没有公开的全局开关可以直接关闭。

可行解决方案 #

按落地优先级从高到低排：

• 方案1：手动上报页面路径，绕过自动编码逻辑（一劳永逸）
  不要依赖GA自动采集的页面路径，在page_view事件上报时主动传入带原始#的路径值，GA不会对手动传入的page_path参数做强制转码。
  用gtag.js部署的话，配置代码参考：

  // 替换为自身GA4衡量ID
  gtag('config', 'G-XXXXXXXXXX', {
    page_path: window.location.pathname + window.location.hash
  })
  

  用GTM部署的话，直接在GA4配置代码的「要设置的字段」里添加page_path，值取{{Page Path}}{{Fragment}}即可。配置完成后，所有报告里都能正常显示/about/howto#faq格式的路径。
• 方案2：用探索报告替代内置标准报告（零埋点改动）
  GA4的探索（Explore）报表对page path and screen class维度的渲染逻辑和实时报告一致，不会强制转码#字符。直接新建自由探索报表，拖入需要的维度、指标，筛选对应数据范围即可看到正常格式的路径，适合不想调整现有埋点的场景。
• 方案3：导出后批量替换（历史数据兜底）
  已经上报的历史数据如果需要修正格式，直接把报表导出为表格/CSV后，全局把字符串里的%23替换回#即可。页面路径里不会出现其他场景的%23编码，替换不会产生误改问题。

注意：不要为了绕过编码在上游提前做反转义（比如把#提前写成%2523），会导致实时报告、Debug视图里的路径显示异常，增加排查成本。

内容的提问来源于stack exchange，提问作者クジェー