如何借助WhatsApp API与Cloud Functions区分多活动宾客的RSVP响应

一、通过WhatsApp Webhook Payload区分活动 #

可以直接在发送邀请时，给快速回复按钮的payload嵌入活动唯一标识，用户回复时webhook会返回该payload，以此精准对应到目标活动：

• 发送邀请模板时，给每个快速回复按钮的payload字段添加活动ID，格式自定义（比如RSVP_{状态}_{活动ID}）：

  {
    "type": "button",
    "sub_type": "quick_reply",
    "parameters": {
      "payload": "RSVP_ATTENDING_wedding_001",
      "text": "我将参加"
    }
  }
  

• 在Cloud Functions的webhook监听函数中，解析用户回复的payload字符串，提取出RSVP状态和活动ID（用字符串分割或正则匹配即可）。

二、重构Firestore数据库结构 #

核心是让RSVP记录与活动强关联，推荐两种可行方案：

方案1：活动文档下的RSVP子集合 #

• 新增events集合，每个活动对应一个文档（文档ID用活动唯一标识，比如wedding_001）
• 每个活动文档下创建rsvps子集合，子集合的文档ID用宾客手机号（或宾客唯一ID），文档字段包含：
  • status: RSVP状态（ATTENDING/DECLINED/UNDECIDED）
  • guestPhone: 宾客手机号
  • updatedAt: 响应时间戳
• 优势：天然隔离不同活动的RSVP，查询某活动的所有RSVP直接访问子集合，性能更优

方案2：独立RSVP集合+复合索引 #

• 保留独立的rsvps集合，但每个RSVP文档必须包含eventId（活动唯一标识）和guestPhone字段
• 文档ID可以用{guestPhone}_{eventId}的组合（避免重复），或者自动生成ID，同时创建复合索引（guestPhone + eventId）
• 优势：集中管理所有RSVP数据，跨活动查询宾客的所有响应更方便

三、修改Cloud Functions逻辑 #

1. 解析webhook payload中的活动ID和RSVP状态
2. 根据选定的数据库方案更新对应记录：
   • 方案1的更新代码示例：

     const { eventId, status, guestPhone } = parsedPayload;
     await db.collection('events').doc(eventId)
       .collection('rsvps').doc(guestPhone)
       .set({ status, updatedAt: Date.now() }, { merge: true });
     

   • 方案2的更新代码示例：

     const { eventId, status, guestPhone } = parsedPayload;
     // 用组合ID作为文档键
     const docId = `${guestPhone}_${eventId}`;
     await db.collection('rsvps').doc(docId)
       .set({ guestPhone, eventId, status, updatedAt: Date.now() }, { merge: true });
     

3. 原有数据迁移：编写一次性脚本，将bucket集合中旧的RSVP记录关联到对应活动后，迁移到新结构中

四、临时方案替代优化 #

如果暂时不想大规模重构，可以先在发送模板时给每个活动的按钮设置不同payload，比如婚礼A的“参加”payload是A_YES，婚礼B是B_YES，然后在Cloud Functions中根据payload区分活动，手动对应到不同的存储路径。但这种方式扩展性差，长期建议采用前面的结构化方案。

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