Hướng dẫn tích hợp SDK iOS dành cho nhà tiếp thị

Thông tin cơ bản

Kể từ phiên bản iOS 14.5, chức năng thu thập IDFA yêu cầu người dùng đồng ý. Trên thực tế, điều đó có nghĩa là quyền truy cập IDFA được điều chỉnh bởi khung Minh bạch về Theo dõi Ứng dụng (ATT). Trên thiết bị iOS từ phiên bản 14 trở lên, SDK sử dụng khung ATT để có quyền truy cập vào IDFA của thiết bị. 

Để biết thông tin giới thiệu về ATT, hãy xem các nguyên tắc về ATT .

Khi phân bổ xảy ra bằng cách sử dụng IDFA, quan trọng là IDFA phải được gửi vào lần khởi chạy đầu tiên. Vì lý do này, SDK cung cấp tiện ích waitForATTUserAuthorization.

Tổng quan về waitForATTUserAuthorization

waitForATTUserAuthorization cho phép bạn định cấu hình thời gian SDK hoãn gửi dữ liệu đến máy chủ AppsFlyer và đợi trạng thái của ATT.

Khi người dùng khởi chạy ứng dụng, trạng thái ATT là notDetermined. Trong thời gian chờ waitForATTUserAuthorization:

• SDK xếp hàng đợi cho sự kiện khởi chạy và các sự kiện trong ứng dụng liên tiếp trong bộ nhớ, tương tự như cách các sự kiện ngoại tuyến được ghi nhận.
• Nếu người dùng đồng ý với lời nhắc ATT (Thu thập IDFA):
  • SDK sẽ thêm IDFA vào các sự kiện được lưu trong bộ nhớ tạm.
  • SDK bắt đầu và gửi các sự kiện được lưu trong bộ nhớ tạm kèm theo IDFA (mà không cần đợi hết thời gian chờ).
• Nếu người dùng từ chối lời nhắc ATT:
  • SDK bắt đầu và gửi các sự kiện được lưu trong bộ nhớ tạm không kèm theo IDFA (mà không cần đợi hết thời gian chờ).
• Nếu thời gian chờ kết thúc và trạng thái ATT vẫn là notDetermined:
  • SDK bắt đầu và gửi các sự kiện được lưu trong bộ nhớ tạm mà không kèm theo IDFA.

Những điều cần lưu ý

• Việc gọi ra requestTrackingAuthorization mà không cài đặt waitForATTUserAuthorization sẽ dẫn đến việc khởi chạy và gửi sự kiện mà không kèm theo IDFA đối với thiết bị iOS từ phiên bản 14 trở lên.
• Nếu người dùng chuyển ứng dụng sang chạy ngầm trong thời gian chờ:
  • Bộ định thời tạm dừng cho đến khi ứng dụng quay trở lại chế độ chạy nổi.
  • Sự kiện được lưu vào bộ nhớ tạm.
• Nếu người dùng tắt ứng dụng theo quy trình/tắt hẳn ứng dụng đột ngột trong thời gian chờ:
  • Bộ định thời được khởi động lại vào lần khởi chạy ứng dụng tiếp theo.
  • Sự kiện được lưu vào bộ nhớ tạm sẽ bị mất.

Bạn có thể chọn tùy chỉnh lời nhắc ATT. Thông báo nêu rõ mục đích của yêu cầu có thể giúp tăng tỷ lệ người dùng chọn đồng ý.

Lưu ý những điều sau khi tạo thông báo của bạn:

• Sử dụng từ ngữ giải thích tốt nhất cho người dùng của bạn về lý do ứng dụng yêu cầu sự đồng ý của người dùng.
• Thông báo cho người dùng về cách dữ liệu của họ sẽ được sử dụng. Để tìm hiểu thêm về quyền riêng tư của người dùng và việc sử dụng dữ liệu, hãy nhấp vào đây.

Sau khi thông báo của bạn hoàn tất, hãy cung cấp cho nhà phát triển văn bản và các hướng dẫn này.

Để xem một số ví dụ bên ngoài về lời nhắc ATT, hãy nhấp vào đây.

SKAdNetwork là một lớp được iOS sử dụng để xác thực các lượt cài đặt ứng dụng do nhà quảng cáo thúc đẩy. Quy trình xác thực lượt cài đặt ứng dụng liên quan đến ứng dụng nguồn và ứng dụng được quảng cáo. 

