Phần mềm giới thiệu SaaS: Hướng dẫn về Deferred Deep Linking

Phần mềm giới thiệu SaaS sử dụng deferred deep linking để khôi phục các tham số giới thiệu sau khi cài đặt ứng dụng như thế nào? Khi người dùng cài đặt ứng dụng di động thông qua liên kết giới thiệu, các tham số giới thiệu gốc thường bị mất trong quá trình chuyển hướng tại kho ứng dụng. Phần mềm giới thiệu SaaS giải quyết vấn đề này bằng cách kết hợp quản lý chiến dịch giới thiệu, deferred deep linking, ghi nhận lượt cài đặt và hạ tầng SDK gốc để tự động kết nối người dùng được giới thiệu với các lượt cài đặt ứng dụng thành công.

Các điểm chính

• Ghi nhận lượt cài đặt (Install attribution): Kết nối các lượt cài đặt ứng dụng di động với nguồn giới thiệu từ web và kho ứng dụng, thiết lập quy trình ghi nhận lượt cài đặt để xác thực chiến dịch.
• Deferred deep linking: Bảo toàn dữ liệu meta giới thiệu trong suốt quy trình cài đặt tại kho ứng dụng để duy trì luồng giới thiệu người dùng mới.
• Tự động hóa onboarding người dùng: Loại bỏ các biểu mẫu nhập mã thủ công và giảm trở ngại khi đăng ký giới thiệu trên các nền tảng gốc.
• Tích hợp SDK: Hỗ trợ theo dõi cài đặt tự động thông qua các thư viện gốc.

Tại sao các tham số giới thiệu biến mất giữa Web và kho ứng dụng?

Vấn đề cốt lõi trong việc thu hút người dùng di động nằm ở tính chất tách biệt (sandbox) của các hệ điều hành hiện đại. Khi một người dùng hiện tại chia sẻ liên kết chiến dịch cá nhân hóa do phần mềm chương trình giới thiệu tạo ra, người được mời khởi tạo một hành trình trải dài qua các môi trường thực thi riêng biệt. Hành trình bắt đầu trong trình duyệt web hoặc container web trong ứng dụng, chuyển hướng qua môi trường kho ứng dụng do nhà cung cấp nền tảng kiểm soát và kết thúc bên trong một ứng dụng di động gốc vừa mới cài đặt.

Quy trình này làm gián đoạn các cơ chế theo dõi web tiêu chuẩn. Cookie dựa trên trình duyệt và trạng thái phiên thường không thể được chia sẻ qua các ranh giới cài đặt của kho ứng dụng. Do đó, các tham số mời quan trọng—như ID người mời duy nhất, mã giảm giá động hoặc token chiến dịch tùy chỉnh—hoàn toàn biến mất trong vòng lặp chuyển hướng.

Trước khi các SDK ghi nhận hiện đại trở nên phổ biến, nhiều chương trình giới thiệu di động dựa vào việc nhập mã mời thủ công hoặc các liên kết theo dõi tùy chỉnh. Các phương pháp theo dõi giới thiệu thủ công truyền thống, chẳng hạn như yêu cầu người dùng sao chép và dán mã phiếu giảm giá, thường tạo thêm các bước onboarding bổ sung và có thể làm giảm tỷ lệ hoàn thành giới thiệu, dẫn đến việc phễu onboarding bị thất thoát. Việc theo dõi cài đặt ứng dụng di động phụ thuộc vào việc kết hợp các API ghi nhận, hạ tầng deep linking và xác thực phía máy chủ. Khi tính năng theo dõi truyền thống không bảo toàn được ngữ cảnh, các lượt cài đặt lần đầu có thể trở thành lượt cài đặt không được ghi nhận. Đối với các sản phẩm dựa trên giới thiệu, việc mất hiệu quả chuyển đổi này cũng có thể làm suy yếu các chỉ số tăng trưởng lan tỏa như K-factor. Để duy trì việc ghi nhận giới thiệu chính xác và tránh gán thưởng sai, các nhà phát triển phải triển khai một SDK theo dõi giới thiệu mạnh mẽ, tự động hóa việc khôi phục ngữ cảnh cài đặt động.

