สิ่งที่ AppsFlyer รวบรวม

AppsFlyer SDK เริ่มต้นเซสชันทันทีที่แอปโฮสต์เริ่มทำงาน และโดยค่าเริ่มต้น จะรวบรวมชุดตัวระบุและสัญญาณบริบท ได้แก่ ตัวระบุโฆษณาระดับอุปกรณ์ (IDFA บน iOS, GAID บน Android), IDFV ที่มีขอบเขตตามผู้ขายบน iOS, รหัสการติดตั้ง AppsFlyer ที่สร้างขึ้นซึ่งคงอยู่ตลอดเซสชัน, ที่อยู่ IP (ใช้สำหรับ geo-IP และสำหรับการจับคู่แบบความน่าจะเป็นในสไตล์ลายนิ้วมือ), user agent, รุ่นอุปกรณ์, เวอร์ชัน OS, ผู้ให้บริการ และเขตเวลา หลังจากการติดตั้ง SDK จะรายงานเหตุการณ์การติดตั้งไปยังเซิร์ฟเวอร์ของ AppsFlyer ซึ่งจะถูกจับคู่กับข้อมูลคลิกที่ส่งต่อโดยเครือข่ายโฆษณา เหตุการณ์ภายในแอปที่ตามมา — Purchase, RegistrationComplete, Tutorial Complete, Custom — ยิงผ่าน SDK เดียวกันและสืบทอดชุดตัวระบุเดียวกัน

หน่วยงานกำกับดูแลได้ระบุอย่างชัดเจนว่านี่คือการประมวลผลข้อมูลส่วนบุคคลภายใต้ GDPR IDFA และ GAID เป็นข้อมูลส่วนบุคคลเพราะเป็นตัวระบุถาวรระดับอุปกรณ์ การจับคู่ลายนิ้วมือแบบความน่าจะเป็นที่ทำงานควบคู่กันยากยิ่งขึ้นในการปกป้องโดยไม่มีการยินยอม เนื่องจากโดยนิยามแล้วคือความพยายามระบุตัวตนผู้ใช้โดยไม่มีความร่วมมืออย่างชัดแจ้งของพวกเขา CNIL, Garante ของอิตาลี และ AEPD ของสเปน ต่างเปิดการสอบสวนต่อผู้เผยแพร่ที่สแต็คการระบุแหล่งที่มายิงก่อนได้รับการยินยอม

การควบคุมความเป็นส่วนตัวเนทีฟของ AppsFlyer

AppsFlyer เปิดเผย primitives ความเป็นส่วนตัวเนทีฟที่มีความหมาย สิ่งเหล่านี้ไม่ใช่การทดแทนเฟรมเวิร์กการยินยอมจริง แต่การเข้าใจสิ่งเหล่านั้นเป็นสิ่งสำคัญเพราะเป็นคันโยกที่ CMP ใช้ควบคุมพฤติกรรม SDK

Start SDK API

SDK รองรับโหมดการเริ่มต้นที่ได้รับการกำหนดค่าแต่ไม่ส่งข้อมูลใดๆ จนกว่าจะมีการเรียก start() อย่างชัดเจน นี่คือ hook ที่สำคัญที่สุดเพียงตัวเดียวสำหรับการ gating การยินยอม — โดยค่าเริ่มต้น SDK จะเริ่มทำงานโดยอัตโนมัติเมื่อเปิดแอป ซึ่งเป็นพฤติกรรมที่ผิดสำหรับเขตอำนาจศาลใดๆ ที่มีข้อกำหนดการยินยอมล่วงหน้า ตั้งค่า isStopped เป็น true ในระหว่างการเริ่มต้น หรือใช้ API การเริ่มแบบเลื่อนออกไป และเรียก start() เฉพาะเมื่อสัญญาณการยินยอมถูกบันทึก

Stop API

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

setSharingFilter

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

การรวมระบบกับ Apple App Tracking Transparency

บน iOS, AppsFlyer อ่านสถานะการอนุญาต ATT และปรับพฤติกรรมโดยอัตโนมัติ — หากผู้ใช้ปฏิเสธ ATT, IDFA จะไม่ถูกส่ง ATT เป็นอิสระจากการยินยอม GDPR และผู้เผยแพร่หลายคนสับสนระหว่างสองอย่างนี้ ATT ควบคุมสัญญาณระดับ iOS เพียงสัญญาณเดียว ส่วนการยินยอม GDPR ควบคุมทุกอย่างอื่น

การรวมระบบบน iOS

