Pixel Facebook không ghi nhận Purchase: Cách kiểm tra

Pixel Facebook không ghi nhận Purchase có thể là bốn vấn đề khác nhau: website chưa phát sự kiện, trình duyệt đã phát nhưng request bị chặn/lỗi, server gửi CAPI nhưng Meta từ chối, hoặc Dataset đã nhận Purchase nhưng Ads Manager không phân bổ cho chiến dịch. Nếu không tách bốn lớp này, việc “test lại” hoặc gửi bù có thể tạo thêm dữ liệu sai.

Quy trình đúng bắt đầu từ đơn hàng thật, xác định điểm kích hoạt Purchase, kiểm tra riêng Browser và Server, đọc phản hồi API, rồi mới xem attribution. Bài này tập trung vào sự kiện website; với lead, tin nhắn hoặc offline, tên trường và nguồn hành động có thể khác nhưng tư duy đối soát vẫn giống nhau.

Câu trả lời ngắn: chọn một giao dịch test có mã riêng, ghi thời điểm và giá trị, kiểm tra Test Events/Browser request, sau đó kiểm tra log CAPI bằng chính mã đó. Đừng chỉ nhìn biểu đồ tổng; đừng gửi lại Purchase với mã ngẫu nhiên trước khi biết sự kiện cũ đã được Meta chấp nhận hay chưa.

Trước hết: “không ghi nhận” đang xảy ra ở đâu?

Hiện tượng	Ý nghĩa có thể	Nơi kiểm tra
Đơn thật có nhưng Test Events không thấy gì	Chưa kích hoạt, sai Dataset hoặc request không tới Meta	Code/browser network/server log
Browser có Purchase, Server không có	CAPI chưa chạy, webhook/worker lỗi hoặc payload bị từ chối	Application log và phản hồi Graph API
Server có Purchase, Browser không có	Có thể là chủ đích hoặc Pixel/trang cảm ơn lỗi	Thiết kế tracking và browser console
Events Manager có Purchase, Ads Manager không có	Khác attribution, không khớp người dùng hoặc không gắn với quảng cáo	Dataset diagnostics và cài đặt báo cáo
Meta có số Purchase thấp hơn hệ thống đơn	Có thể thiếu event, lỗi ghép nối hoặc đơn không thuộc quảng cáo	Đối soát theo từng giao dịch

Bước 1: Chọn nguồn sự thật và điều kiện bắn Purchase

Nguồn sự thật là nơi doanh nghiệp xác nhận giao dịch đã đạt điều kiện được gọi là Purchase. Với thanh toán online, đó có thể là webhook đã xác minh và đơn ở trạng thái paid. Với COD, form tạo đơn thường chưa phải kết quả cuối; doanh nghiệp có thể cần mốc xác nhận hoặc giao thành công tùy chiến lược và lượng dữ liệu.

Ghi rõ cho mỗi loại đơn:

Điều kiện kích hoạt.
Thời điểm hành động thật.
Mã đơn/mã giao dịch làm khóa đối soát.
Giá trị và tiền tệ.
Nguồn gửi: Browser, Server hay cả hai.

Nếu đội kỹ thuật và marketing định nghĩa Purchase khác nhau, sự kiện có thể “hoạt động đúng code” nhưng vẫn sai nghiệp vụ.

Bước 2: Xác nhận đúng Pixel/Dataset ID

Meta đang hợp nhất sự kiện website, app và offline trong Dataset; Dataset tạo từ Pixel hiện có có thể giữ cùng ID. Điều này khiến nhiều tài khoản có tên hiển thị khác nhau nhưng dùng chung dãy số. Hãy đối chiếu ID trong code/plugin/server với ID ở Events Manager trước khi sửa logic.

Các lỗi thường gặp:

Website staging và production dùng chung/sai Pixel.
Plugin gửi browser event vào một ID còn CAPI gửi server event vào ID khác.
Access token thuộc đúng Business nhưng không có quyền với Dataset đang xem.
Nhiều plugin/tag cùng quản lý Pixel khiến không ai biết nguồn thực sự.

Tài liệu cài đặt Meta Pixel chính thức mô tả Pixel và Dataset ID trong giao diện hiện tại. Không tạo tài sản mới chỉ để thử khi chưa xác minh ID cũ.

