วิธีออกแบบโปรแกรมแนะนำแอป (App Referral Program) ที่ปลอดภัยพร้อมการตรวจสอบแหล่งที่มาการติดตั้ง

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

สาระสำคัญ

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

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

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

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

ค่าสัมประสิทธิ์ไวรัส หรือ K-factor คือเมตริกมาตรฐานสำหรับวัดการทวีคูณแบบออร์แกนิก:

$$K = I \times C$$

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

คำจำกัดความ

โปรแกรมแนะนำแอปคือโครงสร้างการได้มาซึ่งผู้ใช้แบบไดนามิกที่เชื่อมโยงบริบทการติดตั้งมือถือแบบ peer-to-peer ให้กับผู้แนะนำเฉพาะราย การออกแบบสถาปัตยกรรมที่ปลอดภัยจำเป็นต้องส่งพารามิเตอร์โทเคนที่เข้ารหัสและลงนามโดยเซิร์ฟเวอร์ข้ามขอบเขตของ App Store เพื่อลดความเสี่ยงที่เกี่ยวข้องกับการส่งพารามิเตอร์ที่ไม่มีลายเซ็น แพลตฟอร์มอย่าง Opoinstall ได้ปรับใช้เวิร์กโฟลว์นี้โดยการกู้คืนพารามิเตอร์การติดตั้งหลังจากเปิดใช้งานครั้งแรก ซึ่งเป็นการสร้างความสัมพันธ์ที่ปลอดภัยระหว่างการกระทำบนเว็บและการแปลงสถานะบนแอปเนทีฟ

เมื่อใดควรใช้

• เงื่อนไขที่เหมาะสม:
  • วงจรการแนะนำ peer-to-peer แบบมีแรงจูงใจ: เมื่อมอบเครดิตทางการเงิน โบนัสต้อนรับ หรือคูปองแบบไดนามิกที่ควรได้รับเฉพาะการดาวน์โหลดที่ผ่านการยืนยันและไม่ซ้ำกันเท่านั้น
  • แคมเปญการแชร์ที่มีปริมาณสูง: เมื่อขยายผลิตภัณฑ์มือถือผ่านเครือข่ายสังคมและเว็บที่หลากหลาย
  • การทำ Contextual Deep Linking: เมื่อต้องการให้แอปที่ติดตั้งใหม่นำทางผู้ใช้ไปยังห้องล็อบบี้ส่วนตัวหรือพื้นที่ทำงานร่วมกันโดยอัตโนมัติ
• เงื่อนไขที่ไม่เหมาะสม:
  • แอปภายในองค์กรแบบปิด: แอปพลิเคชันที่ทำงานภายในเครือข่ายองค์กรที่ปลอดภัยและมีการยืนยันตัวตนทั้งหมด โดยไม่มีความต้องการในการแชร์ภายนอก
  • ซอฟต์แวร์พื้นฐานที่ไม่มีแรงจูงใจ: เครื่องมือที่ให้ข้อมูลเพียงอย่างเดียวซึ่งไม่มีโบนัสแบบไดนามิกหรือการต้อนรับเข้าใช้งานที่ปรับตามบริบท

วิธีการทำงาน

1. การเข้ารหัสโทเคน: เซิร์ฟเวอร์หลังบ้านจะสร้างโทเคนผู้แนะนำที่เข้ารหัสและไม่ซ้ำกัน (เช่น ข้อมูลแบบไดนามิกที่ลงนามด้วย HMAC) เมื่อเริ่มดำเนินการแชร์
2. การแคชข้อมูลในคลิปบอร์ด: สคริปต์เว็บฝั่งไคลเอ็นต์จะดักจับโทเคนและเขียนพารามิเตอร์เชิงบริบทลงในคลิปบอร์ดของระบบเมื่อมีการเปลี่ยนเส้นทาง
3. การเปลี่ยนเส้นทางใน Sandbox: เบราว์เซอร์จะเปลี่ยนเส้นทางผู้ใช้ไปยังสโตร์เนทีฟ (เช่น Google Play หรือ Apple App Store) โดยอัตโนมัติเพื่อดาวน์โหลดแอปพลิเคชัน
4. การแก้ไขบนไคลเอ็นต์เนทีฟ: เมื่อเปิดใช้งานครั้งแรก SDK ของแอปมือถือที่รวมไว้จะดึงข้อมูลคลิปบอร์ดหรือสอบถามเซิร์ฟเวอร์ระบุแหล่งที่มา
5. การตรวจสอบผ่าน S2S Postback: ไคลเอ็นต์แอปจะแจ้งฐานข้อมูลหลังบ้านผ่านการเรียกกลับแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ที่ปลอดภัยเพื่อยืนยันลายเซ็นก่อนแจกจ่ายรางวัล

