Con đường một chuyển đổi đi vào Google Ads

Một khách bấm quảng cáo lúc chín giờ sáng thứ Hai, gọi điện ngay sau đó. Nhân viên chốt lịch, thợ tới làm hôm thứ Tư, đơn đóng với giá 4,2 triệu. Sáng thứ Năm hệ thống gửi con số đó lên Google Ads.

Google ghi 4,2 triệu ấy vào ngày nào?

Không phải thứ Năm. Vào thứ Hai — ngày khách bấm quảng cáo. Bài này giải thích vì sao, và những chỗ khoảng cách bốn ngày đó âm thầm làm hỏng quyết định của bạn.

Bốn phần trước dừng ở chỗ: đo được cuộc gọi đến từ quảng cáo nào. Phần này nói việc kế tiếp — gửi kết quả ngược về Google — và những mốc thời gian không ai nói cho bạn biết.

Tấm vé khớp

Khi khách bấm quảng cáo, Google gắn vào địa chỉ một mã riêng cho lần bấm đó. Website đọc mã, lưu lại, gắn nó với người này.

Mã đó là tấm vé duy nhất để sau này ghép ngược. Cuộc gọi điện thoại không mang theo thông tin quảng cáo nào; đơn hàng trong phần mềm quản lý cũng vậy. Chỉ tấm vé đó biết tiền này ra từ lượt bấm nào, từ khoá nào.

Nên toàn bộ việc gửi kết quả ngược về Google rút gọn thành một câu: giữ tấm vé cho tới lúc biết đơn đáng bao nhiêu, rồi nộp lại vé kèm số tiền.

Vì sao tiền được ghi về ngày bấm quảng cáo

Đây là chỗ hiểu nhầm đắt nhất trong cả bài.

Tài liệu chính thức của Google ghi: "Any attributed conversions will appear in reporting in Google Ads organized by their impression or click time" — chuyển đổi được quy về sẽ hiện trong báo cáo, xếp theo thời điểm hiển thị hoặc thời điểm bấm quảng cáo (Fix discrepancies and errors in offline conversion imports, tra ngày 04/08/2026).

Dịch sang hệ quả thực tế: ô của thứ Hai trong báo cáo vẫn còn dày lên vào thứ Năm, thứ Sáu, tuần sau.

Từ đó ra một luật đọc báo cáo mà rất nhiều tài khoản vi phạm hằng tuần: đừng kết luận gì từ ba tới bảy ngày gần nhất. Chúng luôn trông tệ, và trông tệ đúng bằng độ dài chu kỳ chốt đơn của bạn cộng nhịp gửi dữ liệu. Ngành nào khách chốt trong ngày thì cửa sổ mù ngắn; ngành nào khách hẹn thợ tuần sau thì dài hơn hẳn.

Hiện tượng này cũng giải thích một chuyện hay gặp: bạn tăng ngân sách hôm thứ Hai, thứ Ba mở báo cáo thấy hiệu quả tụt, rồi vội giảm lại. Thực ra bạn đang so ô đã đầy của tuần trước với ô mới vẽ được một phần của hôm qua.

Ba mốc thời gian gây lỗi âm thầm

Mỗi mốc dưới đây đều làm mất dữ liệu mà không báo lỗi ầm ĩ.

Sáu giờ. Gửi kết quả lên quá sớm sau lượt bấm thì Google chưa xử lý xong lượt bấm đó, và nó không tìm thấy tấm vé. Tài liệu ghi: "The click associated with the given identifier or iOS URL parameter occurred less than 6 hours ago, retry after 6 hours have passed" — lượt bấm xảy ra chưa tới 6 giờ trước thì hãy thử lại sau khi đủ 6 giờ (nguồn đã dẫn ở trên). Hệ thống nào gửi tức thời khi đơn đóng, mà đơn lại đóng trong ngày, thì sẽ đều đặn mất một phần dữ liệu mà bảng điều khiển vẫn xanh.

Bốn tới sáu giờ sau khi tạo mới. Vừa tạo một loại chuyển đổi mới thì phải chờ trước khi gửi dữ liệu vào đó: "After creating a new conversion action, wait 4-6 hours before uploading conversions for that conversion action" (Set up offline conversions using Google Click ID, tra ngày 04/08/2026). Đây là cái bẫy của ngày đầu tiên: dựng xong, gửi thử ngay, thấy lỗi, tưởng dựng sai, đi sửa lung tung.

