Hãy rà soát cách tích hợp ChatGPT Ads xử lý danh sách thông tin khách hàng quá dài trước khi dựa vào cơ chế gửi lại tự động. Thay đổi vừa được ghi nhận trong tài liệu Conversions API của OpenAI là dịp phù hợp để kiểm tra phần tạo dữ liệu, nhất là khi nhiều hệ thống cùng cung cấp mã định danh.
Kiểm tra tài liệu ngày 16 tháng 10 năm 2026. Nội dung này khác bản chúng tôi đã đọc ngày 15 tháng 10. Đây là thay đổi được ghi nhận trong tài liệu, không xác định ngày hệ thống bắt đầu áp dụng. GPTAd chưa thử trên tài khoản quảng cáo thực tế.
Tài liệu hiện tại quy định gì?
Mỗi danh sách gửi lên có tối đa ba giá trị. Nếu cùng gửi dạng đơn và dạng danh sách, mỗi trường sau khi gộp có tối đa ba giá trị duy nhất. Vượt một trong hai giới hạn sẽ trả HTTP 400, không tự cắt bớt. Bản trước mô tả việc bỏ qua giá trị thừa. Hãy đọc tài liệu Conversions API hiện tại trước khi sửa tích hợp.
Rà soát phần tạo dữ liệu, không chỉ phần gửi
Bắt đầu từ nơi thông tin khách hàng đi vào quy trình đo lường. Hệ thống thanh toán, dữ liệu xuất từ CRM và bộ chuyển đổi phân tích có thể cùng cung cấp các phiên bản khác nhau của một trường. Dữ liệu từ từng nguồn có vẻ hợp lý nhưng khi gộp lại có thể vượt giới hạn.
GPTAd khuyến nghị lập sơ đồ trách nhiệm đơn giản: dịch vụ nào chọn giá trị, dịch vụ nào chuẩn hóa, dịch vụ nào gộp bản ghi và dịch vụ nào kiểm tra yêu cầu cuối cùng. Chỉ định một người phụ trách quy cách dữ liệu đầu ra. Tránh để các nhóm đều cho rằng API nhận dữ liệu sẽ tự xử lý phần thông tin dư thừa.
Đừng tự động thu thập thêm dữ liệu chỉ để điền đủ số lượng cho phép. Hãy xem mỗi giá trị có phù hợp với sự kiện và được phép dùng cho mục đích đo lường hay không. Khi rà soát kỹ thuật, dùng dữ liệu giả lập và nhật ký đã che thông tin thay vì đưa mã định danh khách hàng vào phiếu xử lý lỗi.
Bảng kiểm thử các trường hợp sát giới hạn
Đây là thiết kế kiểm thử do GPTAd đề xuất, không phải bộ kiểm thử chính thức. Với mỗi trường hợp, ghi tên mẫu, cấu trúc đầu vào, kết quả kiểm tra nội bộ mong đợi và kết quả quan sát. Không sử dụng dữ liệu khách hàng thật.
Thử một trường đại diện với một, hai, ba rồi bốn giá trị. Kiểm tra riêng đầu vào kết hợp dạng đơn và dạng danh sách: một trường hợp tạo ra ba giá trị khác nhau, một trường hợp tạo ra bốn. Thêm trường hợp có giá trị trùng để nhóm không nhầm giữa kiểm tra độ dài danh sách gửi lên và kiểm tra số giá trị duy nhất sau khi gộp.
Chốt kết quả mong đợi trước khi chạy. Nếu phần tạo yêu cầu chặn mẫu vượt giới hạn ngay trong hệ thống, hãy xác minh sự kiện được chuyển sang bước điều tra thay vì bị bỏ đi âm thầm. Nếu bộ chuyển đổi chọn một tập con, ghi rõ ai chịu trách nhiệm và lý do lựa chọn, thay vì cắt tùy ý trong mã gửi lại.
Biến yêu cầu bị từ chối thành lỗi có thể xử lý
GPTAd khuyến nghị tách lỗi truyền tải khỏi lỗi cấu trúc dữ liệu trong hệ thống giám sát. Gửi lại mãi một yêu cầu không hợp lệ không phải cách sửa lỗi. Lưu thông tin chẩn đoán đã che dữ liệu, xác định thành phần tạo yêu cầu và sửa quy tắc trước khi gửi lại những sự kiện đủ điều kiện.
Một cảnh báo hữu ích nên có phiên bản tích hợp, tên trường, số lượng giá trị và kết quả yêu cầu, nhưng không lộ thông tin khách hàng. Rà soát cách hệ thống đánh dấu bản ghi đã gửi, đang chờ hoặc bị từ chối. Đưa dữ liệu vào hàng đợi thành công không chứng minh dịch vụ nhận đã chấp nhận sự kiện.
Hướng dẫn Android được bổ sung
Trang Supported Events hiện nêu rõ nên gửi events[].user.android_advertising_id khi có sẵn cho sự kiện ứng dụng Android, đồng thời cho biết IDFA chưa được hỗ trợ. Đây là hướng dẫn bổ sung, không chứng minh có tính năng iOS mới hay SDK di động mới ra mắt.
Nếu có đo lường ứng dụng, hãy đưa điểm này vào cùng đợt rà soát. Tách quy tắc ánh xạ theo nền tảng khỏi các giả định dành cho sự kiện web, rồi để kỹ sư phụ trách đối chiếu tài liệu hiện tại với tích hợp thực tế.
Đưa bước kiểm tra này vào quy trình đo lường
Kết hợp kiểm tra này với hướng dẫn của GPTAd về quy cách sự kiện và loại bỏ trùng lặp, thay vì xây lại một kiến trúc đang hoạt động tốt. Lưu ngày đối chiếu tài liệu, kết quả kiểm thử và người phụ trách. Mục tiêu là phát hiện và xử lý được lỗi kiểm tra dữ liệu, không phải khẳng định rằng nhiều mã định danh hơn sẽ bảo đảm quảng cáo hiệu quả hơn.
Đọc thêm: quy cách sự kiện và loại bỏ trùng lặp
Đọc thêm: thiết kế đo lường bằng Pixel và CAPI
