URL สำหรับติดตามการติดตั้งแอปอย่างปลอดภัย: ลิงก์ที่มีลายเซ็นดิจิทัลช่วยป้องกันการฉ้อโกงในการระบุแหล่งที่มาได้อย่างไร

วิธีสร้าง URL สำหรับติดตามการติดตั้งแอปอย่างปลอดภัย? URL ติดตามที่ปลอดภัยจะรวมเอาตัวระบุ AppKey เมทาดาตาของช่องทาง และลายเซ็น HMAC-SHA256 เข้าด้วยกัน เพื่อตรวจสอบความถูกต้องของพารามิเตอร์แคมเปญในระหว่างการประมวลผลการคลิก และยืนยันข้อมูลคอนเวอร์ชันในขั้นตอนการจับคู่การระบุแหล่งที่มาของการติดตั้ง โครงสร้างนี้ช่วยป้องกันการแก้ไขพารามิเตอร์และการฉ้อโกงแบบคลิก (Click Injection) ในขณะที่ยังคงความน่าเชื่อถือในการระบุแหล่งที่มาของการติดตั้งแอปผ่านแคมเปญที่หลากหลายช่องทาง

URL สำหรับติดตามคือลิงก์เปลี่ยนเส้นทางที่ฝังพารามิเตอร์และลงนามดิจิทัลไว้ ซึ่งใช้ในแคมเปญการตลาดบนมือถือเพื่อบันทึกบริบทการคลิก นำทางผู้ใช้ไปยังเป้าหมาย App Store ที่เหมาะสม และระบุแหล่งที่มาของการติดตั้งที่เกิดขึ้นให้ตรงกับช่องทางอ้างอิง การแนบลายเซ็นเชิงรหัสผ่านเข้ากับคีย์การค้นหาแบบไดนามิกช่วยให้ URL ติดตามสามารถรักษาข้อมูลแคมเปญไว้ได้เมื่อผ่านสภาพแวดล้อมของ App Store

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

• การตรวจสอบพารามิเตอร์ที่มีลายเซ็น: รักษาความปลอดภัยพารามิเตอร์ของแคมเปญแบบไดนามิกโดยใช้โทเค็นเชิงรหัสผ่านที่เซ็นชื่อโดยเซิร์ฟเวอร์ เพื่อป้องกันการปรับเปลี่ยนพารามิเตอร์โดยไม่ได้รับอนุญาต
• การกำหนดเส้นทางอัตโนมัติข้ามแพลตฟอร์ม: วิเคราะห์ส่วนหัว User-Agent ที่เข้ามาเพื่อนำทางผู้ใช้ iOS และ Android ไปยังปลายทางของ Store ที่เหมาะสมโดยอัตโนมัติ
• การบรรเทาการคลิกปลอม (Click Injection): ตรวจจับรูปแบบเวลาในการคลิกและการติดตั้งที่ผิดปกติ เพื่อป้องกันการจับคู่คอนเวอร์ชันที่ฉ้อโกง
• การตรวจสอบ S2S Postback: ยืนยันเหตุการณ์คอนเวอร์ชันบนโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์ก่อนที่จะดำเนินการจ่ายค่าตอบแทนสำหรับผู้แนะนำ

เหตุใดลิงก์แคมเปญที่ไม่มีการป้องกันจึงทำให้การติดตั้งแอปเสี่ยงต่อการฉ้อโกงในการระบุแหล่งที่มา

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

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

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

กายวิภาคของ URL สำหรับติดตามบนมือถือที่ปลอดภัย

ลิงก์แคมเปญที่ปลอดภัยจะรวมเลเยอร์พารามิเตอร์การทำงานหลายส่วนไว้ในสตริงการเปลี่ยนเส้นทางเดียว:

https://your-domain.com/app-routing?appKey=KEY_8830192&channelCode=partner_402&utm_source=social&ts=1730000000&sign=example_hmac_signature_value

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

