Purchase bị ghi nhận hai lần: Sửa Pixel + CAPI

Purchase bị ghi nhận hai lần thường xuất hiện sau khi website vừa có Meta Pixel vừa bật Conversions API. Nhưng browser + server không phải nguyên nhân duy nhất: trang cảm ơn có thể bắn lại khi reload, hai plugin cùng gửi event, webhook thanh toán được retry hoặc worker gửi lại một giao dịch mà không có cơ chế idempotency.

Cách sửa đúng là xác định sự kiện bị nhân đôi ở tầng nào, rồi giữ một danh tính ổn định cho cùng một giao dịch. Với browser và server mô tả cùng hành động, Meta khuyến nghị dedup bằng cùng tên sự kiện và cùng ID. Ở phía ứng dụng, vẫn cần chặn một webhook/worker gửi lặp nhiều server event.

Câu trả lời ngắn: cùng một đơn phải dùng cùng eventID ở Pixel và event_id ở CAPI; hai nguồn phải cùng tên Purchase. Mỗi đơn khác nhau phải có ID khác nhau. Đồng thời, hệ thống server phải lưu trạng thái đã gửi để webhook retry không tạo một Purchase mới.

Bốn kiểu trùng Purchase cần phân biệt

Kiểu trùng	Dấu hiệu	Cách xử lý chính
Browser + Server không dedup	Một event nguồn Browser và một event nguồn Server cho cùng đơn	Đồng bộ event name và event ID
Browser bắn hai lần	Hai event Browser khi reload hoặc nhiều tag/plugin	Chỉ gọi một lần tại điểm xác minh, loại nguồn trùng
Server bắn hai lần	Hai event Server do webhook retry/worker chạy lại	Idempotency và nhật ký đã gửi
Hai sự kiện thật bị gộp nhầm	Nhiều đơn dùng chung một event ID cố định	Tạo ID riêng cho từng giao dịch

Deduplication của Meta hoạt động thế nào?

Theo tài liệu Handling Duplicate Events của Meta, cách được khuyến nghị là dùng Event ID và Event Name:

eventID của Meta Pixel phải khớp event_id của Conversions API.
event của Pixel phải khớp event_name của server.
Hai sự kiện phải được gửi tới cùng Pixel/Dataset.

Meta cho biết với cùng tổ hợp tên và ID nhận trong khoảng thời gian hỗ trợ, hệ thống sẽ loại bản sự kiện đến sau; tài liệu hiện tại nêu cửa sổ 48 giờ cho cơ chế này. Đây là dedup giữa browser và server, không phải một chiếc van tự động chặn mọi event trùng từ cùng một nguồn.

Ví dụ Pixel:

fbq(
  'track',
  'Purchase',
  { value: 1290000, currency: 'VND' },
  { eventID: 'order_8f2c...' }
);

Server event tương ứng:

{
  "event_name": "Purchase",
  "event_time": 1784710800,
  "event_id": "order_8f2c...",
  "action_source": "website",
  "custom_data": {
    "value": 1290000,
    "currency": "VND"
  }
}

Cả hai ví dụ phải đại diện cùng một giao dịch. Chuỗi minh họa không phải mã đơn thật.

Chọn event_id thế nào?

tài liệu Server Event Parameters nêu mã đơn hoặc transaction ID có thể dùng làm event_id. Trong hệ thống thực tế, bạn có thể dẫn xuất một ID ổn định từ mã giao dịch để tránh phơi bày dữ liệu nội bộ không cần thiết.

Một event ID tốt phải có ba tính chất:

Duy nhất giữa các giao dịch: đơn A và đơn B không dùng cùng ID.
Ổn định khi retry: gửi lại đơn A vẫn dùng ID của đơn A, không sinh UUID mới.
Chia sẻ được giữa hai nguồn: browser và server biết cùng một giá trị.

