Bài viết · 17 tháng 6, 2026

AppsFlyer, Adjust và PDPL: cần làm gì với mobile attribution?

Phân tích AppsFlyer, Adjust dưới góc PDPL: định danh quảng cáo, fingerprint, đồng ý người dùng app và chuyển dữ liệu ra nước ngoài.

consent.vn Editorial8 phút đọc

Trả lời nhanh

Nếu bạn dùng AppsFlyer, Adjust hoặc công cụ mobile attribution tương tự, dưới góc PDPL bạn cần rà soát loại dữ liệu thu thập, cơ chế xin đồng ý trong app, chính sách chia sẻ với đối tác quảng cáo và việc chuyển dữ liệu ra nước ngoài. Trọng tâm là chứng minh bạn có cơ sở xử lý hợp lệ, không chỉ “cài SDK rồi để đó”.

AppsFlyer, Adjust mobile attribution theo PDPL là gì?

Câu trả lời ngắn: đây là bài toán tuân thủ dữ liệu cá nhân trong app, không chỉ là bài toán đo lường marketing. Khi cài AppsFlyer, Adjust hoặc SDK tương tự, doanh nghiệp thường phát sinh các nghĩa vụ theo quy định về thu thập, sử dụng, chia sẻ và có thể cả chuyển dữ liệu cá nhân ra nước ngoài.

Trong thực tế, các SDK attribution có thể xử lý nhiều tín hiệu như định danh quảng cáo, dữ liệu thiết bị, sự kiện trong app, IP, thời gian mở app, nguồn cài đặt, và đôi khi là các kỹ thuật nhận diện hành vi/thiết bị để quy đổi lượt cài đặt hoặc conversion. Với PDPL, câu hỏi không phải chỉ là “tool nào”, mà là:

  • Dữ liệu nào đang được thu thập?
  • Có phải dữ liệu cá nhân hay dữ liệu cá nhân nhạy cảm không?
  • Đã thông báo và xin đồng ý đúng cách trong app chưa?
  • Có chia sẻ cho bên thứ ba nào khác ngoài nhà cung cấp attribution không?
  • Dữ liệu có đi ra khỏi Việt Nam không?

Định danh quảng cáo, fingerprint có làm phát sinh nghĩa vụ gì?

Câu trả lời ngắn: chúng làm phát sinh nghĩa vụ minh bạch, xin đồng ý phù hợp và kiểm soát chia sẻ dữ liệu theo mục đích đã thông báo.

Với mobile attribution, hai điểm hay bị bỏ sót là:

  1. Định danh quảng cáo (advertising ID): thường được dùng để đo hiệu quả chiến dịch, phân bổ install, remarketing. Nếu app thu thập hoặc truyền định danh này cho AppsFlyer/Adjust, doanh nghiệp cần kiểm tra liệu người dùng đã được thông báo rõ ràng chưa và có cơ chế từ chối/opt-out phù hợp không.

  2. Fingerprinting: đây là kỹ thuật suy đoán/ghép nối thiết bị dựa trên nhiều tín hiệu như IP, model máy, OS, ngôn ngữ, thời gian, hành vi... Dù mục đích là attribution, về tuân thủ bạn vẫn phải xem đây là một hình thức xử lý dữ liệu có rủi ro cao hơn vì người dùng khó nhận biết. Theo quy định, càng ít minh bạch thì càng cần giải thích rõ trong privacy notice và xin đồng ý đúng thời điểm.

Lưu ý: không nên kết luận một SDK hay tracker là “bất hợp pháp”. Điều cần làm là xác định nghĩa vụ phát sinh và thiết kế flow consent, logging, retention, vendor control cho phù hợp.

App cần đồng ý người dùng thế nào để dùng AppsFlyer, Adjust?

Câu trả lời ngắn: consent nên được lấy trong app trước khi SDK bắt đầu thu thập những dữ liệu không cần thiết cho vận hành cốt lõi, và phải đủ rõ để người dùng hiểu mục đích đo lường/quảng cáo.