Ứng dụng nguồn là một ứng dụng tham gia vào các chiến dịch quảng cáo bằng cách hiển thị quảng cáo được ký bởi mạng quảng cáo. Việc cấu hình ứng dụng của bạn để hiển thị quảng cáo không nằm trong phạm vi của SDK AppsFlyer. Để cấu hình, hãy làm theo hướng dẫn của Apple.

Đối với ứng dụng được quảng cáo (ứng dụng có SDK AppsFlyer), Giải pháp SKAdNetwork của AppsFlyer sử dụng SKAdNetwork để cung cấp đăng lại phân bổ trong khi AppsFlyer thu thập, dịch và tổng hợp dữ liệu, đồng thời duy trì quyền riêng tư của người dùng. Khi ứng dụng được khởi chạy lần đầu tiên, nền tảng AppsFlyer sử dụng cấu hình do nhà tiếp thị cài đặt để hướng dẫn SDK về cách cài đặt giá trị chuyển đổi SKAdNetwork.

Để sử dụng Giải pháp SKAdNetwork:

• Nhà tiếp thị cần cấu hình đo lường SKAdNetwork trong AppsFlyer. Nhà phát triển không phải thực hiện bất kỳ tác vụ nào.
• SDK AppsFlyer tự động gọi các API SKAdNetwork cần thiết.
• Đảm bảo tắt các lệnh gọi SKAdNetwork trong các SDK khác khi dựa vào AppsFlyer để phân bổ SKAdNetwork.
• Không yêu cầu nhà phát triển hoặc nhà tiếp thị phải có hành động hoặc quy trình đăng ký nào khác trong App Store. 

Để tắt tính năng phân bổ SKAdNetwork, hãy hướng dẫn nhà phát triển của bạn tắt các lệnh gọi này trong SDK. Đảm bảo rằng nhà phát triển không gọi các API SKAdNetwork. 

Bạn có thể gửi doanh thu với bất kỳ sự kiện trong ứng dụng nào. Đảm bảo bạn sử dụng thông số af_revenue để bao gồm doanh thu. Đây là thông số sự kiện duy nhất mà AppsFlyer tính là doanh thu thực trên dữ liệu thô và bảng điều khiển. Để biết thêm thông tin chi tiết, nhấp vào đây. 

Để biết hướng dẫn dành cho nhà phát triển, hãy xem ghi lại doanh thu.

SDK của AppsFlyer cung cấp xác minh máy chủ cho các giao dịch mua trong ứng dụng. Xác thực mua hàng trong ứng dụng sẽ tự động gửi một sự kiện mua trong ứng dụng tới AppsFlyer. Tự gửi sự kiện này tạo ra báo cáo sự kiện trùng lặp gấp đôi.

Nếu ứng dụng của bạn thuộc ngành dọc như du lịch, trò chơi hoặc Thương mại điện tử, hãy xem danh sách các sự kiện trong ứng dụng được đề xuất của chúng tôi theo ngành dọc.

Đối với người dùng chưa cài đặt ứng dụng của bạn, OneLink sẽ phát hiện loại thiết bị và chuyển hướng họ đến đích chính xác (ví dụ: Google Play, Apple App Store, cửa hàng ứng dụng của bên thứ ba hoặc trang web). Điều này dựa vào cài đặt mẫu OneLink của bạn. Tìm hiểu thêm

Lưu ý: Tính năng nhận diện và chuyển hướng thiết bị không yêu cầu SDK AppsFlyer. Tuy nhiên, bắt buộc phải có SDK để liên kết sâu.

Đối với người dùng đã cài đặt ứng dụng của bạn, OneLink sẽ mở ứng dụng. Ngoài việc mở ứng dụng, bạn cũng có thể liên kết sâu người dùng với một hoạt động hoặc trang cụ thể trong ứng dụng. Điều này yêu cầu nhà phát triển của bạn triển khai Liên kết sâu hợp nhất (UDL).

Lưu ý:

• UDL yêu cầu SDK V6.1+.
• Những khách hàng đã sử dụng OneLink để liên kết sâu có thể đang sử dụng phương thức kế thừa, thay vì UDL.

Xem hướng dẫn của chúng tôi về thiết lập liên kết sâu với OneLink.

