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.
Mục lục
- Tại sao việc thiết lập một môi trường thử nghiệm lại quan trọng.
- thần thoại
- Thiết lập môi trường thử nghiệm của bạn
- Xác định mục tiêu của thử nghiệm trong tương lai của bạn
- Thiết kế kiến trúc của môi trường thử nghiệm của bạn
- Phân tích và giải thích kết quả
- Mở rộng tùy chọn ưa thích.
- Phần kết luận.
Tại sao Thiết lập Môi trường Thử nghiệm lại quan trọng?
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'.
thần thoại
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.
Tiếp cậ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:
1. Xác định mục tiêu của thử nghiệm trong tương lai, hiểu các tùy chọn và chọn số liệu
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.
2. Thiết kế kiến trúc của môi trường thử nghiệm của bạn
Cần hoàn thành 2 bước chính trong quy trình thử nghiệm:
- Tạo thử nghiệm với các tham số đã chọn
- Xác định một giai đoạn trong hành trình của người dùng khi người dùng sẽ được chỉ định vào một trong hai nhóm và đảm bảo rằng kết quả là giao diện người dùng có liên quan được hiển thị
Tạo một 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:
- ID thử nghiệm
- mẫu tối đa
- Số lượng và tên của mỗi nhóm
- Xác suất rơi vào mỗi nhóm
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"
}
Quyết định thời điểm và cách thức người dùng sẽ được chỉ định vào các nhóm thử nghiệm:
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ốiexperiment-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.
Tổng quan về phương pháp thiết kế và triển khai
Ưu điểm:
- Mẫu kết quả không đồng nhất
- Kích thước mẫu được biết trước
- Kết quả có thể được tính toán nhanh chóng, tùy thuộc vào xác suất lấy mẫu cố định
Nhược điểm:
- Yêu cầu thay đổi cả frontend và backend
- Việc tính toán các kết quả sẽ dựa vào một số cơ sở dữ liệu, một số cơ sở dữ liệu ban đầu không thể được thiết kế cho mục đích phân tích
Nhiệm vụ và ước tính chỉ định:
- [ ] undefined [Phụ trợ] Tạo mô hình và hiển thị điểm cuối bộ đếm tìm nạp: ~2 điểm câu chuyện
- [ ] undefined [Phụ trợ] Hiển thị điểm cuối bộ đếm gia tăng: ~2 điểm câu chuyện
- [ ] undefined [Phần phụ trợ] Hiển thị các điểm cuối để tìm nạp & bộ đếm gia tăng: ~1 điểm câu chuyện
- [ ] undefined [Frontend] Gọi các điểm cuối của bộ đếm để chuyển đổi giữa các luồng đăng ký: ~3 điểm câu chuyện
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 :
- Hãy đảm bảo rằng các nhóm của bạn đã thống nhất trước trong một hợp đồng để phần giao diện người dùng có thể được triển khai song song với phần phụ trợ.
- Cố gắng tránh giao diện người dùng của bạn bị chặn cho đến khi hoàn thành toàn bộ phần phụ trợ
- Bất kể môi trường thử nghiệm là gì, tất cả các tùy chọn giao diện người dùng vẫn phải được triển khai
3. Phân tích và diễn giải kết quả
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- Đầu vào : danh sách người dùng nằm trong phạm vi thử nghiệm của bạn và dấu thời gian khi họ đăng ký thử nghiệm
- Đầu ra : trạng thái cuối cùng của tất cả các đơn đặt hàng được liên kết với những người dùng này và được xử lý sau khi người dùng đăng ký thử nghiệm
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.
4. Mở rộng tùy chọn ưa thích
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.
Để kết luận
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:
- Trước hết, hãy hiểu những chỉ số nào sẽ bị ảnh hưởng (nếu có) khi triển khai thay đổi mà bạn đang xem xét.
- Xác định rõ mục tiêu và số liệu của bạn trước khi bắt đầu thử nghiệm
- Giữ cho thử nghiệm của bạn đơn giản nhất có thể, tập trung vào một thay đổi chính tại một thời điểm
- Hãy cẩn thận khi xem xét phép ngoại suy kết quả thử nghiệm của bạn trên các nền tảng khác hoặc các dịch vụ tương tự khác
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.
