iOS App Tracking Transparency (ATT) และการยินยอมคุกกี้สำหรับแอปแบบไฮบริดในปี 2026

แอปมือถือแบบไฮบริด — สถาปัตยกรรมที่เชลล์แบบเนทีฟบางๆ หุ้มเว็บวิวที่แสดงส่วนใหญ่ของอินเทอร์เฟซผู้ใช้ — มักดำรงชีวิตอยู่ในสองโลกของความเป็นส่วนตัวพร้อมกัน เชลล์แบบเนทีฟอยู่ภายใต้เฟรมเวิร์ก App Tracking Transparency (ATT) ของ Apple บน iOS และแผนงาน Privacy Sandbox ของ Google บน Android ส่วนเว็บวิวภายในอยู่ภายใต้กฎ GDPR, ePrivacy, CCPA และ CPRA เดียวกันกับที่ใช้กับเบราว์เซอร์ทุกตัว ห้าปีที่ผ่านมาผู้เผยแพร่พยายามปิดช่องว่างด้วยโซลูชันชั่วคราว และห้าปีที่ผ่านมาผู้ตรวจสอบ App Store และหน่วยงานกำกับดูแลของ EU ก็ปฏิเสธวิธีการแบบปะตรงนั้นในสัดส่วนที่เท่าๆ กัน ถึงปี 2026 คำถามว่า ATT และการยินยอมคุกกี้เข้ากันอย่างไรภายในแอปไฮบริดไม่ใช่แค่ระบบที่เลือกมีหรือไม่มีอีกต่อไป — แต่คือความแตกต่างระหว่างแอปที่เปิดตัว สร้างรายได้ และผ่านการตรวจสอบความเป็นส่วนตัว กับแอปที่ถูกถอดออกจากสโตร์หรือถูกปรับจนต้องสร้างใหม่ คู่มือนี้อธิบายว่า ATT ควบคุมอะไรจริงๆ สิ่งใดที่มันตั้งใจปล่อยให้เป็นเรื่องของการยินยอมเว็บ วิธีออกแบบขั้นตอนการขอสิทธิ์และการยินยอมให้ระบบทั้งสองมีความสอดคล้องกันแทนที่จะขัดแย้ง และรูปแบบวิศวกรรมที่ผ่านทั้งกระบวนการตรวจสอบของ Apple และการตรวจสอบของหน่วยงานกำกับดูแล

App Tracking Transparency ควบคุมอะไรจริงๆ

ATT คือประตูสิทธิ์ที่ Apple บังคับใช้ใน iOS และ iPadOS เมื่อแอปต้องการเข้าถึง Identifier for Advertisers (IDFA) ของอุปกรณ์หรือทำการติดตามที่เชื่อมโยงผู้ใช้ข้ามแอปและเว็บไซต์ที่เป็นของผู้ดำเนินการรายอื่น ต้องเรียก requestTrackingAuthorization และแสดงข้อความแจ้งของระบบที่ขอให้ผู้ใช้อนุญาตหรือปฏิเสธการติดตาม การตอบสนองของผู้ใช้เป็นแบบสองทาง คงอยู่จนกว่าจะเปลี่ยนในการตั้งค่า และมองเห็นได้โดยแอปผ่าน API trackingAuthorizationStatus

คำจำกัดความของ Apple เกี่ยวกับการติดตาม

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

สิ่งที่ ATT ไม่ทำ

ATT ไม่ใช่ระบบการจัดการการยินยอมในแง่ของ GDPR มันไม่รวบรวมการตั้งค่าวัตถุประสงค์แบบละเอียด ไม่บันทึกใบเสร็จการยินยอมพร้อมการกำหนดเวอร์ชันนโยบาย ไม่ส่งสัญญาณไปยังผู้จำหน่ายเว็บภายใน WKWebView และไม่ตอบสนองข้อกำหนดพื้นฐานทางกฎหมายสำหรับการจัดเก็บหรืออ่านคุกกี้บนอุปกรณ์ของผู้ใช้ ผู้เผยแพร่ที่ถือว่าข้อความแจ้ง ATT เป็นทัศนคติการปฏิบัติตามกฎทั้งหมดสำหรับแอปไฮบริดอยู่ห่างจากค่าปรับแค่หนึ่งจดหมายจากหน่วยงานกำกับดูแล เนื่องจากการโหลดคุกกี้ภายในเว็บวิวเป็นเหตุการณ์แยกต่างหากภายใต้ ePrivacy และต้องการชั้นการยินยอมของตัวเอง

GDPR และ ePrivacy ใช้บังคับอย่างไรภายใน WKWebView

