Cài đặt S2S postback cho affiliate Việt Nam 2026: hướng dẫn từ góc dev

Postback là chỗ rớt tiền số một, không phải creative

Tên tôi là Minh. Bảy năm backend ở FPT và một fintech Singapore, ba năm affiliate. Bài này không phải câu chuyện chuyển nghề — tôi viết cái đó rồi. Đây là một bài how-to kỹ thuật, viết cho người đã chạy campaign nhưng số trên tracker không khớp số advertiser trả, và không hiểu tiền rơi ở đâu. Câu trả lời gần như luôn nằm ở một chỗ: S2S postback. Đó là leg cuối của pipeline, là chỗ ít marketer Việt kiểm tra nhất, và là chỗ rớt tiền nhiều nhất.

Tôi sẽ vẽ cái pipeline ra bằng tiếng Việt, theo cách một backend engineer vẽ system design — không phải theo cách một marketer vẽ funnel. Bạn sẽ thấy postback là gì, vì sao nó hơn pixel, cách map token sub_id1–sub_id5, cách dựng server-side, sáu lý do postback bị rớt âm thầm, dedup và attribution window đặt bao lâu, và cách test postback trước khi đốt một đồng spend. Mọi con số trong bài đến từ log của hai property tôi tự chạy — không phải benchmark trên slide bán khóa học.

Một điểm load-bearing trước khi vào việc: dashboard của advertiser đếm conversion ở phía họ; tracker của bạn đếm cái về tới bạn. Hai con số đó khác nhau. Khoảng cách giữa chúng là postback rớt — và khi có tranh chấp hoa hồng (sẽ có), bên có receipts thắng. Bạn cần là bên có receipts.

S2S postback là gì, và vì sao nó không phải pixel

Pixel tracking là một đoạn JavaScript hoặc một img tag fire client-side, trong trình duyệt của user, khi conversion xảy ra. S2S postback là một HTTP request fire server-side, từ server của advertiser thẳng tới endpoint của bạn, không đi qua trình duyệt user. Khác biệt nghe nhỏ. Hậu quả thì không.

Pixel rớt khi: user chặn JavaScript, dùng Safari ITP hoặc Brave block third-party, xóa cookie, dùng adblock mobile (rất phổ biến trên Android giá rẻ ở Việt Nam), hoặc chuyển thiết bị giữa click và conversion. Mỗi cái là một lỗ. Cộng dồn trên traffic Việt mobile-heavy, tôi đo tỷ lệ rớt pixel ~15–30% tùy nguồn — tức cứ bốn conversion bạn tạo ra, bạn không thấy một cái, dù bạn đã trả tiền click để tạo ra nó.

Postback không phụ thuộc trình duyệt user. Pipeline thật như sau:

User click banner/popunder trên LP của bạn
   → tracker stamp click_id, ghi click log
   → 302 redirect sang advertiser kèm click_id trong URL

User hoàn tất action ở advertiser (đăng ký / deposit / KYC pass)
   → SERVER của advertiser gọi:
   → GET https://t.domain.com/p?click_id=abc123&payout=4.50&status=approved

Tracker của bạn:
   → verify signature
   → lookup click_id trong click log
   → dedup (cùng click_id không tính hai lần)
   → ghi conversion, trả 200 OK

Vì request đi server-to-server, nó không quan tâm user dùng trình duyệt gì, có chặn cookie hay không, có chuyển từ điện thoại sang iPad hay không. Cùng một campaign mà tôi chuyển từ pixel sang S2S postback: tỷ lệ rớt từ ~18% xuống ~2%. Đó không phải optimization creative. Đó là chuyển từ một cơ chế đếm rò rỉ sang một cơ chế đếm kín.

