Là chủ sở hữu sản phẩm, bạn thường phải đối mặt với câu hỏi nên tiếp tục với tùy chọn A hay tùy chọn B. Hoặc, nên triển khai phiên bản màn hình nào để đạt được kết quả tốt hơn? Việc đưa ra những quyết định như vậy có thể là một thách thức, đặc biệt là khi bạn đang phải đối mặt với thời hạn chặt chẽ với nguồn lực hạn chế. Hơn nữa, những quyết định như vậy được đưa ra dựa trên đánh giá cá nhân hoặc sao chép cách tiếp cận của đối thủ cạnh tranh, điều này có thể dẫn đến kết quả dưới mức tối ưu.
Tin tốt là người ta có thể tránh được những cạm bẫy như vậy bằng cách thiết lập một môi trường thử nghiệm đơn giản đòi hỏi nỗ lực tương đối thấp. Trong bài viết này, chúng tôi sẽ mô tả cách bạn có thể đạt được điều này.
Việc thiết lập một môi trường thử nghiệm rất quan trọng vì hai lý do:
Thứ nhất, nó cho phép bạn đảm bảo rằng sau khi triển khai chức năng mới, bạn sẽ chọn tùy chọn tốt nhất dựa trên phương pháp tiếp cận dựa trên dữ liệu.
Thứ hai, nó cho phép bạn liên tục cải thiện chức năng hiện có của sản phẩm bằng cách so sánh các tùy chọn 'hiện trạng' với các tùy chọn 'tương lai' giả định và thực hiện phân tích 'điều gì sẽ xảy ra nếu'.
Trước khi tiếp tục với cách tiếp cận, chúng ta hãy vạch trần một số lầm tưởng thường gây hiểu lầm cho chủ sở hữu sản phẩm:
Tôi cần nhiều tài nguyên để thiết lập một môi trường phức tạp cho phép thực hiện thử nghiệm và thử nghiệm A/B
Sai : Cách tiếp cận được mô tả chiếm ít hơn một tuần tài nguyên của kỹ sư phần mềm của bạn.
Tôi cần một quy trình thu thập dữ liệu được thiết lập tốt và theo dõi sự kiện chi tiết
Sai : Bạn có thể dựa vào cơ sở dữ liệu hiện có lưu trữ thông tin về vòng đời của thực thể chính của sản phẩm. Chẳng hạn, trạng thái đơn hàng nếu bạn là dịch vụ giao hàng.
Tôi cần một nhóm chuyên gia phân tích sẽ xử lý các yêu cầu của tôi hàng ngày
Sai : Sau khi bạn hiểu cách tiếp cận và chỉ số thử nghiệm của mình, bạn có thể thường xuyên tự lấy dữ liệu bằng truy vấn SQL đơn giản.
Để thiết lập môi trường thử nghiệm của bạn, bạn nên làm theo các bước sau:
Trước khi bạn liên hệ với nhà thiết kế sản phẩm của mình, hãy xác định các mục tiêu và chỉ số sẽ được đo lường như một phần của thử nghiệm. Trong trường hợp câu hỏi cổ điển 'Tùy chọn A hoặc Tùy chọn B', thông thường bạn muốn đạt được điều gì bằng cách thực hiện một thay đổi. Chẳng hạn, bạn có thể đang giải quyết một phần cụ thể của kênh.
Để minh họa, giả sử bạn đang làm việc trong một công ty giao hàng và hiện đang tập trung vào biểu mẫu tạo đơn hàng. Bạn muốn giải quyết một tỷ lệ tương đối thấp người dùng cung cấp địa chỉ giao hàng của họ và sau đó chọn phương thức giao hàng. Ngoài ra, hãy tưởng tượng bạn có hai phiên bản mới của cuộc hành trình:
Phiên bản hiện tại : Một màn hình yêu cầu nhập địa chỉ và hiển thị bản đồ bằng mã pin dựa trên địa chỉ được cung cấp. Màn hình tiếp theo cho phép chọn phương thức giao hàng dựa trên địa chỉ được cung cấp.
Phiên bản mới : Một màn hình yêu cầu nhập địa chỉ và chọn phương thức giao hàng ở đó.
Mục tiêu là xác định tùy chọn nào dẫn đến tỷ lệ người dùng đã cung cấp địa chỉ của họ và chọn phương thức giao hàng cao hơn. Số liệu khá đơn giản: % người dùng đã cung cấp địa chỉ của họ và chọn phương thức giao hàng.
Trên thực tế, có 2 cách để đo lường dữ liệu đó :
Dựa trên dữ liệu đã có sẵn theo thiết kế phụ trợ của bạn . Chẳng hạn, hãy xem xét một cơ sở dữ liệu có thông tin về vòng đời của đơn đặt hàng. Đơn đặt hàng của bạn có thể có các trạng thái hoặc trạng thái như:
Đã tạo bản nháp
Cố gắng tìm phương thức vận chuyển
Đã tìm thấy tùy chọn vận chuyển/Không tìm thấy tùy chọn vận chuyển
Theo dõi sự kiện - đây không phải là thứ sẽ hoạt động ngay lập tức và do đó cần thêm nỗ lực để triển khai. Tuy nhiên, tính năng theo dõi sự kiện sẽ cho phép bạn phân tích chi tiết hơn, ví dụ: loại thiết bị và tên trình duyệt có thể được chuyển thành thông số cho các sự kiện của bạn.
Trong các phần tiếp theo của bài viết này, chúng ta sẽ tập trung vào cách tiếp cận đầu tiên, tức là kiến trúc dữ liệu hiện có, không theo dõi sự kiện.
Cần hoàn thành 2 bước chính trong quy trình thử nghiệm:
Ý tưởng là đưa ra một khung thử nghiệm A/B nhẹ, càng đơn giản càng tốt và sẽ cho phép bạn tạo thử nghiệm với các tham số sau:
Khả năng định cấu hình các tham số này cho phép bạn đặt giới hạn mẫu và chọn ngẫu nhiên các ứng cử viên cho thử nghiệm cho đến khi đạt được kích thước mẫu mong muốn.
Cả máy khách và máy chủ đều cần thay đổi cho điều này: máy chủ sẽ theo dõi số lượng ứng viên cho mỗi thử nghiệm và chương trình phụ trợ sẽ quyết định xem người dùng hiện tại có nên tham gia thử nghiệm hay không. Chương trình phụ trợ sẽ quyết định xem người dùng đã xác thực có nên tham gia thử nghiệm hay không dựa trên kích thước mẫu hiện tại và trên một xác suất cố định. Hơn nữa, chương trình phụ trợ phải duy trì một tập hợp người dùng là một phần của thử nghiệm nhất định để cung cấp trải nghiệm nhất quán cho người dùng và để tính toán chính xác kết quả thử nghiệm.
Đó là cách điểm cuối cho cấu hình của thử nghiệm có thể trông giống như sau:
ĐĂNG /api/your-service/experiment-create
Lời yêu cầu:
{ experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}
Phản ứng:
{
200,
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
Bạn sẽ cần một điểm cuối riêng biệt chịu trách nhiệm chỉ định một người dùng cụ thể cho thử nghiệm và nhóm tương ứng. Hãy gọi nó là experiment-enrollments
.
Trong khi thiết kế toàn bộ môi trường, bạn nên hiểu rõ điểm cuối experiment-enrollments
hành trình của người dùng nên được gọi ở giai đoạn nào. Ngoài ra, có thể xảy ra trường hợp không phải tất cả người dùng đều nên tham gia thử nghiệm. Đó là lý do tại sao sẽ hữu ích nếu cung cấp mã thông báo xác thực người dùng cho một điểm cuối.
Trong ví dụ của chúng tôi, nếu chúng tôi chỉ muốn tập trung vào những người dùng mới đang thực hiện đơn đặt hàng đầu tiên của họ, xác thực người dùng sẽ cho phép chúng tôi xác định đó là loại người dùng nào và liệu một người có nên đăng ký thử nghiệm hay không. Ngoài ra, hãy đảm bảo rằng sau khi điểm cuối được gọi, tất cả thông tin cần thiết đều có sẵn và xem xét các chi tiết cụ thể về hành trình và vòng đời của bạn.
Điểm cuối experiment-enrollments
được mô tả bên dưới. Nó có thể được gọi ở một giai đoạn cụ thể của hành trình (ví dụ: trước khi đến màn hình yêu cầu địa chỉ giao hàng) cho các loại người dùng cụ thể (ví dụ: chỉ những người dùng mới chưa cung cấp địa chỉ) và sẽ tính toán xem người dùng hiện tại có nên tham gia hay không trong một thí nghiệm nhất định hay không:
POST /api/your-service/experiment-enrollments
, mã xác thực người dùng là bắt buộc
Lời yêu cầu:
\ {
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
Phản ứng:
{200, enrolled: true/false, group_name: group_1,}
Để minh họa luồng dữ liệu lý thuyết sẽ như thế nào, hãy giả sử cùng một ví dụ về luồng tạo đơn hàng trong công ty giao hàng. Bạn đang lựa chọn giữa 2 tùy chọn của màn hình tạo lệnh.
Các điểm cuối sau đây được đề cập trong sơ đồ bên dưới, tức là:
/tạo-đặt hàng-bản nháp (bước 3)
/find-shipping-method (bước 16)
/submit-order (bước 20)
được cung cấp để hỗ trợ ví dụ minh họa và không phải là những phần cần thiết của môi trường thí nghiệm
Ngoài ra, kiến trúc minh họa và đơn giản hóa của cơ sở dữ liệu được cung cấp dưới đây.
Có 3 bảng chính:
Experiments set
- bộ này chứa tất cả các thử nghiệm bạn đã tạo trước đó. Cơ sở dữ liệu được cập nhật mỗi khi bạn gọi điểm cuối /experiment-create
.
Experiments database
- nó chứa tất cả các bản ghi được liên kết với mỗi lần đăng ký của một người dùng cụ thể. Cơ sở dữ liệu được cập nhật mỗi khi bạn gọi điểm cuối experiment-enrollments
Order lifecycle database
- nó được cung cấp để hỗ trợ ví dụ minh họa về cách dữ liệu liên quan đến thử nghiệm có thể được lưu trữ. Vấn đề là bảng này (hoặc bất kỳ bảng tương tự nào tương ứng với các chi tiết cụ thể của sản phẩm của bạn) sẽ cho phép bạn xem mục nhập (ví dụ: tạo đơn hàng) có thành công hay không cho người dùng cụ thể đã đăng ký vào một trong các nhóm thử nghiệm mà bạn' đã thiết lập. Trong ví dụ của chúng tôi, chúng tôi có thể dựa vào trạng thái Phương thức vận chuyển đã chọn cho phép kết luận rằng người dùng đã cung cấp thành công chi tiết vận chuyển và sau đó chọn một trong các phương thức vận chuyển được đề xuất.
Ưu điểm:
Nhược điểm:
Nhiệm vụ và ước tính chỉ định:
Khi bạn đã thiết kế phần phụ trợ của mình, hãy liên kết với nhóm giao diện người dùng của bạn theo cách tốt nhất để họ nhận thông tin và ở giai đoạn nào của quy trình.
Hãy ghi nhớ và giảm thiểu các phụ thuộc chính :
Khi thử nghiệm của bạn đã chạy trong một khoảng thời gian đủ, điều quan trọng là phải phân tích và diễn giải kết quả để rút ra kết luận có ý nghĩa.
Xác định danh sách các trường bạn cần tính toán tác động đối với các chỉ số mà bạn đã quyết định tập trung vào trước đó.
Từ ví dụ minh họa trên nguồn dữ liệu sẽ là 2 bảng:
Experiments database
:Đầu vào : id thử nghiệm mà bạn đang tìm kiếm kết quả
Đầu ra : danh sách tất cả id người dùng là người tham gia thử nghiệm cụ thể, nhóm mà mỗi người dùng được chỉ định và dấu thời gian khi người dùng được chỉ định
Order lifecycle database
Dựa trên dữ liệu này, bạn có thể tính % đơn đặt hàng được tạo thành công cho từng nhóm thử nghiệm.
Khi phân tích kết quả của bạn, điều quan trọng là phải nhìn xa hơn những con số thô. Bạn cũng sẽ muốn tìm kiếm ý nghĩa thống kê để đảm bảo rằng bất kỳ sự khác biệt nào bạn quan sát được giữa các nhóm thử nghiệm của mình không chỉ là do cơ hội ngẫu nhiên. Tôi sẽ không tập trung quá nhiều vào phần này vì tôi đã thấy rất nhiều bài viết liên quan đến chủ đề này với tài nguyên trực tuyến này và các tài nguyên trực tuyến khác. Dù sao, kiến thức quá mức không cần thiết ở đây: theo tôi, có thể áp dụng Z-Test hoặc T-Test để kiểm tra tầm quan trọng của sự khác biệt giữa 2 nhóm là đủ.
Tuy nhiên, khi bạn đã xác định rằng kết quả của mình có ý nghĩa thống kê, bạn có thể bắt đầu đưa ra kết luận về tùy chọn nào trong sản phẩm của mình hoạt động tốt hơn.
Sau khi bạn chạy thử nghiệm thành công và có đủ mức độ tin cậy về tùy chọn tốt nhất, bước tiếp theo là mở rộng các thay đổi của bạn trên sản phẩm của bạn. Có thể có một số cách tiếp cận:
Cách đơn giản nhất là điều chỉnh cấu hình thử nghiệm của bạn sao cho 100% người dùng sẽ thuộc nhóm hiển thị kết quả tốt hơn . Bạn sẽ cần dành một chút thời gian để làm sạch mã trong tương lai để việc hiển thị phần giao diện người dùng cụ thể này độc lập với môi trường thử nghiệm
Điều ít đơn giản hơn là nếu sản phẩm của bạn có sẵn trên nhiều nền tảng. Hãy hết sức thận trọng khi giả định rằng kết quả thử nghiệm trên luồng web áp dụng cho luồng ứng dụng dành cho thiết bị di động (và ngược lại). Đôi khi, an toàn hơn là xin lỗi và chạy một thử nghiệm riêng biệt theo cách tương tự nhưng trên một nền tảng khác.
Có môi trường thử nghiệm của riêng bạn là một công cụ rất hữu ích cho bất kỳ người quản lý sản phẩm nào. Bất kể sản phẩm hiện tại của bạn đang ở giai đoạn trưởng thành nào, việc tạo môi trường thử nghiệm sẽ không mất quá nhiều thời gian. Thanh toán chi phí một lần khá thấp để làm cho nó hoạt động sẽ nhanh chóng cho bạn thấy lợi tức đầu tư.
Cuối cùng, đây là một số mẹo để đảm bảo rằng kết quả của thử nghiệm có ý nghĩa:
Bằng cách làm theo các phương pháp hay nhất này, bạn có thể thiết lập môi trường thử nghiệm hiệu quả có thể giúp bạn đưa ra quyết định dựa trên dữ liệu và thúc đẩy tỷ lệ chuyển đổi của mình theo thời gian.