รูปแบบที่น่าเชื่อถือบน iOS คือการติดตั้ง AppsFlyer SDK แต่เลื่อนการเริ่มต้นออกไปจนกว่าทั้ง ATT และขั้นตอนการยินยอมภายในแอปจะเสร็จสิ้น ลำดับขั้นต่ำคือ: แอปเปิดตัว, SDK ถูกกำหนดค่าด้วย isStopped = true, แบนเนอร์การยินยอมภายในแอปแสดงขึ้น, ผู้ใช้ยอมรับหมวดหมู่ที่เกี่ยวข้อง, แฟล็ก isStopped ของ SDK ถูกล้างและเรียก start() หากแอปยังต้องการ ATT ด้วย (ซึ่งต้องการสำหรับผู้ใช้ทุกคนที่ IDFA มีความหมาย), คำขอ ATT จะแสดงพร้อมกับหรือหลังจากแบนเนอร์ภายในแอป CMP ส่วนใหญ่ที่รองรับมือถือมี API ที่ใช้ callback ซึ่งส่งการตัดสินใจการยินยอม callback นั้นคือที่ที่เหมาะสมในการเรียก start()

การรวมระบบบน Android

การใช้งาน Android ขนานกับ iOS ด้วยความแตกต่างสองประการ ประการแรก ไม่มีสิ่งเทียบเท่า ATT — GAID พร้อมใช้งานเว้นแต่ผู้ใช้จะเปิดใช้งานการตั้งค่า "ลบรหัสโฆษณา" ระดับอุปกรณ์ของพวกเขา ซึ่งผู้ใช้ส่วนใหญ่ไม่ทำ ประการที่สอง วงจรชีวิตของ Android มีความก้าวร้าวมากขึ้นเกี่ยวกับการทำงานเบื้องหลัง ดังนั้นการเริ่มต้น SDK จำเป็นต้องเชื่อมโยงกับสถานะการยินยอมที่จัดเก็บอย่างถาวร อ่านสถานะการยินยอมจากที่จัดเก็บในเครื่องเมื่อเปิดแอป กำหนดค่า SDK ตามนั้น และตรวจสอบอีกครั้งเมื่อกลับมาในกรณีที่ผู้ใช้อัปเดตตัวเลือกของพวกเขาในขณะที่แอปอยู่เบื้องหลัง

การรวมระบบบนเว็บบนมือถือ

AppsFlyer ยังทำงานบนเว็บบนมือถือผ่านแบนเนอร์อัจฉริยะและผลิตภัณฑ์ OneLink สิ่งเหล่านี้โดยพื้นฐานคือเครื่องมือวิเคราะห์ฝั่งเว็บและ deep-link ที่วางคุกกี้และเรียกเซิร์ฟเวอร์ AppsFlyer จากเบราว์เซอร์ สิ่งเหล่านี้ปฏิบัติตามกฎเดียวกันกับพื้นผิวการติดตามเว็บอื่นๆ: วางไว้หลังหมวดหมู่การตลาดของ CMP ไม่ให้สคริปต์แบนเนอร์อัจฉริยะทำงานก่อนได้รับการยินยอม และตรวจสอบให้แน่ใจว่าเหตุการณ์ใดๆ ที่ OnLlink ทริกเกอร์จากแคมเปญอีเมลหรือ push เคารพสถานะการยินยอมของผู้ใช้

ข้อผิดพลาดทั่วไป

ข้อผิดพลาดในการรวมระบบสี่ประการปรากฏซ้ำๆ ในการตรวจสอบการปรับใช้ AppsFlyer

การปฏิบัติต่อ ATT เป็นการยินยอม GDPR

ATT และการยินยอม GDPR เป็นสัญญาณที่แตกต่างกันด้วยขอบเขตที่แตกต่างกัน ผู้ใช้ที่ยอมรับ ATT ได้อนุญาตการใช้ IDFA สำหรับการติดตามข้ามแอป พวกเขายังไม่ได้อนุญาตทุกอย่างที่ SDK ทำ สำหรับปริมาณการใช้งาน EU และ UK ต้องการสัญญาณทั้งสองอย่าง โดยแบนเนอร์ภายในแอปเป็นสัญญาณที่มีผลผูกพันและ ATT เป็นเลเยอร์เฉพาะ iOS ด้านบน

การปล่อยให้ SDK เริ่มต้นเมื่อเปิดแอป

นี่คือข้อบกพร่องเดี่ยวที่พบบ่อยที่สุด การรวมระบบเริ่มต้นเรียก start() ทันที ซึ่งยิงเหตุการณ์การติดตั้งพร้อม payload ตัวระบุเต็มรูปแบบก่อนที่ผู้ใช้จะเห็นแบนเนอร์การยินยอม การแก้ไขนั้นตรงไปตรงมา: กำหนดค่า isStopped = true ในเวลาการรวมระบบ และเรียก start() เฉพาะจาก callback การยินยอมเท่านั้น