Đối với người dùng chưa cài đặt ứng dụng của bạn, OneLink sẽ phát hiện loại thiết bị và chuyển hướng họ đến đích chính xác (ví dụ: Google Play, Apple App Store, cửa hàng ứng dụng của bên thứ ba hoặc trang web). Sau khi người dùng khởi chạy ứng dụng, bạn có thể sử dụng deferred deep linking để chuyển hướng họ đến một hoạt động hoặc trang cụ thể trong ứng dụng.

Điều này yêu cầu nhà phát triển của bạn triển khai Liên kết sâu hợp nhất (UDL).

Lưu ý:

• UDL yêu cầu SDK V6.1+.
• Những khách hàng đã sử dụng OneLink để liên kết sâu gián tiếp có thể đang sử dụng phương thức kế thừa, thay vì UDL

Xem hướng dẫn của chúng tôi về liên kết sâu bị trì hoãn để tìm hiểu thêm.

AppsFlyer hỗ trợ đo lường các chiến dịch thông báo đẩy từ tất cả các nhà cung cấp và cũng có thể hỗ trợ các nhà phát triển sử dụng trực tiếp các dịch vụ Cloud Messaging của Google hoặc dịch vụ thông báo đẩy của Apple. Các lượt chuyển đổi, được định nghĩa là ứng dụng mở ra bắt nguồn từ các thông báo đẩy, sẽ hiển thị trong bảng điều khiển Nhắm mục tiêu lại.

Bạn có thể sử dụng OneLink để đo lường mức độ tương tác lại của người dùng thông qua thông báo đẩy. Xem hướng dẫn của chúng tôi về cách đo lường các chiến dịch thu hút lại thông báo đẩy.

Để tìm hiểu cách thiết lập đo lường lượt gỡ cài đặt, hãy đọc tại đây.

Nếu bạn muốn nhận được xác nhận rằng SDK đã khởi động thành công và thông báo cho các máy chủ AppsFlyer, hãy triển khai trình xử lý startWithCompletionHandler. Sau đó, bạn có thể áp dụng logic để xử lý trạng thái thành công hay thất bại của hoạt động khởi chạy SDK.

Ví dụ

[[AppsFlyerLib shared] startWithCompletionHandler:^(NSDictionary<NSString *,id> *dictionary, NSError *error) {
        if (error) {
            NSLog(@"%@", error);
            return;
        }
        if (dictionary) {
            NSLog(@"%@", dictionary);
            return;
        }
    }];

 AppsFlyerLib.shared()?.start(completionHandler: { (dictionnary, error) in
            if (error != nil){
                print(error ?? "")
                return
            } else {
                print(dictionnary ?? "")
                return
            }
        })

Trong trường hợp xảy ra lỗi trong trình theo dõi yêu cầu, mã lỗi và mô tả chuỗi sẽ được cung cấp, như được chỉ ra trong bảng sau.

Phải có API setAdditionalData để tích hợp ở cấp SDK với một số nền tảng đối tác bên ngoài, bao gồm Segment, Adobe và Urban Airship.
Chỉsử dụng API này nếu bài viết tích hợp của nền tảng nêu rõ rằng bắt buộc phải có API setAdditionalData.

Ví dụ về mã setAdditableData:

NSDictionary* customDataMap = [[NSDictionary alloc] initWithObjectsAndKeys:@"value_of_param_1", @"custom_param_1", nil];
[[AppsFlyerLib shared] setAdditionalData:customDataMap];

let customDataMap: [AnyHashable: Any] = [
  "custom_param_1" : "value_of_param_1"
]
AppsFlyerLib.shared().customData = customDataMap

Chủ sở hữu ứng dụng sử dụng Liên kết Chung để liên kết sâu (không có OneLink) và có miền được liên kết với ứng dụng của họ có thể phân bổ các phiên được khởi tạo thông qua miền này bằng phương thức appendParametersToDeepLinkingURL.

Ví dụ: một người dùng tìm kiếm trên Google và nhấp vào miền của bạn, www.example.com:

• Nếu người dùng chưa cài đặt ứng dụng, họ sẽ được chuyển hướng đến trang web (www.example.com).
• Nếu người dùng đã cài đặt ứng dụng trên thiết bị của họ, họ sẽ được liên kết sâu vào ứng dụng được liên kết với www.example.com. Phiên này được phân bổ cho nguồn truyền thông (thông số pid) được chỉ định trong appendParametersToDeepLinkingURL.

