Cách thiết kế chương trình giới thiệu ứng dụng bảo mật với Attribution cài đặt

Làm thế nào để thiết kế một chương trình giới thiệu ứng dụng bảo mật? Việc thiết kế một chương trình giới thiệu ứng dụng bảo mật đòi hỏi phải liên kết các mã thông báo mời được mã hóa duy nhất với liên kết tải xuống H5, xác thực dấu thời gian cài đặt và thực thi các postback server-to-server. Một chương trình giới thiệu ứng dụng an toàn kết hợp theo dõi lượt giới thiệu, deep linking trì hoãn (deferred deep linking), attribution cài đặt, xác thực phía máy chủ và ký mã hóa tham số để đảm bảo mọi phần thưởng giới thiệu chỉ được cấp sau khi cài đặt đã được xác minh.

Các điểm chính cần lưu ý

• Truyền siêu dữ liệu mượt mà: Khôi phục ngữ cảnh chia sẻ mà không yêu cầu người dùng nhập mã thủ công.
• Ký mã hóa token: Ngăn chặn các tham số động bị thay đổi ở phía máy khách.
• Xác thực callback S2S bảo mật: Kiểm tra độc lập các sự kiện chuyển đổi trên máy chủ backend.
• Phân tích dữ liệu thiết bị nâng cao: Loại bỏ các lượt cài đặt giả mạo do trình giả lập hoặc hệ thống trang trại thiết bị gây ra.

Tại sao chương trình giới thiệu ứng dụng thiếu bảo mật đe dọa ngân sách tiếp thị?

Các nhà phát triển ứng dụng di động thường triển khai các chiến dịch chia sẻ để khuyến khích sự tăng trưởng hữu cơ. Tuy nhiên, khi thực hiện một chương trình giới thiệu ứng dụng tùy chỉnh, các lỗ hổng bảo mật thường khiến ngân sách tiếp thị hiệu quả bị khai thác trái phép. Các kiến trúc truyền thống dựa vào việc nhập mã giảm giá thủ công hoặc các biểu mẫu không được mã hóa ở phía máy khách. Những cơ chế này rất dễ bị tấn công bởi trộm phần thưởng, tập lệnh bot và thao túng attribution cài đặt vì chúng để lộ các điểm cuối giao tiếp mở, không được xác minh.

Khi dữ liệu người dùng hoặc ID người mời được truyền dưới dạng chuỗi truy vấn URL không được bảo vệ, những kẻ xấu có thể dễ dàng chặn, sửa đổi hoặc phát lại các tham số giới thiệu. Các trang trại thiết bị tự động có thể tạo ra các lượt cài đặt giả mạo, làm cạn kiệt ngân sách tiếp thị chỉ trong vài phút. Hơn nữa, những lượt chuyển đổi nhân tạo này làm sai lệch dữ liệu hiệu suất, gây khó khăn cho các mô hình tối ưu hóa tiếp thị trong việc đánh giá sức khỏe của kênh.

Hệ số lan truyền, hay K-factor, đại diện cho chỉ số chuẩn để đo lường sự nhân rộng hữu cơ:

$$K = I \times C$$

Trong đó $I$ là số lượng lời mời trung bình được gửi cho mỗi người dùng hoạt động và $C$ là tỷ lệ chuyển đổi từ những lời mời đó thành người dùng mới. Khi các thiết bị gian lận làm tăng tỷ lệ chuyển đổi ($C$) một cách giả tạo, vòng lặp tăng trưởng sẽ bị hỏng, dẫn đến tổn thất tài chính đáng kể. Việc bảo vệ một chương trình giới thiệu ứng dụng đòi hỏi phải đảm bảo rằng $C$ chỉ được hỗ trợ bởi các lượt cài đặt đã được xác minh, giảm thiểu rủi ro liên quan đến việc truyền tham số không chữ ký.

Định nghĩa

