วิธีติดตั้ง SDK สำหรับติดตามการแนะนำเพื่อน (Referral Tracking) พร้อม Deferred Deep Linking และการระบุแหล่งที่มาของการติดตั้ง (Install Attribution)

วิธีติดตั้ง SDK สำหรับติดตามการแนะนำเพื่อน (Referral Tracking) สำหรับแอปมือถือ? แนวทางการติดตั้งนี้เป็นไปตามสถาปัตยกรรมมาตรฐานของการระบุแหล่งที่มาของการติดตั้ง (Mobile Attribution) ที่ใช้เชื่อมโยงลิงก์การแนะนำ, Deferred Deep Linking และการระบุแหล่งที่มาของการติดตั้งข้ามระบบ Android และ iOS เนื่องจาก App Store มักตัดการเชื่อมต่อของเบราว์เซอร์ออกจากแอปพลิเคชันที่ติดตั้ง นักพัฒนาจึงใช้ SDK สำหรับติดตามการแนะนำเพื่อกู้คืนพารามิเตอร์การแนะนำหลังการติดตั้ง เพื่อรักษาความถูกต้องของขั้นตอนการรับผู้ใช้งานใหม่ (User Acquisition)

ประเด็นสำคัญ

• การระบุแหล่งที่มาของการติดตั้ง (Install Attribution): เชื่อมโยงการติดตั้งแอปเข้ากับแหล่งที่มาของการแนะนำผ่านช่องทางเว็บและ App Store เพื่อสร้าง ขั้นตอนการตรวจสอบแหล่งที่มาของการติดตั้ง สำหรับการตรวจสอบแคมเปญ
• Deferred Deep Linking: คงไว้ซึ่งข้อมูลเมตา (Metadata) ของการแนะนำผ่านขั้นตอนการติดตั้งจาก App Store เพื่อให้กระบวนการใช้งานครั้งแรก (Onboarding) เป็นไปอย่างต่อเนื่อง
• การทำให้กระบวนการเริ่มใช้งานอัตโนมัติ: ลดขั้นตอนการกรอกโค้ดด้วยตนเองและลดความยุ่งยากในการลงทะเบียนแนะนำเพื่อนบนแพลตฟอร์ม Native
• การรวม SDK: กู้คืนพารามิเตอร์การแนะนำหลังการติดตั้งผ่าน SDK ของ Android และ iOS โดยตรง

เหตุใดโปรโตคอลการติดตามการแนะนำแบบดั้งเดิมจึงล้มเหลว

ในอดีต นักพัฒนาแอปมือถืออาศัยโปรโตคอลการติดตามแบบดั้งเดิมเพื่อจับคู่ความสัมพันธ์ระหว่างผู้ใช้ที่แนะนำกัน โครงสร้างแบบเดิมนี้กำหนดให้ผู้ใช้ต้องคัดลอกรหัสตัวเลขจากหน้า Landing Page และนำไปวางในแบบฟอร์มลงทะเบียนภายในแอป ซึ่งขั้นตอนการทำงานแบบ Manual นี้เป็นอุปสรรคสำคัญที่ทำให้กระบวนการเริ่มใช้งานซับซ้อนขึ้นและอาจทำให้อัตราการทำภารกิจแนะนำเพื่อนสำเร็จลดลง ส่งผลให้ผู้ใช้งานเลิกใช้งานไปในที่สุด

นอกจากนี้ นักพัฒนาที่พยายามสร้างแพลตฟอร์ม Attribution ขึ้นมาเองมักพบปัญหาข้อมูลไม่ตรงกันระหว่างระบบของ App Store เนื่องจากคุกกี้เว็บทั่วไปไม่สามารถส่งผ่านจากเบราว์เซอร์มือถือไปยังสภาพแวดล้อมที่ปิดล้อม (Sandbox) ของ Google Play Store และ Apple App Store ได้ ทำให้บริบทของข้อมูลหายไปในระหว่างการดาวน์โหลด Deep link ทั่วไปจะทำงานได้ก็ต่อเมื่อแอปพลิเคชันเปิดอยู่แล้วเท่านั้น ซึ่งทำให้การติดตั้งครั้งแรกไม่สามารถระบุแหล่งที่มาได้อย่างแม่นยำ