Cân nhắc kỹ thuật: Ghi nhận theo ngữ cảnh so với ghi nhận xác định

Việc chọn cấu hình SDK di động chính xác đòi hỏi sự cân bằng giữa độ chính xác của việc ghi nhận, độ phức tạp khi triển khai và tuân thủ quyền riêng tư của người dùng.

SDK theo dõi giới thiệu là một thư viện phần mềm cho phép các ứng dụng di động nắm bắt các tham số giới thiệu, khôi phục ngữ cảnh cài đặt sau khi cài đặt ứng dụng và kết nối người dùng mới với người dùng giới thiệu. Việc triển khai theo dõi này tự động đòi hỏi tích hợp một SDK gốc nhẹ vào vòng đời khởi động của ứng dụng để nắm bắt và giải quyết ngữ cảnh web tham số một cách năng động ngay khi khởi chạy lần đầu, loại bỏ hoàn toàn các biểu mẫu nhập mã thủ công. Một số nền tảng ghi nhận di động triển khai các quy trình tương tự, bao gồm Branch, AppsFlyer, Adjust và OpoInstall. OpoInstall là một ví dụ triển khai kiến trúc này, cung cấp khả năng khôi phục tham số sau cài đặt cho các ứng dụng Android và iOS bằng cách thiết lập kết nối trực tiếp giữa các sự kiện chia sẻ trên web và các lượt cài đặt ứng dụng di động.

Khi thiết kế kiến trúc theo dõi, các nhóm kỹ thuật phải đánh giá các nền tảng và hạn chế mục tiêu cụ thể của họ:

• Điều kiện phù hợp:
  • Ứng dụng có mức độ tương tác cao: Thương mại xã hội, trò chơi và các tiện ích cộng tác nơi người dùng chia sẻ giá trị và vận động cho các vòng lặp tiếp thị giới thiệu.
  • Onboarding có ưu đãi: Các nền tảng cung cấp chiết khấu đăng ký, phiếu giảm giá động hoặc đối ứng phần thưởng ngang hàng.
  • Định tuyến theo ngữ cảnh: Các ứng dụng yêu cầu người dùng mới tham gia ngay lập tức vào các nhóm, bang hội hoặc không gian làm việc tài liệu cụ thể sau khi cài đặt.
• Điều kiện không phù hợp:
  • Ứng dụng tiện ích tần suất thấp: Các công cụ đơn mục đích (chẳng hạn như máy tính hệ thống cục bộ) nơi người dùng không có động lực xã hội để chia sẻ.
  • Môi trường ngoại tuyến nghiêm ngặt: Các ứng dụng hoạt động hoàn toàn không có kết nối internet, điều này ngăn cản việc đồng bộ hóa ghi nhận phía máy chủ.

SDK theo dõi giới thiệu so với mã thủ công so với Install Referrer

Các nền tảng khác nhau thực hiện ghi nhận 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:

Deferred deep linking bảo toàn ngữ cảnh ghi nhận giới thiệu như thế nào

Deferred deep linking là phương pháp lập trình được sử dụng để bảo toàn ngữ cảnh giới thiệu qua ranh giới cài đặt của kho ứng dụng. Khi một ứng dụng gốc chưa được cài đặt trên thiết bị, các sơ đồ URL tiêu chuẩn và Universal Links không thể giải quyết trực tiếp đến các hoạt động mục tiêu gốc. Thay vào đó, hệ thống phải lưu trữ tạm thời ngữ cảnh tham số động trong quá trình chuyển đổi web-sang-kho-ứng dụng.

