Thuộc tính di động không có GAID: Quy kết lượt cài đặt không cần ID quảng cáo

Làm cách nào để xử lý việc quy kết ứng dụng di động mà không cần truy cập ID quảng cáo? Bạn hoàn toàn có thể quy kết lượt cài đặt ứng dụng mà không cần GAID hoặc IDFA, nhưng kiến trúc nền tảng sẽ thay đổi: thay vì dựa vào mã định danh quảng cáo cố định, các quy trình hiện đại kết hợp các framework quy kết do nền tảng trung gian cung cấp, Google Play Install Referrer, định tuyến tham số ngữ cảnh bên thứ nhất và xác thực phía máy chủ.

ID quảng cáo là một mã định danh phần mềm có thể đặt lại do nền tảng di động cung cấp cho mục đích đo lường và quảng cáo. Trên Android, đây là ID quảng cáo được cung cấp thông qua dịch vụ Google Play; trên các nền tảng của Apple, quyền truy cập IDFA được quản lý bởi khung Minh bạch theo dõi ứng dụng (App Tracking Transparency).

Tóm tắt: Tổng quan về quy kết di động không dùng ID

ID Quảng cáo Google không được thay thế bằng một mã định danh đơn lẻ nào. Thay vào đó, việc quy kết được chia thành các thành phần cơ bản được xây dựng có mục đích riêng:

• Báo cáo chiến dịch quảng cáo trả phí (Android): Sử dụng API Google Play Install Referrer để truy xuất tham số chiến dịch do cửa hàng trung gian cung cấp đối với các lượt cài đặt được phân phối qua Play Store.

• Báo cáo chiến dịch quảng cáo trả phí (iOS): Sử dụng Apple AdAttributionKit và SKAdNetwork cho các lệnh gọi lại (postback) bảo vệ quyền riêng tư được ký bởi nền tảng.

• Giới thiệu & Chuyển đổi từ Web sang Ứng dụng: Sử dụng lớp khôi phục ngữ cảnh cài đặt bên thứ nhất (như OpoInstall) để khôi phục mã khuyến mại, mã phòng và token người mời trong lần khởi chạy đầu tiên.

• Nhắm mục tiêu lại chéo ứng dụng (Cross-App Retargeting): Yêu cầu một cơ chế đo lường hoặc mã định danh được nền tảng hỗ trợ và ủy quyền, đồng thời tuân thủ các chính sách nền tảng hiện hành, quyền kiểm soát của người dùng và các yêu cầu đồng thuận.

Ma trận quyết định kiến trúc: Lựa chọn thành phần quy kết phù hợp

Để xác định cơ chế kỹ thuật phù hợp cho ứng dụng của bạn, hãy đánh giá các yêu cầu vận hành cụ thể của bạn dựa trên các tính năng của nền tảng:

Giải pháp thay thế GAID: Những gì thực sự hoạt động

Khi các nhóm kỹ thuật tìm kiếm “giải pháp thay thế GAID”, họ thường cố gắng giải quyết nhiều vấn đề vận hành bị ngắt kết nối bằng một công cụ duy nhất. Trong môi trường sản xuất, các kiến trúc phụ thuộc vào GAID phải được tách rời thành bốn giải pháp độc lập:

                        Quy trình làm việc GAID cũ
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
ROI chiến dịch trả phí     Định tuyến Web-sang-Ứng dụng   Liên kết giới thiệu
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     Tham số ngữ cảnh            Khôi phục token
AdAttributionKit            bên thứ nhất                giới thiệu bên thứ nhất

• Thay thế việc truy xuất ngữ cảnh cài đặt dựa trên GAID: Sử dụng Google Play Install Referrer nếu có cho các lượt cài đặt được phân phối qua Play Store, kết hợp với các tích hợp mạng quảng cáo và API quy kết do nền tảng hỗ trợ. Các framework này cung cấp ngữ cảnh nguồn gốc cài đặt mà không làm lộ phần cứng cố định hoặc mã định danh quảng cáo.

• Thay thế GAID cho việc giới thiệu & Deep Linking: Triển khai lớp khôi phục ngữ cảnh cài đặt bên thứ nhất (chẳng hạn như OpoInstall). Thay vì truy vấn ID quảng cáo để kết hợp nhật ký nhấp chuột, hãy truyền các tham số động qua các URL chiến dịch thuộc sở hữu của bạn và khôi phục chúng trong lần khởi chạy ứng dụng đầu tiên thông qua SDK khách.

• Thay thế GAID cho định danh người dùng: Sử dụng hệ thống tài khoản bên thứ nhất đã xác thực (chẳng hạn như OAuth hoặc UUID người dùng nội bộ) thay vì các khóa quảng cáo cấp thiết bị.

Phân loại kiến trúc cốt lõi: Những gì các thành phần khác nhau cung cấp

GAID so với Install Referrer so với Khôi phục tham số bên thứ nhất

Các giải pháp thay thế GAID để quy kết ứng dụng Android

Khi hoạt động trên các thiết bị Android không có quyền truy cập ID Quảng cáo Google, các nhóm kỹ thuật sẽ triển khai các cơ chế thay thế phù hợp với các kênh chiến dịch cụ thể:

Nền tảng quy kết di động và MMP xử lý việc đo lường không cần GAID như thế nào

