Chuyển đến nội dung
Tài liệu
Nhật ký thay đổiGiáMở bảng điều khiển

Hướng dẫn

Thử nghiệm trực tuyến (kiểm định A/B)

Phép so sánh ngoại tuyến của bạn nói rằng phiên bản mới tốt hơn. Một kiểm định A/B trong môi trường production đặt cùng câu hỏi đó cho người dùng thật. Bộ định tuyến của chính bạn phân ngẫu nhiên các đơn vị (người dùng hoặc phiên) vào hai nhánh; oloproof experiment đọc nhật ký của nó và trả lời bằng cùng bốn trạng thái như mọi quy tắc khác. Phương pháp này được một cuộc kiểm toán độc lập chấp nhận theo các điều kiện đã nêu: observed_until là lời bạn khai về thời điểm nhật ký kết quả được trích xuất, các đơn vị được ngẫu nhiên hóa độc lập, kết quả của không đơn vị nào phụ thuộc vào nhánh của đơn vị khác, kết quả không trôi dạt trong lúc tỷ lệ chia thay đổi, và mỗi lần xem đọc toàn bộ nhật ký. Ngoài các điều kiện đó, câu trả lời không được bảo đảm.

Nhật ký và khai báo

Hai tệp, CSV hoặc JSONL: một nhật ký phân công với một hàng cho mỗi đơn vị (cột đơn vị bạn khai báo, và arm), và một nhật ký kết quả với đơn vị và value của nó.

experiment:
  name: checkout-v2
  unit: user
  allocation: {control: 0.5, treatment: 0.5}
  control: control
  treatment: treatment
  assignments: logs/assignments.csv
  outcomes: logs/outcomes.csv
  kind: rate
  rules:
    - {id: lift, kind: superiority}
    - {id: no-harm, kind: non_inferiority, margin: 0.01}
oloproof experiment experiment.yaml --policy release.yaml --json

kind: mean nhận một range: [low, high] được khai báo; direction: max coi thấp hơn là tốt hơn. Một đơn vị được phân công mà không có hàng kết quả là bị thiếu và được chặn ở giá trị tệ nhất của nó ở mỗi phía, trừ khi missing_outcome: zero nói rằng không có hàng nghĩa là không. Ghi một hàng cho mọi đơn vị, kể cả số không: một nhật ký chuyển đổi chỉ chứa những người đã chuyển đổi sẽ đọc mọi đơn vị khác là bị thiếu, và câu trả lời vẫn là INSUFFICIENT_EVIDENCE. Việc điền số không giả định rằng cửa sổ kết quả của mọi đơn vị được tính đã đóng; một đơn vị được phân công một giờ trước chưa chuyển đổi, và tính nó là không sẽ có lợi cho nhánh chuyển đổi nhanh hơn. Hãy khai báo outcome_window_hours, as_of và observed_until (thời điểm nhật ký kết quả được trích xuất), với một cột assigned_at trong nhật ký phân công, và chỉ những đơn vị có cửa sổ đã đóng trước as_of mới được tính; missing_outcome: zero bị từ chối nếu thiếu chúng, dù theo dõi theo cách nào. Hãy viết mọi thời điểm kèm độ lệch múi giờ hoặc Z (2026-10-11T00:00:00Z); thời điểm không có cả hai bị từ chối. as_of không được muộn hơn observed_until, và không cái nào được nằm trong tương lai: một kết quả sau lần trích xuất không có trong nhật ký. Cửa sổ chọn câu hỏi: cửa sổ 48 giờ trả lời "đã chuyển đổi trong vòng 48 giờ", nên nó phải bao trùm độ trễ của kết quả bạn muốn nói đến. Mã đơn vị được so sánh như văn bản sau khi cắt khoảng trắng, với 42.0 được đọc là 42. Mã thoát là mã của quy tắc tệ nhất: 0 PASS, 1 FAIL, 3 INSUFFICIENT_EVIDENCE, 4 MANUAL_REVIEW.