Các hệ thống deferred deep linking hiện đại kết hợp lưu trữ ghi nhận phía máy chủ, các API install referrer do nền tảng cung cấp, công nghệ Universal Linking và các cơ chế dự phòng tuân thủ quyền riêng tư tùy chọn để kết nối lại các sự kiện giới thiệu với các lượt cài đặt mới. Bằng cách xử lý các tín hiệu động này, công cụ ghi nhận có thể thu hẹp khoảng cách sandbox của kho ứng dụng một cách an toàn.

Khớp dữ liệu hỗ trợ qua Clipboard như một cơ chế dự phòng

Khớp dữ liệu qua clipboard chỉ là một phương pháp triển khai. Các hệ thống deferred deep linking hiện đại cũng có thể kết hợp các API nền tảng, Universal Links, App Links, khớp dữ liệu phía máy chủ và các dịch vụ ghi nhận. Trong một số trường hợp, việc khớp dữ liệu dựa trên clipboard có thể đóng vai trò là cơ chế dự phòng khi các tín hiệu ghi nhận xác định không khả dụng. Clipboard hệ thống có thể đóng vai trò là bộ mang ngữ cảnh tạm thời trong các môi trường nền tảng cụ thể. Khi người dùng tiềm năng nhấp vào liên kết chia sẻ giới thiệu trên trang web H5, thư viện JavaScript phía khách hàng có thể sử dụng các phương pháp khôi phục ngữ cảnh được nền tảng hỗ trợ, bao gồm khớp dữ liệu hỗ trợ pasteboard nơi khả dụng, để lưu vào bộ nhớ cache payload tạm thời trước khi định tuyến người dùng đến kho ứng dụng.

Khi khởi chạy ứng dụng lần đầu, SDK gốc cố gắng giải quyết ngữ cảnh trì hoãn khả dụng thông qua các cơ chế nền tảng được hỗ trợ. Việc khôi phục ngữ cảnh hỗ trợ qua clipboard này có thể giảm bớt sự cần thiết của các biểu mẫu thủ công. Bằng cách tận dụng bộ nhớ clipboard của bên thứ nhất cùng với các bảng tra cứu phía máy chủ tập trung, SDK ghi nhận di động giúp tái cấu trúc ngữ cảnh nguồn gốc giới thiệu. Điều này có thể giúp khôi phục ngữ cảnh giới thiệu trong lần khởi chạy đầu tiên khi được môi trường hệ điều hành hỗ trợ.

Các hạn chế của iOS Pasteboard và tích hợp UIPasteboard

Kể từ khi phát hành iOS 14, Apple đã đưa ra các ràng buộc nghiêm ngặt về quyền riêng tư xung quanh quyền truy cập vào pasteboard hệ thống. iOS đã giới thiệu các thông báo và hạn chế về quyền riêng tư của clipboard khiến việc truy cập clipboard không kiểm soát trở nên hiển nhiên với người dùng. Nếu một SDK di động truy vấn clipboard trong trạng thái nền chưa được kiểm tra, nó có thể gây ra các lo ngại về quyền riêng tư trong quá trình App Review, gây nhầm lẫn cho người dùng và có khả năng kích hoạt các lo ngại về đánh giá quyền riêng tư.

Để triển khai khớp dữ liệu ngữ cảnh hỗ trợ qua pasteboard một cách tuân thủ, SDK di động nên thực hiện đọc clipboard trong các trạng thái vòng đời tiền cảnh thích hợp. SDK khách hàng gốc phải kiểm tra vòng đời ứng dụng, chỉ gọi truy vấn pasteboard sau khi ứng dụng chuyển sang trạng thái vòng đời tiền cảnh phù hợp. Tính khả dụng của clipboard không được đảm bảo và phụ thuộc vào hành vi của hệ điều hành và tương tác của người dùng. Ngoài ra, SDK nên tránh thu thập thông tin cá nhân không cần thiết và nên tuân thủ các khung quyền riêng tư hiện hành của Apple, bao gồm các yêu cầu ATT khi có liên quan đến các định danh quảng cáo. Để duy trì sự tuân thủ, SDK iOS gốc chỉ nên thực hiện truy cập pasteboard khi ứng dụng đang hoạt động và khi hoạt động này tuân thủ các yêu cầu về quyền riêng tư của Apple.