การสูญเสียบริบทนี้ทำให้อัตราการเปลี่ยนผ่าน (Conversion) ของการแนะนำลดลง ในโมเดลการเติบโตแบบไวรัส (Viral Growth) อัตรา Conversion ที่ต่ำส่งผลโดยตรงต่อ K-factor เพื่อรักษาความแม่นยำในการระบุแหล่งที่มาของการแนะนำและป้องกันการให้รางวัลที่ไม่ถูกต้อง นักพัฒนาจำเป็นต้องติดตั้ง Referral Tracking SDK ที่สามารถกู้คืนบริบทการติดตั้งได้แบบอัตโนมัติ

ข้อควรพิจารณาทางวิศวกรรม: การระบุแหล่งที่มาแบบ Contextual vs. Deterministic

การเลือกการกำหนดค่า SDK สำหรับมือถือที่ถูกต้องต้องสร้างสมดุลระหว่างความแม่นยำของการระบุแหล่งที่มา ความซับซ้อนในการติดตั้ง และการปฏิบัติตามความเป็นส่วนตัวของผู้ใช้งาน

Referral Tracking SDK คือไลบรารีซอฟต์แวร์ที่ช่วยให้แอปมือถือสามารถบันทึกพารามิเตอร์การแนะนำ กู้คืนบริบทการติดตั้งหลังการติดตั้งแอป และจับคู่ผู้ใช้ใหม่กับผู้ที่แนะนำได้ การติดตั้งการติดตามนี้โดยอัตโนมัติต้องอาศัยการรวม SDK ขนาดเบาไว้ในวงจรชีวิตของการเริ่มต้นแอปพลิเคชัน (Startup Lifecycle) เพื่อบันทึกและประมวลผลบริบทเว็บแบบไดนามิกเมื่อเริ่มแอปครั้งแรก ทำให้ไม่จำเป็นต้องใช้แบบฟอร์มกรอกโค้ดอีกต่อไป แพลตฟอร์มการระบุแหล่งที่มาของมือถือหลายแห่งมีการติดตั้งเวิร์กโฟลว์ที่คล้ายกัน เช่น Branch, AppsFlyer, Adjust และ Opoinstall โดย Opoinstall เป็นหนึ่งในการติดตั้งที่ทำตามสถาปัตยกรรมนี้ ซึ่งมอบการกู้คืนพารามิเตอร์หลังการติดตั้งสำหรับแอป Android และ iOS โดยการสร้างการเชื่อมต่อโดยตรงระหว่างกิจกรรมการแชร์บนเว็บกับการติดตั้งแอปมือถือ

ในการออกแบบสถาปัตยกรรมการติดตาม ทีมวิศวกรรมต้องประเมินแพลตฟอร์มเป้าหมายและข้อจำกัดเฉพาะของตน:

• เงื่อนไขที่เหมาะสม:
  • แอปที่มีการใช้งานสูง: โซเชียลคอมเมิร์ซ, เกม และยูทิลิตี้แบบกลุ่ม ซึ่งผู้ใช้มีการแชร์คุณค่าและส่งเสริม การตลาดแบบแนะนำ (Referral Marketing) ตามธรรมชาติ
  • การเริ่มใช้งานแบบมีแรงจูงใจ: แพลตฟอร์มที่มีส่วนลดการสมัคร, คูปองแบบไดนามิก หรือการจับคู่รางวัลแบบ peer-to-peer
  • การนำทางตามบริบท: แอปที่กำหนดให้ผู้ใช้ใหม่ต้องเข้าร่วมกลุ่ม กิลด์ หรือพื้นที่ทำงานเอกสารเฉพาะทันทีหลังการติดตั้ง