เว็บวิวภายในแอปไฮบริดไม่ได้รับการยกเว้นอย่างน่าอัศจรรย์จากกฎที่ใช้กับเบราว์เซอร์เดสก์ท็อป ทันทีที่ WKWebView อ่านหรือเขียนคุกกี้ที่ไม่จำเป็นอย่างเคร่งครัด ePrivacy จะถูกกระตุ้น ทันทีที่ WKWebView ส่งคำขอวิเคราะห์หรือโฆษณาที่มีข้อมูลส่วนบุคคล GDPR จะถูกกระตุ้น คอนเทนเนอร์ของ Apple ไม่เปลี่ยนการวิเคราะห์ — สิ่งที่เปลี่ยนคือพื้นผิวการใช้งาน เพราะแบนเนอร์การยินยอมต้องแสดงภายในเว็บวิวและสถานะการยินยอมต้องมองเห็นได้โดยโค้ดเนทีฟที่อาจอ่านข้อมูลเดียวกันด้วย

แบนเนอร์ภายในเว็บวิว

รูปแบบมาตรฐานคือการแสดงแบนเนอร์ CMP ภายใน WKWebView แบบเดียวกับที่ทำบนเว็บไซต์ แบนเนอร์ตั้งค่าคุกกี้บนที่เก็บคุกกี้ของเว็บวิว เรียกเหตุการณ์อัปเดตการยินยอมในบริบท JavaScript ของหน้า และอัปเดตเครื่องสถานะ Google Consent Mode v2 ที่แท็กวิเคราะห์และโฆษณาของหน้าอ่าน การใช้งานไม่ต่างจาก CMP เว็บปกติ — สิ่งที่แตกต่างคือที่เก็บคุกกี้ถูกจำกัดอยู่ที่ WKWebView และมองไม่เห็นโดยแอปอื่นหรือ Safari ซึ่งมีประโยชน์สำหรับการแยกส่วนแต่ไม่มีประโยชน์ถ้าผู้เผยแพร่ยังดำเนินเว็บไซต์ที่ผู้ใช้ยินยอมไว้แล้ว

การแบ่งปันการยินยอมระหว่างเว็บวิวและเชลล์เนทีฟ

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

ชั้น CPRA และรัฐของสหรัฐอเมริกา

สำหรับผู้เผยแพร่ในสหรัฐอเมริกา ภาพมีชั้นที่สาม CPRA รวมถึงกลุ่มกฎหมายของรัฐที่ตามมาหลัง Virginia, Colorado, Connecticut และ Utah ปฏิบัติต่อ IDFA เหมือนกับที่ปฏิบัติต่อคุกกี้เว็บ — ทั้งสองเป็นข้อมูลส่วนบุคคลที่การขายหรือการแบ่งปันทำให้เกิดสิทธิ์ในการยกเลิก สัญญาณ Global Privacy Control ที่เบราว์เซอร์เว็บส่งเป็นสัญญาณด้านผู้บริโภค และ Multi-State Privacy Agreement (MSPA) ของ IAB พร้อม US Privacy String ที่เกี่ยวข้องเป็นสัญญาณด้านผู้เผยแพร่ แอปไฮบริดที่วางจำหน่ายในสหรัฐอเมริกาต้องแสดงลิงก์ 'ห้ามขายหรือแบ่งปันข้อมูลส่วนบุคคลของฉัน' ภายในแอปเอง กำหนดเส้นทางการยกเลิกที่เกิดขึ้นไปยังทั้ง CMP ของเว็บวิวและ SDK การวัดผลของเชลล์เนทีฟ และเคารพส่วนหัว GPC ขาเข้าที่มาถึงเว็บวิวจากการเชื่อมโยงเชิงลึก

เด็กและ COPPA ภายในแอปไฮบริด

ถ้าแอปได้รับการจัดเรตสำหรับเด็กหรือมีความคาดหวังที่สมเหตุสมผลว่าจะมีผู้ใช้ที่เป็นเด็ก COPPA ในสหรัฐอเมริกาและข้อกำหนด GDPR-K ในสหภาพยุโรปจะเพิ่มข้อจำกัดเพิ่มเติมบน ATT และการยินยอมมาตรฐาน IDFA ต้องไม่ขอเลยสำหรับบัญชีเด็ก การยินยอมโฆษณาของเว็บวิวต้องมีค่าเริ่มต้นเป็นการปฏิเสธ และ SDK ของบุคคลที่สามทุกตัวในเชลล์เนทีฟต้องได้รับการยืนยันว่าเป็นไปตาม COPPA ก่อนการจำหน่าย การตรวจสอบ App Store ปฏิเสธแอปที่จัดเรตสำหรับเด็กที่แสดงข้อความแจ้ง ATT มาตรฐาน ซึ่งเป็นข้อผิดพลาดการใช้งานทั่วไปเมื่อทีมสร้างไบนารีเดียวสำหรับผู้ชมทุกกลุ่ม