Những gì nó kiểm tra trước

  • Tỷ lệ mẫu. Số đơn vị của các nhánh được kiểm định so với phân bổ đã khai báo (kiểm định nhị thức chính xác cho hai nhánh, khi bình phương cho nhiều hơn, ngưỡng 0,001). Một sai lệch khiến mọi quy tắc thành MANUAL_REVIEW: một phép chia hỏng nghĩa là các nhánh không còn so sánh được, và thêm dữ liệu cùng loại cũng không sửa được. Hãy tìm nguyên nhân (một chuyển hướng làm rơi người dùng, một bộ lọc bot chỉ áp dụng cho một nhánh) trước khi đọc bất kỳ chênh lệch nào.
  • Một đơn vị ở hai nhánh. Phân công đã bị rò rỉ; mọi quy tắc đọc là MANUAL_REVIEW.
  • Nhiều hàng kết quả cho một đơn vị. Bị từ chối, vì các sự kiện của một người dùng không độc lập. Khai báo aggregate: unit_mean để trung bình riêng của mỗi đơn vị là kết quả của nó: khi đó câu trả lời nói về người dùng trung bình, không phải sự kiện trung bình.
  • Một nhánh trống. INSUFFICIENT_EVIDENCE cho đến khi nó có kết quả.
  • Các hàng kết quả không khớp với đơn vị được phân công nào, dưới missing_outcome: zero. Các số không dựa vào phép nối, nên một phép nối hỏng sẽ đọc các đơn vị thật thành số không; mọi quy tắc đọc MANUAL_REVIEW cho đến khi các mã khớp nhau. Theo mặc định, chúng được đếm và để ra ngoài.

Cách nó quyết định

Trung bình của mỗi nhánh nhận khoảng mà Oloproof đã dùng cho một lần chạy (Clopper-Pearson chính xác cho một tỷ lệ, trung bình bị chặn dựa trên đặt cược cho các trường hợp khác), mỗi khoảng với một nửa ngân sách sai số, và chênh lệch được chặn bởi các đầu đối diện của hai khoảng. Nó đúng ở mọi cỡ mẫu và rộng hơn một khoảng chuẩn trong sách giáo khoa. Một quy tắc ưu thế đạt khi toàn bộ khoảng nằm trên không; một quy tắc không kém hơn đạt khi đầu dưới của nó bằng hoặc lớn hơn âm biên.

monitoring: anytime dùng khoảng đặt cược cho cả hai nhánh, đúng bất kể bạn xem thường xuyên thế nào và dừng lúc nào. Điều này đúng miễn là mỗi lần xem đều truyền toàn bộ nhật ký đến thời điểm đó: không bao giờ bỏ hay lọc hàng theo giai đoạn sau khi đã đọc chúng. Mặc định, fixed, được đọc một lần ở cỡ mẫu bạn đã lên kế hoạch.

Nhiều nhánh xử lý

Khai báo treatments: [b, c] thay cho treatment: và cho mỗi quy tắc biết nhánh xử lý mà nó so sánh (treatment: b). Khoảng của mỗi nhánh được lấy ở mức 1 - alpha/m cho m nhánh, nên mọi hiệu nhánh xử lý trừ nhánh đối chứng được bao phủ cùng lúc bởi cận hợp: một quy tắc cho mỗi nhánh xử lý, một khẳng định cho mỗi quy tắc, và cả họ cùng đúng. Mỗi khoảng rộng hơn so với khi có hai nhánh, vì mỗi nhánh trả giá cho các nhánh khác. Với nhiều nhánh xử lý, báo cáo nêu tên nhánh tốt nhất trong số các nhánh vượt qua mọi quy tắc nêu tên chúng, và liệu nó có tách biệt với mọi nhánh vượt qua khác không: mỗi hiệu, được chặn bởi cùng các khoảng đồng thời, loại trừ 0. Các trường hợp hòa giữ thứ tự đã khai báo và không bao giờ được tách biệt. Kiểm tra tỷ lệ mẫu đã đọc mọi nhánh. Bảo đảm chung bao phủ các nhánh của một tệp thí nghiệm: chia các nhánh xử lý ra nhiều tệp sẽ mất bảo đảm đó.

