ยุคของรหัสประจำตัวกำลังสิ้นสุดลงบน Android

เป็นเวลาหลายปีที่การกำหนดเป้าหมายและการวัดผลโฆษณามือถือพึ่งพารหัสประจำตัวข้ามแอปที่เสถียร — โดยหลักคือ Google Advertising ID (GAID) โมเดลนั้นกำลังถูกรื้อถอน Privacy Sandbox on Android ของ Google มีเป้าหมายเพื่อส่งมอบโฆษณาที่เกี่ยวข้องและการวัดผล Conversion โดยไม่ แชร์รหัสประจำตัวระดับผู้ใช้ข้ามแอป

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

Topics API: สัญญาณความสนใจโดยไม่ต้องติดตาม

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

ในทางปฏิบัติ:

• การกำหนดเป้าหมายกลายเป็นกว้างขึ้นและอิงบริบทมากกว่าเจาะจงรายบุคคล
• หัวข้อมีลักษณะหยาบ หมุนเวียนไปตามเวลา และตัดหมวดหมู่ที่ละเอียดอ่อนออกโดยการออกแบบ
• ระบบปฏิบัติการเป็นตัวกลางว่าสัญญาณใดจะไปถึงฝั่งดีมานด์ — คุณไม่ได้เป็นเจ้าของโปรไฟล์อีกต่อไป

คาดว่า CPM แบบอิงความสนใจจะพึ่งพา ความเกี่ยวข้องเชิงบริบท และบริบทแบบ first-party ที่คุณสามารถให้ได้อย่างถูกต้องในคำขอโฆษณามากขึ้น

SDK Runtime: การแยก SDK โฆษณาออกมา

SDK Runtime ย้าย SDK โฆษณาและการวิเคราะห์ไปยังกระบวนการแยกต่างหากที่อยู่ใน sandbox โดยมีสิทธิ์จำกัด ปัจจุบัน SDK โฆษณาที่ฝังอยู่ทำงานด้วยการเข้าถึงเดียวกันกับแอปของคุณ — มันสามารถอ่านข้อมูลแอป สัญญาณอุปกรณ์ และอื่นๆ SDK Runtime จำกัดสิ่งนั้น ลดสิ่งที่ SDK สามารถเก็บได้อย่างเงียบๆ และจำกัดการเชื่อมโยงข้ามแอป

สำหรับผู้เผยแพร่ สิ่งนี้นำมาซึ่งความจริงสองประการ SDK การไกล่เกลี่ย (mediation) และโฆษณาต้องอัปเดตเป็นเวอร์ชันที่รองรับ runtime ซึ่งเป็นการพึ่งพาที่ต้องติดตามกับพันธมิตรแต่ละราย และสัญญาณที่ SDK เคยคว้ามาโดยปริยายจะไม่สามารถใช้ได้อีกต่อไป ดังนั้นการส่งบริบท first-party ที่สะอาดและได้รับความยินยอมผ่าน API ที่รองรับจึงสำคัญยิ่งขึ้น

Attribution Reporting: การวัดผลโดยไม่ใช้ ID

Attribution Reporting API สร้างการวัดผล Conversion ขึ้นใหม่บนอุปกรณ์ แทนที่จะจับคู่การคลิกโฆษณากับการติดตั้งผ่าน ID ที่ใช้ร่วมกัน มันจะบันทึกเหตุการณ์การระบุแหล่งที่มาในเครื่องและส่งคืนรายงานแบบ รวม (aggregated) หรือแบบมีสัญญาณรบกวนและล่าช้าในระดับเหตุการณ์ (event-level) — พิสูจน์ว่าแคมเปญได้ผลในขณะที่ป้องกันการระบุตัวตนซ้ำในระดับผู้ใช้

การแลกเปลี่ยนที่ฝั่งดีมานด์ของคุณจะปรับตัวรวมถึง:

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