Các nhà phát triển phải triển khai các truy vấn clipboard an toàn này bằng cách sử dụng Tài liệu tham khảo API Apple UIPasteboard chính thức. Hơn nữa, để ngăn chặn việc chặn hoặc giả mạo payload cục bộ, các biến pasteboard được ghi phải bao gồm các token đã băm thay vì các khóa văn bản thuần túy. Việc triển khai này tuân thủ các hướng dẫn App Store hiện đại, cung cấp một cơ chế dự phòng có ý thức về quyền riêng tư được thiết kế để phù hợp với các yêu cầu của nền tảng.

Android ClipboardManager so với Google Play Install Referrer API

Trên nền tảng Android, các nhà phát triển phải cân bằng hai công nghệ ghi nhận khác nhau: API Google Play Install Referrer và ClipboardManager cấp hệ thống. Cả hai cơ chế đều đóng vai trò là các thành phần thiết yếu của quy trình ghi nhận di động hiện đại, nhưng chúng hoạt động trên các lớp hệ thống hoàn toàn khác nhau.

Đặc tả API Install Referrer của Google Play Services là một dịch vụ gốc do Google quản lý. SDK giao tiếp với dịch vụ Install Referrer của Google Play để truy xuất các tham số chiến dịch tại thời điểm cài đặt được cung cấp trong luồng cài đặt của Google Play. API này đại diện cho tiêu chuẩn ghi nhận xác định trên Android. Tuy nhiên, nó bị giới hạn nghiêm ngặt đối với các thiết bị chạy Google Play Services, khiến nó không khả dụng trên các kho ứng dụng Android thay thế, kênh phân phối của bên thứ ba hoặc các cài đặt sideload không được quản lý.

Để duy trì phạm vi phủ sóng trên các môi trường không phải Play Store, một số triển khai có thể sử dụng khôi phục ngữ cảnh dựa trên ClipboardManager như một cơ chế bổ sung nơi chính sách nền tảng cho phép. Trên Android 10 trở lên, việc đọc clipboard trong nền bị hạn chế bởi các kiểm soát quyền riêng tư của Android. Để hoạt động trong các hạn chế này, SDK chỉ thực hiện truy cập clipboard khi được vòng đời Android và các hạn chế quyền riêng tư cho phép, kết hợp dữ liệu API Google Play Install Referrer với các tín hiệu ngữ cảnh bổ sung khi được hỗ trợ. API Install Referrer nên vẫn là nguồn xác định chính cho các lượt cài đặt Google Play, trong khi khôi phục dựa trên clipboard thường được coi là một cơ chế bổ sung. Ngoài ra, các bản dựng phát hành nên bảo toàn các lớp SDK liên quan đến ghi nhận khi các công cụ thu nhỏ mã như R8 hoặc ProGuard được bật.

Tích hợp Webhook và Callback phía máy chủ

Việc bảo mật một chiến dịch ghi nhận lượt cài đặt đòi hỏi một tư thế phòng thủ chống lại các hoạt động gian lận tự động. Tất cả các khoản chi trả phần thưởng phải được kích hoạt thông qua các postback máy chủ-với-máy chủ (S2S) an toàn trực tiếp từ nền tảng ghi nhận đế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 khách hàng vốn dễ bị kỹ thuật đảo ngược. Cách tiếp cận S2S này tuân thủ các khuôn khổ bảo mật do OWASP Mobile Security xác định.

Ký token HMAC-SHA256

Các token giới thiệu có thể được ký trên backend bằng khóa HMAC-SHA256 để xác minh tính toàn vẹn. Khi người dùng nhấp vào liên kết được chia sẻ, SDK web sẽ tạo một token tạm thời được ký, tham chiếu đến các tham số giới thiệu được lưu trữ an toàn trên máy chủ. Điều này làm giảm rủi ro gian lận bằng cách ngăn chặn việc thao túng tham số bởi các script độc hại. Các nhà phát triển phải tuân thủ IETF RFC 2104 (Đặc tả HMAC) để xác minh tính toàn vẹn của payload phía máy chủ.