Chỉ số tỷ lệ

Tỷ lệ nhấp là số lượt nhấp chia cho số phiên, và một người dùng có nhiều phiên không phải là nhiều người dùng độc lập. Hãy khai báo tỷ lệ trên một hàng cho mỗi đơn vị, với các khoảng giá trị chứa mọi giá trị của mỗi đơn vị:

  ratio: {numerator: clicks, denominator: sessions, numerator_range: [0, 50], denominator_range: [1, 50]}
  aggregate: unit_sum   # only if a unit has several rows: they are added

Đại lượng ước lượng là tử số trung bình của mỗi nhánh chia cho mẫu số trung bình của nó. Cả hai trung bình đều được chặn bởi khoảng đã được chấp nhận, mỗi cái ở phần ngân sách sai số của nó, và tỷ lệ được chặn bằng cách chia các đầu mút của chúng, nên nó đúng ở mọi cỡ mẫu mà không cần xấp xỉ chuẩn. Một mẫu số có khoảng chạm tới 0 không cho khoảng nào. Một giá trị nằm ngoài khoảng của nó là một lỗi cấu hình nêu tên đơn vị, không bao giờ bị cắt. Khoảng của phương pháp delta, thường hẹp hơn, được hiển thị bên cạnh và không bao giờ quyết định.

Một biến đồng hành từ trước thử nghiệm

Một kết quả bám theo thứ gì đó đo được trước thử nghiệm (chi tiêu tháng trước, số phiên tuần trước) dao động ít hơn khi phần đó được loại ra. Hãy mang giá trị của mỗi đơn vị từ trước thử nghiệm và một hệ số được cố định trước khi đọc các kết quả của thử nghiệm này:

  covariate: {values: logs/pre_period.csv, range: [0, 500], theta_from: logs/history.csv}

Kết quả được quyết định là Y - theta (X - c). theta được khai báo (theta:, với center: tùy chọn, mặc định là điểm giữa của khoảng), hoặc được khớp trên một tệp lịch sử từ một giai đoạn trước thử nghiệm (các cột covariate và outcome), không bao giờ trên chính các kết quả của thử nghiệm này. Vì X được đo trước khi phân nhánh, và đơn vị nào có X cũng đã được cố định trước khi phân nhánh, hiệu đã điều chỉnh có cùng đại lượng ước lượng. Một đơn vị không có giá trị trong tệp thì không được điều chỉnh. Một điều chỉnh hợp lệ vẫn có thể rộng hơn khi không điều chỉnh, vì khoảng giá trị của kết quả đã điều chỉnh rộng hơn, nên báo cáo hiển thị cả hai khoảng và nói khoảng nào hẹp hơn; nó không khẳng định tiết kiệm nào.

Sự mới lạ và giao thoa, được hiển thị

novelty: {exposure_column: exposed_at, time_column: at, days: 7} đọc lần tiếp xúc đầu tiên của mỗi đơn vị từ nhật ký phân nhánh và thời điểm của mỗi hàng kết quả, rồi hiển thị hiệu trong days ngày tiếp xúc đầu tiên và sau đó. Một hiệu sớm đã được quyết định đi cùng một hiệu sau chưa được quyết định hoặc ngược chiều được gọi là "possibly a novelty effect". Việc chia này không bao giờ quyết định một quy tắc: các đơn vị không có hàng trong một dải bị loại khỏi dải đó, không bị chặn ở mức tệ nhất. Nó nhận một kết quả mỗi hàng, không nhận tỷ lệ hay biến đồng hành.

