Để sự kiện chuyển đổi ChatGPT Ads nhất quán, hãy ghi rõ điều gì đã xảy ra, hệ thống nào xác nhận, giá trị được định nghĩa ra sao và mã định danh nào đại diện cho lần phát sinh đó. Phối hợp các thành phần gửi sự kiện từ trình duyệt và máy chủ trước khi kiểm thử bản ghi trùng, gửi lại và hành động lặp lại. GPTAd khuyên bạn dùng đặc tả sự kiện cùng ma trận kiểm thử có thể lặp lại, để báo cáo bắt đầu từ định nghĩa nghiệp vụ đáng tin cậy.
Rà soát ngày 15/10/2026. Đây là hướng dẫn triển khai độc lập của GPTAd. Mọi ví dụ đều giả định; không sử dụng hồ sơ khách hàng hay tuyên bố về hiệu quả nền tảng.
Đặc tả sự kiện giúp những khác biệt này không trở thành lỗi báo cáo âm thầm. Nó mô tả hành động nghiệp vụ trước, cách truyền dữ liệu sau.
Viết đặc tả sự kiện
Tạo một hàng cho mỗi hành động có ý nghĩa, gồm các trường:
- Định nghĩa nghiệp vụ: điều kiện chính xác vừa được đáp ứng.
- Sự kiện trên nền tảng: loại sự kiện được tài liệu mô tả phù hợp với điều kiện đó.
- Nguồn dữ liệu chuẩn: hệ thống có thẩm quyền xác nhận hoàn tất.
- Mã định danh: cách phân biệt lần phát sinh này với lần khác.
- Quy tắc giá trị: bao gồm gì, loại trừ gì và dùng đơn vị nào.
- Kênh truyền: trình duyệt, máy chủ hoặc kết hợp có chủ đích.
- Người phụ trách: ai duyệt thay đổi và điều tra lỗi.
Tài liệu về các sự kiện được hỗ trợ phân biệt tải trang với tương tác nội dung cụ thể, đồng thời đưa ra cấu trúc dữ liệu khác nhau cho từng nhóm sự kiện. Chọn lược đồ sau khi định nghĩa hành động; đừng ép mọi bước trong phễu vào một đối tượng có cấu trúc như giao dịch mua.
Với một công ty phần mềm giả định, “biểu mẫu được tiếp nhận” và “yêu cầu tư vấn đạt chuẩn bán hàng” nên là hai mốc nội bộ riêng. Marketing có thể cần cả hai, nhưng đổi nghĩa mốc thứ nhất thành mốc thứ hai giữa đợt thử nghiệm sẽ làm mất khả năng so sánh.
Định nghĩa giá trị tiền trước khi mã hóa
Tài liệu sự kiện của OpenAI dùng đơn vị tiền tệ nhỏ nhất. Số tiền của mặt hàng là giá trị trên mỗi đơn vị, số lượng là trường riêng, còn số tiền sự kiện đại diện cho toàn bộ sự kiện. Cách này khác đơn vị micros trong đặt giá thầu. Kiểm tra các trường số tiền hiện hành cho cấu trúc sự kiện đã chọn.
Phép tính giả định: hai mặt hàng giá 24,50 USD mỗi món cho tổng tiền hàng là 49,00 USD. Với đơn vị tiền tệ nhỏ nhất tương ứng hai chữ số thập phân, giá trị mỗi món là 2450, số lượng là 2 và tổng tiền hàng là 4900. Các số này minh họa cách biểu diễn, không phải mức giá của nền tảng hay giá trị giao dịch được đề xuất.
Việc phí vận chuyển, thuế, giảm giá hoặc khoản hoàn tiền sau đó có nằm trong định nghĩa giá trị kinh doanh hay không cần được quyết định riêng. Hãy ghi lại, đừng để frontend và backend tự đưa ra giả định độc lập. Kiểm tra quy ước đơn vị nhỏ nhất thực tế của từng đồng tiền thay vì luôn nhân với 100.
Thêm hai kiểm thử phòng lỗi: thiếu mã tiền tệ phải bị chặn bởi kiểm tra hợp lệ nội bộ, còn số tiền lớn bất thường phải được điều tra. Các phép chuyển đổi âm thầm tưởng như “hữu ích” có thể che giấu sai sót từ hệ thống phía trước.
Xem mã lần phát sinh là hạ tầng dùng chung
Theo kiểm tra ngày 15/10, chống ghi nhận trùng lặp trong CAPI yêu cầu Pixel ID, tên sự kiện và event ID khớp giữa trình duyệt và máy chủ; tên sự kiện tùy chỉnh cũng phải khớp. Sự kiện khớp đến trước được giữ lại.
Tạo mã cho lần phát sinh một lần trong luồng ứng dụng rồi truyền đến các thành phần gửi dữ liệu cần thiết. Nếu mỗi thành phần tự tạo một mã ngẫu nhiên mới, không thể xác định hai bản ghi đại diện cho cùng một lần phát sinh. Ngược lại, dùng lại một mã cho mọi giao dịch mua cũng không phân biệt được các kết quả riêng.
Vì thứ tự dữ liệu đến không nên quyết định giá trị nghiệp vụ, hãy chuẩn bị dữ liệu tương thích trước khi gửi qua bất kỳ kênh nào. Đừng thiết kế kênh gửi sau như cơ chế sửa bản ghi của kênh gửi trước.
Chạy ma trận kiểm thử có thể lặp lại
Dùng môi trường tách biệt hoặc công cụ xác thực được tài liệu hướng dẫn khi phù hợp. Tuyệt đối không gửi giao dịch bán hàng hư cấu vào hệ thống thực tế. Ghi mã bộ dữ liệu mẫu, hành vi mong đợi, yêu cầu gửi đi quan sát được, các trường đã che dữ liệu và người kiểm tra kết quả.
- Một kênh: kích hoạt một bộ dữ liệu mẫu đã duyệt và xác nhận có đúng một lần gửi như dự kiến.
- Hai kênh: theo dấu cùng một lần phát sinh từ lúc được tạo trong ứng dụng đến cả hai bản ghi gửi đi; so sánh mọi trường định danh dùng chung.
- Tải lại trình duyệt: mở lại màn hình hoàn tất và kiểm tra ứng dụng có vô tình tạo lần phát sinh mới không.
- Gửi lại do lỗi mạng: mô phỏng truyền dữ liệu bị gián đoạn và xác minh logic thử lại giữ nguyên mã lần phát sinh.
- Hành động lặp lại thực sự: tạo lần phát sinh hợp lệ thứ hai và xác nhận nó có mã khác.
- Đảo thứ tự đến: lần lượt trì hoãn từng kênh và so sánh các trường nghiệp vụ trước khi đánh giá hành vi của hệ thống nhận.
- Dữ liệu không hợp lệ: bỏ một trường bắt buộc và xác minh cảnh báo có đủ ngữ cảnh để sửa thành phần gửi mà không lộ dữ liệu cá nhân.
- Kiểm thử hồi quy tiền tệ: chạy lại kiểm thử giá trị tiền sau khi thay đổi giảm giá hoặc phần mềm thanh toán.
CAPI có chức năng xác thực mà không lưu; tài liệu cũng cảnh báo một sự kiện không hợp lệ có thể khiến cả lô thất bại. Đưa việc cô lập lỗi theo lô vào danh sách kiểm tra phát hành backend, thay vì mặc định các sự kiện còn lại đều thành công.
Kiểm tra đầy đủ việc định tuyến
Hướng dẫn dùng nhiều pixel hỗ trợ gửi đến tất cả pixel hoặc định tuyến đến một pixel. Nếu website dùng nhiều nguồn dữ liệu, hãy kiểm tra đích đến một cách rõ ràng; đừng thêm pixel chỉ để xử lý sự không chắc chắn khi điều tra lỗi.
Tài liệu cuối cùng cần giúp kỹ sư mới trả lời ba câu hỏi mà không phải đoán: Điều gì đã xảy ra? Đó là lần phát sinh nào? Bản ghi đã duyệt phải được gửi đến đâu? Nền tảng này đáng tin cậy hơn một tổng số trên bảng điều khiển chỉ có vẻ hợp lý.