Một flow thực tế cho app Việt Nam thường nên có:

  • Màn hình thông báo ngắn trước khi bật SDK marketing/attribution.
  • Tuỳ chọn riêng cho quảng cáo/đo lường, không gộp chung với điều khoản sử dụng.
  • Link tới privacy notice đầy đủ, nêu rõ bên nhận dữ liệu là AppsFlyer/Adjust và các đối tác liên quan.
  • Cơ chế rút lại đồng ý hoặc tắt tracking trong phần cài đặt.
  • Lưu bằng chứng consent: thời gian, phiên bản notice, trạng thái đồng ý, thiết bị/app version.
  1. Liệt kê SDK và dữ liệu:

    ghi rõ AppsFlyer/Adjust thu gì: advertising ID, IP, event, device info, install source, in-app events.

  2. Phân loại mục đích:

    tách đo lường attribution, chống gian lận, remarketing, phân tích sản phẩm.

  3. Thiết kế màn hình consent trong app:

    chỉ bật SDK sau khi người dùng chọn đồng ý cho các mục đích marketing/measurement theo quy định.

  4. Cập nhật privacy notice:

    nêu ai là bên nhận dữ liệu, mục đích, thời hạn lưu, cách rút lại đồng ý.

  5. Thiết lập log chứng cứ:

    lưu consent event, version text, timestamp, user/app identifier.

  6. Kiểm soát vendor và SDK:

    rà soát cấu hình server-to-server, postback, chia sẻ dữ liệu cho network/agency.

  7. Chuẩn bị quy trình DSAR và incident response:

    nếu có yêu cầu truy cập/xoá hoặc sự cố, xử lý có đầu mối, thời hạn, và tài liệu nội bộ.

AppsFlyer, Adjust mobile attribution pdpl có liên quan chuyển dữ liệu ra nước ngoài không?

Câu trả lời ngắn: có thể có, và đây là điểm cần soi kỹ nhất nếu vendor, máy chủ hoặc đối tác xử lý nằm ngoài Việt Nam.

Trong mô hình mobile attribution, dữ liệu có thể được gửi từ app của bạn lên SDK, sau đó tới hạ tầng của nhà cung cấp ở nước ngoài hoặc chia sẻ tiếp cho network/partner khác. Khi đó, doanh nghiệp cần xem xét nghĩa vụ đối với chuyển dữ liệu cá nhân ra nước ngoài theo quy định hiện hành và hướng dẫn liên quan.

Thực tế nên kiểm tra ít nhất các điểm sau:

  • Địa điểm lưu trữ chính của vendor.
  • Có sub-processor nào ở ngoài Việt Nam không.
  • Dữ liệu có được chuyển theo dạng raw event, hay đã được pseudonymize/aggregate.
  • Có cơ chế hợp đồng và điều khoản xử lý dữ liệu với vendor chưa.
  • Có hồ sơ đánh giá tác động/chính sách nội bộ cho chuyển dữ liệu xuyên biên giới chưa, theo quy định.

Nếu doanh nghiệp chạy app có người dùng tại Việt Nam nhưng analytics/attribution lại do team ở Singapore hoặc Mỹ vận hành, bạn nên đối chiếu cả luồng kỹ thuật lẫn luồng pháp lý. Đây là chỗ nhiều SME “bật SDK rất nhanh” nhưng không có hồ sơ quản trị tương ứng.

Doanh nghiệp SME nên làm gì ngay bây giờ?

Câu trả lời ngắn: đừng bắt đầu từ pháp lý trên giấy; hãy bắt đầu từ sơ đồ dữ liệu và cấu hình SDK.

Một checklist gọn, thực dụng:

  • Vẽ data flow của AppsFlyer/Adjust trong app.
  • Xác định trường dữ liệu nào là bắt buộc, trường nào chỉ phục vụ marketing.
  • Chặn SDK marketing cho tới khi consent được ghi nhận, nếu mô hình của bạn yêu cầu consent.
  • Kiểm tra cấu hình postback, deep link, raw data export, audience sync.
  • Rà hợp đồng với vendor, agency, ad network.
  • Chuẩn bị cơ chế trả lời yêu cầu của người dùng về truy cập, xoá, rút lại đồng ý.
  • Lập quy trình ứng phó sự cố; nếu phát hiện vi phạm dữ liệu cá nhân, thông báo trong 72 giờ kể từ khi phát hiện theo quy định.

Một sai lầm phổ biến là coi banner cookie trên web là đủ cho app. Không đủ. App cần cơ chế consent riêng, vì SDK attribution hoạt động khác và có thể thu tín hiệu sâu hơn từ thiết bị.

Nếu bạn cần một mẫu consent flow hoặc bảng kiểm tra SDK cho app, consent.vn có thể giúp bạn chuẩn hoá banner cookie, lưu bằng chứng đồng ý và quy trình DSAR cho đội product/dev.

Nguồn: Luật 91/2025/QH15 thuvienphapluat.vn; Nghị định 13/2023/NĐ-CP thuvienphapluat.vn; cơ quan thực thi A05 bocongan.gov.vn

Bắt đầu ngay — không cần tài khoản.

Sẵn sàng tuân thủ PDPL?

Bắt đầu ngay