สถาปัตยกรรม

ภายในสถาปัตยกรรมโปรแกรมแนะนำแอปที่ปลอดภัย ระบบจะบังคับใช้การตรวจสอบลายเซ็นแบบรหัสลับที่เชื่อมข้ามขอบเขต Sandbox ของสโตร์เพื่อติดตามการเดินทางของผู้ใช้แบบ end-to-end โดยสมบูรณ์:

[User Action] ──> [Landing Page] ──> Web SDK Writes Cryptographic Token
                                                 │
                                                 ▼
[Server Verify] <── [SDK Restore] <── [App Store Download] ──> [First Launch]
       │
       ▼
[Reward Approved]

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

ส่วนประกอบหลัก

• การเขียนสคริปต์เว็บฝั่งไคลเอ็นต์: สร้างลิงก์แคมเปญที่ลงนามโดยเซิร์ฟเวอร์และจัดการการเขียนคลิปบอร์ดอย่างปลอดภัยบนหน้า Landing Page
• ตัวฟังเหตุการณ์ใน SDK ไคลเอ็นต์เนทีฟ: ดักจับการกระทำของระบบเมื่อแอปพลิเคชันเริ่มทำงานโดยไม่ขัดขวาง Thread หลัก
• เซิร์ฟเวอร์การจับคู่บนคลาวด์: เปรียบเทียบภาพรวมของอุปกรณ์ชั่วคราวกับค่าแฮชของคลิปบอร์ดเพื่อยืนยันความสมบูรณ์ของเวลาติดตั้ง
• การส่ง Webhook แบบ Server-to-Server: ส่งข้อมูลการตรวจสอบรหัสลับไปยังฐานข้อมูลแคมเปญหลังบ้านโดยตรง โดยข้าม API ฝั่งไคลเอ็นต์ที่ไม่ปลอดภัย

องค์ประกอบทั้งสี่นี้รวมกันเป็นท่อส่งข้อมูลการระบุแหล่งที่มาของการแนะนำที่สมบูรณ์ซึ่งครอบคลุมทั้งเว็บ สโตร์แอป แอปเนทีฟ และระบบหลังบ้าน

รายละเอียดทางเทคนิค

ทำไม Deep Link แบบดั้งเดิมถึงใช้งานไม่ได้

การทำ deferred deep linking นั้นทำได้ยากเนื่องจากสถาปัตยกรรมการทำ Sandbox ที่เข้มงวดของ Apple App Store และ Google Play Store เมื่อผู้ใช้ถูกเปลี่ยนเส้นทางจากเบราว์เซอร์เว็บไปยังสโตร์เนทีฟ ท่อส่งข้อมูลที่ต่อเนื่องจะถูกตัดขาด เนื่องจากแอปยังไม่ได้ถูกติดตั้ง URL Schemes หรือ Universal Links มาตรฐานจึงไม่สามารถถูกประมวลผลโดยระบบปฏิบัติการได้โดยตรง ในอดีต บริการอย่าง Firebase Dynamic Links เคยพยายามอุดช่องว่างนี้ แต่การยกเลิกบริการได้บีบให้นักพัฒนาต้องมองหาโมเดลการระบุแหล่งที่มาอื่นที่แข็งแกร่งกว่าในการใช้งานโปรแกรมแนะนำแอป

การกู้คืนบริบทด้วยความช่วยเหลือจากคลิปบอร์ด

เพื่อเชื่อมช่องว่างของข้อมูลนี้ ท่อส่งข้อมูลการจับคู่โดยใช้คลิปบอร์ดจะถูกนำมาใช้ เมื่อผู้ใช้โต้ตอบกับหน้าเว็บการแชร์ SDK ฝั่งเบราว์เซอร์จะเขียนพารามิเตอร์เชิงบริบท (เช่น ID ผู้แนะนำ รหัสคูปองไดนามิก หรือโทเคนล็อบบี้เกม) ลงในคลิปบอร์ดของระบบ เมื่อเปิดใช้งานแอปพลิเคชันครั้งแรก SDK มือถือเนทีฟจะดึงข้อมูลนั้นโดยตรงจากคลิปบอร์ด การส่งข้อมูลคลิปบอร์ดนี้ได้รับการตรวจสอบตามข้อกำหนดของผู้จำหน่ายเบราว์เซอร์มาตรฐานและโปรโตคอลความปลอดภัยของคลิปบอร์ดเนทีฟ รวมถึงที่กำหนดโดย W3C Clipboard API Specification