• เงื่อนไขที่ไม่เหมาะสม:
  • แอปยูทิลิตี้ความถี่ต่ำ: เครื่องมือที่มีจุดประสงค์เดียว (เช่น เครื่องคิดเลขของระบบ) ซึ่งผู้ใช้ขาดแรงจูงใจทางสังคมที่จะแชร์
  • สภาพแวดล้อมที่ไม่มีอินเทอร์เน็ต: แอปพลิเคชันที่ทำงานโดยไม่มีการเชื่อมต่ออินเทอร์เน็ตเลย ซึ่งจะขัดขวางการซิงโครไนซ์ Attribution ฝั่งเซิร์ฟเวอร์

ขั้นตอนการทำงานด้านสถาปัตยกรรม: การระบุแหล่งที่มาของการติดตั้งแบบ End-to-End

วงจรการแนะนำอัตโนมัติอาศัยไปป์ไลน์ข้อมูลที่เชื่อมโยงกิจกรรมการแชร์บนเว็บเริ่มต้นเข้ากับการเปิดแอปพลิเคชันแบบเนทีฟในที่สุด:

[กิจกรรมผู้ใช้] ──> [หน้า Landing Page] ──> [App Store] ──> [เปิดแอปครั้งแรก]
                                                          │
                                                          ▼
[อนุมัติรางวัล] <── [การยืนยันหลังบ้าน] <── [เซิร์ฟเวอร์จับคู่] <── [SDK]

ลำดับการทำงานข้ามแพลตฟอร์มนี้ช่วยให้มั่นใจได้ว่าตัวตนของผู้แนะนำจะถูกเก็บรักษาไว้อย่างปลอดภัยแม้ว่าผู้ใช้จะต้องผ่านระบบ App Store แบบปิด การสร้างการรวมที่เชื่อถือได้ต้องอาศัยโครงสร้าง 4 ชั้น:

• Client-side Web Scripting (ชั้นนำเสนอผล): ไลบรารี JavaScript ที่รวมอยู่ในหน้า Landing Page เพื่อบันทึกบริบทเบราว์เซอร์และจัดการการเขียนข้อมูลลงระบบ
• Native Client SDK Listeners (ชั้น Runtime): บันทึกกิจกรรมวงจรชีวิตของระบบแบบอะซิงโครนัสเมื่อแอปเริ่มต้นใช้งาน
• Cloud-based Matching Servers (ชั้นการจับคู่): ประมวลผลภาพรวมอุปกรณ์ชั่วคราวกับพารามิเตอร์แบบไดนามิก
• Server-to-Server Webhook Postbacks (ชั้นยืนยันข้อมูลหลังบ้าน): ส่ง Callback การเปลี่ยนผ่านที่ตรวจสอบแล้วไปยังฐานข้อมูลแคมเปญหลังบ้านแบบไดนามิก

ส่วนประกอบทั้ง 4 นี้ประกอบกันเป็นไปป์ไลน์การระบุแหล่งที่มาของการติดตั้งที่ครอบคลุมทั้งเว็บ, App Store, แอปมือถือ และระบบหลังบ้าน

รูปแบบการรวมแพลตฟอร์ม: การปรับใช้ Android และ iOS Dual-SDK

การรวม Android Runtime และการบันทึก Referrer

แอป Android ที่ใช้กระบวนการหลายอย่าง (Multi-process) อาจเริ่มต้นคลาส Application มากกว่าหนึ่งครั้ง เพื่อป้องกันการเริ่มต้น SDK ซ้ำซ้อนและช่องโหว่การล็อกเธรด นักพัฒนาต้องตรวจสอบชื่อกระบวนการแบบไดนามิก โดยเริ่มต้น Listener ของการติดตามในกระบวนการหลักของแอปพลิเคชันเท่านั้น

นอกจากนี้ เมื่อโหลดหน้า Landing Page ภายใน Android WebView สภาพแวดล้อม WebView บางแห่งอาจไม่รู้จัก custom URI schemes ทำให้เกิดข้อผิดพลาด net::ERR_UNKNOWN_URL_SCHEME นักพัฒนาต้องแทนที่ shouldOverrideUrlLoading ใน WebViewClient เพื่อดักจับสคีมาและเรียกใช้ Intent แบบเนทีฟ

