基于Google Places API存储用户地区信息的合规方案咨询

核心原则 #

严格区分API原始缓存数据和用户确认的业务数据，前者遵守30天缓存限制，后者可长期存储。

具体实现步骤 #

• 分离存储层级

  • 调用Google Places API返回的place_id、经纬度等原始地理数据，单独存入缓存系统（如Redis），设置30天过期时间，到期自动清理，完全符合服务条款要求。
  • 用户确认后的城市、城镇等地区级信息，直接存入业务数据库（如MySQL、PostgreSQL），与用户ID关联，作为用户的位置偏好长期保存。这类数据是用户主动确认的结果，不属于API原始数据范畴，不受缓存时长限制。

• 业务流程设计

  1. 首次位置检测：调用API获取place_id及对应地区信息，展示给用户确认。
  2. 用户确认后：将确认的地区信息写入业务库，同时将place_id存入缓存并设置30天过期。
  3. 后续业务调用：直接从业务库读取用户已确认的地区信息，无需重复调用API；仅当用户触发重新检测或缓存的place_id过期时，才重新调用API获取最新数据，再次让用户确认后更新业务库。

• 合规性验证
  确保仅对API返回的原始数据（place_id、经纬度）执行30天缓存限制，用户确认后的地区信息属于业务自有数据，不在服务条款的缓存限制范围内，完全合规。

• 异常处理机制

  • 缓存的place_id过期后，重新调用API获取最新位置数据，引导用户再次确认后更新业务库。
  • API调用失败时，暂时使用用户历史确认的地区信息，并提示用户稍后重试位置检测。

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