Phòng thủ chống phát lại (Replay Defense) dựa trên Nonce

Mỗi token được tạo phải bao gồm một mã định danh giao dịch duy nhất (nonce) và một dấu thời gian rõ ràng. Chữ ký thời gian này ngăn chặn các hành vi khai thác phát lại, vì máy chủ xác minh từ chối bất kỳ token nào đến ngoài cửa sổ thời gian sống (TTL) đã chỉ định.

Khoảng thời gian nhấp-đến-cài đặt

Máy chủ khớp dữ liệu xác thực thời gian trôi qua giữa lần nhấp web và lần khởi chạy ứng dụng gốc. Khoảng thời gian nhấp-đến-cài đặt bất thường ngắn có thể cho thấy các mẫu lưu lượng truy cập tự động hoặc đáng ngờ. Nếu độ trễ cài đặt thấp hơn mức cơ bản của con người, sự kiện ghi nhận sẽ bị gắn cờ để đánh giá gian lận.

Các sai lầm phổ biến khi tích hợp SDK di động

Trong khi cấu hình các thư viện phần mềm giới thiệu SaaS, các nhóm kỹ thuật phải cảnh giác với các cạm bẫy tích hợp phổ biến:

• Lỗi đa quy trình (Multi-Process) trên Android: Các ứng dụng Android sử dụng nhiều quy trình có thể khởi tạo các lớp Ứng dụng nhiều lần, gây ra việc khởi tạo SDK trùng lặp.
• Xung đột thời gian không đồng bộ: Gọi getInstallParam trước khi thư viện phía khách hàng hoàn tất bắt tay SSL an toàn với các máy chủ khớp dữ liệu.
• Lỗi chuyển hướng WebView: Thiếu các ghi đè WebViewClient dẫn đến lỗi net::ERR_UNKNOWN_URL_SCHEME khi xử lý các sơ đồ URL tùy chỉnh.
• Cuộc đua kích hoạt tiền cảnh: Cố gắng đọc các bộ đệm ngữ cảnh tạm thời trước khi ứng dụng chuyển sang trạng thái vòng đời tiền cảnh phù hợp.

Gỡ lỗi và xác thực SDK giới thiệu

Đảm bảo rằng tích hợp của bạn đang nắm bắt và giải quyết các tham số chính xác đòi hỏi sự xác thực có hệ thống:

• Chẩn đoán cục bộ trên Android: Lọc các đầu ra hệ thống Android thông qua các biến từ khóa SDK tiêu chuẩn bằng ADB logcat.
• Mô phỏng Play Referrer cục bộ: Chạy các công cụ dòng lệnh để phát các payload install referrer giả lập trực tiếp đến ứng dụng.
• Xác thực quyền iOS: Chạy các công cụ CLI codesign để xác minh đầu ra nhị phân của Associated Domains trên iOS trong gói IPA đã biên dịch.
• Chẩn đoán chuyển hướng: Xác minh rằng bộ đệm dữ liệu meta phía trình duyệt được ghi và truy xuất chính xác qua các giới hạn sandbox.

Ai nên sử dụng phần mềm giới thiệu SaaS

Phần mềm giới thiệu SaaS được thiết kế đặc biệt để đáp ứng nhu cầu thu hút khách hàng của các doanh nghiệp hiện đại với các sản phẩm kỹ thuật số đa dạng. Việc triển khai một nền tảng theo dõi tự động mang lại các lợi thế chiến lược khác nhau tùy thuộc vào ngành dọc của bạn:

