GADDelayAppMeasurementInit具体延迟哪些应用测量内容？

核心生效逻辑 #

• 配置开启后（info.plist中GADDelayAppMeasurementInit设为YES/代码开启动态配置），Google Mobile Ads SDK冷启动阶段会直接跳过应用测量模块的默认自动初始化流程，不会在用户未授权的状态下触发任何用户层级数据上报。直到UMP同意流程返回结果、或者你显式触发测量模块初始化后，该模块才会正式启动工作。
• 该配置仅作用于测量模块，不会阻塞广告核心SDK的基础运行，也不会拦截广告请求接口的调用。

被延迟上报的指标范围 #

配置生效期间，以下数据会被完全拦截，不会提前缓存、也不会在用户同意后补发授权前的采集内容：

• 用户标识类数据：IDFA、设备硬件参数、系统版本、区域语言等用于受众匹配的基础字段
• 用户行为事件：应用启动事件、页面访问路径、广告交互前置埋点、转化链路追踪参数
• 归因匹配数据：用于广告转化效果归因的用户关联参数
  注：SDK自身运行的崩溃日志、非用户维度的性能诊断数据不受该配置影响，会按默认规则上报

对广告投放的影响 #

• 用户未做出同意选择前：无论是否开启延迟测量，SDK都仅返回非个性化广告，不做用户维度的广告匹配，该逻辑和UMP隐私合规的默认管控规则完全对齐，延迟配置本身不会修改这个默认行为。
• 用户同意个性化广告后：测量模块会立刻完成初始化，同步上报当前会话的必要上下文参数，后续个性化/非个性化广告的填充、投放逻辑和未开启延迟测量的表现完全一致，不会出现填充率下降、eCPM异常的问题。
• 用户拒绝个性化广告后：测量模块会保持禁用状态，仅上报聚合维度的广告填充、展示统计数据，不会关联任何用户标识，仅返回非个性化广告，符合隐私合规要求。

Google Mobile Ads SDK会在应用启动时立即初始化应用测量模块，即刻开始向Google发送用户层级事件数据……若你的应用需要先获得用户同意才能发送上述事件，可配置延迟应用测量……

开发注意点 #

公开文档未明确提及的一个实际逻辑：如果开启延迟测量后，在用户走完UMP同意流程前就主动调用广告SDK的start方法，测量模块会被立刻触发初始化，等同于延迟配置失效，开发时需要注意把SDK初始化的调用时机放在同意流程结束之后。

内容的提问来源于stack exchange，提问作者Reanimation