event_id trong Facebook Ads là mã định danh dùng để nói với Meta rằng hai bản ghi đến từ Meta Pixel trong trình duyệt và Conversions API trên máy chủ đang mô tả cùng một hành động. Khi tên sự kiện và ID khớp nhau, Meta có cơ sở gộp hai bản ghi thành một chuyển đổi thay vì đếm hai lần.
Điểm quan trọng nhất không phải tạo một chuỗi “thật ngẫu nhiên”, mà là tạo một ID duy nhất giữa các giao dịch, ổn định khi gửi lại và dùng chung được giữa browser với server. Nếu Pixel tự sinh một ID còn webhook tự sinh ID khác, cả hai đều hợp lệ về định dạng nhưng không thể chống trùng.
Câu trả lời ngắn: với cùng một Purchase,
eventIDtrong lời gọi Pixel phải bằngevent_idtrong payload CAPI; tênPurchasecũng phải giống nhau và hai sự kiện phải đi tới cùng Dataset/Pixel. Một đơn khác phải có ID khác. Webhook retry của cùng đơn phải giữ nguyên ID cũ.
event_id giải quyết vấn đề nào?
Khi website dùng cả Pixel và CAPI, một giao dịch có thể được quan sát ở hai nơi:
- Pixel thấy người dùng hoàn tất hành động trong trình duyệt.
- Server thấy thanh toán, đơn hàng hoặc lead được xác nhận trong hệ thống.
Hai nguồn giúp đo lường bền hơn, nhưng nếu không có khóa chung, Meta có thể hiểu đó là hai hành động độc lập. tài liệu Handling Duplicate Pixel and Conversions API Events của Meta khuyến nghị dùng cặp Event ID và Event Name: eventID của Pixel khớp event_id của CAPI, đồng thời event khớp event_name.
Meta nêu rằng khi cùng tổ hợp tên và ID được gửi tới cùng Pixel trong cửa sổ hỗ trợ, bản ghi đến sau sẽ được xử lý như sự kiện trùng. Tài liệu hiện tại mô tả cửa sổ 48 giờ. Đây là cơ chế chống trùng giữa browser và server, không phải hệ thống tự động xoá mọi bản ghi lặp từ cùng một nguồn.
Phân biệt event_id với các mã khác
| Mã | Vai trò chính | Có thay event_id không? |
|---|---|---|
event_id |
Nhận diện một lần xảy ra cụ thể để dedup Pixel và CAPI | Đây là khóa khuyến nghị cho dedup |
external_id |
Mã first-party liên hệ một khách hàng với hệ thống doanh nghiệp | Không nên coi là mã giao dịch |
fbp |
Định danh trình duyệt từ cookie Meta | Hỗ trợ matching, không phải mã đơn |
fbc |
Thông tin click Facebook được tạo từ fbclid hợp lệ |
Hỗ trợ attribution/matching, không phải mã đơn |
| Order/transaction ID | Mã giao dịch trong backend | Có thể làm đầu vào tạo event_id ổn định |
Một người có thể mua nhiều lần, vì vậy không dùng user ID, email hoặc số điện thoại làm event ID của Purchase. Ngược lại, cùng một đơn có thể được webhook gửi lại nhiều lần; mỗi lần retry vẫn phải dùng danh tính của đúng đơn đó.
Ba tính chất của một event_id tốt
1. Duy nhất giữa các hành động thật
Đơn A và đơn B phải có hai ID khác nhau. Hai lượt gửi form độc lập cũng không dùng chung ID. Nếu dùng chuỗi cố định như purchase cho mọi đơn, các chuyển đổi thật có nguy cơ bị gộp sai.
2. Ổn định khi retry hoặc reload
Webhook của đơn A gửi lần hai không được sinh UUID mới. Người dùng reload trang cảm ơn cũng không nên tạo một danh tính mới. ID nên được tạo từ lúc hệ thống đã có thực thể giao dịch hoặc lưu lại cùng bản ghi nghiệp vụ.
3. Có thể chia sẻ giữa browser và server
Nếu trang cảm ơn phát Pixel và webhook phát CAPI cho cùng trạng thái Purchase, hai nguồn cần nhận cùng một giá trị. Một chiến lược thực tế là dẫn xuất ID từ mã giao dịch bằng một prefix theo loại sự kiện, ví dụ purchase_[ma-giao-dich-noi-bo]. Nếu không muốn đưa nguyên mã nội bộ ra browser, có thể dùng token ổn định đã được ánh xạ ở server.
Luồng triển khai đúng cho Purchase
- Backend tạo order và mã giao dịch ổn định.
- Hệ thống xác định rõ thời điểm nào được coi là Purchase: tạo đơn, nhận tiền hay giao thành công.
- Từ mã giao dịch, tạo hoặc lấy event ID đã lưu.
- Nếu browser đủ điều kiện phát Purchase, truyền đúng event ID vào tham số thứ tư của lời gọi Pixel.
- Khi webhook/worker phát CAPI, dùng cùng
event_idvà cùngevent_name. - Lưu log request, response, trạng thái và số lần thử ở server.
- Webhook retry kiểm tra idempotency; nếu cần gửi lại thì vẫn dùng ID cũ.
Ví dụ Pixel:
fbq(
'track',
'Purchase',
{ value: 1290000, currency: 'VND' },
{ eventID: 'purchase_tx_8f2c' }
);Server event tương ứng:
{
"event_name": "Purchase",
"event_time": 1785600000,
"event_id": "purchase_tx_8f2c",
"action_source": "website",
"custom_data": {
"value": 1290000,
"currency": "VND"
}
}Chuỗi trên chỉ là minh họa. Không dùng mã đơn thật, email hoặc số điện thoại của khách trong tài liệu công khai.
Bảng chẩn đoán khi dedup không hoạt động
| Dấu hiệu | Nguyên nhân thường gặp | Kiểm tra |
|---|---|---|
| Một Browser và một Server đều được tính | ID hoặc event name không khớp | So từng ký tự của hai payload |
| Hai Browser event | Reload trang, hai tag hoặc hai plugin | Pixel Helper, GTM Preview và Network |
| Hai Server event | Webhook retry, worker chạy lại | Log theo transaction và response |
| Nhiều đơn thật bị thiếu | Dùng chung một event ID | Kiểm tra độ duy nhất theo giao dịch |
| Dedup lúc được lúc không | Một nguồn tự sinh UUID mới | Truy ngược nơi tạo ID |
event_id không thay thế idempotency phía server
Nếu webhook thanh toán gọi ba lần, ứng dụng vẫn phải biết giao dịch đã được xử lý chưa. Không nên dựa hoàn toàn vào Meta để dọn hậu quả. Lớp idempotency giúp:
- Không cấp quyền khóa học hoặc cộng doanh thu hai lần.
- Không gửi email/webhook đối tác lặp.
- Không gọi CAPI vô ích sau khi lần trước thành công.
- Cho phép retry an toàn khi request trước thực sự thất bại.
Khóa idempotency thường kết hợp loại nghiệp vụ với mã giao dịch. Trạng thái cần phân biệt “đang xử lý”, “đã gửi thành công” và “thất bại có thể thử lại”. Nếu request timeout, đừng vội sinh một ID mới; trước hết kiểm tra log và trạng thái response.
Cách kiểm thử mà không làm bẩn dữ liệu
- Dùng Test Events hoặc môi trường kiểm thử phù hợp.
- Chọn một giao dịch test có thể nhận diện và loại khỏi báo cáo kinh doanh.
- Ghi lại event name, event ID, Dataset ID, thời điểm, value và currency của hai nguồn.
- Thử luồng bình thường, reload trang và webhook retry.
- Xác nhận một giao dịch chỉ tạo một kết quả cuối cùng.
- Kiểm tra thêm một giao dịch thứ hai để chắc chắn ID không bị tái sử dụng.
Không upload hàng loạt đơn cũ với thời gian giả để “dạy thuật toán”. Việc đó làm sai báo cáo và không kiểm tra được kiến trúc dedup. Dữ liệu thật, đúng thời điểm và đúng định nghĩa chuyển đổi có giá trị hơn số lượng sự kiện nhân tạo.
Những lỗi cần tránh
Sinh UUID độc lập ở từng nguồn: browser và server không còn khóa chung.
Dùng user ID cho Purchase: một khách mua hai lần dễ bị hiểu thành cùng một sự kiện.
Dùng URL thành công làm bằng chứng duy nhất: người dùng có thể mở lại hoặc truy cập trực tiếp URL.
Chỉ nhìn tổng số trong Ads Manager: attribution và độ trễ có thể làm tổng thay đổi; cần đối chiếu từng transaction.
Tắt CAPI ngay khi thấy trùng: cách này che lỗi dedup và làm mất đường gửi server đáng tin cậy.
Đọc tiếp và học thử
Nếu bạn đang gặp sự cố cụ thể, bài Purchase bị ghi nhận hai lần cung cấp quy trình xử lý theo browser, server và webhook. Khi event không xuất hiện, dùng checklist Pixel Facebook không ghi nhận Purchase.
Sau khi dedup đúng, bước tiếp theo là kiểm tra Meta có đủ tín hiệu hợp lệ để liên hệ event với người dùng hay không. Xem bài Event Match Quality thấp: sửa dữ liệu theo đúng thứ tự và hub Meta Pixel, Dataset và Conversions API.
Trong khóa học Facebook Ads Chuyển Đổi Vàng, phần dữ liệu chuyển đổi đặt event ID trong toàn bộ luồng đơn hàng, webhook, browser/server và chất lượng tín hiệu. Bạn có thể mở bài học thử trước khi quyết định đăng ký.
Kết luận
event_id không phải một trường kỹ thuật thêm cho đủ payload. Nó là danh tính của một lần xảy ra cụ thể. Cùng một hành động đi qua Pixel và CAPI phải giữ cùng tên và cùng ID; hành động khác phải có ID khác; retry phải giữ ID cũ. Khi kết hợp nguyên tắc này với idempotency và log theo giao dịch, bạn vừa tránh đếm đôi vừa không làm mất khả năng gửi lại an toàn.
0 Bình luận
Để lại bình luận