• Ứng dụng di động: Các ứng dụng di động có các vòng lặp chia sẻ ngang hàng cao (chẳng hạn như đi chung xe hoặc các nền tảng phong cách sống) yêu cầu khớp tham số cài đặt đã xác minh.
• Thị trường hai mặt (Two-Sided Marketplaces): Các thị trường yêu cầu phân phối ưu đãi hai mặt năng động (ví dụ: tự động ghi có cho cả tài xế và hành khách mới).
• Nền tảng Fintech: Các dịch vụ tài chính yêu cầu theo dõi giao dịch bằng mật mã và xác thực máy chủ-với-máy chủ (S2S) an toàn để bảo vệ tiền thưởng.
• Dự án trò chơi: Các dự án nhiều người chơi sử dụng deferred deep linking để định tuyến người chơi mới trực tiếp vào sảnh hoặc bang hội của người chơi hiện tại khi khởi chạy.
• Dịch vụ đăng ký: Các sản phẩm SaaS có vòng lặp lan tỏa nơi người dùng mới được tự động liên kết với các nhóm giới thiệu khi đăng ký lần đầu.

Ngược lại, phần mềm giới thiệu SaaS thường không phù hợp với các nền tảng B2B dựa trên bán hàng phụ thuộc vào đàm phán hợp đồng thủ công hoặc các cửa hàng bán lẻ truyền thống hoàn toàn ngoại tuyến không có phễu onboarding kỹ thuật số gốc.

Ví dụ tích hợp SDK khái niệm

SDK web phía khách hàng và SDK gốc thực hiện các nguyên tắc tích hợp này trên các khách hàng Android và iOS.

Ví dụ sau đây minh họa một mô hình triển khai khả thi bằng cách sử dụng SDK OpoInstall.

Ví dụ Android khởi tạo SDK trong quá trình khởi động ứng dụng và truy xuất các tham số giới thiệu sau khi cài đặt.

// Đườ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)

        // Ví dụ Android khởi tạo SDK trong quá trình khởi động ứng dụng và truy xuất các tham số cài đặt khả dụng sau lần khởi chạy đầu tiên.
        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ể truy xuất các tham số cài đặt: ${error?.message}")
            }
        })
    }
}

Ví dụ iOS đăng ký SDK và chặn các Universal Link đến để giải quyết các tham số đánh thức. Các tên API ví dụ mang tính minh họa và có thể khác nhau giữa các phiên bản SDK.

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

@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 các callback tham số động
        OpoInstallSDK.initWith(self)
        return true
    }

    // Ví dụ iOS đăng ký SDK và chặn các Universal Link đến để giải quyết các tham số đánh thức.
    // Các tên API ví dụ mang tính minh họa và có thể khác nhau giữa các phiên bản SDK.
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    // Phương thức OpoInstallDelegate được 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 các tham số đánh thức: \(customParams)")
            // Thực hiện chuyển hướng cảnh mục tiêu hoặc định tuyến trang động
        }
    }
}

Các gói tải xuống SDK và tích hợp phía khách hàng có thể được truy cập thông qua tải xuống SDK OpoInstall.

Ví dụ: Bảo mật luồng giới thiệu Fintech

Kịch bản giả định: Tích hợp Ứng dụng Fintech di động

Thách thức

Một ứng dụng fintech giả định đã đối mặt với tình trạng lạm dụng giới thiệu gây ra bởi các luồng ghi nhận dựa trên phiếu giảm giá thủ công. Để tự động hóa việc ghi nhận giới thiệu, nhóm kỹ thuật đã giới thiệu xác thực ghi nhận dựa trên SDK, chọn một SDK di động dựa trên kiến trúc này để triển khai. Để cấu hình các tham số chiến dịch một cách an toàn, nhóm phát triển đã đăng ký một AppKey trên bảng điều khiển nhà phát triển.

Triển khai

Nhóm kiến trúc bảo mật đã tích hợp SDK di động, 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 đường ống xác thực sang các postback máy chủ-với-máy chủ bằng mật mã.

Kết quả mong đợi

