Phoenix — Tinder's Testing Platform, Part I

Bài tóm tắt Tinder 2019 3. Quy mô lớn Độ khó: Trung bình

Tinder · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 1/3 của series về nền tảng experimentation Phoenix ("testing" ở đây là A/B test, không phải kiểm thử phần mềm). Phần 2: Tinder 2019 (Levers, remote config); phần 3: Tinder 2020 (pipeline metric). Đọc qua trình duyệt, raw/ chỉ là placeholder.

Bối cảnh

  • Tinder dùng thí nghiệm để quyết định thay đổi sản phẩm và tự dựng Phoenix để quản lý mọi thí nghiệm.
  • Bốn thành phần: Ground Control (vòng đời thí nghiệm: tạo, sửa, rollout, kết thúc), Assignment (user nhận treatment nào), Levers (SDK phía client áp treatment, phần 2), Metrics System (thu event client/server, xử lý hằng ngày, phần 3).

Thay đổi chính

  • Các trục cấu hình độc lập nhau:
    • Trước hay sau đăng nhập: pre-auth dùng device ID làm đơn vị (ví dụ thử luồng đăng ký), post-auth dùng user ID (đổi máy vẫn cùng trải nghiệm).
    • Phía client hay server: thí nghiệm client truyền thống phải đi kèm một bản phát hành app (ngày tới tuần); Levers xoá khoảng cách đó.
    • Sticky hay không: sticky giữ treatment khi user đổi thuộc tính (máy, vùng); trải nghiệm giới hạn theo địa lý thì không nên sticky.
  • Experiment family: gom các thí nghiệm có thể ảnh hưởng lẫn nhau; trong một family, user chỉ vào một thí nghiệm, phân xử theo độ ưu tiên. Tránh việc không quy được tăng/giảm metric về thí nghiệm nào.
  • Gán bằng hash: hash định danh rồi lấy mod để chọn treatment. Chỉ hash định danh thì cùng một user rơi vào control ở mọi thí nghiệm, nên thêm experiment ID làm salt (ghép từ family và thí nghiệm). Muốn xáo lại phân bổ (lỗi, chạy lại, phiên bản 2) thì thêm shuffle ID.
  • Feature gating khác thí nghiệm: gating là kiểm soát (đủ điều kiện, ví dụ ở nước thử nghiệm, thì thấy tính năng); thí nghiệm là so sánh (người đủ điều kiện còn bị chia tiếp thành các treatment).

Vì sao

  • Nhiều team cùng thử nghiệm trên một sản phẩm; không có family và salt thì các thí nghiệm nhiễm lẫn nhau và cùng một nhóm user luôn gánh control.

Bài học cho SWE

  • Phân bổ bằng hash là tất định và không cần lưu trạng thái, nhưng phải chọn salt cẩn thận để các thí nghiệm độc lập, và để dành một núm (shuffle ID) cho lúc cần xáo lại.
  • Tách rõ cờ tính năng dùng để kiểm soát rollout và thí nghiệm dùng để đo; dùng lẫn thì kết luận đo lường bị nhiễu. Cờ dùng xong cũng thành nợ cần dọn (DoorDash 2026).

Liên quan