Sai lầm phổ biến là browser tự sinh UUID lúc trang cảm ơn tải, còn server tự sinh UUID khác khi webhook đến. Cả hai đều “unique”, nhưng không khớp nên Meta coi là hai Purchase. Một lỗi khác là dùng giá trị cố định như purchase_event cho mọi đơn, khiến những giao dịch thật có nguy cơ bị hiểu sai.

Kiểu 1: Pixel và CAPI cùng gửi nhưng ID không khớp

Chọn một đơn test và ghi lại:

Pixel/Dataset ID.
Event name ở Browser và Server.
eventID ở Browser.
event_id ở Server.
Thời điểm và value/currency.

Nếu browser gửi Purchase + order_123 nhưng server gửi Purchase + capi_456, dedup không có khóa chung. Nếu một bên gửi Purchase, bên kia gửi custom event PaidOrder, đó có thể là hai định nghĩa khác nhau và cũng không nên ép gộp chỉ để giảm số.

Cách sửa là tạo ID tại nguồn có thể dùng chung—thường là mã giao dịch sau khi order được tạo—rồi đưa ID đó vào lời gọi Pixel và payload CAPI.

Kiểu 2: Trang cảm ơn bắn Purchase mỗi lần tải

Đây là lỗi browser-only. Người dùng reload, quay lại lịch sử hoặc mở lại link và Pixel bắn thêm Purchase. Meta không nhất thiết tự loại hai browser event chỉ vì value giống nhau.

Cách xử lý:

Không coi việc nhìn thấy URL cảm ơn là bằng chứng duy nhất của thanh toán.
Lấy trạng thái đơn từ server và chỉ render lời gọi event cho giao dịch hợp lệ.
Gắn eventID ổn định theo đơn.
Ghi cờ browser event đã phát nếu kiến trúc cần, nhưng không dựa vào localStorage như nguồn sự thật duy nhất.
Kiểm tra back/refresh/direct URL.

Với chuyển khoản hoặc COD, browser có thể không phải nơi tốt nhất để quyết định Purchase vì trạng thái hoàn tất xảy ra sau phiên truy cập.

Kiểu 3: Hai plugin/tag cùng bắn Purchase

Một website có thể đồng thời dùng plugin e-commerce, Google Tag Manager, đoạn code theme và app đối tác. Mỗi thành phần đều được cấu hình “theo dõi Purchase”, dẫn tới hai hoặc ba event Browser.

Lập bảng kiểm kê nguồn:

Nguồn	Event đang gửi	Vai trò sau khi chuẩn hóa
Plugin nền tảng	PageView, ViewContent, Purchase	Giữ hoặc tắt theo kiến trúc chọn
Google Tag Manager	Purchase trên thank-you	Tránh gửi lại nếu plugin đã chịu trách nhiệm
Server/CAPI	Purchase sau xác minh	Giữ và dedup với browser nếu cùng hành động

Mục tiêu không phải tắt mọi nguồn trừ một. Pixel và CAPI có thể bổ sung cho nhau; vấn đề là mỗi nguồn phải có vai trò, chủ sở hữu và cơ chế dedup rõ ràng.

Kiểu 4: Webhook hoặc worker gửi lại Server event

Nhà cung cấp thanh toán gửi lại webhook là hành vi bình thường khi chưa nhận phản hồi hoặc mạng không ổn định. Worker cũng có thể chạy lại sau lỗi. Nếu mỗi lần xử lý lại đều gửi một event ID mới, Meta thấy nhiều server Purchase.

Cần một lớp idempotency trong ứng dụng:

Tạo khóa ổn định theo giao dịch và loại event.
Trước khi gửi, kiểm tra trạng thái đã thành công hay chưa.
Nếu chưa, gửi với cùng event ID.
Lưu response, thời điểm và số lần thử.
Nếu đã thành công, webhook retry chỉ xác nhận rồi bỏ qua bước gửi.

Dedup của Meta không thay thế lớp này. Ứng dụng cần biết chính nó đã gửi gì để đối soát và tránh gọi API không cần thiết. Case SePay → Meta Dataset minh họa cách cho phép webhook phát lại nhưng vẫn không nhân đôi Purchase.