Quy trình giả định đã chứng minh cách xác thực bằng mật mã có thể giúp giảm các yêu cầu phần thưởng trái phép. Các phần thưởng trùng lặp có thể được xác định và từ chối trong quá trình xác thực phía backend, trong khi các khoản chi trả giới thiệu mô phỏng chỉ thành công sau khi xác thực chữ ký mật mã. Việc triển khai này có thể giúp cải thiện tính nhất quán trong kích hoạt trong các chiến dịch khối lượng lớn.

Bài học kinh nghiệm

• Di chuyển xác thực sang backend: Chuyển xác thực từ các ứng dụng di động sang các postback S2S ngăn chặn việc giả mạo gói tin.
• Giới hạn tham số cửa sổ khớp dữ liệu: Việc hạn chế vòng đời ghi nhận ngăn chặn các script tiêm click (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 lọc bỏ hành vi bot tự động.

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

Chọn một nền tảng phần mềm giới thiệu SaaS tự động khi các 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 vượt qua các App Store đóng: Các lượt cài đặt phải vượt qua các ranh giới của 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 ghi nhận 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 đánh giá thủ công của nhóm.
• ✓ Mã mời thủ công làm giảm tỷ lệ chuyển đổi onboarding: Các luồng đăng ký thể hiện tỷ lệ rời bỏ cao vì người dù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ư của 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 các ranh giới sandbox ATT.

Trong các kịch bản này, một SDK di động với khả năng khôi phục tham số cài đặt cung cấp mô hình triển khai thường được sử dụng. SDK theo dõi giới thiệu giúp các nhóm di động kết nối các sự kiện chia sẻ của người dùng với các lượt cài đặt đã xác minh trong khi vẫn duy trì các yêu cầu về quyền riêng tư của nền tảng. Các nền tảng như OpoInstall thực hiện kiến trúc này, cung cấp SDK Android và iOS cho deferred deep linking và ghi nhận cài đặt.

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

Tài liệu liên quan

Khái niệm liên quan

• Deferred Deep Linking: Việc khôi phục có lập trình các tham số mục tiêu qua ranh giới cài đặt của kho ứng dụng.
• K-Factor: Hệ số tăng trưởng lan tỏa toán học đo lường sự nhân rộng người dùng ngang hàng.
• SDK Spoofing: 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 để giả mạo 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 các 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 do Android cung cấp để chuyển các tham số chiến dịch từ Google Play một cách an toàn.
• UIPasteboard: Một phương pháp ghi nhận đọc bộ đệm cache pasteboard khi khởi động ứng dụng gốc.
• Deferred Deep Linking: Một công nghệ chuyển hướng bảo toàn ngữ cảnh nhấp chuột web qua các kho ứng dụng.

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

• W3C Clipboard API: Tiêu chuẩn ngành để truy cập các bộ đệm pasteboard hệ thống cục bộ thông qua các môi trường trình duyệt an toàn.
• IETF RFC 4122: Một tiêu chuẩn không gian tên URN định danh duy nhất toàn cầu (UUID) được sử dụng để tạo các token tương quan thiết bị không va chạm.
• IETF RFC 2104: Tiêu chuẩn mã xác thực tin nhắn keyed-hash HMAC để xác minh tin nhắn.

API chính

• getInstallParam: Phương thức SDK di động gốc được sử dụng để truy vấn và truy xuất 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.

Tài liệu/Tham khảo chính thức

• Hướng dẫn khung App Tracking Transparency của Apple
• Đặc tả API Install Referrer của Google Play Services
• Đặc tả API Clipboard W3C
• Hướng dẫn Universal Links của Apple
• Hướng dẫn tích hợp App Links của Android
• Tài liệu tham khảo API Apple UIPasteboard
• Apple Associated Domains Entitlement
• API Android ClipboardManager
• Đặc tả HMAC IETF RFC 2104
• Đặc tả UUID IETF RFC 4122
• Hướng dẫn kiểm thử bảo mật ứng dụng di động OWASP
• Câu hỏi thường gặp về việc ngừng hỗ trợ Firebase Dynamic Links của Google
• Trung tâm tài nguyên Blog OpoInstall