Xem tài liệu tham khảo về SDK iOS để biết thêm thông tin.

Lưu ý: Biểu ngữ Thông minh giúp chủ sở hữu ứng dụng chuyển đổi khách truy cập trang web thành người dùng ứng dụng.

Theo mặc định, phải mất ít nhất 5 giây giữa hai lần khởi chạy ứng dụng để được tính là hai phiên riêng biệt (tìm hiểu thêm về tính các phiên).

Sử dụng API sau để đặt thời gian tối thiểu giữa các phiên:

[AppsFlyerLib shared].minTimeBetweenSessions = <your_custom_time_in_seconds>;

AppsFlyerLib.shared().minTimeBetweenSessions = <your_custom_time_in_seconds>

Đặt một giá trị cao  cho thời gian tùy chỉnh giữa các phiên khởi chạy có thể ảnh hưởng xấu tới API dựa trên dữ liệu các phiên, chẳng hạn như liên kết sâu.

Không khả dụng trong iOS. 

Một số dịch vụ của bên thứ 3 như nhà cung cấp dịch vụ email gói liên kết trong email với tên miền ghi nhận click của riêng họ. Một số dịch vụ thậm chí cho phép bạn thiết lập các miền ghi nhận nhấp chuột của riêng bạn. Nếu OneLink được gói trong các miền như vậy, điều này có thể giới hạn chức năng của nó.

Để khắc phục vấn đề này, bạn có thể sử dụng API setResolveDeepLinkURLs. Sử dụng API này để nhận OneLink từ các miền nhấp chuột khởi chạy ứng dụng.  Đảm bảo gọi API này trước khi khởi tạo SDK.

Ví dụ: bạn có ba miền nhấp chuột chuyển hướng đến OneLink của bạn, đó là https://mysubdomain.onelink.me/abCD. Sử dụng API này để nhận OneLink mà miền nhấp chuột của bạn chuyển hướng đến.  Phương thức API này nhận được danh sách các miền mà SDK giải quyết.

[AppsFlyerLib shared].resolveDeepLinkURLs = @[@"example.com",@"click.example.com"];

AppsFlyerLib.shared().resolveDeepLinkURLs = ["example.com", "click.example.com"]

Mã ở trên cho phép bạn sử dụng miền nhấp chuột của mình trong khi vẫn duy trì chức năng OneLink. Các miền nhấp chuột có trách nhiệm khởi chạy ứng dụng. API, khi đến lượt, nhận được OneLink từ những miền nhấp chuột và sau đó bạn có thể sử dụng dữ liệu từ OneLink này để liên kết sâu và tùy chỉnh nội dung người dùng.

Với AppsFlyer, bạn có thể ghi nhận thông báo đẩy như một phần của chiến dịch nhắm mục tiêu lại.

Để kích hoạt tính năng này, hãy gọi phương thức handlePushNotificationData bên trong AppDelegate.m.

-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler {
[[AppsFlyerLib shared] handlePushNotification:userInfo];
}

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    AppsFlyerLib.shared().handlePushNotification(userInfo)
}

Để biết thêm thông tin về đo số lượng thông báo đẩy, hãy đọc tại đây.

Việc cho phép người dùng hiện tại mời bạn bè và những mối liên hệ của họ sử dụng ứng dụng có thể là một yếu tố tăng trưởng then chốt với ứng dụng của bạn. Với AppsFlyer, bạn có thể phân bổ và ghi nhận lượt cài đặt bắt nguồn từ lời mời của người dùng trong ứng dụng của bạn.

Để biết thêm chi tiết, hãy xem bài viết Phân bổ mời người dùng.

Lưu ý! Quảng cáo chéo của IDFV yêu cầu SDK 6.0.2+. IDFV được thu thập tự động và nhà phát triển không cần thực hiện thêm hành động nào.

ID duy nhất của AppsFlyer được tạo cho mỗi lần ứng dụng được cài đặt mới. Bạn có thể sử dụng ID này cho nhiều mục đích khác nhau:

• Gửi các sự kiện trong ứng dụng server-to-server .
• Khớp ID với hồ sơ người dùng trong các hệ thống backend của bạn.
• Ánh xạ các mục khi hợp nhất dữ liệu từ API kéo và đẩy.

