Khoảng 6% các thí nghiệm tại Microsoft cho thấy sự không khớp về tỷ lệ mẫu, điều này tương đương với khoảng một lần phát hiện mỗi ngày đối với một sản phẩm chạy 10,000 thí nghiệm mỗi năm.Fabijan và cộng sự, KDD 2019Các nhóm thực hiện ít bài kiểm tra hơn hiếm khi thấy con số đó, bởi vì bài kiểm tra mà nền tảng của họ thực hiện không thể đạt được ý nghĩa thống kê với khối lượng lưu lượng truy cập của họ. Bài kiểm tra trông có vẻ ổn, báo cáo mức tăng 4%, nhưng dù sao cũng sai.
Hướng dẫn này dành cho người đọc kết quả thí nghiệm và phải quyết định có nên gửi mẫu đi hay không. Sau khi đọc xong, bạn sẽ có thể xác định xem thử nghiệm của mình có đủ lớn để việc kiểm tra sự không khớp có ý nghĩa gì không, chạy năm nhánh chẩn đoán theo thứ tự tìm ra nguyên nhân nhanh nhất, và phân biệt sự mất cân bằng làm vô hiệu hóa kết quả với sự mất cân bằng mà bạn có thể phân đoạn xung quanh và giữ lại.
Thông báo từ cảnh báo SRM thực sự cho bạn biết điều gì.
Sai lệch tỷ lệ mẫu là khoảng cách giữa tỷ lệ phân chia bạn đã thiết lập và tỷ lệ phân chia bạn quan sát được: bạn thiết lập 50/50 nhưng nhận được 50.8/49.2. Phương pháp kiểm tra tiêu chuẩn là sử dụng kiểm định chi bình phương Pearson để kiểm tra sự phù hợp của số lượng người tham gia, với một bậc tự do cho kiểm định hai nhánh.
Điều này quan trọng vì cơ chế làm mất người dùng hầu như không bao giờ trung lập đối với chỉ số của bạn. Nếu việc chuyển hướng loại bỏ các kết nối chậm từ biến thể khác, những người còn lại là những người có kết nối tốt hơn, và họ chuyển đổi tốt hơn. Hiệu quả tăng lên là có thật trong dữ liệu nhưng lại không tồn tại trong thực tế.
Đây là điều đầu tiên mà hầu hết các nhóm đều mắc sai lầm: không có ngưỡng chung nào trong ngành. Các nền tảng khác nhau có sự chênh lệch rất lớn.
| Nền tảng | Thử nghiệm | Cờ tại | Lưu ý |
|---|---|---|---|
| AB ngon | Thống kê theo phương pháp tuần tự (S-SRM) | p <0.01 | Được thiết kế để giám sát liên tục, do đó các lần xem lặp lại đều được tính đến. |
| Thống kê | Chi vuông | p <0.01 | "Chúng tôi coi mức độ phơi nhiễm là không cân bằng nếu giá trị p của SRM nhỏ hơn 0.01." |
| Sách tăng trưởng | Chi vuông | p <0.001 | Cảnh báo bị ẩn ở trên |
| Microsoft (hình minh họa) | Chi vuông | ~1 trong 500,000 | Việc phân chia 50.2/49.8 ở mức n lớn đã giải quyết được vấn đề này. |
Có hai hệ quả. Một bài kiểm tra bị gắn cờ trên một nền tảng lại vượt qua bài kiểm tra trên nền tảng khác với dữ liệu giống hệt nhau, vì vậy "công cụ của chúng tôi không cảnh báo" không phải là bằng chứng cho thấy sự phân tách rõ ràng. Và ngưỡng 0.01 sẽ gắn cờ một trong một trăm bài kiểm tra bình thường. Nếu bạn xem xét giá trị p hàng ngày trong suốt ba tuần thử nghiệm, giới hạn đỉnh độc lập đơn giản đối với cảnh báo sai là 19%; con số thực tế thấp hơn vì các ngày liên tiếp có tương quan mạnh, nhưng không phải là 1%. Đó là lý do tại sao AB Tasty chạy một quy trình tuần tự. Nếu nền tảng của bạn chạy kiểm định chi-square với thời gian cố định, hãy chỉ xem xét một lần, vào cuối, trên số lượng tích lũy.
Hãy kiểm tra xem xét nghiệm của bạn có thể phát hiện ra sự mất cân bằng nào không.
Với tỷ lệ 50/50, thống kê chi-square được đơn giản hóa thành 4n(p̂−0.5)², trong đó n là tổng số lần tiếp xúc. Đảo ngược nó và bạn sẽ nhận được sự mất cân bằng nhỏ nhất mà kiểm tra của bạn có thể phát hiện:
| Tổng số lần tiếp xúc | Khoảng phân chia nhỏ nhất được đánh dấu ở mức p < 0.01 | ở mức p < 0.001 |
|---|---|---|
| 5,000 | 51.8 / 48.2 | 52.3 / 47.7 |
| 10,000 | 51.3 / 48.7 | 51.6 / 48.4 |
| 30,000 | 50.7 / 49.3 | 51.0 / 49.0 |
| 100,000 | 50.4 / 49.6 | 50.5 / 49.5 |
| 1,000,000 | 50.13 / 49.87 | 50.16 / 49.84 |
Hãy hiểu đó là giới hạn, chứ không phải giấy phép. Với 10,000 lượt hiển thị, bất kỳ sự mất cân bằng nào nhỏ hơn 1.3 điểm đều không thể nhận thấy được, và hiệu ứng chọn lọc 1.3 điểm là quá đủ để tạo ra một sự tăng nhẹ về tỷ lệ chuyển đổi. Đó là vấn đề cấu trúc ở hầu hết khu vực. Thổ Nhĩ Kỳ đã ghi nhận khoảng 6 tỷ giao dịch thương mại điện tử trên khoảng 634,000 doanh nghiệp vào năm 2025 (Bộ Thương mại, ngày 12 tháng 5 năm 2026Trung bình mỗi năm có khoảng 9,500 lượt truy cập, và con số trung bình này bị kéo lên cao bởi một số ít các sàn thương mại điện tử. Một cửa hàng tầm trung thử nghiệm bước thanh toán sẽ xử lý hàng chục nghìn lượt truy cập, chứ không phải hàng triệu, vì vậy việc kiểm tra SRM của họ chỉ phát hiện ra những lỗi nghiêm trọng chứ không phải những lỗi nhỏ hơn.
Với khối lượng dữ liệu lớn như vậy, đừng chỉ dựa vào cảnh báo. Hãy tự mình thu thập số liệu thống kê phơi nhiễm thô theo ngày và theo từng phân khúc, và coi sự dịch chuyển liên tục theo cùng một hướng là đáng ngờ ngay cả khi giá trị p không đáng kể. Nếu bạn không chắc chắn nền tảng của mình hiển thị những số liệu thống kê đó ở đâu, thì... Tài liệu SRM Checker Chúng được ánh xạ theo từng công cụ.
Năm nhánh, theo thứ tự tìm ra nguyên nhân nhanh nhất.
Hệ thống phân loại KDD phân loại các nguyên nhân SRM theo giai đoạn vòng đời: gán, thực thi, xử lý nhật ký, phân tích, can thiệp. Chẩn đoán chúng theo thứ tự khác, ưu tiên nguyên nhân rẻ nhất và phổ biến nhất trước.
- Phân tích và kích hoạt. Triệu chứng: Sự phân tách diễn ra suôn sẻ trong nhật ký phơi nhiễm thô nhưng lại bị lỗi trong bảng điểm. Kiểm tra: Tính toán lại tỷ lệ mà không sử dụng điều kiện kích hoạt, bộ lọc ngày và các phép nối cấp độ số liệu. Xác nhận nếu tỷ lệ trở lại mức mong đợi. Khắc phục: Đánh giá việc kích hoạt một cách giống hệt nhau ở cả hai nhóm, trước khi bất kỳ hành vi cụ thể nào của biến thể có thể thay đổi điều kiện đủ điều kiện. Đây là cảnh báo sai phổ biến nhất, cần mười phút để loại trừ.
- Đang xử lý nhật ký. Triệu chứng: Số lượt truy cập khác nhau giữa hai quy trình, hoặc khoảng cách xuất hiện sau bước ETL. Kiểm tra: So sánh số lượt truy cập phía SDK, số lượt truy cập kho dữ liệu và số lượt truy cập báo cáo trong cùng một khoảng thời gian, sau đó so sánh tỷ lệ loại trừ của bộ lọc bot cho mỗi nhánh. Xác nhận nếu số lượt truy cập ở phía thượng nguồn bằng nhau và ở phía hạ nguồn không bằng nhau. Khắc phục: Lọc một cách xác định và đồng nhất. Lưu lượng truy cập tự động đạt 53% tổng lưu lượng truy cập web vào năm 2026, tăng từ 51% vào năm 2024.Báo cáo về phần mềm độc hại của Imperva, ngày 29 tháng 4 năm 2026), do đó, một bộ lọc dựa trên kinh nghiệm về thời gian tải hoặc hành vi của tác nhân người dùng có thể loại trừ với tỷ lệ khác nhau cho mỗi biến thể. Việc mất dữ liệu do thiếu sự đồng ý cũng nằm ở đây: khi
ad_storageNếu yêu cầu bị từ chối, nền tảng gắn thẻ của Google sẽ ngừng thiết lập cookie quảng cáo (Tài liệu về sự đồng ý sử dụng nền tảng gắn thẻ của GoogleVì vậy, nếu tỷ lệ từ chối khác nhau giữa các khu vực địa lý trong một thử nghiệm, thì bất kỳ sự phân bổ nào dựa trên các định danh đó đều làm mất người dùng một cách không đồng đều. - Chấp hành. Triệu chứng: Sự mất cân bằng gia tăng theo dung lượng trang, tệ hơn trên thiết bị di động hoặc bắt đầu ngay từ khi triển khai. Kiểm tra: Chia tỷ lệ theo thiết bị, trình duyệt, loại kết nối và ngày; so sánh thời gian tiếp xúc giữa các nhóm. Xác nhận xem sự thiếu hụt có tập trung vào các phân đoạn chậm hoặc ở một trình duyệt cụ thể hay không. Khắc phục: Đây là điểm mà các bài kiểm tra chuyển hướng không hiệu quả. Chuyển hướng chỉ thêm một điều hướng đầy đủ vào một nhóm duy nhất, và tất cả những người rời bỏ trang trong quá trình chuyển hướng đều là tổn thất có chọn lọc. Hiển thị cả hai biến thể ở phía máy chủ tại một URL duy nhất, hoặc chấp nhận rằng các nhóm không thể so sánh được.
- Phân công. Triệu chứng: Tỷ lệ bị lệch ngay từ giờ đầu tiên và duy trì độ lệch đó. Kiểm tra: Chạy A/A trên cùng một phân bổ và xác minh rằng chuỗi băm (hash salt) không được sử dụng lại từ một thử nghiệm trước đó trên nhóm tài nguyên này. Xác nhận nếu A/A cũng cho thấy sự mất cân bằng. Khắc phục: Phân bổ lại với một chuỗi băm mới và khởi động lại. Sự tồn đọng từ một thử nghiệm trước đó là phiên bản âm thầm của vấn đề này, và chỉ có A/A mới phát hiện ra.
- Sự giao thoa. Triệu chứng: Sự mất cân bằng tập trung ở một số ít định danh có hoạt động cao, hoặc trong các dải IP nội bộ. Kiểm tra: Phân bố số lần tiếp xúc trên mỗi người dùng, và 1% định danh hàng đầu theo khối lượng sự kiện. Xác nhận xem việc loại bỏ chúng có khôi phục lại tỷ lệ hay không. Khắc phục: Loại trừ lưu lượng truy cập nội bộ và lưu lượng truy cập được lập trình bằng quy tắc đã được ghi lại, không phải bằng tay, để lần sau việc loại trừ sẽ giống hệt nhau.
Hướng dẫn chi tiết
Các số liệu dưới đây chỉ mang tính minh họa, không phải dữ liệu khách hàng. Một bài kiểm tra khi thanh toán báo cáo 61,480 lượt tiếp xúc với nhóm đối chứng và 58,520 lượt tiếp xúc với nhóm biến thể: 51.2/48.8 trên 120,000 người dùng, giá trị p của kiểm định chi-square nhỏ hơn 0.001. Nhánh 1: việc bỏ điều kiện kích hoạt trả về 60,020 / 59,980, do đó việc phân bổ là chính xác và sự mất mát xảy ra sau khi tiếp xúc. Nhánh 2: số liệu trong quy trình xử lý trùng khớp, tỷ lệ loại trừ bot là 0.9% ở cả hai nhánh. Nhánh 3: máy tính để bàn ở mức 50.1/49.9, thiết bị di động ở mức 52.4/47.6, và thời gian tiếp xúc trung bình của biến thể cao hơn 900 ms trên thiết bị di động. Chẩn đoán: biến thể gửi thêm một yêu cầu chặn hiển thị, người dùng di động bỏ ngang trong quá trình này, những người còn lại có kết nối tốt hơn. Kết quả đọc ra không hợp lệ. Giải pháp là sửa lỗi hiệu suất, và bài kiểm tra được chạy lại, không phải diễn giải lại.
Những gì bạn có thể cứu vãn và những gì bạn không thể.
- Hủy bỏ kết quả đọc khi cơ chế mất mát có thể tương quan với chỉ số đo lường. Mọi nguyên nhân thực thi và gán đều đủ điều kiện theo mặc định.
- Thu hồi theo từng đoạn Chỉ khi sự mất cân bằng chỉ giới hạn trong một phân khúc mà bạn có thể loại trừ một cách rõ ràng, phân khúc đó đã được xác định trước khi bạn xem xét chỉ số và phần còn lại vượt qua bài kiểm tra SRM của riêng nó. Hai trong ba điều kiện là không đủ.
- Giữ lại bài kiểm tra Khi nguyên nhân hoàn toàn nằm ở khâu phân tích và bảng điểm được điều chỉnh đạt yêu cầu. Bạn đang đọc lại cùng một dữ liệu với bộ lọc cố định, chứ không phải đang "săn mồi".
- Hãy ghi lại thông tin đó bằng mọi cách. Ghi lại danh mục nguyên nhân trong thí nghiệm. Phân loại này mang lại hiệu quả tích lũy: nếu ba trong số mười bài kiểm tra gần đây nhất của bạn thất bại ở nhánh 3, vấn đề của bạn không phải là thử nghiệm, mà là việc triển khai giao diện người dùng. [CẦN DỮ LIỆU NỘI BỘ: tỷ lệ các thử nghiệm do Switas thực hiện trong 24 tháng qua không vượt qua kiểm tra SRM, được phân chia theo nhánh phân loại, để thay thế chuẩn mực 6% của Microsoft bằng con số từ thị trường này]
Điểm mấu chốt nằm ở đây.
Cây quyết định này giả định một thử nghiệm hai nhánh với phân bổ cố định, đã biết và ngẫu nhiên hóa ở cấp độ người dùng. Nó không bao gồm các thử nghiệm đa nhánh, cần kiểm định chi-square đầy đủ trên tất cả các nhánh cộng với việc theo dõi xem cặp nào không chính xác, hoặc phân bổ tăng dần, trong đó tỷ lệ dự kiến thay đổi trong quá trình thử nghiệm và kiểm định chi-square tích lũy là một phép thử hoàn toàn sai. Nó không áp dụng cho các thiết kế ngẫu nhiên theo cụm hoặc địa lý, trong đó đơn vị không phải là người dùng và sự mất cân bằng quan trọng nằm ở đặc điểm của cụm. Nó không nói gì về việc định nghĩa số liệu của bạn có đúng hay không. Và nó không thể giúp ích gì khi các lần tiếp xúc không được ghi lại và bạn đang suy luận việc phân bổ từ một sự kiện số liệu, điều này không phải là kiểm tra phân tách mà là một phỏng đoán.
FAQ
Liệu tỷ lệ 51/49 luôn là vấn đề? Điều đó hoàn toàn phụ thuộc vào n. Ở mức 5,000 lần chụp, đó là nhiễu thông thường; ở mức 500,000 lần chụp, đó gần như chắc chắn là một khuyết tật. Hãy đánh giá tỷ lệ này dựa trên bảng khả năng phát hiện, chứ không phải dựa trên quy tắc phần trăm cố định nào đó.
Tôi có thể chỉ cần điều chỉnh lại trọng số của các cánh tay theo phương pháp thống kê thay vì chạy lại chương trình không? Không. Việc điều chỉnh trọng số sẽ sửa lại số liệu và giữ nguyên lựa chọn. Những người dùng bị mất sẽ biến mất, và họ không phải là mẫu ngẫu nhiên từ nhóm nghiên cứu.
Tôi nên xem giá trị p của SRM bao lâu một lần? Chỉ một lần duy nhất, vào cuối cùng, dựa trên số liệu tích lũy, trừ khi nền tảng của bạn chạy theo quy trình tuần tự. Việc kiểm tra chi-square cố định hàng ngày sẽ làm tăng đáng kể các cảnh báo sai.
Liệu SRM cũng làm mất hiệu lực các chỉ số an toàn? Đúng vậy, vì lý do tương tự. Nếu các nhánh giữ các nhóm dân cư khác nhau, thì một lan can cố định không đáng tin cậy hơn một thước đo chính di động.
Nếu xét nghiệm A/A cũng cho thấy sự không khớp thì sao? Vậy thì lỗi nằm ở khâu phân công hoặc ở quy trình ghi nhật ký, chứ không phải ở khâu xử lý của bạn. Hãy sửa lỗi đó trước khi chạy bất kỳ thứ gì khác, vì nó đang làm ảnh hưởng đến mọi bài kiểm tra trên nền tảng đó.
Các bài kiểm tra chuyển hướng có luôn gây ra lỗi SRM không? Không phải lúc nào cũng vậy, nhưng chúng tiềm ẩn rủi ro về cấu trúc mà không thiết kế nào khác có, bởi vì chức năng điều hướng bổ sung chỉ tồn tại ở một nhánh. Nếu bạn bắt buộc phải sử dụng, hãy kiểm tra tỷ lệ theo tốc độ kết nối và thiết bị trước khi đọc bất kỳ số liệu nào.
Lượng truy cập của tôi quá thấp nên việc kiểm tra đó chẳng có ý nghĩa gì. Vậy thì sao? Theo dõi số liệu thống kê phơi nhiễm hàng ngày để phát hiện sự thay đổi liên tục, chạy kiểm tra A/A định kỳ trên lớp phân công và đăng ký trước một danh sách dài hơn các bước kiểm tra tính hợp lệ. Bạn đang thay thế quy trình bằng sức mạnh thống kê.
Việc lọc bot nên được thực hiện trước hay sau khi phân công nhiệm vụ? Sau khi ghi nhật ký phơi nhiễm, trước khi phân tích, sử dụng các quy tắc xác định được áp dụng giống hệt nhau cho cả hai nhóm. Lọc theo kinh nghiệm bên trong SDK chính là cách mà bộ lọc tự tạo ra sự không khớp.
Hãy tự kiểm tra chương trình thí nghiệm của bạn.
Nếu bạn muốn có thêm một người kiểm tra lại tình trạng hoạt động của các bài kiểm tra mà bạn đang chạy, hoặc muốn xem xét lại lớp phân công và ghi nhật ký mà tất cả chúng đều phụ thuộc vào, thì đó chính là những gì chúng tôi cung cấp. Dịch vụ CRO và thử nghiệm không.
nguồn
- Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Chẩn đoán sự không khớp tỷ lệ mẫu trong các thí nghiệm kiểm soát trực tuyến: Phân loại và các quy tắc thực tiễn dành cho người hành nghề", KDD 2019
- Tài liệu AB Tasty, Tỷ lệ mẫu không khớp (phương pháp S-SRM tuần tự, ngưỡng 0.01)
- Statsig, "Hướng dẫn nhanh về sự không khớp tỷ lệ mẫu", ngày 31 tháng 8 năm 2023 (chi-square, ngưỡng 0.01)
- Tài liệu GrowthBook, Thử nghiệm (kiểm định chi-square, cảnh báo dưới 0.001)
- Imperva, "Báo cáo về Bot độc hại năm 2026: Bot trong kỷ nguyên tác nhân", ngày 29 tháng 4 năm 2026
- Bộ Thương mại Cộng hòa Thổ Nhĩ Kỳ, số liệu thương mại điện tử năm 2025, ngày 12 tháng 5 năm 2026.
- Nền tảng gắn thẻ của Google, Chế độ chấp thuận và hành vi lưu trữ
- Tài liệu hướng dẫn và câu hỏi thường gặp về SRM Checker, Lukas Vermeer