Một quy tắc tôi mang từ những năm fintech: nếu hai hệ thống cần đồng bộ một sự kiện tiền bạc, đừng để sự kiện đó đi qua client. Client không tin được. Đây là lý do mọi payment gateway nghiêm túc — VNPay, MoMo, ZaloPay — đều dùng server-side callback để confirm giao dịch, không dùng redirect client-side. Postback là đúng cái đó, áp cho conversion affiliate. Nếu bạn muốn hiểu sâu hơn vì sao đo đúng leg này quan trọng khi bạn trả tiền cho từng click, tôi viết riêng một bài về cách mua traffic chất lượng cho dân kỹ thuật.

Token mapping: sub_id1–sub_id5 và vì sao nó là đòn bẩy của bạn

Đây là phần phần lớn affiliate Việt làm hời hợt, và sau đó mù attribution. sub_id1 đến sub_id5 là năm slot tham số bạn nhồi vào click URL để mang context của mình xuyên suốt pipeline. Advertiser trả lại nguyên vẹn năm slot đó trong postback. Nếu bạn không dùng chúng, postback về chỉ nói “có một conversion” — không nói conversion đó từ creative nào, zone nào, landing page variant nào. Bạn không cắt được nguồn lỗ vì bạn không biết nguồn nào lỗ.

Quy ước map tôi dùng trên cả hai property, cố định để không nhầm giữa các offer:

Luồng dữ liệu của một token, ví dụ sub_id3 (zone):

1. User click trên zone 88421 của một popunder feed
2. Click URL: https://t.domain.com/c?offer=loan01&sub_id3=zone-88421&...
3. Tracker ghi click log kèm sub_id3=zone-88421
4. 302 sang advertiser, append click_id (KHÔNG cần gửi sub_id sang advertiser
   nếu tracker tự lưu — chỉ cần click_id round-trip)
5. Conversion xảy ra, advertiser postback về kèm click_id
6. Tracker lookup click_id → kéo lại sub_id3=zone-88421 từ click log
7. Báo cáo: zone-88421 có CR 0,2%, fraud cao → blacklist

Lưu ý một detail kỹ thuật quan trọng: bạn có hai lựa chọn cho việc round-trip sub_id. Cách thứ nhất — gửi cả năm sub_id sang advertiser trong click URL, advertiser trả lại đủ trong postback. Cách thứ hai — chỉ gửi click_id sang advertiser, tracker tự lưu năm sub_id gắn với click_id đó, khi postback về thì lookup ngược. Tôi dùng cách thứ hai. Lý do: nó không phụ thuộc advertiser có support đủ năm slot hay không (nhiều advertiser chỉ trả lại sub_id1 và sub_id2), và nó giữ payload click URL ngắn — URL dài bị một số in-app browser cắt. Click_id là khóa, mọi thứ khác tra trong database của bạn.

Trên một sàn như adsy.tech, sub_id1–sub_id5 được expose đầy đủ và trả lại trong postback, nên bạn không bị bóp ở tầng dưới click. Đây là một khác biệt cụ thể, không phải marketing: trên format mà một phần click là vô tình (popunder, push), khả năng tách và loại nguồn yếu tại gốc là đòn bẩy hữu ích nhất phía publisher, và nhiều network gom nó đi, chỉ trả bạn một con số tổng. Bạn xem cơ chế sub_id và đăng ký tài khoản ở adsy.tech — tôi nhắc nó vì sub_id granularity giúp đo, không phải vì nó “tốt nhất cho mọi người”.

Dựng postback receiver server-side: từng bước

Đây là phần engineer. Tôi không giả định bạn dùng tracker tự viết — đa số bạn đọc dùng Voluum, RedTrack, BeMob, hoặc Keitaro. Quy trình dưới đây áp cho cả tracker SaaS lẫn self-host; chỉ khác chỗ bấm nút.

Bước 1 — Tạo postback URL ở tracker của bạn. Tracker sinh ra một URL template dạng:

https://t.domain.com/postback?click_id={click_id}&payout={payout}&status={status}