Bước 3: Kiểm tra sự kiện Browser

Nếu Purchase được gửi từ trình duyệt, dùng một giao dịch test và theo dõi:

Trang/ứng dụng có thực sự đi qua điểm gọi fbq('track', 'Purchase', ...) không.
Base Pixel có tải trước lời gọi sự kiện không.
Console có lỗi JavaScript không.
Network có request tới endpoint Meta hay bị chặn.
Event name, value, currency và eventID có đúng không.

Thử trong cửa sổ bình thường và ẩn danh giúp phát hiện tác động của extension/cookie, nhưng ad blocker có thể làm browser event biến mất dù hệ thống server vẫn tốt. Đó là một lý do Meta khuyến nghị cân nhắc dùng Conversions API cùng Pixel cho sự kiện website. Tài liệu Conversions API của Meta cũng lưu ý CAPI ít bị ảnh hưởng hơn bởi lỗi tải trình duyệt, kết nối và ad blocker.

Không đặt Purchase chỉ dựa vào việc trang cảm ơn được tải nếu người dùng có thể reload hoặc mở URL trực tiếp. Điểm kích hoạt phải gắn với giao dịch đã được xác minh.

Bước 4: Kiểm tra sự kiện Server/CAPI

Server không có giao diện nên log là bằng chứng chính. Với mỗi lần gửi, cần lưu tối thiểu mã sự kiện đã ẩn danh, tên event, thời điểm, HTTP status, response body đã loại secret và trạng thái retry. Không ghi access token hoặc thông tin cá nhân thô vào log.

Theo Server Event Parameters của Meta, các trường cốt lõi gồm:

event_name: tên sự kiện chuẩn hoặc custom.
event_time: Unix timestamp theo giây của lúc hành động thực sự xảy ra.
user_data: dữ liệu khách hàng hợp lệ để ghép nối.
action_source: nơi chuyển đổi xảy ra, ví dụ website.
event_source_url: bắt buộc với website event qua CAPI.
event_id: khuyến nghị khi cần dedup browser/server.

Một payload minh họa đã lược dữ liệu nhạy cảm:

{
  "event_name": "Purchase",
  "event_time": 1784710800,
  "event_id": "order_8f2c...",
  "action_source": "website",
  "event_source_url": "https://example.com/checkout/success",
  "user_data": {
    "em": ["sha256_normalized_email"],
    "ph": ["sha256_normalized_phone"]
  },
  "custom_data": {
    "value": 1290000,
    "currency": "VND"
  }
}

Ví dụ chỉ mô tả cấu trúc. Dữ liệu khách hàng phải được chuẩn hóa, xử lý và gửi theo tài liệu/chính sách hiện hành; CAPI không phải cách lách quyền riêng tư.

Bước 5: Đọc phản hồi API, không chỉ kiểm tra “đã gọi hàm”

Hàm PHP/Node hoàn tất không có nghĩa Meta đã chấp nhận event. Hệ thống phải đọc HTTP status và response. Một lỗi token, quyền, JSON, timestamp quá cũ, thiếu trường hoặc Dataset sai có thể khiến request bị từ chối. Nếu catch exception rồi bỏ qua để người dùng vẫn thanh toán được, luồng nghiệp vụ đúng nhưng tracking thiếu.

Cách thiết kế bền hơn:

Hoàn tất đơn và quyền lợi khách hàng trước.
Ghi tác vụ gửi CAPI vào trạng thái có thể retry.
Gửi event và lưu phản hồi.
Nếu lỗi tạm thời, retry với cùng event_id.
Nếu lỗi dữ liệu, đưa vào hàng chờ chẩn đoán thay vì lặp vô hạn.

Case SePay nhận tiền nhưng Meta Dataset thiếu Purchase là ví dụ thực tế: nghiệp vụ đã hoàn tất nhưng bước báo cáo cần khả năng phát lại an toàn.

Bước 6: Kiểm tra thời gian, giá trị và tiền tệ

Event có thể xuất hiện nhưng chẩn đoán hoặc báo cáo sai nếu:

event_time dùng thời điểm gửi lại thay vì thời điểm thanh toán.
Timestamp dùng mili giây thay vì giây.
value dùng chuỗi có dấu chấm/phẩy không đúng kiểu.
currency thiếu hoặc không khớp giá trị.
Múi giờ trong hệ thống đơn và báo cáo khác nhau.

