Chuyển kết quả baseline thành ba công việc có người phụ trách

Vấn đề và mục tiêu

Rủi ro khi đã có baseline (PB-M02) nhưng chưa có việc nào được làm xong: danh sách phát hiện dài, không ai nhận, không rõ thế nào là “xong”. Mục tiêu: từ baseline, chọn tối đa ba việc, mỗi việc có một người phụ trách, URL cụ thể, tiêu chí nghiệm thu về triển khai (không phải về kết quả AI) và kế hoạch đo lại (PB-M03). Điều thư viện hướng dẫn đếm là việc được triển khai và nghiệm thu rồi đo lại hợp lệ, không phải mức tăng hiển thị.

Quan sát làm căn cứ

• Đã có bảng ghi baseline (T02) của một nhóm sản phẩm, đã xác minh theo PB-M01.
• Team có người sửa được trang hoặc dữ liệu liên quan.

Chưa thể kết luận từ hướng dẫn này: việc nào trong ba việc sẽ thay đổi kết quả AI; thứ tự ưu tiên “đúng” cho mọi nhóm sản phẩm. Cách chọn ba việc dưới đây là thực hành đề xuất của team, không phải quy tắc của nền tảng nào.

Điều cần kiểm tra

1. Bảng ghi T02 của baseline: mẫu số (số câu hỏi được lên lịch, đã đo, Phân tích được, Chưa xác định), các dòng Loại khỏi kỳ đo (invalid) và Chưa xác định (unknown) và lý do. Việc dựa trên dòng Chưa xác định chưa nên là việc ưu tiên, trừ khi việc đó là xác minh lại.
2. Bề mặt AI đo của baseline. Baseline trên một bề mặt không đại diện bề mặt khác; AI Overviews và AI Mode có thể dùng kỹ thuật khác nên link khác nhau (CLM-google-ai-features-003). Việc rút ra từ baseline AI Mode chỉ được đo lại trên AI Mode.
3. Trang hoặc dữ liệu thực tế mà việc sẽ động tới (bản chụp trước khi sửa).
4. Quan sát gốc: dòng O-xxx và câu hỏi N-xx trong T02 làm trigger của từng việc.

Điều kiện cần

• Baseline có dữ liệu Phân tích được (PB-M02) và kế hoạch hành động (T07) trống hoặc đang dùng.
• Người phụ trách: marketing lead chọn việc; mỗi việc có người phụ trách thực hiện riêng và một người nghiệm thu khác nếu có thể. Công sức ước tính (thực hành đề xuất của team): 1-2 giờ họp chọn việc, sau đó thời gian tuỳ việc.

Các bước

1. Liệt kê ứng viên từ baseline: mỗi ứng viên gắn với ít nhất một quan sát (O-xxx) và một câu hỏi (N-xx). Bỏ ứng viên không truy được về quan sát nào.
2. Chọn tối đa ba việc (thực hành đề xuất của team). Gợi ý tiêu chí: việc nằm trong khả năng sửa của team, người phụ trách rõ, làm xong và kiểm tra được trong thời gian ngắn, ít đụng chạm nhau để dễ tách thay đổi khi đọc kết quả. Ghi lý do chọn và lý do gác lại các ứng viên khác.
3. Viết giả thuyết dạng kiểm tra: “kiểm tra xem… “ chứ không “vì… nên AI…”. Giả thuyết chưa có bằng chứng thí nghiệm.
4. Ghi mỗi việc vào T07: change_description cụ thể, URL (không chứa dữ liệu khách), người phụ trách, planned_date.
5. Viết tiêu chí nghiệm thu triển khai cho từng việc: URL truy cập đúng, nội dung khớp với dữ liệu kinh doanh do người phụ trách xác nhận, có bản chụp trước và sau, nhật ký thay đổi đầy đủ. Không dùng “AI đề xuất thương hiệu của bạn” hay “tăng hiển thị” làm tiêu chí nghiệm thu.
6. Ghi thay đổi đồng thời đã biết (khuyến mãi, catalog, chiến dịch, đổi giao diện nền tảng) vào concurrent_changes. Nếu không biết, ghi “không biết”.
7. Triển khai, ghi completed_date. Người nghiệm thu kiểm tra theo tiêu chí ở bước 5 và điền accepted_by, acceptance_evidence. Chưa nghiệm thu thì trạng thái chưa là accepted.
8. Lên kế hoạch đo lại theo PB-M03: cùng bộ câu hỏi, cùng bề mặt AI và điều kiện, ghi trong remeasure_plan. Không có tài liệu nền tảng nào chúng tôi đọc nêu thời gian từ khi sửa đến khi AI phản ánh, nên thư viện hướng dẫn không đưa ra con số; ghi lý do cho khoảng thời gian bạn chọn.
9. Đo lại và ghi observation_after bằng lời mô tả quan sát kèm mẫu số, không dùng từ nhân quả.
10. Xem lại sau đo lại: giữ, đo thêm, sửa tiếp hoặc dừng. Việc không đổi kết quả vẫn là việc đã triển khai và được ghi.

Ví dụ (ví dụ giả lập, không phải dữ liệu thật)

Từ baseline giả lập (24 câu hỏi, Phân tích được 18, Chưa xác định 6), team có 6 ứng viên. Chọn 3:

Ba ứng viên còn lại gác lại, ghi lý do (cần dev, cần quyết định giá). Đo lại: cùng 24 câu hỏi, sau khi cả ba việc nghiệm thu. Không việc nào có tiêu chí “xuất hiện trong AI”.

Kết quả cần lưu

• Tối đa ba việc; mỗi việc truy được về quan sát trong T02.
• Mỗi việc có người phụ trách, người nghiệm thu, URL, planned_date.
• Tiêu chí nghiệm thu chỉ nói về triển khai, không nói về kết quả AI.
• concurrent_changes được điền hoặc ghi “không biết”.
• Mỗi việc đã làm có completed_date, bằng chứng trước/sau, và dòng trong nhật ký thay đổi.
• Kế hoạch đo lại nêu bộ câu hỏi, bề mặt AI, điều kiện và lý do chọn thời điểm.

Cách đo lại

Dùng PB-M03 sau khi việc đã nghiệm thu. Báo mẫu số hai kỳ (số câu hỏi được lên lịch, đã đo, Phân tích được, Chưa xác định, số câu trả lời có đề xuất mua hàng) và từng lớp kết quả riêng; không gộp thành điểm chung. Với nhiều việc thực hiện gần nhau, kết quả đo không tách được việc nào gây ra thay đổi nào; đây là lý do tối đa ba việc và ghi rõ thay đổi đồng thời.

Giới hạn và khôi phục

• Ba là con số thực hành đề xuất để giữ khả năng kiểm soát, không phải ngưỡng kỹ thuật.
• Hướng dẫn này không chứng minh việc nào làm tăng hiển thị; chỉ chứng minh việc đã triển khai và đã được kiểm tra.
• Một nhóm sản phẩm, một bề mặt AI, một ngôn ngữ và thị trường.
• Khôi phục: giữ bản trước khi sửa để khôi phục (rollback) nếu việc đã làm sai với dữ liệu kinh doanh.

Mẫu liên quan

T07 (Kế hoạch hành động và nhật ký thay đổi), T02 (Bảng ghi baseline và đối chiếu bằng chứng). Sau khi đo lại: T08 (Báo cáo đo lại trên cùng bộ câu hỏi). Nguồn việc cần làm: PB-R01 (trang danh mục) và PB-R02 (được trích dẫn nhưng chưa được đề xuất).