Amazon Personalize曝光追踪跨服务数据同步方案咨询

1. 统一会话上下文存储，打通跨服务数据 #

核心是用中间存储层（比如AWS DynamoDB或Redis）保存用户的推荐会话数据，让Flask和Lambda都能读写：

• Flask调用get_recommendations()成功后，立即将以下数据写入存储，关联用户ID/唯一会话ID：
  • 完整推荐商品列表
  • 本次请求的recommendationId
  • 会话创建时间、过期时间（避免无效数据堆积）
• Lambda处理Segment交互事件时，先通过用户ID从存储中拉取当前有效的推荐会话数据，将交互事件与对应的recommendationId绑定后，调用Personalize的put_event()提交交互事件，同时更新存储中的交互记录（标记该商品已被用户交互）

2. 整合曝光事件提交逻辑，确保数据完整性 #

不要让Flask或Lambda单独处理曝光事件，而是基于会话存储的完整数据来提交：

• 当用户成功加载推荐页面后，前端触发一个"曝光完成"的请求到Flask
• Flask从存储中取出该用户当前会话的推荐列表、recommendationId，以及已记录的交互记录
• 调用Personalize的put_event()提交曝光事件，在事件参数中：
  • 用recommendationId关联推荐请求
  • 在itemId字段传入完整推荐商品列表
  • 额外添加自定义属性（比如interacted_items）标记已被用户交互的商品，帮助Personalize优化推荐结果
• 提交完成后，在存储中标记该会话的曝光事件已提交，避免重复操作

3. 事件关联与幂等控制 #

• 给每个推荐会话生成唯一的sessionId，Flask、Lambda、Personalize全程使用这个ID关联所有相关事件（推荐请求、曝光、交互）
• 在存储中记录每个sessionId的事件状态（曝光是否提交、交互事件是否已处理），避免重复提交或漏处理
• 确保所有调用put_event()的请求都携带正确的userId、sessionId和recommendationId，让Personalize能准确关联用户行为与推荐结果

4. 可选：合并事件处理入口简化数据流 #

如果业务架构允许，可将Lambda的交互事件处理逻辑迁移到Flask，让Flask成为事件处理的统一入口：

• 前端将用户交互事件直接发送到Flask，而非Segment
• Flask收到交互事件后，直接调用Personalize的put_event()提交，同时更新会话存储中的交互记录
• 这种方式下，Flask天然拥有推荐数据和交互数据，无需跨服务同步，可直接完成曝光事件的提交

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