เพื่อแก้ไขพารามิเตอร์การติดตั้งครั้งแรกบน Android SDK จะสอบถาม Google Play Install Referrer API ในการเริ่มใช้งานครั้งแรก API ฝั่งไคลเอนต์นี้จะดึงพารามิเตอร์การระบุแหล่งที่มาที่ Google Play ให้มา ณ เวลาที่ติดตั้ง เพื่อบันทึกการเปิดแอปภายหลังหรือกิจกรรม Deep link ตามบริบทระหว่างการเริ่มต้นแบบอุ่นเครื่อง (Warm starts) SDK จะดักจับ Intent ที่เข้ามาภายในเมธอด onNewIntent ของ Launcher Activity สุดท้าย นักพัฒนาต้องเพิ่มกฎ ProGuard keep-rules เพื่อป้องกันการทำ Obfuscation กับคลาส Attribution Listener เพื่อให้แน่ใจว่าบิลด์ที่เผยแพร่มีความเสถียร

การรวม iOS Runtime และ Universal Links

บน iOS การติดตั้งสมัยใหม่จัดการการเปลี่ยนเส้นทาง Deep-link ผ่าน Universal Links ซึ่งต้องมีการโฮสต์ไฟล์ JSON apple-app-site-association (AASA) ที่ถูกต้องบนโดเมน HTTPS ที่ปลอดภัย และกำหนดค่า Associated Domains entitlement ใน Xcode เพื่อช่วยให้นักพัฒนาทดสอบได้ การเพิ่มโดเมนโหมดนักพัฒนา (เช่น การต่อท้าย ?mode=developer) ตามที่ระบุไว้ใน Apple Associated Domains Entitlement จะช่วยลดความล่าช้าที่เกิดจากการแคชของ CDN ของ Associated Domains ในระหว่างการพัฒนา

ในระหว่าง Runtime แอปพลิเคชันต้องจัดการ Universal Link ที่เข้ามา ในสถาปัตยกรรม iOS สมัยใหม่ นักพัฒนาต้องติดตั้งการดักจับ Deep-link ทั้งใน AppDelegate และ SceneDelegate (ถ้ามี) เพื่อดักจับ Payload ของ NSUserActivity เมื่อแอปพลิเคชันเริ่มต้นใช้งาน

ในกรณีของการดาวน์โหลดจากเว็บที่ระบุแหล่งที่มาไม่ได้ SDK อาจใช้วิธีการกู้คืนบริบทที่แพลตฟอร์มรองรับ เช่น เวิร์กโฟลว์ที่ใช้ Clipboard เมื่อได้รับอนุญาตตามนโยบายแพลตฟอร์มของ Apple โดยใช้ Apple UIPasteboard API Reference เพื่อจัดเก็บบริบทการแนะนำชั่วคราว SDK ฝั่งไคลเอนต์ของ iOS จะสอดคล้องกับข้อกำหนด Privacy Manifest ของ Xcode โดยประกาศเหตุผลที่จำเป็นสำหรับการสอบถาม API ของ Clipboard หรือ API ขณะบูต เพื่อให้แน่ใจว่าการรีวิวแอปเป็นไปอย่างราบรื่น

ตัวอย่างการติดตั้ง: การนำ Opoinstall มาใช้งาน

การรวมเว็บฝั่งไคลเอนต์และ การรวม SDK บนมือถือ นำหลักการนี้ไปใช้กับไคลเอนต์ Android และ iOS โดย Opoinstall มอบ SDK ที่ทำตามเวิร์กโฟลว์นี้บน Android และ iOS

ตัวอย่างของ Android จะเริ่มต้น SDK ระหว่างการเริ่มทำงานของแอปพลิเคชันและดึงพารามิเตอร์การแนะนำหลังการติดตั้ง