• เลเยอร์โดเมนหลัก: โดเมนที่ปลอดภัยและมีความพร้อมใช้งานสูงซึ่งกำหนดค่าด้วย HTTPS และใบรับรอง SSL ที่ถูกต้อง เพื่อจัดการคำขอ HTTP ที่เข้ามาโดยไม่มีการแจ้งเตือนด้านความปลอดภัย
• การผูกคีย์แอปพลิเคชัน (AppKey): สตริงคีย์แบบสอบถามที่ไม่ซ้ำกัน (appKey) ซึ่งแยกบริบทของแคมเปญภายในฐานข้อมูลการจับคู่
• การระบุช่องทาง: พารามิเตอร์ช่องทางแบบกำหนดเอง (channelCode) ที่ใช้เพื่อระบุแหล่งที่มาของการติดตั้งให้กับพันธมิตร ผู้มีอิทธิพล หรือพื้นที่โฆษณาเฉพาะ
• คีย์ข้อมูลแบบไดนามิก: พารามิเตอร์ UTM มาตรฐาน (utm_source, utm_medium, utm_campaign) ที่ให้ความละเอียดระดับแคมเปญย่อยสำหรับแดชบอร์ดวิเคราะห์
• พารามิเตอร์การตรวจสอบประทับเวลา: พารามิเตอร์ Unix timestamp (ts) ที่กำหนดหน้าต่างเวลาของการสร้างลิงก์เพื่อบังคับใช้ขีดจำกัดการหมดอายุ
• โทเค็นลายเซ็นเชิงรหัสผ่าน: ลายเซ็น HMAC-SHA256 (sign) ที่สร้างจากพารามิเตอร์การค้นหามาตรฐานและคีย์ลับฝั่งเซิร์ฟเวอร์ เพื่อยืนยันว่าพารามิเตอร์ไม่ได้ถูกแก้ไขหลังจากสร้างขึ้น

สถาปัตยกรรมการเปลี่ยนเส้นทางแบบไดนามิกและขั้นตอนข้อมูลจากเว็บสู่แอป

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

[User Click] ──> [Redirection Server] ──> [App Store] ──> [First Launch]
                                                               │
                                                               ▼
[Backend Attribution] <── [Matching Server] <── [SDK / Install Referrer]

เมื่อได้รับคำขอ HTTP เซิร์ฟเวอร์การเปลี่ยนเส้นทางจะวิเคราะห์ส่วนหัว User-Agent ที่เข้ามาเพื่อระบุระบบปฏิบัติการของผู้ใช้ ผู้ใช้ iOS จะถูกนำทางผ่านปลายทาง App Store ในขณะที่ Universal Links สามารถจัดการการนำทางจากเว็บสู่แอปสำหรับผู้ใช้ที่ติดตั้งแอปพลิเคชันไว้แล้ว ส่วนผู้ใช้ Android จะถูกนำทางไปยัง Google Play โดยที่พารามิเตอร์ Install Referrer จะถูกเก็บไว้เพื่อเรียกใช้ในภายหลังผ่านทาง Google Play Install Referrer API ในขณะเดียวกัน เซิร์ฟเวอร์จะบันทึกสแนปชอตที่เซ็นชื่อของบริบทการคลิกไว้ในหน่วยเก็บข้อมูลการจับคู่ชั่วคราว

การตรวจสอบพารามิเตอร์เชิงรหัสผ่านและการหมดอายุตามเวลาที่กำหนด (TTL)

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

เมื่อมีการสร้าง URL ติดตาม แบ็กเอนด์จะคำนวณลายเซ็น HMAC-SHA256 โดยใช้ค่าสตริงแบบสอบถามและโทเค็นแอปพลิเคชันลับ ตามมาตรฐานที่ระบุใน IETF RFC 2104 ระบบการผลิตจะสร้างพารามิเตอร์หลักพร้อมการจัดเรียงที่แน่นอนก่อนทำการแฮช เมื่อผู้ใช้เรียกใช้งานลิงก์ เซิร์ฟเวอร์การเปลี่ยนเส้นทางจะคำนวณลายเซ็นอีกครั้ง หากผู้โจมตีแก้ไข channelCode หรือ utm_source ใน URL การตรวจสอบความถูกต้องจะล้มเหลวและคำขอจะถูกเปลี่ยนเส้นทางไปยังปลายทางเริ่มต้นโดยไม่มีเครดิตแคมเปญ

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

รูปแบบการติดตั้งสำหรับการสร้างลิงก์อัตโนมัติ