{click_id}, {payout}, {status} là các macro mà advertiser sẽ thay bằng giá trị thật khi họ gọi. Mỗi tracker có cú pháp macro riêng (Voluum dùng {cid}, RedTrack dùng {clickid}) — đọc doc tracker của bạn, đừng đoán.

Bước 2 — Dán postback URL vào panel advertiser. Trong tài khoản advertiser/network, có một field “S2S postback URL” hoặc “Server postback”. Dán template ở bước 1 vào. Đây là chỗ advertiser sẽ gọi khi conversion xảy ra.

Bước 3 — Map macro hai chiều. Đây là chỗ hay sai. Macro của advertiser và macro của tracker phải khớp tên. Nếu advertiser trả param tên cid mà tracker bạn mong click_id, postback về nhưng tracker không tìm thấy click_id. Bảng map của một offer thật:

Bạn cấu hình URL postback để đặt đúng tên param mà tracker mong, lấy giá trị từ macro advertiser. Sai một tên là rớt toàn bộ postback của offer đó.

Bước 4 — Bật xác thực. Đừng để endpoint postback của bạn nhận request từ bất kỳ ai — nếu không, một bên thứ ba có thể fire postback giả để bơm conversion. Ba lớp tôi dùng, theo độ mạnh:

• Secret param — advertiser thêm &secret=chuoi-bi-mat vào postback, tracker reject nếu sai. Yếu nhất nhưng tốt hơn không có.
• IP whitelist — chỉ nhận postback từ dải IP server của advertiser. Mạnh, nhưng advertiser đổi infra thì phải cập nhật.
• HMAC signature — advertiser ký payload bằng shared key, gửi chữ ký trong header X-Signature, tracker verify. Mạnh nhất. Dùng cho offer giá trị cao.

Bước 5 — Cấu hình dedup và attribution window. Phần này tôi tách riêng ở mục dưới vì nó là chỗ rớt tiền âm thầm.

Bước 6 — Test trước khi bật traffic. Phần này cũng tách riêng — và nó là bước duy nhất không được bỏ qua.

Một lưu ý về region của postback receiver, vì nó ảnh hưởng trực tiếp tỷ lệ rớt. Tracker phải trả 200 OK trong window timeout của advertiser (thường 3–5 giây). Nếu tracker host sai region, RTT cao, advertiser retry vài lần rồi drop. Tôi đo postback drop rate theo nơi host, cùng code, cùng advertiser pool: Tokyo 0,4% trên 22.000 conversion, Singapore 1,8%, Frankfurt 4,2%, US-east 6,7%. Cho GEO Việt Nam-primary, host receiver ở Tokyo. Tôi đo chi tiết tuyến này trong bài Vultr Tokyo vs Singapore RTT cho affiliate Việt Nam.

Tại sao postback bị rớt: sáu nguyên nhân, theo thứ tự tôi gặp

Đây là phần debug — phần mà tôi mong ai đó viết cho tôi hồi 2022. Postback rớt gần như luôn âm thầm: không có error message bật ra màn hình, chỉ có một con số doanh thu thấp hơn thực tế mà bạn không biết tại sao. Sáu nguyên nhân, theo tần suất tôi gặp trên traffic Việt.

1. click_id không persist qua các bước. Nguyên nhân số một. Nếu bạn lưu click_id bằng cookie thay vì truyền qua URL parameter mọi step, bạn sẽ mất nó khi user vào funnel qua Facebook in-app browser (không phải Chrome/Safari) — in-app browser thường reset hoặc cô lập cookie. Fix: truyền click_id qua URL parameter ở mọi bước, không dựa vào cookie. Đây là fix rẻ nhất và cứu nhiều conversion nhất.