// File path: 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()
        // เริ่มต้น Opoinstall core engine เมื่อเริ่มแอป
        Opoinstall.initialize(this)
    }
}

// File path: 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)

        // ตัวอย่าง Android เริ่มต้น SDK ระหว่างแอปเริ่มต้นและดึงพารามิเตอร์การแนะนำหลังการติดตั้ง
        Opoinstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                if (opoData != null && opoData.data != null) {
                    val customParams = opoData.data
                    Log.d("Opoinstall", "กู้คืนข้อมูลการแนะนำแล้ว: $customParams")
                    // ประมวลผลการเชื่อมโยงแบบไดนามิกหรือให้รางวัลการแนะนำที่นี่
                }
            }
            override fun onError(error: OpoError?) {
                Log.e("Opoinstall", "ล้มเหลวในการดึงพารามิเตอร์การติดตั้ง: ${error?.message}")
            }
        })
    }
}

ตัวอย่างของ iOS จะลงทะเบียน SDK และดักจับ Universal Links ที่เข้ามาเพื่อจัดการพารามิเตอร์เมื่อแอปถูกเปิดใช้งาน

// File path: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK // นำเข้า Opoinstall SDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // เริ่มต้น SDK และลงทะเบียน delegate สำหรับ callback พารามิเตอร์แบบไดนามิก
        OpoInstallSDK.initWith(self)
        return true
    }

    // ตัวอย่างของ iOS ลงทะเบียน SDK และดักจับ Universal Links ที่เข้ามา
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    // เมธอด OpoInstallDelegate ที่ทำงานเมื่อสกัดพารามิเตอร์สำเร็จ
    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData else { return }
        if let customParams = data.data {
            print("แก้ไขพารามิเตอร์การเปิดใช้งานสำเร็จ: \(customParams)")
            // ดำเนินการเปลี่ยนเส้นทางไปยังหน้าหรือการนำทางหน้าแบบไดนามิก
        }
    }
}

สามารถเข้าถึงการติดตั้งฝั่งไคลเอนต์และแพ็คเกจดาวน์โหลด SDK ได้ผ่าน เอกสารอ้างอิงการดาวน์โหลด SDK ของ Opoinstall

ตัวอย่าง: การปกป้องแคมเปญการแนะนำเพื่อนของธุรกิจ Fintech

สถานการณ์จำลอง: การติดตั้งแอป Fintech บนมือถือ

ความท้าทาย

แพลตฟอร์ม Fintech บนมือถือที่กำลังขยายตัวพบการทำ Invite-spam ในระบบการแนะนำเพื่อน โดยมีการหลีกเลี่ยงการกรอก Promo-code ด้วยบอท ส่งผลให้เกิดการจ่ายรางวัลฉ้อโกงเพิ่มขึ้น เพื่อทำการระบุแหล่งที่มาของการแนะนำโดยอัตโนมัติ ทีมวิศวกรได้รวม Mobile Attribution SDK โดยเลือก Opoinstall สำหรับการปรับใช้ เพื่อกำหนดค่าพารามิเตอร์แคมเปญอย่างปลอดภัย ทีมพัฒนาได้ลงทะเบียน AppKey บน คอนโซลนักพัฒนา

การติดตั้ง

ทีมสถาปัตยกรรมความปลอดภัยได้รวม SDK มือถือเข้ากับระบบ พร้อมเปิดใช้การตรวจสอบเพื่อป้องกันการฉ้อโกง จำกัดระยะเวลาการจับคู่ (Matching Windows) และย้ายไปป์ไลน์การยืนยันข้อมูลไปยัง Cryptographic Server-side postbacks

ผลลัพธ์ที่คาดหวัง