การลืมจัดการการถอน

หากผู้ใช้ยอมรับแล้วถอนภายหลัง SDK จะต้องได้รับแจ้งให้หยุดการส่ง ใช้ stop() API และอัปเดตสถานะการยินยอมที่บันทึกไว้เพื่อให้การเปิดแอปครั้งถัดไปเคารพการตัดสินใจใหม่

การละเลย postbacks แบบ server-to-server

AppsFlyer ส่งต่อเหตุการณ์การแปลงไปยังเครือข่ายโฆษณาที่รวมไว้จำนวนมากผ่าน postbacks ฝั่งเซิร์ฟเวอร์ การส่งต่อแต่ละครั้งมีข้อมูลส่วนบุคคลและสืบทอดขอบเขตการยินยอมของเหตุการณ์ต้นฉบับ ใช้ setSharingFilter เพื่อให้แน่ใจว่าการส่งต่อไปยังพาร์ทเนอร์ที่ครอบคลุมโดยตัวเลือกการยินยอมของผู้ใช้เท่านั้น ไม่ใช่ทุกพาร์ทเนอร์ใน AppsFlyer dashboard ของคุณ

รายการตรวจสอบการตรวจสอบ

คำถามเฉพาะหกข้อที่ต้องตอบสำหรับการปรับใช้ AppsFlyer ที่สัมผัสกับปริมาณการใช้งาน EU, UK หรือ California

• SDK รอการยินยอมหรือไม่? ในการติดตั้งใหม่บนอุปกรณ์ทดสอบที่ตั้งอยู่ใน EU ยืนยันว่าไม่มี endpoint AppsFlyer ใดที่รับคำขอใดๆ ก่อนที่ผู้ใช้จะยอมรับแบนเนอร์
• ATT แยกจากการยินยอมภายในแอปหรือไม่? ยืนยันว่าแบนเนอร์ภายในแอปคือสัญญาณการยินยอมที่ควบคุมและ ATT ถูกปฏิบัติเป็นเลเยอร์เพิ่มเติมเฉพาะ iOS
• การส่งต่อพาร์ทเนอร์มีขอบเขตของการยินยอมหรือไม่? ยืนยันว่า setSharingFilter ถูกกำหนดค่าเพื่อยกเว้นพาร์ทเนอร์ที่ผู้ใช้ไม่ได้อนุญาต
• การถอนหยุด SDK หรือไม่? ยืนยันว่าการเรียก stop() ทำงานเมื่อถอนการยินยอมและสถานะใหม่คงอยู่ตลอดการเปิดแอป
• postbacks ของเซิร์ฟเวอร์ถูกตรวจสอบหรือไม่? ยืนยันว่ารายการ "Configured integrations" ของ AppsFlyer dashboard จับคู่อย่างสะอาดกับพาร์ทเนอร์การตลาดที่เปิดเผยในแบนเนอร์
• การลบข้อมูลเป็นอัตโนมัติหรือไม่? ยืนยันว่าคำขอ DSAR ทริกเกอร์ API การลบของ AppsFlyer ไม่ใช่ตั๋วด้วยตนเอง

AppsFlyer อยู่ที่ไหนในสแต็กที่ยินยอมเป็นอันดับแรก

การระบุแหล่งที่มาบนมือถือเป็นหนึ่งในพื้นผิวที่มีตัวระบุหนาแน่นที่สุดในสแต็กการตลาด และ SDK ของ AppsFlyer เป็นหนึ่งในการรวมระบบเดี่ยวที่มีผลสำคัญที่สุด ข่าวดีคือแพลตฟอร์มเปิดเผย primitives — Start SDK, Stop, ตัวกรองการแชร์, API การลบ — ที่จำเป็นสำหรับทำให้การบังคับใช้การยินยอมสะอาดและตรวจสอบได้ งานสำหรับผู้เผยแพร่คือการเชื่อมต่อ primitives เหล่านั้นกับ CMP ที่เป็นเจ้าของการตัดสินใจการยินยอมที่มีผลผูกพัน ปฏิบัติต่อ ATT เป็นสัญญาณเสริมแทนการแทนที่ และตรวจสอบให้แน่ใจว่าการส่งต่อพาร์ทเนอร์ฝั่งเซิร์ฟเวอร์ไม่สามารถหลุดรอดออกจากซองการยินยอมที่แบนเนอร์บันทึกไว้ได้ เมื่อทำอย่างถูกต้อง ผลลัพธ์คือสแต็กการระบุแหล่งที่มาที่ตอบสนองหน่วยงานกำกับดูแลในขณะที่รักษาข้อมูลการติดตั้งและเหตุการณ์ที่ทีมการซื้อผู้ใช้พึ่งพา