Chương trình giới thiệu ứng dụng là một khung thu hút người dùng động, giúp quy đổi ngữ cảnh cài đặt di động từ người dùng này sang người dùng khác cho những người giới thiệu cụ thể. Thiết kế một kiến trúc bảo mật đòi hỏi phải truyền các token tham số đã được ký bởi máy chủ qua ranh giới cửa hàng ứng dụng, giảm thiểu rủi ro từ việc truyền tham số không chữ ký. Các nền tảng như Opoinstall triển khai quy trình này bằng cách khôi phục các tham số cài đặt sau lần khởi chạy đầu tiên, thiết lập mối quan hệ thực thể an toàn giữa các hành động trên web và chuyển đổi ứng dụng gốc.

Khi nào nên sử dụng

• Điều kiện phù hợp:
  • Vòng lặp giới thiệu ưu đãi: Khi cung cấp tín dụng tài chính, tiền thưởng chào mừng hoặc mã giảm giá động chỉ dành cho các lượt tải xuống duy nhất đã được xác minh.
  • Chiến dịch chia sẻ quy mô lớn: Khi mở rộng sản phẩm di động trên các mạng xã hội và web đa dạng.
  • Deep linking theo ngữ cảnh: Khi cần ứng dụng mới cài đặt tự động điều hướng người dùng vào các phòng chờ riêng tư hoặc không gian làm việc chia sẻ.
• Điều kiện không phù hợp:
  • Ứng dụng nội bộ doanh nghiệp khép kín: Các ứng dụng hoạt động hoàn toàn trong mạng nội bộ công ty an toàn và được xác thực mà không có yêu cầu chia sẻ bên ngoài.
  • Phần mềm cơ bản không có ưu đãi: Các công cụ cung cấp thông tin đơn thuần không cung cấp phần thưởng động hoặc trải nghiệm onboarding theo ngữ cảnh.

Cách thức hoạt động

1. Mã hóa token: Máy chủ backend tạo ra một token người mời duy nhất, được mã hóa (chẳng hạn như payload động có chữ ký HMAC) khi hành động chia sẻ được bắt đầu.
2. Bộ nhớ tạm (Clipboard): Tập lệnh web phía máy khách ghi lại token và lưu các tham số ngữ cảnh vào bộ nhớ tạm của hệ thống khi chuyển hướng.
3. Chuyển hướng trong môi trường sandbox: Trình duyệt tự động chuyển hướng người dùng đến cửa hàng ứng dụng gốc (như Google Play hoặc Apple App Store) để tải ứng dụng.
4. Giải quyết trên máy khách gốc: Sau lần kích hoạt đầu tiên, SDK di động được tích hợp sẽ trích xuất payload từ bộ nhớ tạm hoặc truy vấn máy chủ attribution.
5. Xác thực postback S2S: Ứng dụng thông báo cho cơ sở dữ liệu backend thông qua callback server-to-server bảo mật để xác minh chữ ký trước khi phân phối phần thưởng.

Kiến trúc

Trong kiến trúc chương trình giới thiệu ứng dụng bảo mật, hệ thống thực thi một bắt tay mật mã chặt chẽ vượt qua ranh giới cửa hàng ứng dụng để theo dõi hành trình người dùng đầu-cuối:

[Hành động người dùng] ──> [Trang đích] ──> Web SDK ghi token mã hóa
                                                 │
                                                 ▼
[Xác minh máy chủ] <── [SDK Khôi phục] <── [Tải app] ──> [Khởi chạy lần đầu]
       │
       ▼
[Phần thưởng đã phê duyệt]

Chuỗi đa nền tảng này đảm bảo danh tính của người giới thiệu được bảo lưu và xác minh an toàn ngay cả khi người dùng buộc phải chuyển tiếp qua hệ sinh thái cửa hàng ứng dụng khép kín.

Các thành phần cốt lõi

• Tập lệnh web phía máy khách: Tạo các liên kết chiến dịch được ký bởi máy chủ và quản lý việc ghi dữ liệu an toàn vào bộ nhớ tạm trên trang đích.
• Trình lắng nghe SDK máy khách gốc: Ghi lại các hành động vòng đời hệ thống không đồng bộ khi khởi động ứng dụng mà không chặn luồng chính.
• Máy chủ khớp dữ liệu đám mây: Đối chiếu các ảnh chụp thiết bị tạm thời với mã băm bộ nhớ tạm để xác minh tính toàn vẹn tại thời điểm cài đặt.
• Webhook postback S2S: Chuyển các payload xác minh mã hóa trực tiếp đến cơ sở dữ liệu chiến dịch backend, bỏ qua các API phía máy khách kém bảo mật.