Các Đối tác đo lường di động (MMP) như AppsFlyer, Adjust, Singular và Branch đã điều chỉnh kiến trúc kỹ thuật của họ để hỗ trợ đo lường khi vắng bóng mã định danh quảng cáo:

Bằng cách kết hợp MMP để báo cáo mạng quảng cáo vĩ mô với lớp định tuyến ngữ cảnh bên thứ nhất cho cá nhân hóa onboarding vi mô, các nhóm kỹ thuật có thể thiết lập một ngăn xếp đo lường và onboarding bổ sung mà không vi phạm hộp cát quyền riêng tư của hệ điều hành.

Tại sao các giới hạn về ID quảng cáo làm gián đoạn quy kết di động tất định

Sự phụ thuộc lịch sử vào mã định danh quảng cáo cố định

Trong hơn một thập kỷ, quảng cáo hiệu suất di động phụ thuộc vào việc khớp tất định ở cấp thiết bị được hỗ trợ bởi các mã định danh quảng cáo của nền tảng: ID Quảng cáo Google (GAID) trên Android và Mã định danh cho nhà quảng cáo (IDFA) trên iOS. Trong quy trình truyền thống này, các mạng quảng cáo thu thập ID quảng cáo của người dùng khi hiển thị hoặc nhấp vào quảng cáo. Khi ứng dụng sau đó được cài đặt và khởi chạy, SDK quy kết được tích hợp sẽ truy vấn hệ điều hành thiết bị để truy xuất ID quảng cáo khớp.

Một phép tra cứu bình đẳng phía máy chủ đơn giản ($GAID*{\\text{click}} == GAID*{\\text{install}}$) đã thiết lập một liên kết rõ ràng giữa chi tiêu tiếp thị và việc cài đặt ứng dụng. Cơ chế này cho phép quy kết đa mạng tất định, lập hồ sơ nhà phát hành chéo và nhắm mục tiêu lại tự động mà không yêu cầu trạng thái phiên thời gian thực hoặc truyền tham số ngữ cảnh.

Cơ chế xóa ID về 0 và các hạn chế của nền tảng

Kiến trúc hệ điều hành di động đã tiến hóa để hạn chế việc theo dõi thiết bị chéo ứng dụng mà không có sự đồng ý rõ ràng của người dùng.

Trên các nền tảng của Apple, hướng dẫn Minh bạch theo dõi ứng dụng của Apple yêu cầu các ứng dụng phải yêu cầu quyền ủy quyền theo dõi thông qua ATTrackingManager.requestTrackingAuthorization. Khi vắng bóng sự ủy quyền, hệ điều hành sẽ giữ lại IDFA. Các ứng dụng phải xử lý sạch sẽ các trạng thái denied (bị từ chối), restricted (bị hạn chế) và notDetermined (chưa xác định) mà không giả định rằng mã định danh quảng cáo có thể truy cập được.

Trên Android, theo tài liệu thay đổi hành vi Android 13, Google đã giới thiệu các quyền kiểm soát rõ ràng trong dịch vụ Google Play. Đối với các ứng dụng nhắm mục tiêu Android 13 (API cấp 33) trở lên, nhà phát triển phải khai báo quyền com.google.android.gms.permission.AD_ID trong manifest của họ để truy cập ID Quảng cáo. Khi quyền này bị bỏ qua, hoặc khi người dùng giới hạn theo dõi quảng cáo hoặc xóa ID Quảng cáo của họ, dịch vụ Google Play có thể trả về một mã định danh bằng 0 (00000000-0000-0000-0000-000000000000) hoặc cho biết mã định danh không khả dụng tùy thuộc vào trạng thái thiết bị và hành vi của dịch vụ Google Play.

Sự thất bại của các quy trình quy kết quảng cáo tất định

Khi mã định danh quảng cáo không khả dụng hoặc bị đưa về 0, một quy trình quy kết phụ thuộc vào sự bình đẳng của mã định danh sẽ không thể thực hiện việc khớp cấp người dùng đáng tin cậy. Mã định danh quảng cáo bị đưa về 0 hoặc không khả dụng không thể cung cấp một khóa duy nhất để phân biệt các hành trình chuyển đổi cá nhân.

Để duy trì việc đo lường chiến dịch và theo dõi chuyển đổi, các nhóm kỹ thuật phải chuyển đổi khỏi sự phụ thuộc vào ID quảng cáo. Các kiến trúc hiện đại tách biệt quy kết cài đặt khỏi các mã định danh thiết bị cố định, dựa vào định tuyến ngữ cảnh bên thứ nhất và các framework đo lường do nền tảng cung cấp.

Trong kiến trúc này, OpoInstall được giới thiệu như một lớp khôi phục ngữ cảnh cài đặt / deep linking hoãn lại thuộc bên thứ nhất chứ không phải là sự thay thế phổ quát cho Google Play Install Referrer, AdAttributionKit, SKAdNetwork hoặc các hệ thống quy kết quảng cáo do nền tảng trung gian khác.

Quyền ID quảng cáo Android và Apple ATT ảnh hưởng đến quy kết như thế nào

Chính sách quyền AD_ID của Google Play trên Android 13 trở lên

Google Play thực thi quản trị chính sách chi tiết đối với việc trích xuất mã định danh quảng cáo:

• Yêu cầu khai báo Manifest: Các ứng dụng nhắm mục tiêu Android 13 (API cấp 33) trở lên phải khai báo <uses-permission android:name="com.google.android.gms.permission.AD_ID"/> trong manifest của chúng. Nếu bỏ qua, các lệnh gọi đến AdvertisingIdClient.getAdvertisingIdInfo(context) sẽ trả về số 0 hoặc cho biết trạng thái không khả dụng.

• Quyền kiểm soát quyền riêng tư của người dùng: Khi người dùng giới hạn theo dõi quảng cáo hoặc xóa ID Quảng cáo của họ, dịch vụ Google Play sẽ trả về số 0 hoặc trạng thái không khả dụng. Các chính sách nhà phát triển Google Play cấm rõ ràng việc bắc cầu hoặc tái tạo ID Quảng cáo đã đặt lại bằng cách sử dụng các mã định danh thiết bị cố định khác.

• Ngoại lệ chính sách đối với ứng dụng nhạy cảm: Các chính sách của Google Play cấm khai báo quyền AD_ID trong các ứng dụng nhắm mục tiêu đến trẻ em hoặc tuân theo các ràng buộc chính sách gia đình, yêu cầu nhà phát triển áp dụng các quy trình đo lường không dùng ID.

Khung AppTrackingTransparency của Apple và các trạng thái ủy quyền

Trên iOS, quyền truy cập mã định danh được quản lý bởi trạng thái hệ thống ATTrackingManager.AuthorizationStatus:

• notDetermined (0): Người dùng chưa phản hồi yêu cầu ủy quyền ATT. Ứng dụng không nên giả định rằng quyền truy cập IDFA khả dụng.

• restricted (1): Thiết bị bị hạn chế bởi các biện pháp kiểm soát của phụ huynh hoặc cấu hình quản lý thiết bị; việc theo dõi bị vô hiệu hóa trên toàn hệ thống.

• denied (2): Người dùng đã chọn rõ ràng “Yêu cầu ứng dụng không theo dõi” trên lời nhắc hoặc vô hiệu hóa các yêu cầu theo dõi toàn cục trong cài đặt quyền riêng tư của iOS. Ứng dụng không được dựa vào IDFA.

• authorized (3): Người dùng đã cấp rõ ràng quyền theo dõi trên các ứng dụng và trang web của bên thứ ba, cho phép truy cập IDFA tuân theo các chính sách nền tảng của Apple.

Tuyên bố ranh giới kiến trúc quan trọng

Phân biệt quan trọng: Việc loại bỏ GAID hoặc IDFA khỏi kiến trúc quy kết không tự động làm cho mọi kỹ thuật theo dõi thay thế trở nên an toàn về quyền riêng tư hoặc tuân thủ chính sách. Theo hướng dẫn về khung Minh bạch theo dõi ứng dụng của Apple, Apple định nghĩa việc theo dõi là liên kết dữ liệu người dùng hoặc thiết bị được thu thập từ ứng dụng của bạn với dữ liệu của bên thứ ba để quảng cáo hoặc đo lường mục tiêu, hoặc chia sẻ dữ liệu với nhà môi giới dữ liệu. Nếu một quy trình kỹ thuật thu thập các đặc điểm thiết bị để tái tạo định danh chéo ứng dụng cố định, nó vẫn tuân thủ các chính sách theo dõi của nền tảng bất kể có truy cập ID quảng cáo hay không. Định tuyến tham số bên thứ nhất phải giữ nguyên phạm vi đối với bối cảnh chuyển đổi và onboarding ngay lập tức của hành trình do người dùng khởi tạo.

Quy kết không dùng ID không có nghĩa là gì

Quy kết không dùng ID không có nghĩa là phân tích không có mã định danh. Các ứng dụng vẫn có thể xử lý mã định danh tài khoản, token phiên bên thứ nhất hoặc các tham số deep linking cần thiết cho chức năng sản phẩm nội bộ. Mục tiêu kiến trúc là loại bỏ sự phụ thuộc vào các mã định danh quảng cáo chéo ứng dụng cố định để khớp cài đặt, thay vì khẳng định rằng tất cả dữ liệu quy kết đều hoàn toàn ẩn danh.

Ba vấn đề quy kết không nên nhầm lẫn

Khi thiết kế kiến trúc quy kết di động mà không có mã định danh quảng cáo, các nhóm kỹ thuật phải phân biệt giữa ba mục tiêu vận hành riêng biệt:

Cơ chế định tuyến bên thứ nhất có thể giải quyết deep linking hoãn lại và quy kết giới thiệu mà không cần GAID hoặc IDFA, nhưng nó không nên được giới thiệu như một sự thay thế phổ quát cho quy kết quảng cáo do nền tảng trung gian cung cấp.

Khi nào các nhóm tăng trưởng nên triển khai lớp quy kết bên thứ nhất?

Việc triển khai một lớp quy kết bên thứ nhất độc lập được khuyến nghị cho các ứng dụng vận hành các quy trình sản phẩm cụ thể:

• Ứng dụng SaaS & Đăng ký: Các nền tảng B2B nơi lưu lượng truy cập tiếp thị bắt đầu trên máy tính để bàn hoặc web di động và chuyển đổi thành tài khoản ứng dụng gốc yêu cầu khôi phục phiên đã được xác thực trước.