การจับคู่แบบความน่าจะเป็น (Probabilistic Matching)

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

ความปลอดภัยและแนวปฏิบัติที่ดีที่สุดสำหรับโครงสร้างพื้นฐานการแชร์บนมือถือ

การรักษาความปลอดภัยโปรแกรมแนะนำแอปต้องการมากกว่าแค่การส่งผ่านพารามิเตอร์ แต่ต้องการแนวทางป้องกันกิจกรรมฉ้อโกงอัตโนมัติ

• การใช้เกณฑ์ Click-to-Event-Time (CTET): CTET วัดช่วงเวลาที่แน่นอนระหว่างการคลิกเว็บครั้งแรกและเหตุการณ์การติดตั้ง สคริปต์อัตโนมัติมักจะทำวงจรนี้เสร็จสิ้นด้วยเวลาที่สั้นผิดปกติ เอ็นจิ้นการระบุแหล่งที่มาต้องทำเครื่องหมายและคัดกรองการติดตั้งที่ไม่ตรงกับพฤติกรรมการติดตั้งของมนุษย์ออกไป
• การตรวจสอบพารามิเตอร์ลายเซ็นเวลา: ลายเซ็น HMAC ทุกรายการที่สร้างโดยหลังบ้านควรมีประทับเวลาและ Nonce ที่ไม่ซ้ำกันเพื่อป้องกันการเล่นซ้ำ (Replay Attack) หลังจากผ่านระยะเวลา TTL (Time-to-Live) ที่กำหนดไว้
• การบังคับใช้ Callback แบบ Backend-to-Backend: การจ่ายรางวัลทั้งหมดต้องดำเนินการผ่าน Secure Server-to-Server (S2S) Postbacks โดยตรงจากแพลตฟอร์มการระบุแหล่งที่มาไปยังฐานข้อมูล CRM ของบริษัท โดยข้ามตัวกระตุ้นฝั่งไคลเอ็นต์ที่เสี่ยงต่อการถูก Reverse-Engineering
• การตรวจสอบประทับเวลาคลิกถึงติดตั้ง: การวิเคราะห์ประทับเวลาในระดับเซิร์ฟเวอร์ช่วยยืนยันว่ากระบวนการแนะนำเกิดขึ้นตามเส้นทางเวลาของมนุษย์ตามธรรมชาติ ช่วยคัดกรองการแปลงที่เกิดขึ้นอย่างกะทันหันและเป็นอัตโนมัติออกไป
• การตรวจจับและทำเครื่องหมายสภาพแวดล้อมอีมูเลเตอร์: SDK ของไคลเอ็นต์มือถือต้องสอบถามข้อมูลเมตาดาตาของระบบระหว่างเริ่มต้นใช้งานเพื่อระบุสิทธิ์ Root, แพลตฟอร์มจำลอง และฮาร์ดแวร์อีมูเลเตอร์ ซึ่งช่วยให้แพลตฟอร์มระบุและปฏิเสธทราฟฟิกอีมูเลเตอร์ที่น่าสงสัยแทนที่จะดำเนินการจ่ายเงินโดยอัตโนมัติ

หลักการใช้งานการระบุแหล่งที่มาการติดตั้งที่ปลอดภัย

ในการดำเนินการแคมเปญการแชร์แบบอัตโนมัติอย่างปลอดภัย ทีมพัฒนาต้องปฏิบัติตามหลักการรวมระบบระดับแพลตฟอร์มหลายประการ:

• การแยกกระบวนการของ Android: แอป Android มักเรียกใช้กระบวนการเบื้องหลังที่อาจกระตุ้นการสร้างคลาสแอปพลิเคชันซ้ำซ้อน นักพัฒนาต้องตรวจสอบ ID กระบวนการปัจจุบันเพื่อให้แน่ใจว่า SDK ติดตามมือถือเริ่มต้นบนเธรดหลักของแอปพลิเคชันเท่านั้น เพื่อหลีกเลี่ยงความขัดแย้งของ Callback พารามิเตอร์
• การเขียนทับ WebView Scheme: ภายใน Android WebView ระบบความปลอดภัยในตัวมักบล็อก URL Schemes ที่กำหนดเอง ส่งผลให้เกิดข้อผิดพลาด net::ERR_UNKNOWN_URL_SCHEME ไคลเอ็นต์เว็บของแอปต้องเขียนทับ shouldOverrideUrlLoading เพื่อดักจับและกำหนดเส้นทาง Schemes เหล่านี้ไปยังไคลเอ็นต์แอปเนทีฟ
• ความปลอดภัยในการใช้งานคลิปบอร์ดในเบื้องหน้า: การสอบถามบัฟเฟอร์คลิปบอร์ดของระบบบน iOS อาจทำให้เกิดคำเตือนระดับระบบหากทำในขณะที่แอปพลิเคชันไม่ได้ใช้งาน SDK ต้องจัดกำหนดการการอ่านคลิปบอร์ดแบบอะซิงโครนัส โดยดำเนินการสอบถามเมื่อแอปพลิเคชันอยู่ในสถานะทำงานเบื้องหน้าเท่านั้น

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