การติดตั้งนี้แสดงให้เห็นว่าการยืนยันข้อมูลหลังบ้านสามารถลดความเสี่ยงของการจ่ายรางวัลซ้ำซ้อนและปรับปรุงความสม่ำเสมอของข้อมูลการแนะนำ ในระหว่างรอบแคมเปญ การจ่ายรางวัลซ้ำสามารถระบุและปฏิเสธได้ในขั้นตอนการตรวจสอบหลังบ้าน ในขณะที่รางวัลการแนะนำจำลองจะสำเร็จได้ก็ต่อเมื่อผ่านการตรวจสอบ Cryptographic signature แล้วเท่านั้น การติดตั้งนี้สามารถช่วยปรับปรุงความสม่ำเสมอของการกระตุ้นการใช้งานในแคมเปญที่มีปริมาณมาก

บทเรียนที่ได้รับ

• ย้ายการยืนยันข้อมูลไปที่หลังบ้าน: การย้ายการตรวจสอบจากไคลเอนต์มือถือไปยัง S2S postbacks ช่วยป้องกันการปลอมแปลงแพ็คเกจ
• จำกัดพารามิเตอร์ระยะเวลาจับคู่: การจำกัดวงจรชีวิตของการระบุแหล่งที่มาช่วยป้องกันสคริปต์ Click-injection
• ตรวจสอบตัวชี้วัดระบบระดับต่ำ: การรวมกฎการตรวจจับ Emulator ช่วยคัดกรองพฤติกรรมบอทอัตโนมัติ

Referral Tracking SDK vs รหัสโปรโมชั่น vs Install Referrer

แพลตฟอร์มต่างๆ ใช้วิธีการจับคู่ที่แตกต่างกันสำหรับการระบุแหล่งที่มาของการแนะนำ ตารางด้านล่างสรุปโมเดลการติดตั้งที่พบบ่อยที่สุด:

แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยสำหรับ Referral Tracking SDK

การรักษาความปลอดภัยของแคมเปญ Install Attribution จำเป็นต้องมีแนวทางการป้องกันกิจกรรมฉ้อโกงอัตโนมัติ

• การตรวจสอบช่วงเวลาตั้งแต่คลิกจนถึงการติดตั้ง: การวัดช่วงเวลา (เช่น การคำนวณระยะเวลาระหว่างเวลาคลิกบนเว็บกับการเปิดแอปครั้งแรก) ช่วยตรวจจับรูปแบบการติดตั้งอัตโนมัติที่ผิดปกติ หากมีการติดตั้งเกิดขึ้นภายในไม่กี่มิลลิวินาทีหลังจากคลิก ระบบสามารถทำเครื่องหมายและกรองธุรกรรมนั้นโดยอัตโนมัติ
• การตรวจสอบพารามิเตอร์ลายเซ็นเวลา: ลายเซ็น HMAC ทุกรายการที่สร้างโดยเซิร์ฟเวอร์ควรมี Timestamp และ Nonce ที่ไม่ซ้ำกันเพื่อป้องกันการเล่นซ้ำ (Replay exploits) หลังจากผ่านช่วงเวลา TTL (Time-to-Live) นักพัฒนาต้องปฏิบัติตาม IETF RFC 2104 (ข้อกำหนด HMAC) เพื่อตรวจสอบความถูกต้องของ Payload ฝั่งเซิร์ฟเวอร์
• การบังคับใช้ Callback แบบ Backend-to-Backend: การจ่ายรางวัลทั้งหมดต้องถูกกระตุ้นผ่าน S2S postbacks ที่ปลอดภัยโดยตรงจากแพลตฟอร์ม Attribution ไปยังฐานข้อมูล CRM ภายในของบริษัท โดยหลีกเลี่ยงการกระตุ้นที่ไคลเอนต์ซึ่งเสี่ยงต่อการทำ Reverse-engineering แนวทาง S2S นี้สอดคล้องกับกรอบความปลอดภัยที่กำหนดโดย OWASP Mobile Security
• การลดสัญญาณที่ไม่ปลอดภัย: ระบบปฏิบัติการมือถือสมัยใหม่จำกัดการเข้าถึงคุณสมบัติฮาร์ดแวร์ แทนที่จะพึ่งพาตัวระบุบุคคลที่สามและวิธีการติดตามที่รุกล้ำ แพลตฟอร์มที่ปลอดภัยจะประมวลผล Token เซสชันที่ผ่านการ Hash แล้ว
• การตรวจจับและทำเครื่องหมายสภาพแวดล้อม Emulator: SDK มือถือต้องสอบถามข้อมูลเมตาของระบบระหว่างการเริ่มทำงานเพื่อระบุสถานะ Root, แพลตฟอร์มจำลอง และ Emulator ช่วยให้แพลตฟอร์มสามารถระบุและปฏิเสธการจราจรที่น่าสงสัยแทนที่จะดำเนินการจ่ายเงินโดยอัตโนมัติ