Tài liệu Meta cho phép event_time sớm hơn thời điểm gửi để hỗ trợ xử lý trễ, nhưng giới hạn thời gian áp dụng. Vì thế phải xử lý retry sớm, không gom sự kiện nhiều tuần rồi mới gửi bù.

Bước 7: Nếu Events Manager có Purchase nhưng Ads Manager vẫn thiếu

Lúc này tracking connectivity có thể đã hoạt động. Tiếp tục kiểm tra:

Purchase có thuộc đúng Dataset dùng cho ad set không.
Sự kiện có dữ liệu ghép nối hợp lệ hay không.
Giao dịch có thực sự đến sau một tương tác quảng cáo thuộc cửa sổ attribution không.
Báo cáo đang dùng cùng ngày, múi giờ và mô hình attribution không.
Event browser/server đã được dedup đúng chưa.

Không phải mọi Purchase của website đều phải được Meta phân bổ cho quảng cáo. Organic, direct, email hoặc nguồn khác vẫn tạo đơn. Đây là lý do số đơn website, số event Dataset và số conversion trong Ads Manager cần được đối soát riêng.

Checklist 15 phút cho một đơn test

Ghi mã đơn, thời gian, giá trị và loại thanh toán.
Xác minh điều kiện Purchase đã đạt.
Xác minh Pixel/Dataset ID.
Mở Test Events trước khi thao tác.
Theo dõi browser console/network.
Kiểm tra log server/webhook/worker.
Đọc HTTP response của Graph API.
So event name, event time, action source, value và currency.
So eventID browser với event_id server nếu dùng cả hai.
Xác nhận event xuất hiện đúng nguồn Browser/Server.
Ghi kết quả vào bảng đối soát thay vì dựa vào trí nhớ.

Không nên làm gì khi Purchase bị thiếu?

Không gửi bù với mã ngẫu nhiên: bạn có thể tạo một Purchase mới thay vì hoàn tất sự kiện cũ.

Không cài thêm plugin Pixel ngay: nhiều nguồn có thể làm trùng PageView/Purchase và khiến chẩn đoán khó hơn.

Không công khai access token hoặc payload thật: log và ảnh hướng dẫn phải che dữ liệu khách hàng, token, IP và mã giao dịch nhạy cảm.

Không coi Test Events là doanh thu: đây là công cụ kỹ thuật, không thay thế đối soát thanh toán.

Không sửa đồng thời browser, server và attribution: giữ một giao dịch test và lần theo từng lớp để biết lỗi nằm ở đâu.

Nếu Purchase lại bị đếm đôi

Khi sửa thiếu event bằng cách bật thêm CAPI, lỗi tiếp theo thường là browser và server cùng gửi một giao dịch nhưng không khử trùng. Hãy đọc Purchase bị ghi nhận hai lần: sửa Pixel và CAPI. Nếu toàn bộ camp đang không ra đơn, bài quy trình chẩn đoán Facebook Ads không ra đơn giúp kiểm tra cả những tầng ngoài tracking.

Bài nền Meta Pixel, Dataset và Conversions API khác nhau thế nào giải thích vai trò của từng thành phần trước khi bạn thay đổi kiến trúc.

Nếu đang dùng website, WooCommerce, Pancake POS, Google Sheets hoặc một luồng thanh toán/webhook và muốn xem cách thiết kế chuyển đổi theo nguồn sự thật, bạn có thể xem bài mở trong khóa học Facebook Ads Chuyển Đổi Vàng. Khóa học tập trung vào dữ liệu chuyển đổi và chẩn đoán; không cam kết một cấu hình kỹ thuật sẽ tự tạo lợi nhuận.

Kết luận

Pixel Facebook không ghi nhận Purchase chỉ được sửa chắc chắn khi bạn biết event mất ở browser, server, Dataset hay attribution. Dùng một giao dịch test có danh tính rõ ràng, đọc request và response, giữ log có thể đối soát và retry với cùng mã sự kiện. Mục tiêu không phải làm biểu đồ đẹp hơn; mục tiêu là để dữ liệu quảng cáo phản ánh đúng kết quả kinh doanh trong phạm vi Meta có thể quan sát và phân bổ.