Sự cần thiết của tài liệu riêng về các chuyển đổi trên web

Qua quá trình làm việc và triển khai nhiều dự án đo lường cho nhiều doanh nghiệp nhỏ, mình cảm thấy cần có một bản ghi lại tổng quan:

• Giao diện bên ngoài (không tính trang Admin)
• Luồng vận hành
• Các đoạn mã code, tham số, tham biến liên quan đến chuyển đổi trên website

Lưu ý: khái niệm luồng vận hành khác với khái niệm tương tác với các page. Luồng vận hành thì tính các page thuộc cùng một dạng page là một điểm trong luồng chứ không tính riêng lẻ các page.
VD: Nếu người dùng xem nhiều sản phẩm trước khi đến với hành động chuyển đổi mua hàng thì luồng vẫn chỉ tính người dùng đang ở bước trang mua hàng.
Luồng vận hành chỉ tính trong phạm vi phiên truy cập cuối cùng trước khi mua hàng.
Luồng vận hành làm rõ cho loại page khách hàng đang tương tác tương ứng các trạng thái khách hàng đang trong phễu chuyển đổi hay hành trình khách hàng.
Chứ luồng vận hành không bao gồm các tương tác nhỏ lẻ ở từng page cụ thể.
Tức các page sẽ được đại diện bằng loại page (dạng page).

So sánh tài liệu này với các giải pháp, công cụ và quy trình kỹ thuật khác​

Web archive: Lưu lại toàn bộ giao diện bên ngoài nhưng không cho thấy luồng vận hành và code chuyển đổi liên quan. Điều đó dẫn đến khó kiểm soát, so sánh đối chiếu các vấn đề sau:

• Thay đổi luồng, tạo thêm trang hoặc bớt trang trong quá trình chuyển đổi để gian lận chỉ số chuyển đổi.
• Thay đổi, thêm bớt tên gọi tham số, biến số để gian lận chuyển đổi.

Github và các công cụ quản lý project:
Lưu lại code phân tán có kèm phân quyền nhưng không kèm theo hình ảnh để các nhân viên non-tech hình dung được vấn đề.

Lưu lại toàn bộ một phiên bản cũ chỉ để tham chiếu:

• Tốn bộ nhớ. Số lượng bản backup cần phải giới hạn.
• Cần một tài liệu quy chuẩn riêng về mỗi lần backup nếu dự án lớn.
• Không so sánh được với nội dung hiện hành trên website.
• Mỗi lần kiểm tra chuyển đổi cần so lại với bản backup gây bất tiện. Trong khi số lượng sai khác có thể tạo ra là vô cùng nhiều. Điều đó khiến việc truy xuất lại bản backup liên tục. Dẫn đến việc nặng hệ thống vì gần như chạy song song hai phiên bản.
• Do đó cần tài liệu riêng để tra cứu đối chiếu riêng các thành phần có tạo chuyển đổi.
  

Tài liệu Test Case chuyên nghiệp:

• Các Testcase được tổ chức để xem xét chi tiết các trường hợp và bao gồm tất cả các lỗi phát sinh. Việc lọc ra các lỗi liên quan đến chuyển đổi mua hàng sẽ khá khó đối với nhóm non-tech.
• Test case chi tiết thì test từng page, từng view (trên app) thay vì test một luồng đại diện. Test nhanh kiểm tra trên từng chiến dịch không phải là test case chi tiết và được tính vào kiểm tra trong quy trình trước khi chạy chiến dịch.
• Còn tài liệu này tập trung vào việc nhằm kiểm soát các vấn đề phát sinh trong chuyển đổi mua hàng ở mức logic và các yếu tố kỹ thuật cơ bản cần nắm được bởi bộ phận non-tech.
• Các lỗi phát sinh sâu hơn sẽ được tóm tắt ở trong vài luồng đặc thù có thể phát sinh thêm.

Nhóm đối tượng nhận tài liệu:

• Nhân viên thuộc nhóm non-tech (không có hiểu biết sâu về công nghệ) nhưng cần làm việc với bộ phận Tech.
  

Mục tiêu tài liệu:
Lưu trữ các trang mẫu tiêu biểu kèm chú giải và một số đoạn mã nguồn tiêu biểu của website tính đến ngày 06/01/2026 dưới dạng văn bản nhằm so sánh và đối chiếu.

• Làm căn cứ cơ sở cho các hoạt động đo lường, giải quyết tranh chấp và đối chiếu số liệu sau này trên website.

Thời điểm giới hạn của tài liệu:
Tính đến phiên bản web ngày thời điểm hoàn thiện tài liệu