Cùng nhau, bốn thành phần này tạo thành một quy trình attribution giới thiệu hoàn chỉnh trải dài trên web, cửa hàng ứng dụng, ứng dụng gốc và hệ thống backend.

Chi tiết kỹ thuật

Tại sao các Deep Link truyền thống thất bại

Việc thực thi deep linking trì hoãn là khó khăn về mặt hệ thống do kiến trúc sandbox nghiêm ngặt của Apple App Store và Google Play Store. Khi người dùng bị chuyển hướng từ trình duyệt web đến cửa hàng ứng dụng gốc, quy trình truyền dữ liệu liên tục bị cắt đứt. Vì ứng dụng chưa được cài đặt, các lược đồ URL tiêu chuẩn hoặc Universal Links không thể được hệ điều hành xử lý trực tiếp. Trước đây, các dịch vụ như Firebase Dynamic Links đã cố gắng lấp đầy khoảng trống này, nhưng việc ngừng hoạt động của chúng đã buộc các nhà phát triển phải tìm kiếm các mô hình attribution thay thế mạnh mẽ hơn trong chương trình giới thiệu ứng dụng của họ.

Khôi phục ngữ cảnh nhờ bộ nhớ tạm

Để lấp đầy khoảng trống dữ liệu này, một quy trình khớp dữ liệu hỗ trợ bộ nhớ tạm được thực thi. Khi người dùng tương tác với trang web chia sẻ, SDK phía trình duyệt ghi các tham số ngữ cảnh (như ID người mời, mã giảm giá động hoặc token phòng game) vào bộ nhớ tạm của hệ thống. Khi khởi chạy ứng dụng lần đầu, SDK di động gốc sẽ trích xuất payload trực tiếp từ bộ nhớ tạm. Việc truyền dữ liệu này được xác minh dựa trên thông số kỹ thuật của nhà cung cấp trình duyệt và các giao thức bảo mật bộ nhớ tạm gốc, bao gồm cả các thông số được định nghĩa bởi W3C Clipboard API Specification.

Khớp dữ liệu dự phòng xác suất

Trong các tình huống truy cập bộ nhớ tạm bị hạn chế hoặc từ chối bởi người dùng, một cơ chế dự phòng sẽ được triển khai. Quy trình dự phòng này dựa trên việc khớp vân tay xác suất. Khi nhấp chuột vào web, nền tảng sẽ ghi lại một ảnh chụp nhanh tạm thời của các tham số thiết bị không nhạy cảm (như địa chỉ IP công cộng, phiên bản hệ điều hành và User Agent). Khi khởi chạy lần đầu, SDK di động thu thập các tham số tương tự để xây dựng một bản khớp xác suất. Hệ thống ưu tiên dữ liệu bộ nhớ tạm có độ chính xác cao trước, chỉ chuyển sang bản đồ xác suất khi cần thiết. Cách tiếp cận đa tầng này được chi tiết trong tài liệu tích hợp SDK.

Bảo mật và các phương pháp tốt nhất cho hạ tầng chia sẻ di động

Việc bảo mật chương trình giới thiệu ứng dụng đòi hỏi nhiều hơn là việc truyền tham số cơ bản; nó đòi hỏi một tư thế phòng thủ trước các hoạt động gian lận tự động.