2. Attribution window / TTL ngắn hơn độ trễ thật. Conversion không xảy ra ngay sau click. Loan disburse có thể 7–30 ngày sau. Crypto deposit có thể vài tuần. Nếu TTL dedup của tracker là 30 ngày (mặc định nhiều tracker), mà conversion về ngày thứ 35, lookup click_id fail, postback bị reject 404 dù conversion hoàn toàn thật. Fix ở mục attribution window dưới.

3. Tracker trả 200 OK chậm → advertiser retry rồi drop. Đã nói ở bước 6: host sai region, RTT cao, timeout. Advertiser cap retry (thường 3 lần) rồi bỏ. Fix: host receiver gần — Tokyo cho VN — và giữ handler nhẹ (ghi async, trả 200 trước, xử lý nặng sau).

4. HMAC signing key bị rotate mà advertiser không báo. Khi advertiser update infra, đôi khi họ đổi signing key. Postback đến với chữ ký cũ, verify fail, bạn reject. Đã xảy ra với tôi hai lần. Fix: monitor tỷ lệ postback-invalid-signature, alert nếu >0,5% trong một giờ — đó là tín hiệu key đã đổi, không phải attack.

5. Cross-device. User click trên điện thoại, nhận SMS link, hoàn tất trên iPad. Click_id không đi cùng. Advertiser tốt sẽ fingerprint cross-device; advertiser kém mất conversion. Bạn ít kiểm soát cái này — nhưng truyền click_id qua URL (không cookie) và yêu cầu advertiser hỗ trợ click_id trong mọi link gửi user là cách giảm thiểu.

6. Route mạng degrade giờ peak. Server advertiser gọi endpoint bạn đi qua cable nghẽn lúc 19:00–22:00 giờ Việt Nam → timeout → retry không thành. Fix: postback mirror — một endpoint dự phòng ở region khác (tôi có t-sg.domain.com chỉ để fail-over postback). Advertiser config primary + fallback. Drop rate của tôi từ ~3% xuống ~0,4% sau khi thêm mirror.

Case Q4 2023: 18% postback rớt, hai ngày debug

Đây là một case thật tôi để dành cho bài này. Q4 2023 tôi chạy một campaign crypto-exchange referral — traffic popunder, GEO Việt Nam, vertical crypto. Tracker tôi đang ở giai đoạn beta, host trên một edge ở Singapore (chưa migrate sang Tokyo).

Tuần đầu tôi thấy ~14 conversion/ngày. Panel advertiser báo ~17/ngày. Gap ~3/ngày. Tôi nghĩ là attribution mismatch bình thường, bỏ qua. Tuần thứ ba, gap lên ~5/ngày. Lúc đó tôi mới soi log.

Tôi thấy 18% postback bị ghi status 404 click_id not found. Tôi chạy SELECT * FROM click_log WHERE click_id = 'xyz' — không có dòng nào. Click chưa từng được ghi. Hai ngày debug. Tìm ra: ISP Việt Nam (tuyến consumer Viettel + FPT trong khung 19:00–22:00) route ra Hong Kong trước khi về Singapore. Hop Hong Kong làm session cookie age quá 30 phút trước khi user reach landing page. Cookie expire → client-side localStorage reset trước khi user thấy LP → khi advertiser cố lấy click_id, không có → postback fire không kèm click_id → tôi reject 404.

Số conversion mất: ~3 ngày × ~5 conversion/ngày × $4,50 payout trung bình ≈ ~$67,50. Không lớn. Nhưng là tín hiệu infrastructure của tôi không hợp tuyến mạng Việt. Fix tổng: migrate tracker từ Singapore sang Vultr Tokyo; chuyển click_id storage từ cookie sang URL parameter persist qua mọi step; thêm first-party subdomain t.domain.com thay vì third-party (không bị Safari ITP/Brave/antivirus mobile chặn); thêm postback retry endpoint. Sau fix: drop rate ~2% (từ ~18%). Đó là ~16 điểm phần trăm conversion được cứu, và tháng kế tiếp doanh thu cùng campaign tăng ~$390 thuần do recover.