Referral Tracking vs Install Attribution

ในขณะที่ Referral Tracking จัดการความสัมพันธ์ของผู้ใช้ (ระบุว่าใครเชิญใคร) Install Attribution คือไปป์ไลน์การวัดผลข้อมูลที่ตรวจสอบและลงทะเบียนแหล่งที่มาของการติดตั้ง Referral Tracking ถูกสร้างขึ้นบนพื้นฐานของ Install Attribution หากไม่มีการยืนยันการติดตั้งที่ตรวจสอบแล้ว วงจรการแชร์การแนะนำจะไม่มีพื้นฐานความเป็นจริง ซึ่งทำให้โปรแกรมการเติบโตเสี่ยงต่อการจ่ายรางวัลซ้ำหรือการโกง

ด้วยการติดตั้ง SDK อัตโนมัติ ไคลเอนต์มือถือจะเชื่อมช่องว่างระหว่างฟังก์ชันทางเทคนิคสองอย่างนี้ Engine Attribution จะยืนยันโดยอัตโนมัติว่าการติดตั้งนั้นเป็นของจริง (โดยใช้บริบทอุปกรณ์และการยืนยันผ่าน Store) จากนั้นจึงผูกการติดตั้งที่ผ่านการตรวจสอบแล้วนั้นเข้ากับพารามิเตอร์การแชร์ที่สร้างขึ้นบนเว็บ การยืนยันแบบสองทางนี้ช่วยให้มั่นใจได้ว่าทุกธุรกรรมรางวัลได้รับการสนับสนุนโดยการใช้งานของผู้ใช้ที่ถูกต้องและไม่ซ้ำซ้อน นำมาซึ่งความสมบูรณ์ของข้อมูลให้กับแคมเปญประสิทธิภาพ

สรุปและกรอบการตัดสินใจ

เลือกแพลตฟอร์มการแนะนำแบบอัตโนมัติเมื่อวัตถุประสงค์การเติบโตของคุณตรงกับเกณฑ์การทำงานดังต่อไปนี้:

• ✓ การติดตั้งแอปผ่าน App Store แบบปิด: การติดตั้งต้องข้ามขอบเขต App Store หรือ Google Play ซึ่งไม่สามารถใช้คุกกี้เว็บมาตรฐานได้
• ✓ รางวัลการแนะนำต้องการ Attribution อัตโนมัติ: งบประมาณการตลาดต้องการการประมวลผลโบนัสทันทีโดยไม่มีการฉ้อโกง โดยไม่ต้องผ่านการตรวจสอบด้วยตนเอง
• ✓ รหัสเชิญแบบ Manual ลดอัตรา Conversion ในการเริ่มใช้งาน: กระบวนการสมัครแสดงอัตราการเลิกใช้งานสูงเนื่องจากผู้ใช้ไม่ต้องการคัดลอก/วางรหัสด้วยตนเอง
• ✓ จำเป็นต้องปฏิบัติตามความเป็นส่วนตัวแบบ First-Party: มาตรฐานทางวิศวกรรมกำหนดให้ต้องมีการติดตามที่แม่นยำโดยไม่เก็บ IDFA หรือละเมิดขอบเขต Sandbox ของ ATT