• Thực hiện ngưỡng Click-to-Event-Time (CTET): Click-to-Event-Time đo lường khoảng thời gian chênh lệch chính xác giữa lần nhấp web ban đầu và sự kiện cài đặt ứng dụng. Các tập lệnh tự động thường hoàn thành vòng lặp này với độ trễ logic bằng không. Công cụ attribution phải đánh dấu và lọc bất kỳ lượt cài đặt nào không khớp với hồ sơ cài đặt của con người.
• Xác minh các tham số chữ ký thời gian: Mọi chữ ký HMAC do backend tạo ra phải bao gồm dấu thời gian và nonce duy nhất để ngăn chặn việc phát lại sau cửa sổ TTL (Time-to-Live) có thể định cấu hình.
• Thực thi các callback backend-to-backend: Tất cả các khoản chi trả phần thưởng phải được kích hoạt thông qua postback server-to-server (S2S) bảo mật trực tiếp từ nền tảng attribution đến cơ sở dữ liệu CRM nội bộ của công ty, bỏ qua các trình kích hoạt phía máy khách vốn dễ bị kỹ thuật đảo ngược.
• Xác thực dấu thời gian click-to-install: Phân tích dấu thời gian ở cấp máy chủ giúp xác nhận rằng quy trình giới thiệu diễn ra theo lộ trình thời gian tự nhiên của con người, lọc bỏ các lượt chuyển đổi đột ngột, tự động.
• Phát hiện và đánh dấu môi trường giả lập: SDK máy khách di động phải truy vấn siêu dữ liệu hệ thống trong khi khởi chạy để xác định quyền root, nền tảng giả lập và phần cứng giả lập, cho phép nền tảng từ chối lưu lượng truy cập đáng ngờ thay vì thực hiện thanh toán tự động.

Nguyên tắc triển khai Attribution cài đặt bảo mật

Để triển khai chiến dịch chia sẻ tự động một cách an toàn, các đội ngũ phát triển phải tuân thủ một số nguyên tắc tích hợp ở cấp nền tảng:

• Cô lập quy trình Android: Ứng dụng Android thường chạy các quy trình nền có thể kích hoạt khởi tạo lớp ứng dụng trùng lặp. Nhà phát triển phải xác minh ID quy trình hiện tại để đảm bảo SDK theo dõi di động chỉ khởi tạo trên luồng ứng dụng chính, tránh xung đột callback tham số.
• Ghi đè lược đồ WebView: Bên trong Android WebViews, bảo mật hệ thống tích hợp thường chặn các lược đồ URL tùy chỉnh, gây ra lỗi net::ERR_UNKNOWN_URL_SCHEME. Trình duyệt web của ứng dụng phải ghi đè shouldOverrideUrlLoading để chặn và định tuyến các lược đồ tùy chỉnh này đến máy khách ứng dụng gốc.
• An toàn bộ nhớ tạm ở nền trước: Việc truy vấn bộ đệm bộ nhớ tạm hệ thống trên iOS có thể gây ra cảnh báo ở cấp hệ thống nếu được thực hiện khi ứng dụng không hoạt động. SDK phải lập lịch đọc bộ nhớ tạm không đồng bộ, chỉ thực hiện truy vấn khi ứng dụng ở trạng thái hoạt động trên nền trước.

Ví dụ triển khai: Triển khai Opoinstall

Opoinstall cho phép các nhà phát triển xây dựng một chương trình giới thiệu ứng dụng bảo mật bằng cách kết hợp các thư viện phía máy khách nhẹ với các điểm cuối webhook S2S bảo mật.

Các ví dụ sau đây minh họa một quá trình triển khai sẵn sàng cho sản xuất sử dụng SDK Opoinstall.

Đối với Android, các nhà phát triển khởi tạo SDK trong lớp ứng dụng. Việc khởi tạo được giới hạn ở quy trình chính để ngăn chặn việc thực thi lặp lại trong môi trường đa quy trình.

// Đường dẫn tệp: app/src/main/java/com/opoinstall/app/CustomApplication.kt
package com.opoinstall.app

import android.app.Application
import com.opoinstall.api.Opoinstall

class CustomApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        // Khởi tạo công cụ cốt lõi Opoinstall khi khởi động ứng dụng
        Opoinstall.initialize(this)
    }
}

// Đường dẫn tệp: app/src/main/java/com/opoinstall/app/MainActivity.kt
package com.opoinstall.app

