Bắt đầu với KétSuite Ads

Phạm vi tài liệu: dựa trên bản mô phỏng KétSuite Ads. Các số liệu, kết nối, AI và hành động trên nền tảng đều là minh họa; tài liệu không xác nhận tính năng đã phát hành.

Bắt đầu từ một câu hỏi kinh doanh#

Chọn một câu hỏi có thể kiểm chứng, chẳng hạn “kênh nào mang về đơn đã thanh toán với chi phí chấp nhận được?”. Tránh mục tiêu chỉ là kết nối thật nhiều tài khoản. Kết quả của giai đoạn đầu là một kỳ báo cáo đối chiếu được và một người chịu trách nhiệm cho mỗi điểm đứt dữ liệu.

Bảng trên là cách phân công trách nhiệm đề xuất. Mock có bốn vai trò mẫu trong Thành viên & phê duyệt: Chủ tài khoản, Quản lý quảng cáo, Chuyên viên phân tích và Kế toán, kèm ngưỡng tăng ngân sách Quản lý được tự duyệt. Hãy ánh xạ từng người trong bảng vào một vai trò trước khi giao việc; cách chọn ngưỡng nằm ở phân quyền và phê duyệt. Mock không có đăng nhập: Xem như dùng để thử quyền của từng vai trò.

Nối đúng tài khoản và nguồn tín hiệu#

Trong Tài khoản quảng cáo, xem nền tảng, trạng thái kết nối, quyền và chế độ của từng tài khoản. Mock có Meta, Google, TikTok và Zalo. Khi kết nối mới, xác nhận phạm vi quản lý và ảnh hưởng tới phí; không mặc định mọi tài khoản phải được AI quản lý.

Chỉ theo dõi dùng để đọc số liệu, không tính phí quản lý và AI không thay đổi tài khoản đó. Đang quản lý nằm trong phạm vi tính phí và có thể nhận thay đổi khi đáp ứng quyền, chế độ AI và các kiểm tra an toàn. Phí tính theo từng ngày được quản lý: chuyển sang chỉ theo dõi thì ngừng tính từ ngày hôm sau, còn những ngày đã quản lý vẫn tính. Kết nối thành công không có nghĩa mọi khả năng ghi đều sẵn sàng.

Tiếp theo mở Nguồn tín hiệu. Website ghi nhận hành trình trên trang; KétChat và KétPhone bổ sung quá trình tư vấn, chốt đơn ngoài trang. Đối chiếu trạng thái nguồn với đơn mẫu trước khi tin vào ROAS. Một cuộc gọi hay cuộc trò chuyện chưa phải là một lượt mua hàng.

Ảnh mock: chọn phạm vi từng tài khoản trước khi bật tự động hóa hoặc tính phí.

Đọc các vùng đánh số trên ảnh:

1. Kết nối tài khoản: bắt đầu từ tài khoản doanh nghiệp sở hữu hoặc được cấp quyền; kiểm người chịu trách nhiệm và phạm vi đồng bộ.
2. Phạm vi quản lý và chế độ AI: hai lựa chọn này trả lời những câu hỏi khác nhau: tài khoản có thuộc phạm vi dịch vụ và AI được phép hành động đến đâu.
3. Chỉ theo dõi: phù hợp khi cần đối chiếu một tài khoản trước khi giao quyền tối ưu; trong mock, tài khoản này không chịu phí quản lý và AI không thay đổi nó.

Nghiệm thu một phạm vi nhỏ trước khi giao quyền tối ưu#

Các cổng dưới đây là quy trình nghiệm thu đề xuất cho đội ngũ. Chưa qua cổng dữ liệu thì chưa chuyển sang tự động hóa.

flowchart TD
 A["Chọn một tài khoản và nhóm sản phẩm"] --> B["Thống nhất kỳ, đơn mua và hoàn hủy"]
 B --> C["Đối chiếu các tình huống đơn mẫu"]
 C --> D("Giải thích được chênh lệch?"):::kv-decision
 D -->|Chưa| E["Sửa nguồn hoặc quy trình đối soát"]
 E --> C
 D -->|Có| F["Thử duyệt và hoàn tác trong mock"]
 F --> G("Có người theo dõi và điều kiện dừng?"):::kv-decision
 G -->|Chưa| H["Giữ chỉ đề xuất hoặc chỉ theo dõi"]
 G -->|Có| I["Mở rộng từng phạm vi đã nghiệm thu"]
 class E,H kv-warning
 class I kv-positive