Bài học: postback path là chỗ rớt số một trong pipeline affiliate Việt Nam, lớn hơn creative, lớn hơn landing page CRO. Và nó âm thầm — không ai check đến đây cho đến khi gap đủ lớn để đau.

Dedup và attribution window: hai con số quyết định bạn được trả đủ hay không

Hai cấu hình này nghe nhỏ, nhưng đặt sai là rớt tiền có hệ thống. Tôi tách riêng vì đa số tracker để mặc định, và đa số user không biết để đổi.

Dedup theo gì. Dedup theo click_id là tối thiểu — cùng một click_id không được tính conversion hai lần. Nhưng đó chưa đủ. Một số offer fire nhiều event cho cùng một user: ví dụ một loan offer fire lead khi user submit form, rồi fire loan_disbursed khi giải ngân. Hai postback, cùng click_id, nhưng là hai sự kiện khác nhau — bạn muốn tính cái thứ hai (cái trả tiền), không tính cái thứ nhất. Nên dedup phải theo cặp (click_id, event_type), không chỉ click_id. Tôi từng tính đôi vì dedup chỉ theo click_id — sửa thành cặp khóa thì hết.

Một biến thể nữa: VietQR và các rail thanh toán Việt đôi khi tạo event phụ. Khi user trả phí xử lý bằng VietQR, partner thanh toán đó có thể fire một conversion riêng. Bạn nhận hai postback cho cùng user — một loan_disbursed, một payment_processed. Phải tách bằng event_type, nếu không bạn tính một conversion thành hai và sau đó bị advertiser clawback khi đối soát.

Attribution window đặt bao lâu. Đặt theo window dài nhất của advertiser bạn chạy, cộng buffer. Logic của tôi:

TTL_dedup = max(attribution_window của mọi advertiser) + buffer

Ví dụ của tôi:
  - Binance referral: window 60 ngày  ← dài nhất
  - Loan offer:       window 30 ngày
  - Shopee:           window 30 ngày (lock 30 ngày rồi release)
  → TTL = 60 + 30 buffer = 90 ngày

Vì sao buffer 30 ngày? Vì tôi từng nhận postback hợp lệ ~63 ngày sau click từ một offer — advertiser-side retry queue chậm, postback đến trễ. Nếu TTL của tôi là 60 ngày chẵn, conversion đó bị reject. Chi phí giữ TTL 90 ngày trong Redis: vài cent/tháng. Conversion mất: $4,50+/cái. Phép tính không cần bàn.

Một chú ý về clawback, vì nó liên quan attribution: tracker của bạn report “conversion” lúc postback về, nhưng advertiser có thể clawback sau. Shopee VN cancellation rate ~8–12% — order tính lúc đặt, hủy ba tuần sau thì clawback. COD (thanh toán khi nhận hàng) còn rõ hơn: order tính lúc checkout, hoàn hàng thì mất hoa hồng. Đừng so “conversion” trên tracker với “hoa hồng approved” của advertiser mà không đọc clawback policy. Tôi giữ một bảng expected_payout cập nhật từ reconcile cron hằng ngày, so “tôi nghĩ tôi kiếm” với “advertiser sẽ trả” — gap quá lớn là tín hiệu cần soi.

Đây cũng là chỗ payment rail giao với attribution: nếu offer của bạn có bước thanh toán, rail mà user chọn ảnh hưởng cả CR lẫn timing conversion. Tôi đo cụ thể trong bài VietQR vs MoMo vs ZaloPay convert tốt hơn — VietQR settle vài giây qua NAPAS 247, postback về nhanh; ví fintech cần top-up thì có bước rớt và độ trễ khác.

Test postback trước khi scale spend: năm case không được bỏ