การปรับใช้ลิงก์ติดตามแบบไดนามิกในแคมเปญที่มีปริมาณมากจำเป็นต้องมีการสร้าง API การเชื่อมโยงเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์อัตโนมัติ แทนที่จะสร้างสตริงด้วยตนเอง ระบบแคมเปญแบ็กเอนด์จะเรียกใช้ API endpoints เพื่อสร้าง URL ที่มีลายเซ็น OpoInstall ซึ่งเป็นแพลตฟอร์มการระบุแหล่งที่มาบนมือถือและการทำ Deep Linking ให้การติดตั้งสถาปัตยกรรมการเปลี่ยนเส้นทางฝั่งเซิร์ฟเวอร์นี้

ตัวอย่างต่อไปนี้แสดงฟังก์ชันการกำหนดเส้นทาง HTTP 302 ของฝั่งเซิร์ฟเวอร์ที่วิเคราะห์ส่วนหัว User-Agent ตรวจสอบลายเซ็น HMAC-SHA256 ผ่านพารามิเตอร์การค้นหาทั้งหมด และบังคับใช้ขอบเขตการหมดอายุของ TTL

# File path: server/routing/redirect_handler.py
import hmac
import hashlib
import time
import os
import urllib.parse
from flask import Flask, request, redirect

app = Flask(__name__)

# Ensure secret key is configured in environment variables
SECRET_KEY = os.environ["ATTRIBUTION_SECRET_KEY"]
TTL_SECONDS = 172800  # 48-hour expiration window

@app.route("/app-routing", methods=["GET"])
def handle_tracking_url_redirection():
    # Extract query parameters
    app_key = request.args.get("appKey")
    channel_code = request.args.get("channelCode")
    provided_signature = request.args.get("sign")

    # Step 1: Safely parse timestamp and prevent negative or future timestamp exploits
    try:
        timestamp = int(request.args.get("ts", 0))
    except (ValueError, TypeError):
        return redirect("https://example.com/fallback-invalid-timestamp", code=302)

    current_time = int(time.time())
    
    # Check TTL bounds and block future timestamps (clock skew threshold: 300s)
    if (current_time - timestamp) > TTL_SECONDS or timestamp > (current_time + 300):
        return redirect("https://example.com/fallback-expired", code=302)

    # Step 2: Construct canonical query dictionary including all routing parameters
    params = {
        "appKey": app_key or "",
        "channelCode": channel_code or "",
        "ts": str(timestamp),
        "utm_source": request.args.get("utm_source", ""),
        "utm_medium": request.args.get("utm_medium", ""),
        "utm_campaign": request.args.get("utm_campaign", "")
    }

    # Deterministically sort and URL-encode parameter keys and values prior to signing
    # Maintain all expected parameters in canonical string for strict client-server verification
    canonical_string = "&".join(
        f"{urllib.parse.quote(str(k))}={urllib.parse.quote(str(v))}"
        for k, v in sorted(params.items())
    )

    computed_hash = hmac.new(
        SECRET_KEY.encode("utf-8"),
        canonical_string.encode("utf-8"),
        hashlib.sha256
    ).hexdigest()

    # Step 3: Constant-time comparison to prevent timing attacks
    if not hmac.compare_digest(computed_hash, provided_signature or ""):
        # Signature mismatch - route to default fallback without attribution credit
        return redirect("https://example.com/fallback-unauthorized", code=302)

    # Step 4: Parse User-Agent for OS-level auto-routing
    user_agent = request.headers.get("User-Agent", "").lower()

    if "iphone" in user_agent or "ipad" in user_agent:
        # Route iOS users to App Store while keeping click context on backend
        return redirect("https://apps.apple.com/app/id123456789", code=302)
    elif "android" in user_agent:
        # Properly encode multiple Play Referrer parameters
        referrer_params = {
            "utm_source": channel_code or "unknown",
            "utm_medium": request.args.get("utm_medium", "campaign_link"),
            "utm_campaign": request.args.get("utm_campaign", "organic")
        }
        encoded_referrer = urllib.parse.urlencode(referrer_params)
        return redirect(f"https://play.google.com/store/apps/details?id=com.example.app&referrer={encoded_referrer}", code=302)
    else:
        # Route desktop/unknown browsers to H5 landing page
        return redirect("https://example.com/landing_page", code=302)

ตัวอย่างต่อไปนี้แสดงบันทึกการทำงานของเซิร์ฟเวอร์และสคีมา JSON ของส่วนหัวการเปลี่ยนเส้นทางสำหรับการตรวจสอบความถูกต้องของลิงก์ติดตาม

