AppsFlyer Thu Thập Gì

AppsFlyer SDK khởi tạo phiên ngay khi ứng dụng chủ bắt đầu và theo mặc định thu thập một gói mã định danh và tín hiệu ngữ cảnh: mã định danh quảng cáo cấp thiết bị (IDFA trên iOS, GAID trên Android), IDFV phạm vi nhà cung cấp trên iOS, ID cài đặt AppsFlyer được tạo ra tồn tại qua các phiên, địa chỉ IP (được sử dụng cho geo-IP và cho khớp xác suất kiểu dấu vân tay), tác nhân người dùng, mẫu thiết bị, phiên bản OS, nhà mạng và múi giờ. Sau khi cài đặt, SDK báo cáo sự kiện cài đặt cho máy chủ AppsFlyer, nơi nó được khớp với dữ liệu nhấp chuột được chuyển tiếp bởi mạng quảng cáo. Các sự kiện trong ứng dụng tiếp theo — Purchase, RegistrationComplete, Tutorial Complete, Custom — kích hoạt thông qua cùng SDK và kế thừa cùng bộ mã định danh.

Các cơ quan quản lý đã nói rõ rằng đây là xử lý dữ liệu cá nhân theo GDPR. IDFA và GAID là dữ liệu cá nhân vì chúng là mã định danh cố định cấp thiết bị. Việc khớp dấu vân tay xác suất chạy song song thậm chí còn khó bảo vệ hơn mà không có sự đồng ý vì theo định nghĩa, đó là nỗ lực xác định người dùng mà không có sự hợp tác rõ ràng của họ. CNIL, Garante của Ý và AEPD của Tây Ban Nha đều đã mở điều tra đối với các nhà xuất bản có ngăn xếp phân bổ kích hoạt trước khi có sự đồng ý.

Các Kiểm Soát Quyền Riêng Tư Gốc của AppsFlyer

AppsFlyer cung cấp một bộ nguyên thủy quyền riêng tư gốc có ý nghĩa. Chúng không phải là sự thay thế cho khung đồng ý thực sự, nhưng việc hiểu chúng là thiết yếu vì chúng là các đòn bẩy mà CMP sử dụng để kiểm soát hành vi SDK.

Start SDK API

SDK hỗ trợ chế độ khởi tạo được cấu hình nhưng không truyền bất kỳ dữ liệu nào cho đến khi start() được gọi rõ ràng. Đây là hook quan trọng nhất duy nhất cho việc kiểm soát đồng ý — theo mặc định SDK tự động khởi động khi khởi chạy ứng dụng, đây là hành vi sai cho bất kỳ khu vực tài phán nào có yêu cầu đồng ý trước. Đặt isStopped thành true khi khởi tạo, hoặc sử dụng API khởi động trì hoãn, và chỉ gọi start() khi tín hiệu đồng ý được ghi lại.

Stop API

Nếu đồng ý bị thu hồi giữa phiên, việc gọi stop() sẽ dừng tất cả truyền tải tiếp theo. Nó không xóa ngược dữ liệu đã gửi. Để xóa hoàn toàn, bạn cần nộp yêu cầu xóa chủ thể dữ liệu qua cổng quyền riêng tư của AppsFlyer — các nhóm tích hợp nên tự động hóa qua AppsFlyer API thay vì quy trình làm việc thủ công.

setSharingFilter

Điều này lọc các mạng quảng cáo phía dưới nào nhận dữ liệu postback. Đây là nguyên thủy phù hợp cho đồng ý chi tiết trên mỗi đối tác — ví dụ như cho phép phân bổ nói chung nhưng chặn chuyển tiếp đến một mạng cụ thể mà người dùng đã từ chối.

Tích hợp Apple App Tracking Transparency

Trên iOS, AppsFlyer đọc trạng thái ủy quyền ATT và tự động điều chỉnh hành vi — nếu người dùng từ chối ATT, IDFA không được truyền. ATT độc lập với sự đồng ý GDPR, và nhiều nhà xuất bản nhầm lẫn chúng. ATT kiểm soát một tín hiệu cấp iOS duy nhất; sự đồng ý GDPR kiểm soát mọi thứ khác.

Tích Hợp trên iOS

Mô hình đáng tin cậy trên iOS là cài đặt AppsFlyer SDK nhưng trì hoãn khởi tạo cho đến khi cả ATT lẫn luồng đồng ý trong ứng dụng đều hoàn thành. Trình tự tối thiểu là: ứng dụng khởi chạy, SDK được cấu hình với isStopped = true, banner đồng ý trong ứng dụng hiển thị, người dùng chấp nhận các danh mục liên quan, cờ isStopped của SDK được xóa và start() được gọi. Nếu ứng dụng cũng cần ATT (điều này đối với bất kỳ người dùng nào mà IDFA có ý nghĩa), lời nhắc ATT được hiển thị cùng với hoặc sau banner trong ứng dụng. Hầu hết CMP hỗ trợ di động đều có API dựa trên callback cung cấp quyết định đồng ý; callback đó là nơi phù hợp để gọi start().

Tích Hợp trên Android

Triển khai Android song song với iOS với hai điểm khác biệt. Thứ nhất, không có tương đương ATT — GAID có sẵn trừ khi người dùng đã kích hoạt cài đặt "Xóa ID quảng cáo" cấp thiết bị, điều mà hầu hết người dùng không làm. Thứ hai, vòng đời của Android hung hăng hơn về việc chạy nền, vì vậy việc khởi tạo SDK cần được gắn với trạng thái đồng ý được lưu trữ liên tục. Đọc trạng thái đồng ý từ bộ nhớ cục bộ khi khởi chạy ứng dụng, cấu hình SDK tương ứng và kiểm tra lại khi tiếp tục trong trường hợp người dùng đã cập nhật lựa chọn của họ khi ứng dụng đang chạy nền.

