Hướng dẫn tích hợp SDK cơ bản

ID AppsFlyer được tạo tự động cho mỗi lượt cài đặt ứng dụng mới. Nhà tiếp thị không cần phải thực hiện bất kỳ hành động nào.

Bạn có thể sử dụng mã định danh này để thực hiện các hoạt động sau:

• Gửi các sự kiện trong ứng dụng server-to-server .
• So khớp ID AppsFlyer với hồ sơ người dùng trong các hệ thống backend của bạn.
• Tải xuống báo cáo dữ liệu thô sự kiện trong ứng dụng và sử dụng appsflyer_id để phân tích hành vi và hành trình của người dùng.

Đặt Customer user ID (CUID) của riêng bạn trong SDK AppsFlyer để tham chiếu chéo ID duy nhất từ hệ thống BI với ID AppsFlyer và các mã định danh khác. CUID có sẵn trong các báo cáo dữ liệu thô của AppsFlyer. Bạn cũng có thể sử dụng CUID này trong API postback để tham chiếu chéo với ID nội bộ của bạn. 

Xem hướng dẫn triển khai CUID dành cho nhà phát triển.

Người giới thiệu Cài đặt Google Play

API của Người giới thiệu Cài đặt Google Play giúp cải thiện độ chính xác của phân bổ, bảo vệ khỏi bị gian lận lượt cài đặt và cho phép truy xuất an toàn dữ liệu lượt giới thiệu từ Google Play (ví dụ: phiên bản của ứng dụng tại thời điểm ứng dụng được cài đặt lần đầu). 

Bạn nên cung cấp cho nhà phát triển của mình các hướng dẫn này để thêm API của Người giới thiệu Cài đặt Google Play. 

GAID

Kể từ phiên bản SDK V4.8.0, AppsFlyer sẽ tự động thu thập mã nhận dạng thiết bị này.

Với AppsFlyer, bạn có thể phân bổ lượt cài đặt bắt nguồn từ các cửa hàng ứng dụng của bên thứ ba, chẳng hạn như Amazon, Opera, GetJar, Baidu và Huawei. Điều này cho phép bạn quảng bá ứng dụng của mình và tiếp cận đối tượng lớn hơn ở các thị trường không có Google Play.

SDK sử dụng các phương thức sau để phân bổ thiết bị trong cửa hàng ứng dụng của bên thứ ba:

• IMEI hoặc ID Android: SDK không tự động thu thập IMEI hoặc ID Android. Tuy nhiên, nếu có nhu cầu thu thập các mã định danh này (ví dụ: đối với các ứng dụng ở thị trường nội địa Trung Quốc) thì nhà phát triển của bạn có thể triển khai một trong các hình thức thu thập sau:
  • Thu thập thủ công: Các ứng dụng chuyển IMEI hoặc ID Android đến SDK (sử dụng setImeiData hoặc APIsetAndroidIdData) . SDK gửi dữ liệu đến máy chủ AppsFlyer. 
  • Chọn tham gia thu thập ID thiết bị: Buộc SDK thu thập IMEI hoặc ID Android. 
• OAID: Phân bổ lượt cài đặt từ các cửa hàng ứng dụng Android của bên thứ ba. Để biết thêm thông tin, hãy xem hướng dẫn triển khai OAID.

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 phải có sự đồng ý của người dù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 sẽ trì hoãn và chờ trạng thái ATT trước khi gửi dữ liệu đến máy chủ AppsFlyer.

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 sẽ tạo hàng đợi 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 ghi nhận các sự kiện ngoại tuyế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ớ đệm mà không kèm 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 sẽ bắt đầu và gửi các sự kiện đã lưu trong bộ nhớ đệ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, ứng dụng sẽ tắt hẳn 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ể 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 ý.

Hãy cem xét những điều sau khi tạo tin nhắ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à sử dụng dữ liệu.

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

Xem một số ví dụ bên ngoài về lời nhắc ATT.

SKAN 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 từ một 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 SKAN của AppsFlyer sử dụng SKAN để cung cấp tính năng đă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 SKAN.

Để sử dụng giải pháp SKAN:

• Nhà tiếp thị cần cấu hình đo lường SKAN trong AppsFlyer. Nhà phát triển không phải thực hiện bất kỳ công việc nào.
• SDK AppsFlyer tự động gọi ra các API SKAN cần thiết.
• Đảm bảo vô hiệu các lệnh gọi SKAN trong các SDK khác nếu bạn sử dụng AppsFlyer để phân bổ SKAN.
• 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ổ SKAN, 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. 

Bạn có thể gửi doanh thu với bất kỳ sự kiện trong ứng dụng. Đả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 bảng điều khiển và trong báo cáo dữ liệu thô. Tìm hiểu thêm.

Để 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.

Xem danh sách các sự kiện trong ứng dụng được đề xuất theo ngành, ví dụ, du lịch, trò chơi hoặc Thương mại điện tử.

Đố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

Đố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ẽ nhận diện loại thiết bị và chuyển hướng họ đến điểm đích chính xác: 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 liên kết sâu gián tiếp để 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ề cách thiết lập deferred deep linking bằng OneLink.