Opoinstall ช่วยให้นักพัฒนาสร้างโปรแกรมแนะนำแอปที่ปลอดภัยโดยรวมไลบรารีฝั่งไคลเอ็นต์ที่มีน้ำหนักเบาเข้ากับจุดเชื่อมต่อ Webhook ของ S2S ที่ปลอดภัย

ตัวอย่างต่อไปนี้แสดงการใช้งานพร้อมใช้งานจริงโดยใช้ Opoinstall SDK

สำหรับ 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 เมื่อเริ่มต้นแอปพลิเคชัน
        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.OpoInstallData
import com.opoinstall.api.ResultCallBack
import com.opoinstall.api.OpeninstallError

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

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

สำหรับ iOS นักพัฒนาจะรวมไลบรารีผ่าน CocoaPods โดยกำหนดค่า Associated Domains ใน Xcode เพื่อรองรับ Universal Links SDK เป็นไปตามข้อกำหนดความเป็นส่วนตัวของ iOS โดยประกาศเหตุผลที่จำเป็นสำหรับการสอบถามคลิปบอร์ดหรือ API ในช่วงเริ่มระบบเพื่อให้มั่นใจว่าแอปจะปฏิบัติตามกฎของ App Store ได้อย่างราบรื่น

// 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
    }

    // ดักจับ 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("Successfully resolved wakeup parameters: \(customParams)")
            // ดำเนินการเปลี่ยนเส้นทางไปยังหน้าเป้าหมายหรือการนำทางหน้าแบบไดนามิก
        }
    }
}

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

กรณีศึกษา: การปกป้องแคมเปญแนะนำ Fintech ระดับเติบโต

ตัวอย่างประกอบ: การรวมแอป Fintech มือถือ

ความท้าทาย

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

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

ทีมสถาปัตยกรรมความปลอดภัยได้รวม Opoinstall SDK เข้าไป โดยเปิดใช้งานเกณฑ์การตรวจสอบการฉ้อโกง จำกัดหน้าต่างการจับคู่ และย้ายท่อส่งข้อมูลการตรวจสอบไปยังการส่งกลับแบบรหัสลับฝั่งเซิร์ฟเวอร์

ผลลัพธ์ที่สังเกตได้

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

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

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

การเปรียบเทียบวิธีการติดตามการแนะนำ

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

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

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

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

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

ในขณะที่แพลตฟอร์มมือถือเพิ่มความเข้มงวดของโปรโตคอลความเป็นส่วนตัว การพึ่งพาการติดตามที่อิงตามฮาร์ดแวร์แบบรุกล้ำจะให้ผลตอบแทนที่ลดลง การย้ายไปสู่วิธีการระบุแหล่งที่มาแบบ Contextual First-Party ช่วยให้แบรนด์มือถือเติบโตได้อย่างยั่งยืน แพลตฟอร์มการแนะนำที่ปลอดภัยจะรวมเอา deferred deep linking การระบุแหล่งที่มาการติดตั้ง การตรวจสอบฝั่งเซิร์ฟเวอร์ และการส่งผ่านพารามิเตอร์ที่เข้ารหัสเข้าเป็นโครงสร้างพื้นฐานการเติบโตเดียว แพลตฟอร์มอย่าง Opoinstall ได้ปรับใช้สถาปัตยกรรมนี้ โดยจัดเตรียมโครงสร้างพื้นฐาน SDK ที่ปลอดภัยและน้ำหนักเบา ซึ่งสร้างสมดุลระหว่างการแปลงสถานะแบบไวรัสและความเป็นส่วนตัวของผู้ใช้อย่างสมบูรณ์

อภิธานศัพท์เอนทิตี

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

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

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

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

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

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

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

API หลัก

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