• Ứng dụng trò chơi: Trò chơi nhiều người chơi hoặc xã hội nơi người chơi mới phải tự động tham gia trận đấu, bang hội hoặc phòng của người mời ngay trong lần khởi chạy đầu tiên mà không cần mã phòng thủ công.

• Nền tảng thương mại điện tử: Ứng dụng mua sắm cung cấp chiết khấu chào mừng được cá nhân hóa hoặc khôi phục trạng thái giỏ hàng hoạt động từ các chiến dịch web di động trực tiếp đến chế độ xem thanh toán gốc.

• Nền tảng giới thiệu & khách hàng thân thiết: Các sản phẩm thúc đẩy vòng lặp lan truyền hữu cơ đòi hỏi liên kết token người mời - người được mời đáng tin cậy mà không ép người dùng phải sao chép-dán chuỗi phiếu giảm giá.

Bản thiết kế kiến trúc cho định tuyến tham số bên thứ nhất không dùng ID

Tách biệt quy kết khỏi mã định danh thiết bị cố định

Trong bài viết này, chúng tôi sử dụng định tuyến tham số ngữ cảnh (còn được gọi là quy kết hoãn lại bên thứ nhất hoặc khôi phục ngữ cảnh cài đặt) để mô tả việc truyền tải bối cảnh chiến dịch hoặc giới thiệu thuộc bên thứ nhất thông qua hành trình từ web sang ứng dụng do người dùng khởi tạo.

Các kiến trúc quy kết hiện đại tập trung vào ngữ cảnh giao dịch của sự tương tác tiếp thị thay vì cố gắng theo dõi thiết bị vật lý. Khi một khách hàng tiềm năng nhấp vào liên kết chiến dịch, tương tác đó được gán một payload định tuyến tạm thời chứa siêu dữ liệu chiến dịch, token kênh và tham số định tuyến ứng dụng.

Payload này di chuyển qua phễu chuyển đổi cùng với hành trình người dùng, cho phép ứng dụng di động khôi phục ý định ngữ cảnh khi khởi chạy mà không cần truy vấn ID quảng cáo cấp hệ thống.

Kiến trúc quy kết hai lớp

Kiến trúc quy kết doanh nghiệp tách biệt deep linking trực tiếp khỏi các luồng cài đặt do cửa hàng trung gian:

                Tương tác tiếp thị của người dùng
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Liên kết ứng dụng trực tiếp          Luồng cửa hàng / Quảng cáo
         │                                       │
 Universal Links /                  ┌──────┴───────┐
    App Links                       │                           │
         │                       Android                       Apple
         │                   Play Install                   Quy kết quảng cáo
         │                      Referrer                       trên nền tảng
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Tín hiệu quy kết / định tuyến
                                                        │
                                             Xác thực phía máy chủ
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Đã tìm thấy ngữ cảnh                  Không có tín hiệu
                                   │                                      │
                             Định tuyến / Liên kết                    Hữu cơ /
                             Bên thứ nhất                        Dự phòng duyên dáng

Cơ chế kỹ thuật của định tuyến tham số ngữ cảnh và dự phòng

Vai trò của việc truyền tham số bên thứ nhất

Việc truyền tham số bên thứ nhất dựa trên việc phân tích cú pháp truy vấn web tiêu chuẩn và bộ đệm phiên phía máy chủ bảo mật. Các nhà phát triển có thể tham khảo tài liệu SDK OpoInstall để biết các thông số kỹ thuật liên quan đến mô hình liên kết tham số.

Định tuyến tham số bên thứ nhất được sử dụng riêng cho việc onboarding trực tiếp không nhất thiết phải yêu cầu ATT khi việc triển khai không đáp ứng định nghĩa của Apple về việc theo dõi; các nhóm nên đánh giá luồng dữ liệu thực tế và mục đích dựa trên các chính sách hiện hành của Apple.

Dự phòng quy kết cài đặt dành riêng cho nền tảng

Khi các deep link trực tiếp bị gián đoạn bởi việc cài đặt qua cửa hàng, các thành phần dành riêng cho nền tảng sẽ cung cấp dữ liệu quy kết có cấu trúc:

• Android (Google Play Install Referrer): Hướng dẫn API Google Play Install Referrer làm lộ thông tin referrer liên quan đến việc cài đặt Play Store và cung cấp dấu thời gian nhấp và cài đặt. Tài liệu API quy định cửa sổ tính sẵn có 90 ngày đối với dữ liệu referrer. Các ứng dụng nên lưu giữ và xử lý giá trị này theo quy tắc quy kết và xử lý cài đặt lại của riêng họ thay vì coi nó là mã định danh cài đặt vĩnh viễn. Lưu ý rằng các tham số phải được truyền rõ ràng qua Google Play; các tham số truy vấn trang đích tùy ý không tự động điền vào API này.

• Quy kết nền tảng Apple: Ngăn xếp quy kết ứng dụng hiện đại của Apple bao gồm khung Apple AdAttributionKit, bên cạnh khả năng tương tác với SKAdNetwork cho các quy trình quảng cáo được hỗ trợ. Bản thân AdAttributionKit không yêu cầu lời nhắc ủy quyền ATT; tuy nhiên, các luồng dữ liệu khác trong cùng một ứng dụng vẫn có thể cấu thành việc theo dõi và do đó yêu cầu ủy quyền ATT. AdAttributionKit hoạt động trong khuôn khổ quảng cáo đã ký của Apple với các mạng quảng cáo đủ điều kiện được đăng ký với các khung quy kết của Apple.