คาดว่าจะมีช่วงเวลาที่ผู้โฆษณาเรียกใช้การระบุแหล่งที่มาของ Privacy Sandbox ควบคู่ ไปกับวิธีดั้งเดิมเพื่อปรับเทียบ อินเวนทอรีที่วัดผลได้ดีภายใต้ API ใหม่จะรักษางบประมาณไว้ ส่วนอินเวนทอรีที่พึ่งพาสัญญาณที่เลิกใช้จะเผชิญแรงกดดัน

สิ่งที่ผู้เผยแพร่แอปควรทำในตอนนี้

การเปลี่ยนผ่านนี้ให้รางวัลแก่การเตรียมตัว ขั้นตอนที่เป็นรูปธรรม:

• ตรวจสอบ SDK ของคุณ ยืนยันว่า SDK การไกล่เกลี่ย เครือข่ายโฆษณา และการวิเคราะห์ของคุณส่งมอบเวอร์ชันที่พร้อมสำหรับ Privacy Sandbox & SDK Runtime และวางแผนอัปเกรด
• ลงทะเบียนและทดสอบ ใช้การลงทะเบียน Privacy Sandbox ของ Google และทดสอบบน developer preview เพื่อที่คุณจะไม่ต้องดีบักในระบบจริง
• เสริมความแข็งแกร่งให้บริบท first-party ลงทุนในสัญญาณเชิงบริบทและที่ได้รับความยินยอมซึ่งคุณสามารถส่งได้อย่างถูกต้อง เพราะ ID ข้ามแอปจะไม่แบกรับภาระอีกต่อไป
• ทำเกณฑ์มาตรฐานการวัดผลแต่เนิ่นๆ เปรียบเทียบผลลัพธ์ของ Attribution Reporting กับการระบุแหล่งที่มาปัจจุบันเพื่อตั้งความคาดหวังที่สมจริงของผู้ซื้อ
• จัดการความยินยอมให้ถูกต้อง Sandbox ลดการแชร์ข้อมูลแบบเงียบๆ แต่ไม่ได้ขจัดหน้าที่ตามกฎหมายของคุณในการเก็บและเคารพความยินยอมสำหรับการประมวลผลที่ยังคงอยู่

เหตุใดความยินยอมและ CMP จึงยังคงสำคัญ

ความเข้าใจผิดทั่วไปคือ Privacy Sandbox ทำให้ความยินยอมล้าสมัย ไม่ใช่เช่นนั้น Sandbox จำกัด วิธีที่ ข้อมูลเคลื่อนไหว แต่ภายใต้ GDPR กฎ ePrivacy และนโยบายของ Google เอง คุณยังคงต้องได้มาและส่งสัญญาณฐานทางกฎหมายที่ถูกต้อง — และพันธมิตรฝั่งดีมานด์ยังคงต้องการสัญญาณความยินยอมที่ทำงานร่วมกันได้เพื่อเสนอราคา Google Consent Mode v2 และ IAB TCF 2.3 ยังคงเป็นเนื้อเยื่อเชื่อมต่อระหว่าง UI ความยินยอมของคุณกับ ad stack

FlexyConsent ครอบคลุมเว็บไซต์ทั้งบนเดสก์ท็อปและมือถือ (CMP ID 317 เป็น CMP สำหรับเว็บ) FlexyConsent ส่งสัญญาณ IAB TCF 2.4 และ Google Consent Mode v2 แอปแบบเนทีฟต้องใช้ CMP ในแอป เช่น UMP ของ Google

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

• Privacy Sandbox แทนที่ ID ข้ามแอปด้วย Topics บนอุปกรณ์ SDK Runtime ที่แยกออกมา และ Attribution Reporting ที่มีสัญญาณรบกวน
• การกำหนดเป้าหมายเปลี่ยนไปสู่สัญญาณเชิงบริบทและ first-party ที่ได้รับความยินยอม การระบุแหล่งที่มาแบบแน่นอนเปิดทางให้รายงานแบบรวมและล่าช้า
• ตรวจสอบและอัปเกรด SDK โฆษณาของคุณตอนนี้ ลงทะเบียนเพื่อทดสอบ และเปรียบเทียบการวัดผลใหม่กับแบบดั้งเดิมก่อนที่การเลิกใช้จะส่งผล
• ความยินยอมยังคงเป็นข้อบังคับ