Sử dụng API sau để lấy ID duy nhất:

NSString *appsflyerId = [AppsFlyerLib shared].getAppsFlyerUID;

let appsflyerId = AppsFlyerLib.shared().getAppsFlyerUID()

Để thiết lập ID người dùng Customer User ID:

[AppsFlyerLib shared].customerUserID = @"my user id";

AppsFlyerLib.shared().customerUserID = "my user id"

Trong iOS, Customer User ID cần được đặt cho mỗi lần khởi chạy ứng dụng. Chúng tôi khuyên bạn nên đặt Customer User ID sớm trong luồng của ứng dụng, vì nó chỉ được liên kết với các sự kiện được báo cáo sau khi thiết lập:

• Nếu setCustomerUserId được gọi trước khi gọi start, Customer User ID sẽ xuất hiện trong các báo cáo dữ liệu thô cho các lượt cài đặt và sự kiện.
• Nếu được đặt sau, Customer User ID chỉ được liên kết với các sự kiện được ghi nhận sau khi cài đặt Customer User ID.

Để tránh thiết lập lại giá trị ID Người dùng Khách hàng sau lần khởi chạy đầu tiên và để giảm các cuộc gọi đến máy chủ của bạn để lấy Customer User ID, bạn có thể kiểm tra xem giá trị của nó có trống hay không bằng cách:

NSString *customerUserID = [AppsFlyerLib shared].customerUserID;

let customerUserID = AppsFlyerLib.shared().customerUserID

Để biết thêm thông tin về Customer User ID, nhấp vào đây.

Bạn có thể trì hoãn Khởi tạo SDK cho đến khi Customer User ID được thiết lập. Điều này hữu ích nếu bạn cần là dữ liệu cài đặt và sự kiện chứa customer user ID của bạn.

Thực hiện mã sau:

- (void)applicationDidBecomeActive:(UIApplication *)application {
    NSString *customUserId = [[NSUserDefaults standardUserDefaults] stringForKey:@"customerUserId"]; // Your custom logic of retrieving CUID
    if (customUserId != nil && ![customUserId  isEqual: @""]) {
        [AppsFlyerLib shared].customerUserID = customUserId; // Set CUID in AppsFlyer SDK for this session
        [[AppsFlyerLib shared] start]; // Start
    }
}

func applicationDidBecomeActive(_ application: UIApplication) {
        let customUserId = UserDefaults.standard.string(forKey: "customUserId")  //  your logic to retrieve CUID
        if(customUserId != nil && customUserId != ""){
            AppsFlyerLib.shared().customerUserID = customUserId // Set CUID in AppsFlyer SDK for this session
            AppsFlyerLib.shared().start() // Start
        }
    }

Để tìm hiểu thêm về việc trì hoãn khởi tạo SDK cho đến khi Customer User ID khả dụng, hãy truy cập tại đây .

Bạn có thể cần trì hoãn việc khởi tạo SDK và gửi dữ liệu cho đến khi người dùng đồng ý (ví dụ: chấp thuận GDPR hoặc COPPA).

Lưu ý: Điều này không liên quan đến ATT được giới thiệu trong iOS 14. 

Để trì hoãn việc khởi tạo SDK:

1. Ngăn không cho phiên được gửi trong quá trình chuyển đổi nền trước-nền sau. Trong một phương thức sendLaunch() (được gọi trên mọi applicationDidBecomeActive (theo phần 3.3), bao lệnh gọi đến start bằng việc kiểm tra điều kiện. Ví dụ:
   
   

   -(void)sendLaunch:(UIApplication *)application {
       if (consent_given) { // check the condition
           [[AppsFlyerLib shared] start]; // Start
       }
   }

2. Gửi phiên ngay khi lý do trì hoãn không còn phù hợp (ngay sau khi điều kiện thay đổi). Gọi start khi bạn sẵn sàng gửi dữ liệu phiên đầu tiên. Ví dụ:
   
   

   ...
   consent_given = YES; // change the condition
   [[AppsFlyerLib shared] start]; // Start
   ...

Trong một số trường hợp nghiêm trọng, bạn có thể sẽ phải tắt tất cả các tùy chọn ghi dữ liệu SDK để bảo đảm tuân thủ pháp luật và quyền riêng tư. Có thể thực hiện được điều này bằng thuộc tính isStopped. Khi thuộc tính này được đặt thành true, SDK sẽ ngừng hoạt động và không còn giao tiếp với các máy chủ AppsFlyer.

Có một số trường hợp khác nhau để người dùng lựa chọn không tham gia. Chúng tôi khuyên bạn nên thực hiện theo những hướng dẫn chính xác cho từng trường hợp liên quan tới ứng dụng của bạn.

[AppsFlyerLib shared].isStopped = true;

AppsFlyerLib.shared().isStopped = true

Trong bất kỳ sự kiện nào, SDK có thể được kích hoạt lại bằng cách gọi API tương tự, nếu kết quả là sai.

Sử dụng API này trong quá trình Khởi tạo SDK để ẩn danh hoàn toàn các cài đặt, sự kiện và phiên của người dùng:

[AppsFlyer shared].anonymizeUser = YES;

AppsFlyerLib.shared().anonymizeUser = true

Chức năng ghi dữ liệu có thể được khởi động lại bằng cách đặt anonymizeUser thành false.

Sử dụng SDK chế độ nghiêm ngặt để xóa hoàn toàn chức năng thu thập IDFA và các phần phụ thuộc của khung AdSupport (ví dụ: khi phát triển ứng dụng cho trẻ em).

Lưu ý: IDFV vẫn có sẵn.

Trong Podfile của bạn, thay thế phần phụ thuộc AppsFlyerLib bằng:

pod 'AppsFlyerFramework/Strict','6.2.3'

Để vô hiệu hóa các khung AdSupport và iAd, SDK cung cấp các bộ thiết lập sau:

• disableCollectASA = true. Tìm hiểu thêm
• disableAdvertisingIdentifier = true. Tìm hiểu thêm

Để vô hiệu hóa các khung quảng cáo:

[AppsFlyerLib shared].disableCollectASA = YES
[AppsFlyerLib shared].disableAdvertisingIdentifier = YES;

AppsFlyerLib.shared().disableCollectASA = true
AppsFlyerLib.shared().disableAdvertisingIdentifier = true

Trong một số trường hợp, nhà quảng cáo có thể muốn ngừng chia sẻ dữ liệu cấp người dùng với các mạng/đối tác quảng cáo cho những người dùng cụ thể. Lý do cho điều này bao gồm: 

• Các chính sách bảo mật như CCPA hoặc GDPR
• Cơ chế chọn lựa không tham gia của người dùng
• Cạnh tranh với một số đối tác (mạng quảng cáo, bên thứ 3)

AppsFlyer cung cấp hai phương thức API để ngừng chia sẻ dữ liệu với một số hoặc tất cả các đối tác:

• setSharingFilter: Được nhà quảng cáo sử dụng để ngăn chặn việc chia sẻ dữ liệu với một số (một hoặc nhiều) mạng/đối tác tích hợp.
• setSharingFilterForAllPartners: Được các nhà quảng cáo sử dụng để ngăn chặn việc chia sẻ dữ liệu với tất cả các mạng lưới/đối tác tích hợp.

Các phương thức lọc này được hỗ trợ từ SDK V5.4.1.

Phương thức lọc phải được gọi mỗi khi SDK được khởi tạo và ảnh hưởng đến toàn phiên. Nếu cần thời gian để xác định xem bạn có cần đặt bộ lọc chia sẻ hay không, thì hãy trì hoãn quá trình khởi tạo SDK. 

Khi phương thức này được kích hoạt trước lệnh gọi start đầu tiên:

• Người dùng từ SRN được phân bổ là Tự nhiên và dữ liệu của họ không được chia sẻ với các đối tác tích hợp.
• Người dùng từ mạng quảng cáo lượt nhấp (không phải SRN) được phân bổ chính xác trên AppsFlyer, nhưng không được chia sẻ với mạng quảng cáo thông qua postback, API, báo cáo dữ liệu thô hoặc bằng bất kỳ phương thức nào khác.

Hiện tại, không thể lọc dữ liệu gỡ cài đặt bằng các phương thức này. Tuy nhiên, bạn có thể ngừng gửi sự kiện Gỡ cài đặt cho đối tác bằng cách sử dụng trang thiết lập trong AppsFlyer.