Sai lệch tỷ lệ mẫu (SRM)

Sai lệch tỷ lệ mẫu, thường được viết tắt là SRM, xảy ra khi sự phân bổ lưu lượng truy cập thực tế giữa các biến thể thử nghiệm khác với sự phân bổ dự định nhiều hơn mức mà biến động ngẫu nhiên có thể giải thích. Một thử nghiệm được cấu hình với tỷ lệ phân chia đều 50/50 nhưng lại thu hút 51,200 lượt truy cập vào nhóm đối chứng và 48,800 lượt vào nhóm thử nghiệm không chỉ đơn thuần là do không may mắn; với khối lượng truy cập đó, sự chênh lệch lớn như vậy là không hợp lý về mặt thống kê ngay cả khi sử dụng phương pháp ngẫu nhiên hóa chính xác. SRM được phát hiện bằng phép kiểm định chi bình phương so với sự phân bổ dự kiến, và bất kỳ phép kiểm định nào cho thấy kết quả này đều nên được coi là không hợp lệ cho đến khi tìm ra nguyên nhân.

SRM rất quan trọng vì nó báo hiệu rằng hai nhóm không còn có thể so sánh được nữa. Toàn bộ logic của một thí nghiệm có kiểm soát dựa trên việc phân bổ ngẫu nhiên tạo ra các nhóm chỉ khác nhau ở phương pháp điều trị được áp dụng. Nếu một quy trình có hệ thống nào đó đang chuyển hướng những khách truy cập cụ thể vào một nhóm, hoặc loại bỏ khách truy cập khỏi một nhóm trước khi họ được tính, thì bất kỳ sự khác biệt nào được quan sát thấy trong tỷ lệ chuyển đổi có thể phản ánh quy trình đó chứ không phải sự thay đổi đang được thử nghiệm. Kết quả được báo cáo không chỉ không chính xác; nó đang đo lường một thứ khác với những gì nhóm nghiên cứu tin rằng họ đang đo lường.

Nguyên nhân hầu hết là do vấn đề kỹ thuật chứ không phải thống kê. Mã biến thể tải chậm khiến khách truy cập rời đi trước khi được tính, loại bỏ một cách có hệ thống những người dùng thiếu kiên nhẫn nhất khỏi một nhóm. Các bài kiểm tra dựa trên chuyển hướng làm mất lưu lượng truy cập trong quá trình chuyển hướng, và sự mất mát này không được phân bổ đều trên các thiết bị hoặc tốc độ kết nối. Việc lọc bot được áp dụng không nhất quán trên các biến thể, các lớp bộ nhớ đệm phục vụ một phiên bản không cân xứng, các lệnh theo dõi được kích hoạt trước khi quá trình hiển thị hoàn tất trong một biến thể nhưng sau đó trong biến thể khác, và sự tương tác giữa các thử nghiệm đang chạy đồng thời đều tạo ra SRM. Mỗi lỗi này đều là một khiếm khuyết thực sự sẽ làm sai lệch kết quả cho dù có ai kiểm tra tỷ lệ hay không.

Phản ứng thích hợp là dừng thử nghiệm, chẩn đoán nguyên nhân, khắc phục và bắt đầu lại từ đầu. Những nỗ lực cứu vãn một thử nghiệm bị ảnh hưởng bởi SRM bằng cách điều chỉnh trọng số các nhóm hoặc phân tích một tập hợp con hiếm khi có thể biện minh được, bởi vì lưu lượng truy cập bị thiếu hoặc phân bổ sai không phải là ngẫu nhiên. Bản năng muốn cứu vãn một thử nghiệm đã tiêu tốn ba tuần lưu lượng truy cập là rất mạnh, đặc biệt khi nó dường như cho thấy một kết quả khả quan, nhưng kết quả từ một lỗi ngẫu nhiên hóa không có giá trị chứng cứ và việc triển khai dựa trên kết quả đó còn tệ hơn là không thử nghiệm gì cả.

Vì SRM (Stack Form Assessment) hoạt động một cách vô hình trừ khi có người tìm kiếm nó, nên việc kiểm tra cần phải được tự động hóa. Các chương trình hoàn thiện sẽ chạy thử nghiệm SRM trên mọi thí nghiệm như một phần của quy trình phân tích tiêu chuẩn, gắn cờ bất kỳ sự sai lệch nào vượt quá ngưỡng nghiêm ngặt và từ chối công bố kết quả cho đến khi cờ được gỡ bỏ. Việc kiểm toán hồi cứu các thí nghiệm trong quá khứ thường phát hiện ra một phần đáng kể các thử nghiệm trước đây bị ảnh hưởng, đây là một trong những phát hiện khó chịu nhất mà một chương trình thử nghiệm có thể thực hiện, và cũng là một trong những phát hiện có giá trị nhất, bởi vì nó giải thích tại sao một số thành công trong quá khứ lại không bao giờ được hiện thực hóa trong kết quả kinh doanh.

Việc điều tra sự không khớp là một quy trình có hệ thống chứ không phải là một cuộc săn tìm. Bước đầu tiên là kiểm tra xem sự mất cân bằng có tồn tại trong các bản ghi phân bổ của chính công cụ kiểm thử hay chỉ trong nền tảng phân tích, điều này giúp phân biệt vấn đề ngẫu nhiên hóa với vấn đề theo dõi. Bước thứ hai là phân tích tỷ lệ theo thiết bị, trình duyệt, vị trí địa lý và nguồn lưu lượng truy cập, vì nguyên nhân thường ảnh hưởng đến một nhóm không cân xứng và phân khúc cho thấy độ lệch lớn nhất thường chỉ ra trực tiếp cơ chế gây ra vấn đề. Bước thứ ba là kiểm tra thời điểm, vì tỷ lệ ban đầu chính xác nhưng sau đó bị lệch thường cho thấy sự triển khai, thay đổi bộ nhớ đệm hoặc một tập lệnh của bên thứ ba được đưa vào giữa quá trình kiểm thử. Việc ghi lại từng cuộc điều tra sẽ xây dựng một danh mục các nguyên nhân lặp đi lặp lại, và hầu hết các tổ chức đều tìm thấy hai hoặc ba cơ chế giống nhau chịu trách nhiệm cho phần lớn các sự cố của họ.

Việc giới thiệu quy trình kiểm tra SRM tự động thường là một trong những khuyến nghị kỹ thuật sớm nhất trong quá trình phát triển sản phẩm. Dịch vụ CRO Sự tham gia tích cực, bởi vì chi phí triển khai rất thấp và ngay lập tức nâng cao độ tin cậy của mọi thứ mà chương trình tạo ra sau đó. Trong trường hợp SRM truy nguyên nhân là do độ trễ hiển thị biến thể hoặc độ trễ chuyển hướng, giải pháp nằm ở... hiệu suất web Việc tập trung vào cải thiện hiệu suất hơn là thay vì chỉ chỉnh sửa công cụ kiểm thử, và việc khắc phục vấn đề tốc độ cơ bản thường giúp cải thiện cả tính hợp lệ của các thí nghiệm và tỷ lệ chuyển đổi mà chúng đo lường.