Tích Hợp trên Web Di Động

AppsFlyer cũng hoạt động trên web di động thông qua các sản phẩm banner thông minh và OneLink. Đây về cơ bản là các công cụ phân tích phía web và liên kết sâu thả cookie và gọi máy chủ AppsFlyer từ trình duyệt. Chúng tuân theo các quy tắc giống như bất kỳ bề mặt theo dõi web nào khác: đặt chúng sau danh mục tiếp thị của CMP, không để script banner thông minh chạy trước khi đồng ý được cấp và đảm bảo rằng bất kỳ sự kiện nào do OneLink kích hoạt từ email hoặc chiến dịch push tôn trọng trạng thái đồng ý của người dùng.

Các Sai Lầm Phổ Biến

Bốn lỗi tích hợp xuất hiện liên tục trong các kiểm toán triển khai AppsFlyer.

Coi ATT như Đồng Ý GDPR

ATT và sự đồng ý GDPR là các tín hiệu khác nhau với phạm vi khác nhau. Người dùng chấp nhận ATT đã ủy quyền sử dụng IDFA cho theo dõi xuyên ứng dụng; họ chưa ủy quyền mọi thứ khác mà SDK thực hiện. Đối với lưu lượng EU và UK, cả hai tín hiệu đều cần thiết, với banner trong ứng dụng là tín hiệu ràng buộc và ATT là lớp đặc trưng iOS bên trên.

Để SDK Khởi Tạo khi Khởi Chạy

Đây là lỗi đơn lẻ phổ biến nhất. Tích hợp mặc định gọi start() ngay lập tức, kích hoạt sự kiện cài đặt với tải trọng mã định danh đầy đủ trước khi người dùng thấy banner đồng ý. Biện pháp khắc phục đơn giản: cấu hình isStopped = true tại thời điểm tích hợp và chỉ gọi start() từ callback đồng ý.

Quên Xử Lý Thu Hồi

Nếu người dùng chấp nhận và sau đó thu hồi, SDK cần được thông báo để ngừng truyền. Sử dụng stop() API và cập nhật trạng thái đồng ý đã lưu để lần khởi chạy ứng dụng tiếp theo tôn trọng quyết định mới.

Bỏ Qua Postback Máy Chủ Với Máy Chủ

AppsFlyer chuyển tiếp sự kiện chuyển đổi đến nhiều mạng quảng cáo tích hợp qua postback phía máy chủ. Mỗi lần chuyển tiếp mang dữ liệu cá nhân và kế thừa phạm vi đồng ý của sự kiện gốc. Sử dụng setSharingFilter để đảm bảo rằng chuyển tiếp chỉ đến các đối tác được bao phủ bởi lựa chọn đồng ý của người dùng, không phải mọi đối tác trong bảng điều khiển AppsFlyer của bạn.

Danh Sách Kiểm Tra Kiểm Toán

Sáu câu hỏi cụ thể để trả lời cho bất kỳ triển khai AppsFlyer nào liên quan đến lưu lượng EU, UK hoặc California.

• SDK có chờ đồng ý không? Trên thiết bị thử nghiệm mới cài đặt tại EU, xác nhận không có điểm cuối AppsFlyer nào nhận bất kỳ yêu cầu nào trước khi người dùng chấp nhận banner.
• ATT có tách biệt với đồng ý trong ứng dụng không? Xác nhận banner trong ứng dụng là tín hiệu đồng ý kiểm soát và ATT được coi là lớp iOS cụ thể bổ sung.
• Việc chuyển tiếp đối tác có được giới hạn theo đồng ý không? Xác nhận setSharingFilter được cấu hình để loại trừ các đối tác mà người dùng chưa ủy quyền.
• Thu hồi có dừng SDK không? Xác nhận việc gọi stop() hoạt động khi thu hồi đồng ý và trạng thái mới tồn tại qua các lần khởi chạy.
• Postback máy chủ có được kiểm toán không? Xác nhận danh sách "Tích hợp đã được cấu hình" của bảng điều khiển AppsFlyer ánh xạ rõ ràng với các đối tác tiếp thị được tiết lộ trong banner.
• Việc xóa dữ liệu có được tự động hóa không? Xác nhận các yêu cầu DSAR kích hoạt API xóa của AppsFlyer, không phải vé thủ công.

AppsFlyer Phù Hợp Với Ngăn Xếp Ưu Tiên Đồng Ý Ở Đâu

Phân bổ di động là một trong những bề mặt mã định danh nặng nhất trong ngăn xếp tiếp thị, và SDK của AppsFlyer là một trong những tích hợp đơn lẻ có hệ quả nhất của nó. Tin tốt là nền tảng cung cấp các nguyên thủy — Start SDK, Stop, bộ lọc chia sẻ, API xóa — cần thiết để thực thi đồng ý sạch sẽ và có thể xác minh. Công việc của nhà xuất bản là kết nối các nguyên thủy đó với CMP sở hữu quyết định đồng ý ràng buộc, coi ATT là tín hiệu bổ sung thay vì thay thế, và đảm bảo rằng việc chuyển tiếp đối tác phía máy chủ không thể thoát khỏi phong bì đồng ý mà banner đã ghi lại. Được thực hiện đúng cách, kết quả là một ngăn xếp phân bổ thỏa mãn các cơ quan quản lý trong khi bảo toàn dữ liệu cài đặt và sự kiện mà các nhóm mua lại người dùng phụ thuộc vào.