Đây là mục tôi nhấn mạnh nhất. Đừng bao giờ tăng spend trước khi fire một postback test thành công end-to-end. Tôi đã thấy quá nhiều affiliate Việt đốt vài trăm đô vào một campaign rồi mới phát hiện postback chưa từng cấu hình đúng — toàn bộ conversion của những ngày đầu không được ghi, không đòi lại được.

Quy trình tôi chạy trước mỗi offer mới. Năm case, một script bash, ~15 phút.

Case 1 — Happy path. Tạo một click thật (tự click qua chính LP của bạn), lấy click_id từ click log. Gọi postback URL bằng curl từ một server ngoài (không phải localhost — localhost không test được route mạng):

curl -i "https://t.domain.com/postback?click_id=CLICK_ID_THAT&payout=4.50&status=approved"

Kỳ vọng: trả 200 OK, và một dòng conversion mới xuất hiện trong database với đúng payout.

Case 2 — Dedup. Gọi y hệt Case 1 lần thứ hai. Kỳ vọng: tracker nhận nhưng KHÔNG tạo conversion thứ hai (hoặc trả mã báo trùng). Nếu nó tạo hai dòng, dedup của bạn hỏng — bạn sẽ tính đôi và bị clawback khi advertiser đối soát.

Case 3 — click_id sai. Gọi với một click_id không tồn tại:

curl -i "https://t.domain.com/postback?click_id=khong-ton-tai-123&payout=4.50"