// File path: server/schemas/tracking_url_redirection_response.json
{
  "response_header": {
    "status_code": 302,
    "location_target": "https://apps.apple.com/app/id123456789",
    "cache_control": "no-cache, no-store, must-revalidate"
  },
  "server_execution_log": {
    "incoming_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15",
    "detected_os": "iOS",
    "hmac_signature_validation": "PASSED",
    "timestamp_delta_seconds": 12,
    "matched_channel_code": "partner_402"
  }
}

สามารถดูข้อมูลจำเพาะเพิ่มเติมและแนวทางการรวมระบบได้ใน คู่มือการกำหนดค่า URL ติดตาม และส่วน ดาวน์โหลด SDK สำหรับการระบุแหล่งที่มาบนมือถือ

ข้อผิดพลาดทั่วไปในการทำเครื่องมือติดตาม URL

การกำหนดค่าลิงก์ระบุแหล่งที่มาบนมือถืออาจพบกรณีเฉพาะทางที่อาจส่งผลต่อความแม่นยำของข้อมูลหากจัดการอย่างไม่ถูกต้อง:

• การเปิดเผยคีย์แบบไดนามิกที่ไม่ได้แฮช: การแนบรหัสผู้ใช้หรือพันธมิตรที่ละเอียดอ่อนในรูปแบบข้อความธรรมดา ทำให้สามารถแก้ไขพารามิเตอร์โดยไม่ได้รับอนุญาตได้
• สตริงการค้นหาที่ไม่ได้จัดการอักขระพิเศษ: การไม่เข้ารหัส URL สำหรับอักขระพิเศษในชื่อแคมเปญ ทำให้เกิดข้อผิดพลาดในการแยกวิเคราะห์การเปลี่ยนเส้นทางบนเบราว์เซอร์มือถือ
• การละเว้นพารามิเตอร์ประทับเวลา: การสร้าง URL ติดตามแบบคงที่โดยไม่มีขีดจำกัด TTL ทำให้ปลายทางของแคมเปญเสี่ยงต่อการถูกโจมตีแบบเล่นซ้ำในระยะยาว
• โดเมนที่ไม่ได้รับอนุญาต: การปรับใช้โดเมนติดตามแบบกำหนดเองโดยไม่ปรับปรุงไฟล์ยืนยันตัวตน Associated Domains ของ iOS หรือ App Links ของ Android ทำให้การจัดการ Universal Link ทำงานผิดพลาด

ตัวอย่าง: การรักษาความปลอดภัยลิงก์พันธมิตรข้ามช่องทางจากการถูกแก้ไข

สถานการณ์จำลอง: การรวมแคมเปญการตลาดแบบพันธมิตรบนมือถือ

ความท้าทาย

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

การดำเนินการ

ทีมวิศวกรได้ปรับปรุงโครงสร้างพื้นฐานของลิงก์โดยบังคับใช้การตรวจสอบลายเซ็น HMAC-SHA256 ใน URL แคมเปญแบบไดนามิกทั้งหมด กำหนดค่าหน้าต่าง TTL 48 ชั่วโมง และกำหนดเส้นทางข้อมูลย้อนกลับ (Postbacks) ผ่าน Webhooks ที่ปลอดภัยจากเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ การกำหนดค่าแคมเปญถูกจัดตั้งขึ้นบนระบบจัดการแคมเปญ

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

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

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

• ลงนามพารามิเตอร์แบบไดนามิกฝั่งเซิร์ฟเวอร์: แฮชเชิงรหัสผ่านป้องกันการปรับเปลี่ยนพารามิเตอร์ที่ฝั่งไคลเอ็นต์
• บังคับใช้หน้าต่างหมดอายุของ TTL: การจำกัดความถูกต้องของลิงก์ช่วยป้องกันการใช้ประโยชน์จากการเล่นซ้ำบน URL เก่า
• ตรวจสอบลายเซ็นบน Postbacks ของเซิร์ฟเวอร์: การตรวจสอบแฮชซ้ำระหว่างการตรวจสอบ Postback ช่วยรักษาความปลอดภัยของท่อจ่ายค่าตอบแทน

URL ติดตาม vs ลิงก์ดาวน์โหลดแบบคงที่ vs URL ของ App Store ดั้งเดิม

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

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