Tại sao quy kết dựa trên khay nhớ tạm không nên là chiến lược chính

Việc truyền tải qua khay nhớ tạm (clipboard) hoặc bảng dán nên được coi là cơ chế dự phòng ngoại lệ thay vì thiết kế quy kết chính. Quyền truy cập khay nhớ tạm giới thiệu các thông báo quyền riêng tư hiển thị với người dùng, các hạn chế của nền tảng và tính khả dụng không nhất quán giữa các phiên bản hệ điều hành. Khi lưu trữ bảng dán được đánh giá:

• Phạm vi rõ ràng: Payload phải có thời gian sống ngắn và giới hạn ở mức tối thiểu dữ liệu cụ thể của ứng dụng cần thiết cho luồng bên thứ nhất dự kiến. Các giá trị nhạy cảm phải được bảo vệ thích hợp khi đang truyền và khi lưu trữ.

• Dọn dẹp tức thì: Các ứng dụng phải nhanh chóng xóa hoặc ghi đè các token tham số tạm thời sau khi tiêu thụ trong chuỗi khởi chạy ban đầu.

• Tuân thủ chính sách: Chỉ sử dụng cơ chế bảng dán khi có luồng người dùng bên thứ nhất được xác định rõ ràng và tuân theo đánh giá chính sách nền tảng hiện hành.

Dự phòng duyên dáng và trạng thái chưa quy kết

Một kiến trúc bảo vệ quyền riêng tư có khả năng phục hồi không cố gắng ép buộc khớp quy kết thông qua kỹ thuật lấy dấu vân tay thiết bị xâm nhập:

• Deep Link / Universal Link trực tiếp: Kích hoạt ứng dụng gốc tức thì khi ứng dụng đã được cài đặt trên thiết bị.

• Truyền tham số qua cửa hàng: Truy xuất các tham số chiến dịch thông qua API nền tảng (như Google Play Install Referrer) khi khả dụng.

• Khôi phục tham số bên thứ nhất: Khớp các phiên cài đặt mới với các tương tác trang đích web hoạt động trong cửa sổ thời gian hẹp.

• Không có tín hiệu (Chưa quy kết): Khi điều kiện mạng thay đổi, phiên hết hạn hoặc không có ngữ cảnh khớp, ứng dụng sẽ xuống cấp an toàn về trạng thái mặc định sạch sẽ mà không làm gián đoạn trải nghiệm onboarding của người dùng.

Kịch bản triển khai mẫu: Khôi phục ngữ cảnh với OpoInstall

Để hiểu cách các thành phần này hoạt động trong môi trường sản xuất, hãy xem xét một ứng dụng trò chơi di động đa nền tảng thực hiện hai kênh thu hút đồng thời:

• Kênh A (Quảng cáo lập trình trả phí): Chiến dịch quảng cáo chạy trên các mạng quảng cáo bên ngoài chuyển hướng đến App Store và Google Play.