Cách kiểm thử sau khi sửa

Tạo ít nhất ba kịch bản:

Kịch bản A: giao dịch bình thường

Một browser event và một server event nếu kiến trúc dùng cả hai.
Cùng event name và ID.
Events Manager thể hiện xử lý/gộp đúng.

Kịch bản B: reload trang cảm ơn

Không tạo một Purchase mới có ID khác.
Không kích hoạt lại nghiệp vụ.

Kịch bản C: webhook retry

Không tạo giao dịch mới.
Nếu lần đầu đã gửi thành công, lần sau bỏ qua.
Nếu lần đầu lỗi trước khi Meta chấp nhận, retry dùng cùng event ID.

Sau đó đối chiếu theo từng order ID, không chỉ tổng số trong ngày. Tổng có thể bị ảnh hưởng bởi attribution và timezone; kiểm tra theo giao dịch giúp chứng minh dedup đang đúng.

Đừng sửa đếm đôi bằng cách tắt CAPI ngay

Meta mô tả Conversions API là kết nối trực tiếp từ dữ liệu marketing của doanh nghiệp và khuyến nghị cân nhắc dùng cùng Pixel cho website event. Tài liệu About Conversions API nêu hai nguồn có thể tăng độ bền kết nối và đo lường khi triển khai phù hợp.

Tắt CAPI có thể làm biểu đồ hết trùng nhưng cũng bỏ khả năng gửi sự kiện từ server, POS, CRM hoặc hành động xảy ra sau trình duyệt. Sửa đúng là:

Loại nguồn gửi thừa không có chủ đích.
Giữ Pixel và CAPI nếu hai nguồn có vai trò bổ sung.
Đồng bộ danh tính event khi cùng mô tả một hành động.
Đảm bảo idempotency cho webhook/worker.

Những lỗi dễ bị bỏ sót

Hai event có cùng ID nhưng khác tên: không đáp ứng cặp khóa khuyến nghị.

Hai event gửi sang hai Dataset: bạn có thể đang xem tổng hợp sai tài sản.

Order ID có ký tự/format khác nhau: browser gửi 123, server gửi ORDER-123.

Retry tạo timestamp mới và ID mới: khiến một hành động trông như sự kiện khác.

Test Event đi vào production: giao dịch test phải được gắn và loại khỏi báo cáo nghiệp vụ theo quy trình nội bộ.

Gộp hai Purchase thật: xảy ra khi tái sử dụng một ID cố định hoặc ID theo user thay vì theo giao dịch.

Đọc tiếp và học thử

Nếu vấn đề của bạn là thiếu event thay vì thừa event, đọc Pixel Facebook không ghi nhận Purchase. Bài Meta Pixel, Dataset và Conversions API khác nhau thế nào giải thích vì sao nên tách lớp thu thập, nơi tập hợp dữ liệu và nguồn gửi server.

Nếu toàn bộ chiến dịch đang tiêu tiền nhưng không tạo kết quả, hãy quay lại quy trình chẩn đoán Facebook Ads không ra đơn để tránh coi tracking là nguyên nhân duy nhất.

Phần deduplication, event ID và các luồng website/POS/Google Sheets được đặt trong bối cảnh chất lượng chuyển đổi tại khóa học Facebook Ads Chuyển Đổi Vàng. Bạn có thể xem bài mở trước; khóa học không hứa Pixel + CAPI tự làm quảng cáo có lãi, mà giúp bạn hiểu và kiểm soát dữ liệu Meta đang học.

Kết luận

Purchase bị ghi nhận hai lần không được giải quyết bằng cách xoá ngẫu nhiên một nguồn. Hãy xác định event trùng đến từ browser, server hay cả hai. Cùng một giao dịch cần cùng danh tính khi đi qua Pixel và CAPI; giao dịch khác phải có danh tính khác. Kết hợp dedup của Meta với idempotency phía ứng dụng sẽ giúp hệ thống vừa không đếm đôi, vừa có thể retry an toàn khi mạng hoặc webhook gặp lỗi.