เลือกระบบ URL ติดตามอัตโนมัติเมื่อแคมเปญของคุณตรงกับเกณฑ์การใช้งานต่อไปนี้:

• ✓ การโปรโมตแบบหลายช่องทางต้องการการระบุแหล่งที่มา: ข้อกำหนดการวัดผลการได้มาซึ่งผู้ใช้ต้องอาศัยการตรวจสอบว่าพันธมิตร ผู้มีอิทธิพล หรือเครือข่ายโฆษณาใดเป็นผู้ขับเคลื่อนการติดตั้ง
• ✓ ลิงก์แคมเปญเสี่ยงต่อการฉ้อโกงสาธารณะ: การกระจายลิงก์เกิดขึ้นผ่านเครือข่ายของบุคคลที่สามที่ไม่น่าเชื่อถือซึ่งเสี่ยงต่อการแก้ไขพารามิเตอร์
• ✓ การเข้าชมข้ามแพลตฟอร์มต้องการการกระจายด้วยลิงก์เดียว: สินทรัพย์ทางการตลาดต้องการ URL ติดตามเดียวที่สามารถกำหนดเส้นทางอัตโนมัติทั้งสำหรับ Android และ iOS
• ✓ การประมวลผลการจ่ายค่าตอบแทนต้องการการตรวจสอบฝั่งเซิร์ฟเวอร์: รางวัลสำหรับผู้แนะนำต้องมีเหตุการณ์คอนเวอร์ชันที่ผ่านการยืนยันเชิงรหัสผ่านก่อนที่จะมีการชำระเงิน

ในสถานการณ์เหล่านี้ การปรับใช้กรอบงาน URL ติดตามที่ปลอดภัยจะช่วยให้มีสถาปัตยกรรมที่ใช้งานได้จริง ลิงก์ติดตามเฉพาะช่วยให้ทีมพัฒนามือถือสามารถวัดประสิทธิภาพแคมเปญในขณะที่รักษาความสมบูรณ์ของข้อมูล แพลตฟอร์มอย่าง OpoInstall ใช้กรอบงานนี้เพื่อรองรับการสร้าง URL แบบไดนามิกและ Postback ของเซิร์ฟเวอร์ที่ปลอดภัย

อภิธานศัพท์

ข้อมูลเพิ่มเติม

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

• Install Attribution: ท่อส่งการวัดผลพื้นฐานที่ระบุแหล่งที่มาของการดาวน์โหลดแอปพลิเคชัน
• Click Spamming: วิธีการฉ้อโกงโฆษณาที่ผู้โจมตีทำให้เซิร์ฟเวอร์การจับคู่ท่วมไปด้วยการคลิกจำลอง
• Deferred Deep Linking: การเรียกคืนพารามิเตอร์เป้าหมายผ่าน App Store โดยอัตโนมัติ

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

• Google Play Install Referrer: API ดั้งเดิมของ Google ที่ส่งเมทาดาตาของแคมเปญ ณ เวลาติดตั้งบน Android
• Universal Links: มาตรฐาน Deep linking ดั้งเดิมของ Apple ที่เชื่อมโยงการกระทำบนเว็บเข้ากับหน้าจอ Native
• App Links: โปรโตคอล Deep linking ที่ได้รับการยืนยันของ Google ที่จัดการ URL เว็บกำหนดเองบน Android

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

• IETF RFC 2104: ข้อมูลจำเพาะ Keyed-Hashing สำหรับการตรวจสอบความถูกต้องของข้อความเพื่อความปลอดภัยของ HMAC

อินเทอร์เฟซการเชื่อมต่อหลัก

• Parameter Resolution Interface: กลไก SDK ไคลเอ็นต์ที่ใช้เพื่อสอบถามพารามิเตอร์การติดตั้งที่กำหนดเองในการเปิดใช้งานครั้งแรก
• Conversion Event Interface: กลไก SDK ไคลเอ็นต์ที่ใช้ในการอัปโหลดเหตุการณ์สำคัญในแอป

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

• ข้อกำหนด Google Play Services Install Referrer API
• แนวทางกรอบงาน App Tracking Transparency ของ Apple
• ข้อกำหนด IETF RFC 2104 HMAC
• คู่มือการทดสอบความปลอดภัยแอปมือถือ OWASP