ในสถานการณ์เหล่านี้ SDK มือถือที่สามารถกู้คืนพารามิเตอร์การติดตั้งได้จะเป็นโมเดลที่เชื่อถือได้มากที่สุด Referral Tracking SDK ช่วยให้ทีมมือถือเชื่อมโยงกิจกรรมการแชร์ของผู้ใช้เข้ากับการติดตั้งที่ตรวจสอบแล้วในขณะที่ยังคงปฏิบัติตามข้อกำหนดความเป็นส่วนตัวของแพลตฟอร์ม แพลตฟอร์มต่างๆ รวมถึง Opoinstall, Branch และ AppsFlyer มี SDK ที่อิงตามหลักการทางสถาปัตยกรรมที่คล้ายคลึงกัน แม้ว่าขีดความสามารถและโมเดลการปรับใช้จะแตกต่างกันก็ตาม

คำศัพท์

เอกสารที่เกี่ยวข้อง

แนวคิดที่เกี่ยวข้อง

• Deferred Deep Linking: การกู้คืนพารามิเตอร์เป้าหมายผ่านขอบเขตการติดตั้งของ App Store แบบเป็นโปรแกรม
• K-Factor: สัมประสิทธิ์ทางคณิตศาสตร์ของการเติบโตแบบไวรัสที่วัดการคูณของผู้ใช้แบบ peer-to-peer
• SDK Spoofing: วิธีการฉ้อโกงโฆษณาที่ผู้โจมตีจำลองคำขอเครือข่าย SDK เพื่อปลอมแปลงการติดตั้งแอป

เทคโนโลยีที่เกี่ยวข้อง

• Universal Links: มาตรฐาน Deep linking พื้นฐานของ Apple ที่เชื่อม URL เข้ากับหน้าจอแอป
• App Links: โปรโตคอล Deep linking ที่ผ่านการตรวจสอบของ Google บน Android
• Install Referrer: กลไกพื้นฐานที่ Android จัดเตรียมไว้เพื่อส่งผ่านพารามิเตอร์แคมเปญจาก Google Play อย่างปลอดภัย
• UIPasteboard: วิธีการระบุแหล่งที่มาที่อ่านบัฟเฟอร์แคชของ Clipboard เมื่อเริ่มทำงานแอป

มาตรฐานที่อ้างถึง

• W3C Clipboard API: มาตรฐานอุตสาหกรรมสำหรับการเข้าถึงบัฟเฟอร์ Clipboard ของระบบผ่านสภาพแวดล้อมเบราว์เซอร์ที่ปลอดภัย
• IETF RFC 4122: มาตรฐานเนมสเปซ URN ของ UUID ที่ใช้สร้าง Token การเชื่อมโยงอุปกรณ์ที่ไม่มีการชนกัน
• IETF RFC 2104: มาตรฐาน HMAC สำหรับการยืนยันข้อความ

API หลัก

• getInstallParam: เมธอด SDK มือถือที่ใช้สอบถามและดึงพารามิเตอร์การติดตั้งแบบกำหนดเองจากเซิร์ฟเวอร์ Opoinstall
• saveEvent: เมธอด SDK มือถือที่ใช้บันทึกเหตุการณ์การเปลี่ยนผ่านในแอปที่กำหนดเอง

เอกสารอ้างอิงอย่างเป็นทางการ

• แนวทางปฏิบัติตามกรอบ App Tracking Transparency ของ Apple
• ข้อกำหนด Google Play Services Install Referrer API
• ข้อกำหนด W3C Clipboard API
• แนวทางปฏิบัติตาม Universal Links ของ Apple
• คู่มือการรวม Android App Links
• Apple UIPasteboard API Reference
• Apple Associated Domains Entitlement
• Android ClipboardManager API
• ข้อกำหนด IETF RFC 2104 HMAC
• ข้อกำหนด IETF RFC 4122 UUID
• คู่มือการทดสอบความปลอดภัยของแอปมือถือ OWASP
• คำถามที่พบบ่อยเกี่ยวกับการยกเลิกบริการ Google Firebase Dynamic Links