• Kênh B (Chia sẻ lan truyền của người dùng): Người chơi hiện tại chia sẻ liên kết mời tùy chỉnh (https://game.example.com/join?room=9876&inviter=usr_432) thông qua các ứng dụng nhắn tin xã hội.

*   

[Kênh A: Quảng cáo trả phí] ──> [Tải xuống qua cửa hàng] ──> [Play Referrer / AdAttributionKit] ──> [ROI quảng cáo tổng hợp]
[Kênh B: Mời]            ──> [Trang đích web]        ──> [Khôi phục token bên thứ nhất]        ──> [Tự động tham gia phòng game]

Khi người dùng mới cài đặt qua Kênh A, ứng dụng dựa vào API Google Play Install Referrer hoặc Apple AdAttributionKit để báo cáo hiệu suất chiến dịch cho bảng điều khiển tiếp thị. Khi người dùng cài đặt qua Kênh B, SDK định tuyến bên thứ nhất sẽ nắm bắt token lời mời động trong lần khởi chạy đầu tiên, ngay lập tức đưa người chơi mới vào phòng 9876 mà không cần truy vấn ID quảng cáo hoặc kích hoạt lời nhắc ATT.

Các trường hợp lỗi sản xuất phổ biến trong quy kết di động không dùng ID

Khi triển khai kiến trúc quy kết không dựa vào mã định danh quảng cáo cố định, các nhóm kỹ thuật thường gặp phải các chế độ lỗi vận hành cụ thể:

• Trường hợp lỗi 1: Tham số trang đích bị mất sau khi chuyển hướng cửa hàng: Nếu các liên kết chiến dịch chuyển hướng qua các trình rút gọn URL trung gian chưa được mã hóa, các tham số truy vấn như channelCode hoặc referrer có thể bị loại bỏ trước khi đến tập lệnh trang đích hoặc đích đến cửa hàng ứng dụng.

• Trường hợp lỗi 2: Đổi quà giới thiệu trùng lặp và thiếu khóa chống trùng lặp (Idempotency): Trong môi trường sản xuất, nếu máy khách di động gọi khôi phục tham số trên mọi sự kiện Activity.onResume hoặc nền trước ứng dụng mà không kiểm tra cờ lưu giữ cục bộ, người dùng có thể kích hoạt các yêu cầu phần thưởng trùng lặp hoặc điều hướng deep link lặp đi lặp lại.

• Trường hợp lỗi 3: Quản lý sai trạng thái cài đặt lại: Mặc dù Google Play Install Referrer lưu giữ dữ liệu referrer lịch sử trong tối đa 90 ngày, các ứng dụng được cài đặt lại có thể nhận được dữ liệu quy kết cũ từ vòng đời cài đặt trước đó trừ khi phần phụ trợ của máy khách xác thực xem tài khoản đã hoàn tất đăng ký hay chưa.

• Trường hợp lỗi 4: Lượt cài đặt hữu cơ bị phân loại nhầm thông qua cửa sổ khớp rộng: Nếu các cửa sổ khớp phiên phía máy chủ được cấu hình quá rộng trong môi trường có mạng chung hoặc mật độ người dùng cao, các lượt cài đặt hữu cơ có thể xung đột với các phiên nhấp chuột web không liên quan.

Mẫu tích hợp SDK minh họa để khôi phục ngữ cảnh cài đặt bên thứ nhất

Tổng quan về tích hợp phía máy khách

SDK khôi phục ngữ cảnh cài đặt bên thứ nhất có thể được sử dụng để thực hiện khôi phục tham số ngữ cảnh mà không cần ID Quảng cáo. Các nhóm phát triển có thể tải xuống các gói SDK di động OpoInstall và tài nguyên tích hợp.

Lưu ý API SDK: Vòng đời khởi tạo và truy xuất được hiển thị bên dưới là một triển khai giả mã minh họa. Tên API dưới đây mang tính chất minh họa cố ý và không nên được coi là tài liệu nhà供应商. Trong môi trường sản xuất, hãy ưu tiên việc khởi tạo cấp ứng dụng và vòng đời ngữ cảnh cài đặt được tài liệu hóa của SDK thay vì gắn kết việc truy xuất quy kết trực tiếp với vòng đời Activity cá nhân. Xác minh tất cả các lớp, tên phương thức, loại lệnh gọi lại và khóa cấu hình dựa trên tài liệu hiện tại của nhà cung cấp trước khi sử dụng trong môi trường sản xuất.

// Triển khai Android: Trích xuất tham số không dùng ID (Mẫu kiến trúc)
// Vị trí trong Phần A: [CODE_BLOCK_01]
// Lưu ý: Triển khai giả mã minh họa dựa trên các hợp đồng SDK OpoInstall.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Trích đoạn mẫu)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Cấu hình khóa ứng dụng bằng phương thức được chỉ định trong tài liệu nhà cung cấp -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt: Vòng đời máy trạng thái cấp ứng dụng
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Khởi tạo SDK định tuyến bên thứ nhất trong tiến trình chính
        OpoInstall.initialize(this)

        // Truy xuất ngữ cảnh cài đặt một lần ở tầng ứng dụng
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Đã khôi phục ngữ cảnh: Channel=$channelCode, Data=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // Nếu xảy ra lỗi mạng tạm thời, trạng thái có thể giữ nguyên khả năng thử lại hoặc dự phòng sạch sẽ
                Log.w("InstallContext", "Truy vấn quy kết hoàn tất với trạng thái: ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Phân phối ngữ cảnh đã khôi phục tới các dịch vụ tài khoản/định tuyến nội bộ
    }
}

Triển khai trên iOS: Tích hợp vòng đời Swift

Trên iOS, ứng dụng tích hợp SDK trong ủy quyền vòng đời ứng dụng. SDK truy xuất các tham số cài đặt không đồng bộ trên luồng thực thi chính mà không gọi các yêu cầu ủy quyền AppTrackingTransparency khi việc theo dõi chéo ứng dụng không được thực hiện.

Việc triển khai Swift dưới đây chứng minh quy trình khởi tạo và trích xuất tham số minh họa:

// Mẫu tích hợp iOS: Truy xuất ngữ cảnh cài đặt cấp ứng dụng
// Vị trí trong Phần A: [CODE_BLOCK_02]
// Lưu ý: CHỈ LÀ GIẢ MÃ. Tên loại và phương thức là các trình giữ chỗ minh họa.