รูปแบบวิศวกรรมที่ใช้งานได้จริง

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

ข้อความแจ้งล่วงหน้าและแนวทาง Apple

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

ฝั่งเซิร์ฟเวอร์และ SKAdNetwork เป็นทางเลือกสำรอง

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

ข้อผิดพลาดทั่วไปที่ทำให้เกิดการปฏิเสธหรือการตรวจสอบ

แอปไฮบริดที่ถูกถอดออกหรือถูกปรับมักล้มเหลวในรูปแบบเดียวกันเพียงไม่กี่แบบ แบนเนอร์ CMP ภายใน WKWebView เปิดใช้งานก่อนที่ข้อความแจ้ง ATT จะได้รับการแก้ไข ทำให้วางคุกกี้บนอุปกรณ์ขณะที่การอนุญาตของ Apple ยังอยู่ระหว่างดำเนินการ — ผลการค้นพบที่อาจทำให้ App Store ปฏิเสธ ข้อความแจ้ง ATT แสดงโดยไม่มีข้อความแจ้งล่วงหน้าและเมื่อเริ่มแอปครั้งแรก ทำให้อัตราการยอมรับต่ำและประสบการณ์ผู้ใช้ที่สับสนซึ่งเพิ่มการเลิกใช้ SDK วิเคราะห์ของเชลล์เนทีฟอ่าน IDFA ก่อนที่ CMP จะส่งเหตุการณ์การยินยอมครั้งแรก ทำให้ข้อมูลส่วนบุคคลอยู่บนสายโดยไม่มีพื้นฐานทางกฎหมายที่ชัดเจน สถานะการยินยอมของเว็บวิวและสถานะการอนุญาตของเชลล์เนทีฟถูกเก็บไว้ในที่เก็บแยกกันโดยไม่มีการซิงโครไนซ์ ทำให้เกิดผู้ใช้ที่ปฏิเสธการโฆษณาในเว็บวิวแต่ SDK โฆษณาเนทีฟยังคงทำงาน แต่ละรายการเป็นการแก้ไขหนึ่งถึงสองวันวิศวกรรมและการทดสอบถดถอย — แต่แต่ละรายการก็เป็นรูปแบบที่ผู้ตรวจสอบหรือผู้ตรวจสอบเริ่มต้นด้วยเช่นกัน

สรุป

ATT และการยินยอมคุกกี้ไม่ใช่ชั้นที่ซ้ำซ้อนกัน ATT คือประตูสิทธิ์ที่จำกัดอยู่ที่ iOS API เฉพาะ และการยินยอมคุกกี้คือพื้นฐานทางกฎหมายสำหรับการประมวลผลข้อมูลภายในสภาพแวดล้อมของคลาสเบราว์เซอร์ใดก็ตาม รวมถึง WKWebView แอปไฮบริดต้องการทั้งสอง เชื่อมต่อกันเพื่อให้ผู้ใช้เห็นการตัดสินใจที่สอดคล้องกันแทนที่จะเป็นข้อความแจ้งสองแบบที่ขัดแย้ง และเพื่อให้เชลล์เนทีฟและเว็บวิวเคารพคำตอบเดียวกัน ผู้เผยแพร่ที่ทำสิ่งนี้ถูกต้องจะเปิดตัวแอปที่ผ่านการตรวจสอบ สร้างรายได้อย่างน่าเชื่อถือ และไม่ปรากฏในสรุปการบังคับใช้ของหน่วยงานกำกับดูแล ผู้เผยแพร่ที่ถือว่า ATT เป็นคำตอบทั้งหมดหรือที่ปล่อยให้การยินยอมเว็บวิวและเชลล์เนทีฟแยกออกจากกันจะใช้เวลาปี 2026 สลับกันระหว่างการประชุมตรวจสอบ App Store และจดหมายตอบการตรวจสอบ สร้างสะพานหนึ่งครั้ง ถือว่า CMP เป็นแหล่งความจริง และปล่อยให้ ATT เป็นล็อกเฉพาะ iOS บนสถานะความเป็นส่วนตัวที่สอดคล้องกันอยู่แล้วที่ชั้นเว็บ

← บล็อก อ่านทั้งหมด →