Chín mươi ngày. Tấm vé không sống mãi. Tài liệu ghi Google chỉ giữ mã lần bấm trong 90 ngày, và khuyến nghị gửi thường xuyên hơn; nếu chuyển đổi xảy ra sau mốc đó thì phải chọn một sự kiện khác xảy ra trong hạn để gửi lên. Với sửa chữa nhà hay khám lẻ thì 90 ngày là thoải mái. Với cấy ghép răng phức tạp hay thẩm mỹ lớn, nơi khách cân nhắc hàng tháng, đây là hạn cứng phải tính từ đầu chứ không phải phát hiện lúc mất dữ liệu.

Trên hệ thống 1fix.vn, đơn vị dịch vụ sửa chữa nhà tại TP.HCM do chính chúng tôi xây và vận hành, dữ liệu được gửi mỗi sáng một lần, độ trễ một tới ba ngày kể từ lượt bấm. Nhịp đó nằm an toàn ngoài mốc sáu giờ và cách rất xa mốc 90 ngày. Chậm một nhịp là có chủ đích: một đơn vừa tạo lúc năm giờ chiều chưa chắc đã hoàn thành, giá cuối cùng có thể đổi khi thợ tới nơi.

Ba đường gửi dữ liệu, và vì sao phải biết mình đi đường nào

Có nhiều hơn một cách đưa kết quả về Google, và chúng khác nhau ở chỗ quan trọng: cái nào đang bị Google thay đổi.

Đường nhập tệp. Đổ dữ liệu vào Google Sheets, kho lưu trữ đám mây, hoặc nối thẳng cơ sở dữ liệu, rồi Google tự lấy về theo lịch. Cửa sổ lấy lại khác nhau theo nguồn, và tài liệu ghi rõ con số: với Google Cloud Storage, Amazon S3, HTTP, SFTP và Google Sheets, mỗi lần chạy Google nhập lại chuyển đổi của 90 ngày trước; với BigQuery, Amazon Redshift, Snowflake, MySQL và PostgreSQL thì mỗi lần chạy nhập 14 ngày (nguồn đã dẫn). Chênh lệch này quyết định một bản ghi sửa muộn còn kịp vào hay không.

Đường Google Ads Scripts. Viết một đoạn mã chạy ngay trong tài khoản quảng cáo, gọi hàm gửi hàng loạt. Đây là đường hệ thống 1fix.vn đang dùng.

Đường giao diện lập trình Google Ads. Gọi thẳng từ máy chủ của bạn. Đây là đường đang bị thay đổi.

Chỗ này đáng nói rõ vì nhiều người đang hoảng nhầm. Google thông báo từ 15/06/2026 việc nhập chuyển đổi ngoại tuyến chuyển sang Data Manager API và bị chặn ở giao diện lập trình Google Ads (nguồn đã dẫn). Nhưng thông báo đó nhắm vào một phương thức của một giao diện cụ thể, không phải mọi cách gửi dữ liệu. Đường nhập tệp và đường Google Ads Scripts là các bề mặt khác.

Việc phải làm không phải là lo lắng, mà là biết chắc: hệ thống của bạn đang gửi bằng đường nào? Ai dựng nó phải trả lời được câu đó trong một câu. Không trả lời được thì đó mới là rủi ro thật, chứ không phải cái mốc ngày kia.

Chỗ chúng tôi chưa chứng minh được

Chưa đo được mất bao nhiêu dữ liệu nếu gửi tức thời thay vì chờ. Chúng tôi chọn nhịp một ngày một lần ngay từ đầu vì lý do đơn giá có thể đổi, chứ chưa chạy song song hai nhịp để đo phần chênh. Con số sáu giờ là của Google, không phải kết quả đo của chúng tôi.

Chưa có số liệu ở ngành khách cân nhắc dài. Nhịp gửi và độ trễ nêu trên là của ngành sửa chữa nhà, nơi đơn thường đóng trong vài ngày. Mốc 90 ngày ở đó không bao giờ chạm tới, nên chúng tôi chưa biết nó chật tới mức nào ở ngành khác.

Phần sau nói về chuyện xảy ra khi gửi lên một con số sai: nó khoá lại lúc nào, và vì sao "gửi tạm rồi sửa sau" là kế hoạch nghe hợp lý mà không chạy được.