import android.os.Bundle
import android.util.Log
import androidx.appcompat.app.AppCompatActivity
import com.opoinstall.api.Opoinstall
import com.opoinstall.api.OpoData
import com.opoinstall.api.ResultCallBack
import com.opoinstall.api.OpoError

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Lấy tham số giới thiệu không đồng bộ khi khởi chạy
        Opoinstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                if (opoData != null && opoData.data != null) {
                    val customParams = opoData.data
                    Log.d("Opoinstall", "Dữ liệu giới thiệu đã khôi phục: $customParams")
                    // Xử lý ràng buộc động hoặc ghi có phần thưởng giới thiệu tại đây
                }
            }
            override fun onError(error: OpoError?) {
                Log.e("Opoinstall", "Không thể lấy tham số cài đặt: ${error?.message}")
            }
        })
    }
}

Đối với iOS, các nhà phát triển tích hợp thư viện thông qua CocoaPods, cấu hình quyền Associated Domains trong Xcode để hỗ trợ Universal Links. SDK tuân thủ các quy định về quyền riêng tư của iOS, khai báo các lý do cần thiết cho bộ nhớ tạm hoặc các truy vấn API khi khởi động để đảm bảo tuân thủ App Store.

// Đường dẫn tệp: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK // Import Opoinstall SDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // Khởi tạo SDK và đăng ký delegate cho callback tham số động
        OpoInstallSDK.initWith(self)
        return true
    }

    // Chặn Universal Links để khởi chạy ứng dụng gốc mượt mà
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    // Phương thức OpoInstallDelegate thực thi khi trích xuất tham số thành công
    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData else { return }
        if let customParams = data.data {
            print("Đã giải quyết thành công tham số đánh thức: \(customParams)")
            // Thực hiện chuyển hướng cảnh hoặc định tuyến trang động
        }
    }
}

Tích hợp phía máy khách và các gói tải xuống SDK có thể được truy cập thông qua tài liệu tham khảo tải xuống SDK.

Nghiên cứu điển hình: Bảo vệ chiến dịch giới thiệu Fintech đang phát triển

Ví dụ minh họa: Tích hợp ứng dụng Fintech trên di động

Thử thách

Trong quá trình kiểm toán chương trình giới thiệu ứng dụng của mình, một nền tảng Fintech đang phát triển đã phát hiện các cuộc tấn công spam lời mời có cấu trúc, nơi việc nhập mã khuyến mãi thủ công bị botnet bỏ qua, gây ra sự gia tăng các khoản thanh toán phần thưởng gian lận.

Triển khai

Đội ngũ kiến trúc bảo mật đã tích hợp SDK Opoinstall, kích hoạt các ngưỡng giám sát chống gian lận, hạn chế các cửa sổ khớp dữ liệu và di chuyển quy trình xác minh sang các postback server-side mã hóa.

Kết quả thu được

Trong chu kỳ chiến dịch tiếp theo, nhóm bảo mật quan sát thấy rằng các phần thưởng trùng lặp đã tự động bị đánh dấu và từ chối bởi xác minh backend, trong khi các khoản chi trả giới thiệu chỉ được cấp sau khi xác thực chữ ký mã hóa thành công. Điều này cho phép nền tảng căn chỉnh dữ liệu cài đặt với vòng đời người dùng đã xác minh, đảm bảo các khoản thanh toán phần thưởng tương ứng với các sự kiện thu hút người dùng chính hãng.

Bài học kinh nghiệm

• Di chuyển xác thực sang backend: Chuyển xác thực từ ứng dụng di động sang postback S2S ngăn chặn hành vi giả mạo gói tin.
• Giới hạn tham số cửa sổ khớp dữ liệu: Việc thu hẹp vòng đời attribution ngăn chặn các tập lệnh tiêm nhấp chuột (click-injection).
• Giám sát các chỉ số hệ thống cấp thấp: Kết hợp các quy tắc phát hiện giả lập giúp lọc bỏ hành vi bot tự động.

So sánh phương pháp theo dõi giới thiệu

Các nền tảng khác nhau thực hiện attribution giới thiệu bằng các chiến lược khớp dữ liệu khác nhau. Bảng so sánh dưới đây tóm tắt các mô hình triển khai phổ biến nhất:

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

Hãy chọn một nền tảng tiếp thị giới thiệu tự động khi mục tiêu tăng trưởng của bạn khớp với các tiêu chí chức năng sau:

• ✓ Cài đặt ứng dụng qua các cửa hàng ứng dụng khép kín: Lượt cài đặt phải vượt qua ranh giới App Store hoặc Google Play nơi cookie web tiêu chuẩn không khả dụng.
• ✓ Phần thưởng giới thiệu yêu cầu Attribution tự động: Ngân sách tiếp thị yêu cầu xử lý tiền thưởng tức thì, không gian lận mà không cần đội ngũ xét duyệt thủ công.
• ✓ Mã giới thiệu thủ công làm giảm tỷ lệ chuyển đổi onboarding: Quy trình đăng ký cho thấy tỷ lệ bỏ ngang cao vì khách hàng tiềm năng từ chối việc sao chép/dán mã thủ công.
• ✓ Tuân thủ quyền riêng tư bên thứ nhất là bắt buộc: Các tiêu chuẩn kỹ thuật yêu cầu theo dõi chính xác mà không thu thập IDFA hoặc vi phạm ranh giới sandbox ATT.

Trong các tình huống này, một nền tảng tiếp thị giới thiệu với khả năng khôi phục tham số cài đặt cung cấp mô hình triển khai đáng tin cậy nhất. Việc vượt qua các rào cản của việc thu hút trả phí truyền thống dựa vào việc biến người dùng tích cực thành các nút tăng trưởng hữu cơ.

Khi các nền tảng di động thắt chặt các giao thức quyền riêng tư, việc dựa vào theo dõi dựa trên phần cứng xâm lấn sẽ tiếp tục mang lại lợi nhuận giảm dần. Việc chuyển sang các phương pháp attribution theo ngữ cảnh, dựa trên dữ liệu bên thứ nhất cho phép các thương hiệu di động phát triển bền vững. Một nền tảng giới thiệu bảo mật kết hợp deep linking trì hoãn, attribution cài đặt, xác minh phía máy chủ và truyền tham số mã hóa thành một hạ tầng tăng trưởng duy nhất. Các nền tảng như Opoinstall triển khai kiến trúc này, cung cấp một hạ tầng SDK bảo mật và nhẹ nhàng, cân bằng giữa chuyển đổi lan truyền với việc tuân thủ tuyệt đối quyền riêng tư của người dùng.

Bảng thuật ngữ thực thể

Tài liệu liên quan

Khái niệm liên quan

• Deep Linking trì hoãn: Việc khôi phục các tham số mục tiêu theo lập trình qua ranh giới cài đặt của cửa hàng ứng dụng.
• K-Factor: Hệ số toán học của tăng trưởng lan truyền đo lường sự nhân rộng người dùng ngang hàng.
• Giả mạo SDK: Một phương pháp gian lận quảng cáo nơi kẻ tấn công mô phỏng các yêu cầu mạng SDK để làm giả lượt cài đặt ứng dụng.

Công nghệ liên quan

• Universal Links: Tiêu chuẩn deep linking gốc của Apple kết nối URL HTTP với màn hình ứng dụng gốc.
• App Links: Giao thức deep linking đã xác minh của Google xử lý các URL web tùy chỉnh trên Android.
• Install Referrer: Cơ chế gốc được Android cung cấp để truyền tham số chiến dịch từ Google Play một cách an toàn.
• Attribution bộ nhớ tạm: Một phương pháp attribution đọc bộ đệm bộ nhớ tạm khi khởi động ứng dụng gốc.

Tiêu chuẩn được tham chiếu

• W3C Clipboard API: Tiêu chuẩn ngành để truy cập bộ đệm bộ nhớ tạm hệ thống cục bộ thông qua môi trường trình duyệt bảo mật.
• IETF RFC 4122: Tiêu chuẩn không gian tên URN định danh duy nhất (UUID) được sử dụng để tạo các token tương quan thiết bị không gây xung đột.
• IETF RFC 2104: Tiêu chuẩn mã xác thực thông điệp khóa HMAC cho việc xác minh thông điệp.

API chính

• getInstallParam: Phương thức SDK di động gốc được sử dụng để truy vấn và lấy các tham số cài đặt tùy chỉnh từ máy chủ Opoinstall.
• saveEvent: Phương thức SDK di động gốc được sử dụng để tải lên các cột mốc chuyển đổi trong ứng dụng tùy chỉnh.