cluster_column: team đếm các nhóm chứa đơn vị của nhiều nhánh và hỏi liệu kết quả của một đơn vị có thể phụ thuộc vào nhánh của đơn vị khác không. Nếu có, hãy ngẫu nhiên hóa theo nhóm và khai báo nó là đơn vị.

Nhiều nhánh xử lý, tỷ lệ và biến đồng hành đã được một cuộc kiểm toán độc lập và bản xác nhận của nó chấp nhận vào ngày 3 tháng 11 năm 2026, theo cùng các điều kiện như hai nhánh.

Ngoại tuyến và trực tuyến

Nêu tên phép so sánh ngoại tuyến và chỉ số của nó (offline_comparison: <id>, offline_metric: pass_rate) và câu trả lời báo cáo liệu hai hướng đã quyết định có khớp nhau không. Điều này được báo cáo và không bao giờ quyết định gì: một bất đồng là lý do để xem lại bộ kiểm thử, không phải phán quyết về bản phát hành.

Cạm bẫy

  • Xem trộm. Đọc một kiểm định có kỳ hạn cố định mỗi ngày và dừng vào một ngày đẹp làm thổi phồng các chiến thắng giả. Hãy lên kế hoạch cỡ mẫu, hoặc khai báo monitoring: anytime.
  • Sự mới lạ và việc học. Người dùng phản ứng với bất cứ điều gì mới, rồi ổn định lại. Mức tăng của tuần đầu có thể phai nhạt; hãy chạy đủ lâu để bao phủ các chu kỳ của người dùng bạn, và khai báo novelty: để xem phần chia.
  • Giao thoa. Khoảng giả định rằng kết quả của một đơn vị không phụ thuộc vào nhánh của đơn vị khác. Hàng tồn kho dùng chung, sàn giao dịch, tính năng mạng xã hội hoặc bộ nhớ đệm được một nhánh làm nóng phá vỡ điều đó; khi đó hãy ngẫu nhiên hóa theo một đơn vị lớn hơn (một khu vực, một nhóm), và khai báo cluster_column: để xem các cụm trộn lẫn đến mức nào.
  • Trôi dạt khi tỷ lệ chia thay đổi. Khoảng giả định rằng phân bổ giữ nguyên trong suốt thử nghiệm, hoặc kết quả không trôi dạt trong khi nó thay đổi. Một đợt tăng dần từ 10% lên 50%, hoặc 90/10 rồi 10/90 qua một ngày thường và một ngày cuối tuần, gán trọng số các giai đoạn khác nhau ở mỗi nhánh và trộn một hiệu ứng thời gian vào chênh lệch; kiểm tra tỷ lệ mẫu đọc số đếm gộp và không thấy điều đó. Hãy giữ tỷ lệ chia cố định, hoặc chỉ quyết định trên giai đoạn sau đợt tăng dần.
  • Đổi đơn vị. Ngẫu nhiên hóa và phân tích theo cùng một đơn vị. Ngẫu nhiên hóa người dùng nhưng đếm các phiên như độc lập sẽ thu hẹp khoảng một cách sai lầm.

Điều này không thể cho bạn biết

  • Liệu kết quả có đúng cho người dùng ngoài khung thời gian, khu vực hoặc lưu lượng của kiểm định hay không.
  • Bất cứ điều gì về một chỉ số bạn không khai báo trước kiểm định; một chỉ số được chọn sau khi đã biết là một mô tả.
  • Liệu bộ định tuyến của bạn có thật sự ngẫu nhiên hóa: kiểm tra tỷ lệ mẫu bắt được lỗi lớn, không bắt được lỗi tinh vi.
  • Nhánh xử lý nào tốt nhất trong số các nhánh không vượt qua: chỉ các nhánh vượt qua mới được xếp hạng. Phân bổ phân tầng và thiết kế switchback chưa được xây dựng.