Hãy chọn một nhóm sản phẩm, một tài khoản quảng cáo và một người chịu trách nhiệm đối soát. Mục tiêu của lần đầu là chứng minh đội ngũ giải thích được đường đi của tiền và đơn, chưa phải nối hết mọi tài khoản. Nếu vừa đổi tích hợp, tệp khách hàng, nội dung và ngân sách trong cùng một đợt, khi số lệch sẽ khó biết bắt đầu từ đâu.

Bước 1 — thống nhất định nghĩa. Ghi kỳ báo cáo, múi giờ, đơn nào được coi là mua thật, cách xử lý hoàn một phần và ai xác nhận nguồn đơn. Lưu một mốc đối chiếu trước khi thay đổi: chi tiêu theo tài khoản, đơn đã thanh toán, đơn còn chờ và đơn chưa ghép nguồn. Mốc này giúp phân biệt dữ liệu được bổ sung với doanh thu mới phát sinh; mock không tự tạo biên bản nghiệm thu thay doanh nghiệp.

Bước 2 — đối chiếu các tình huống có chủ đích. Chọn đơn Website có nguồn rõ, đơn KétChat/KétPhone chốt ngoài trang, đơn hoàn/hủy và đơn thiếu nguồn. Đây là bộ tình huống để kiểm đường đi, không phải mẫu thống kê chứng minh độ chính xác toàn hệ thống. Với mỗi đơn, mở hành trình rồi trả lời: giá trị đúng chưa, kênh chốt đúng chưa, vì sao ghi nhận cho chiến dịch này, có dấu hiệu ghi nhận hai lần không? Gặp sai thì xử lý nguyên nhân trước khi nối thêm nguồn.

Bước 3 — kiểm trách nhiệm khi có lỗi. Thử luồng mất quyền trong mock: người vận hành có nhận ra tài khoản bị ảnh hưởng, quay lại đúng đề xuất sau kết nối và đọc lại căn cứ mới không? Thử hoàn tác một thay đổi nhỏ để biết nơi kiểm kết quả. Khôi phục được thao tác không đồng nghĩa dữ liệu tích hợp đã trở lại đầy đủ.

Khi nào nên giữ tài khoản ở chế độ chỉ theo dõi?#

Giữ chỉ theo dõi khi đang kiểm dữ liệu, quyền thay đổi chưa được giao hoặc tài khoản thuộc một phạm vi kinh doanh cần đánh giá riêng. Đừng đổi sang quản lý chỉ để làm cho danh sách trông đồng nhất. Trong mock, chuyển phạm vi ảnh hưởng cả quyền AI và cơ sở tính phí; quyết định này cần người chịu trách nhiệm ngân sách hiểu rõ.

Một dấu hiệu đủ để mở rộng là đội ngũ xử lý được một vòng hoàn chỉnh: nhận ra bất thường → tìm đúng đơn hoặc tài khoản → sửa nguyên nhân → kiểm kết quả → giải thích phần số liệu thay đổi. Số tài khoản kết nối thành công chỉ là chỉ số triển khai, chưa phải chỉ số thành công kinh doanh. Mở rộng từng phạm vi đã nghiệm thu giúp truy nguyên sai lệch dễ hơn nếu nguồn mới có chất lượng khác nguồn cũ.

Lộ trình áp dụng từng bước#

1. Chọn một nhóm chiến dịch đại diện, thống nhất kỳ báo cáo và xác nhận đơn mua tương ứng.
2. Đặt trần trong Ngân sách & nhịp chi và kiểm Quy tắc an toàn. Bắt đầu bằng chế độ chỉ đề xuất để đội ngũ hiểu lý do thay đổi.
3. Xử lý một đơn chưa rõ nguồn trong Đơn hàng & chuyển đổi, kiểm hành trình và ghi nhận kết quả đối soát.
4. Duyệt một đề xuất có đủ căn cứ; đọc Nhật ký thay đổi và thử quy trình hoàn tác trong mock.
5. Sau khi dữ liệu và trách nhiệm ổn định, dùng thử nghiệm đối chứng để đánh giá có nên mở rộng phạm vi.

Bước tiếp: điều hành chiến dịch và ngân sách.