// ----------------------------------------------------------------------------
// 1. Info.plist (Trích đoạn mẫu)
// ----------------------------------------------------------------------------
/*
<!-- Cấu hình khóa ứng dụng bằng phương thức được chỉ định trong tài liệu nhà cung cấp -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift: Khởi tạo vòng đời và truy xuất ngữ cảnh
// ----------------------------------------------------------------------------
import UIKit
// Lưu ý: Đã cố ý bỏ qua việc nhập mô-đun SDK; hãy sử dụng tên mô-đun do trình quản lý gói của bạn cung cấp.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Khởi tạo SDK định tuyến bên thứ nhất mà không gọi ủy quyền ATT
        OpoInstallSDK.initWith(self)

        // Bảo vệ việc truy xuất bằng kiểm tra máy trạng thái tại điểm nhập ứng dụng
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Truy xuất các tham số cài đặt hoãn lại không đồng bộ
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Phân phối ngữ cảnh đã khôi phục tới các dịch vụ tài khoản/định tuyến nội bộ
    }

    // Gọi lại ủy quyền Universal Link cho deep linking
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

Cân nhắc kỹ thuật cho việc triển khai máy khách

• Vòng đời giao diện không chặn (Non-Blocking): Luôn khởi tạo SDK quy kết không đồng bộ và truy vấn các tham số mà không chặn luồng giao diện chính trong quá trình khởi chạy ứng dụng.

• Xử lý tính độc lập cục bộ (Idempotency): Duy trì một máy trạng thái hoặc cờ lưu giữ (ví dụ: NOT_STARTED, FETCHING, PROCESSED) để quản lý việc trích xuất tham số sạch sẽ và ngăn chặn các truy vấn API dư thừa.

• Bảo vệ phát lại phía máy chủ (Replay Defense): Xác thực các payload tham số động đối với nhật ký giao dịch phía phụ trợ để đảm bảo mã giới thiệu hoặc token khuyến mại không thể bị phát lại một cách độc hại.

API quy kết nền tảng và quá trình chuyển đổi Privacy Sandbox

Quy kết nền tảng Android và quá trình chuyển đổi Privacy Sandbox

API Báo cáo quy kết của Android được thiết kế để hỗ trợ đo lường bảo vệ quyền riêng tư trên các ứng dụng và web mà không dựa vào mã định danh chéo bên.

API Báo cáo quy kết của Android khả dụng cho các tích hợp Privacy Sandbox được hỗ trợ, nhưng chúng không phải là sự thay thế phổ quát cho Install Referrer hoặc tích hợp MMP. Khả năng áp dụng trong môi trường sản xuất phụ thuộc vào phiên bản Android cụ thể, tích hợp công nghệ quảng cáo, các yêu cầu đăng ký và hỗ trợ hệ sinh thái. Các nhóm nên xác minh tài liệu Android Privacy Sandbox hiện tại trước khi biến Báo cáo quy kết thành phụ thuộc sản xuất.

Đối với các ứng dụng Android phân phối qua Play, Google Play Install Referrer vẫn là một cơ chế bên thứ nhất thiết thực để truy xuất các tham số chiến dịch liên quan đến việc cài đặt trên Play Store. Các mạng quảng cáo và nhà cung cấp quy kết cũng có thể cung cấp các tích hợp đo lường được nền tảng hỗ trợ.

Quy kết nền tảng Apple: AdAttributionKit và SKAdNetwork

Trên iOS, Apple cung cấp các cơ chế quy kết bảo vệ quyền riêng tư tập trung vào AdAttributionKit, hỗ trợ các chiến dịch quảng cáo ứng dụng trên App Store và các chợ ứng dụng thay thế, bên cạnh khả năng tương tác với SKAdNetwork. Các framework này cung cấp các tín hiệu quy kết do nền tảng trung gian cung cấp mà không làm lộ mã định danh quảng cáo thiết bị cố định. Mức độ chi tiết và thời gian báo cáo tiếp tục được quản lý bởi ngưỡng quyền riêng tư và cửa sổ quy kết của Apple.

Sự cùng tồn tại của định tuyến bên thứ nhất và API nền tảng

API quyền riêng tư của nền tảng và định tuyến ngữ cảnh bên thứ nhất giải quyết các yêu cầu kỹ thuật khác nhau:

• API quyền riêng tư của nền tảng: Được thiết kế để đo lường quảng cáo cấp vĩ mô, tính toán ROI mạng quảng cáo và tối ưu hóa chiến dịch lập trình mà không cần mã định danh cố định.

• Định tuyến tham số bên thứ nhất: Được thiết kế cho onboarding ứng dụng cấp vi mô, liên kết phần thưởng giới thiệu giữa người dùng với người dùng tức thì, định tuyến deep link và hành trình chuyển đổi từ web sang ứng dụng trực tiếp.

Cách xác thực độ chính xác của quy kết trong môi trường Sandbox

Kiểm tra quy kết cài đặt khi không có quyền truy cập ID quảng cáo

Để xác minh rằng ứng dụng xử lý chính xác quy kết cài đặt trên các trạng thái thiết bị và quyền đa dạng:

• Trạng thái thiếu AD_ID: Triển khai bản dựng thử nghiệm Android loại trừ quyền com.google.android.gms.permission.AD_ID khỏi AndroidManifest.xml và xác minh rằng ứng dụng khởi tạo sạch sẽ.

• Hạn chế mã định danh người dùng: Trên thiết bị thử nghiệm Android có dịch vụ Google Play, hãy bật giới hạn quảng cáo hoặc xóa ID quảng cáo trong cài đặt hệ thống để đảm bảo việc trích xuất tham số không bị sự cố hoặc đình trệ.

• Mô phỏng chiến dịch Play Store: Kích hoạt hành trình cài đặt bằng URL chiến dịch thử nghiệm truyền rõ ràng giá trị dự kiến thông qua cơ chế Google Play Install Referrer. Không giả định rằng tham số truy vấn trang đích tùy ý sẽ tự động trở thành giá trị Install Referrer.

• Xác minh cài đặt lại: Cài đặt lại ứng dụng sau khi cài đặt được quy kết trước đó và xác minh rằng luồng quy kết không tái sử dụng sai trạng thái cài đặt đầu tiên cũ.

• Xác minh dự phòng hữu cơ: Khởi chạy bản dựng không liên kết để xác nhận rằng getInstallParam giải quyết gọn gàng về null hoặc dự phòng hữu cơ mà không bị treo.

Mô phỏng trạng thái bị từ chối ATT trên thiết bị iOS vật lý

Để kiểm tra việc truy xuất tham số iOS khi việc theo dõi bị từ chối:

• Cài đặt bản dựng thử nghiệm trên thiết bị iOS vật lý thông qua Xcode.

• Xác minh rằng phương thức truy xuất tham số SDK thực thi không đồng bộ và giải quyết các tham số thành công mà không nhắc nhở ATT hoặc truy vấn API IDFA.

• Kiểm tra hành vi khởi chạy ứng dụng trên cả chu kỳ khởi động lạnh (cold start) và đánh thức nền.

Kiểm tra payload mạng để giảm thiểu dữ liệu

Các nhóm bảo mật và tuân thủ nên kiểm tra lưu lượng mạng phía máy khách bằng cách sử dụng proxy HTTP:

• Xác nhận loại trừ ID: Xác minh rằng các yêu cầu quy kết gửi đi không bao gồm các mã định danh cố định như IMEI, địa chỉ MAC, Android ID (SSAID) hoặc chuỗi IDFA không được ủy quyền.

• Bảo mật truyền tải: Đảm bảo giao tiếp API quy kết sử dụng HTTPS với các cấu hình TLS hiện đại và xác thực chứng chỉ tiêu chuẩn.

• Bảo vệ payload: Xác nhận rằng các token động được lưu trữ khi đang truyền hoặc trong bộ đệm tạm thời sử dụng các tiêu chuẩn bảo vệ phù hợp.

Xây dựng cơ sở hạ tầng quy kết không dùng ID với OpoInstall

Các nhóm kỹ thuật đánh giá ngăn xếp tăng trưởng độc lập với ID quảng cáo yêu cầu ba năng lực kỹ thuật cốt lõi:

1. Khôi phục ngữ cảnh mượt mà: Truyền siêu dữ liệu tùy chỉnh từ trang đích web sang ứng dụng gốc mà không cần mã giới thiệu thủ công hoặc thu thập phần cứng.

2. Quản lý bối cảnh chiến dịch đa nền tảng: Quản lý các chiến dịch web-sang-ứng dụng và di động trên các nền tảng mà không yêu cầu nhiều bản dựng ứng dụng.

3. Tuân thủ nghiêm ngặt nền tảng: Hoạt động hoàn toàn trong các hộp cát ứng dụng bên thứ nhất và tôn trọng các ràng buộc về quyền riêng tư của hệ điều hành.

Để khám phá các mẫu triển khai cho việc đo lường và định tuyến di động, hãy tham khảo tài liệu OpoInstall hoặc truy cập bảng điều khiển nhà phát triển OpoInstall.

Tóm tắt và Khung quyết định

Để xây dựng kiến trúc tăng trưởng di động bền vững giữa bối cảnh các hạn chế về mã định danh quảng cáo ngày càng gia tăng, các nhóm kỹ thuật phải chuyển đổi khỏi sự phụ thuộc vào GAID và IDFA cũ. Việc dựa vào mã định danh thiết bị cố định giới thiệu tính mong manh về cấu trúc khi hệ điều hành và chính sách quản regulatory tiếp tục hạn chế việc theo dõi chéo ứng dụng.

Một framework quy kết hiện đại kết hợp việc truyền tham số bên thứ nhất, API đo lường do nền tảng trung gian cung cấp và việc trích xuất SDK phía máy khách có khả năng phục hồi. Bằng cách triển khai kiến trúc định tuyến ngữ cảnh, các nhóm di động duy trì hành trình chuyển đổi từ web sang ứng dụng đáng tin cậy trong khi vẫn tuân thủ các yêu cầu về quyền riêng tư của nền tảng.

Tài liệu liên quan

• Khái niệm: Hạn chế ID quảng cáo, Định tuyến tham số ngữ cảnh, Install Referrer, AdAttributionKit, Minh bạch theo dõi ứng dụng

• Công nghệ: API Google Play Install Referrer, API quảng cáo dịch vụ Google Play, Khung Apple ATT, Apple AdAttributionKit, SDK di động OpoInstall

• Chủ đề bảo mật: Giảm thiểu dữ liệu di động, bảo vệ phát lại, bảo mật truyền tải

• API: API Google Play Install Referrer, API ID quảng cáo Google, API Minh bạch theo dõi ứng dụng của Apple, API tham số cài đặt OpoInstall

Tài liệu chính thức

Android

• Tài liệu ID quảng cáo dịch vụ Google Play

• Thay đổi hành vi Android 13 đối với ID quảng cáo

• Hướng dẫn API Google Play Install Referrer

Apple

• Tài liệu nhà phát triển Apple về Minh bạch theo dõi ứng dụng

• Tài liệu nhà phát triển Apple về AdAttributionKit

• Tài liệu nhà phát triển Apple về quy kết quảng cáo

• Hiểu về khả năng tương tác giữa AdAttributionKit và SKAdNetwork

Quy kết bảo vệ quyền riêng tư

• Tổng quan về Google Privacy Sandbox