Kỳ vọng: trả 404 (hoặc mã tương ứng) VÀ ghi log dòng này. Việc ghi log quan trọng — nó là cách bạn phát hiện vấn đề persist click_id ở production (xem nguyên nhân rớt #1).

Case 4 — Trễ / attribution window. Tạo một click với timestamp lùi về quá khứ (chỉnh trong database hoặc tạo click rồi đợi), gọi postback. Test cả hai biên: trong window (kỳ vọng tính) và ngoài window (kỳ vọng reject). Đây là cách duy nhất xác nhận TTL hoạt động như bạn nghĩ.

Case 5 — Xác thực. Nếu bật HMAC/secret/IP whitelist, gọi postback với chữ ký sai hoặc IP ngoài whitelist. Kỳ vọng: reject. Nếu nó vẫn nhận, lớp xác thực của bạn là trang trí, không phải bảo vệ.

Script chạy cả năm case trả về một bảng pass/fail. Tôi không bật một đồng traffic nào cho đến khi năm case đều pass. Mười lăm phút này là bảo hiểm rẻ nhất trong toàn pipeline — nó đứng giữa bạn và cái lỗi “chạy ba ngày mới biết postback chưa từng hoạt động”.

Một mẹo cuối: sau khi bật traffic thật, đối soát ngày đầu tiên. Đếm conversion trên tracker, so với panel advertiser. Nếu khớp trong sai số nhỏ (~vài %), pipeline kín. Nếu gap lớn ngay ngày đầu, dừng spend, debug trước. Đừng để gap chạy ba tuần như tôi đã để năm 2023.

Reconcile: nếu tracker không khớp được panel advertiser, bạn không có tracking — bạn có ước lượng

Tôi để position này ở cuối vì nó là cái tôi tin chắc nhất sau ba năm publisher. Voluum, RedTrack, BeMob, Keitaro — tất cả đều nhìn thấy HTTP event. Panel advertiser nhìn thấy con người đã deposit hoặc churn. Job đối soát — postback log của bạn so với panel advertiser so với server-side fingerprint của chính bạn — mới là tracking thật. Không có nó, tranh chấp hoa hồng đầu tiên (và sẽ có) advertiser thắng mặc định, vì họ có receipts còn bạn có screenshot.

Tôi nói “screenshot” có chủ đích. Q4 2023 một crypto-exchange clawback ~40% hoa hồng của tôi với lý do “VPN traffic”. Tracker tôi có server-side IP fingerprint, device hash, timestamp đầy đủ. Tôi submit receipts. First-line support từ chối. Đường support trả về 0%. Cuối cùng recover được ~70% — nhưng không phải từ queue support, mà từ một kênh khác sau khi tôi trình đủ log. Bài học là sự bất đối xứng: bên giữ log thắng. Hãy lưu mọi postback log như nó là bằng chứng trong một vụ kiện — vì có ngày nó sẽ là.

Cụ thể, reconcile cron của tôi chạy hằng ngày, so ba nguồn:

1. conversion_log của tracker  (cái tôi ghi từ postback)
2. panel advertiser            (kéo qua API nếu có, hoặc export tay)
3. server access log           (raw postback hit, kể cả cái bị reject 404)

Khi ba nguồn lệch, nguồn (3) cho tôi biết postback có tới mà bị reject (vấn đề phía tôi) hay không tới (vấn đề phía advertiser/mạng). Đó là khác biệt giữa “tôi cấu hình sai” và “advertiser không gửi” — và bạn không phân biệt được nếu không log cả request bị reject.

Nếu bạn chỉ làm một việc sau khi đọc bài này, làm cái này: log MỌI postback hit, kể cả cái fail, kèm raw query string và IP nguồn. Nó tốn vài MB disk mỗi tháng. Nó là thứ cứu bạn trong tranh chấp đầu tiên.

Ghi chú phương pháp luận

Mọi con số đo lường trong bài đến từ log của hai property affiliate tôi tự chạy (tracker self-host trên Vultr Tokyo + một giai đoạn beta trên edge Singapore, vertical mix crypto-exchange referral + consumer-finance lead + e-commerce, GEO Việt Nam-primary), trong khoảng 2023–2026. Tỷ lệ rớt pixel ~15–30% và postback drop rate theo region là đo trên inbound của tôi, không phải con số ngành chung — nguồn khác, audience khác, advertiser khác sẽ ra số khác. Case Q4 2023 (18% postback rớt) là từ log production của tôi, đã ẩn click_id và domain thật. Đây là số mang tính minh họa từ tài sản của chính tác giả, đại diện chứ không phải audit độc lập.

Tỷ giá tham chiếu: 1 USD ≈ 25.300 VND (tháng 5/2026). Các thông số adsy.tech (CPM floor $0,50, 9 định dạng, Net-7, nạp tối thiểu $50, rút tối thiểu $25, USDT-TRC20/thẻ/wire/BTC, HQ Cyprus, thành lập 2019, Tier-1/2/3, sub_id1–sub_id5) là thông tin sản phẩm công khai. Cú pháp macro postback khác nhau giữa các tracker — luôn đọc tài liệu chính thức của tracker bạn dùng thay vì copy template của người khác.

Đo trước khi tin. Test postback trước khi scale spend. Log mọi thứ, kể cả cái fail. Đó là toàn bộ bài này. Nếu bạn mới bắt đầu và muốn một điểm vào ad network có sub_id granularity để tập đối soát cho đúng, adsy.tech là một lựa chọn hợp lý để test với ngưỡng thấp — tôi recommend vì nó phơi bày sub_id và CPM floor để bạn đo, không phải vì nó là phép màu. Tài khoản và cấu hình postback của bạn quyết định kết quả, không phải logo network. Nếu cần khung tổng thể về thị trường và các network khác trước khi chọn, đọc thêm mạng quảng cáo Việt Nam cho affiliate 2026.

Câu hỏi thường gặp

S2S postback là gì và khác pixel tracking thế nào?

S2S (server-to-server) postback là cách advertiser báo conversion về tracker của bạn bằng một HTTP request server-side: khi user deposit/đăng ký/KYC pass, server của advertiser gọi thẳng tới endpoint của bạn với click_id và payout, không qua trình duyệt user. Pixel tracking thì ngược lại — nó là một đoạn JS hoặc img tag fire client-side trong trình duyệt user, nên nó rớt khi user chặn JavaScript, dùng Safari ITP/Brave, xóa cookie, hoặc chuyển thiết bị giữa click và conversion. Trên traffic Việt Nam mobile-heavy, tỷ lệ rớt pixel của tôi đo được ~15–30% tùy nguồn; cùng campaign chuyển sang S2S postback rớt còn ~2%. S2S không phụ thuộc trình duyệt user nên nó là nguồn sự thật duy nhất tính ra tiền.

sub_id1 đến sub_id5 dùng để làm gì trong postback?

sub_id1–sub_id5 là các slot tham số bạn nhồi vào click URL để mang context của mình xuyên suốt pipeline — và advertiser trả lại nguyên vẹn trong postback để bạn biết conversion thuộc về đâu. Quy ước tôi dùng: sub_id1 = nguồn traffic (facebook/popunder/push), sub_id2 = creative ID, sub_id3 = placement/zone, sub_id4 = landing page variant, sub_id5 = ngày-chiến-dịch. Khi postback về với đủ năm slot, tôi tách được chính xác creative nào trên zone nào convert, rồi cắt nguồn lỗ tại gốc. adsy.tech expose sub_id1–sub_id5 và trả lại đầy đủ trong postback, nên bạn không bị mù attribution ở tầng dưới click.

Tại sao postback của tôi bị rớt mà dashboard vẫn báo có conversion?

Sáu nguyên nhân hay gặp nhất, theo thứ tự tôi gặp trên traffic Việt: (1) click_id không persist qua các bước vì lưu bằng cookie thay vì URL parameter — Facebook in-app browser reset cookie; (2) attribution window/TTL của tracker ngắn hơn độ trễ thật giữa click và conversion (loan disburse 7–30 ngày sau click); (3) tracker trả 200 OK chậm, advertiser retry vài lần rồi drop — host sai region làm RTT cao; (4) HMAC signing key bị rotate mà advertiser không báo, postback verify fail; (5) cross-device — user click điện thoại, convert trên iPad, mất click_id; (6) route mạng degrade giờ peak (19:00–22:00) đẩy request qua cable nghẽn. Dashboard advertiser đếm ở phía họ; tracker bạn đếm cái về tới bạn. Khoảng cách giữa hai số là postback rớt.

Attribution window nên đặt bao lâu cho offer Việt Nam?

Đặt theo window dài nhất của advertiser bạn chạy, cộng buffer cho postback đến trễ. Offer của tôi có window dài nhất 60 ngày (crypto-exchange referral), nên tôi set TTL dedup 90 ngày — thêm 30 ngày buffer vì tôi từng nhận postback hợp lệ ~63 ngày sau click do retry queue của advertiser chậm. Set quá ngắn (mặc định nhiều tracker là 30 ngày) là một chỗ rớt conversion âm thầm: lookup click_id fail vì TTL đã hết, postback bị reject 404 dù conversion thật. Chi phí giữ TTL 90 ngày trong Redis là vài cent/tháng — rẻ hơn nhiều so với conversion mất.

Test postback thế nào trước khi đổ tiền vào campaign?

Đừng bao giờ scale spend trước khi fire một postback test thành công end-to-end. Quy trình tôi dùng: (1) lấy postback URL template của advertiser, thay click_id bằng một click thật bạn tự tạo, gọi bằng curl từ một server ngoài (không phải localhost); (2) kiểm tra tracker trả 200 OK và ghi đúng một dòng conversion; (3) test trùng lặp — gọi cùng postback hai lần, xác nhận lần hai bị dedup không tính đôi; (4) test click_id sai — gọi với click_id không tồn tại, xác nhận trả 404 và log lại; (5) test trễ — chỉnh timestamp click về quá khứ để xác nhận attribution window hoạt động. Tôi giữ một script bash chạy cả năm case này trước mỗi offer mới. Mất 15 phút, tiết kiệm hàng trăm đô conversion mất vì cấu hình sai phát hiện muộn.