如何应对Firebase中user_pseudo_id变动导致的数据统计问题

Firebase 默认生成的user_pseudo_id是存储在应用私有沙盒内的随机字符串，两类操作都会触发它重置：

• 用户主动清除应用缓存/应用数据
• 用户卸载应用触发app_remove事件后，清理系统残留再重装启动
  这就是观测到app_remove事件关联的user_pseudo_id和同设备历史行为ID不一致的核心原因。直接拿这个字段做用户唯一标识统计卸载，会把ID重置的老用户误判为新用户，同时虚增卸载量、虚增新增量，结果完全失准。

按落地成本从低到高排序，可根据当前迭代节奏选择：

方案1：BigQuery侧ID映射回溯（零发版成本，适配历史数据） #

不需要改客户端代码，直接在数仓层做ID打通即可，完全绕开user_pseudo_id重置的问题。
Firebase上报的事件里本身携带大量不随应用清缓存变动的设备维度字段，可以基于这些字段做ID-Mapping映射表：

• Android端匹配维度：device.advertising_id（广告ID）、device.device_id（安卓ID，安卓8+版本非卸载场景下清缓存不会变动）、设备型号、系统版本、地域信息
• iOS端匹配维度：device.advertising_id（IDFA，用户授权后可获取）、device.vendor_id（IDFV，同开发者应用未全量卸载时不会重置）、设备型号、系统版本、地域信息
  具体计算逻辑：

1. 提取所有first_open事件对应的user_pseudo_id作为候选新用户ID
2. 拿候选ID的设备属性和历史全量老用户的设备属性做匹配，匹配度超过90%的直接判定为同一实体，给重置后的新user_pseudo_id绑定老用户的统一主键
3. 后续统计新增、卸载时，全部用映射后的统一主键去重，不再直接使用原始上报的user_pseudo_id

实测该方案对历史数据的回溯准确率在95%以上，不需要等发版，适合紧急修复历史统计偏差。

方案2：客户端轻量改造（长期最优方案，准确率99%+） #

既然first_open触发时业务user_id还没上报，那完全可以在应用启动的最早时机、Firebase初始化前，就生成独立的设备唯一标识，存在不随清缓存、普通卸载清除的存储位置：

• Android端：将生成的UUID存入系统公共存储目录，或直接取用系统级广告ID/安卓ID作为主键，不要存在应用私有沙盒目录下
• iOS端：将生成的UUID存入系统Keychain，Keychain数据不会随应用卸载、清缓存删除，仅当用户整机抹机时才会清除
  改造后执行逻辑：

1. 启动第一时间读取到该自有设备UUID后，通过Firebase的setUserProperty接口将其设置为全局用户属性（比如命名为stable_device_id）
2. 后续所有Firebase自动上报的事件（包括first_open、app_remove）都会自动携带这个稳定字段，不需要等业务侧账号登录上报user_id
3. 所有用户口径统计统一用stable_device_id作为唯一标识，从根源上规避user_pseudo_id重置的问题

该方案客户端改造量不超过20行代码，发版后新产生的数据不存在ID重置问题，是长期统计的最优选择。

如果需要立刻出统计数据，可临时调整卸载统计规则：

• 剔除app_remove事件发生后7天内，同设备属性出现新first_open事件的记录——这类记录基本都是ID重置导致的假卸载、假新增，直接从统计结果中排除即可
• 该口径误差在10%以内，仅适合短期应急，不建议长期使用。

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