ข้อเสนอนี้ขึ้นอยู่กับกระบวนการลงทะเบียน Privacy Sandbox และ การรับรอง ดูข้อมูลเพิ่มเติมเกี่ยวกับเอกสารรับรองได้ที่ลิงก์เอกสารรับรองที่ระบุ การอัปเดตข้อเสนอนี้ในอนาคตจะ อธิบายข้อกำหนดในการรับสิทธิ์เข้าถึงระบบนี้
โฆษณาเพื่อการติดตั้งแอปบนอุปกรณ์เคลื่อนที่ หรือที่เรียกว่าโฆษณาเพื่อการได้ผู้ใช้ใหม่ เป็นโฆษณาประเภทหนึ่ง บนอุปกรณ์เคลื่อนที่ซึ่งออกแบบมาเพื่อกระตุ้นให้ผู้ใช้ดาวน์โหลดแอปบนอุปกรณ์เคลื่อนที่ โดยปกติแล้ว โฆษณาเหล่านี้จะแสดงต่อผู้ใช้ตามความสนใจและข้อมูลประชากร และ มักจะปรากฏในแอปบนอุปกรณ์เคลื่อนที่อื่นๆ เช่น เกม โซเชียลมีเดีย และแอปข่าว เมื่อผู้ใช้คลิกโฆษณาเพื่อการติดตั้งแอป ระบบจะนำผู้ใช้ไปยัง App Store เพื่อดาวน์โหลดแอปโดยตรง
ตัวอย่างเช่น ผู้ลงโฆษณาที่ต้องการกระตุ้นการติดตั้งแอปใหม่สำหรับแอปนำส่งอาหารบนอุปกรณ์เคลื่อนที่ในสหรัฐอเมริกาอาจกำหนดเป้าหมายโฆษณาเป็นผู้ใช้ที่อยู่ในสหรัฐอเมริกาและเคยมีส่วนร่วมกับแอปนำส่งอาหารอื่นๆ มาก่อน
โดยปกติแล้วจะมีการติดตั้งใช้งานโดยการรวมสัญญาณตามบริบท สัญญาณจากบุคคลที่หนึ่ง และสัญญาณจากบุคคลที่สามระหว่างเทคโนโลยีโฆษณาเพื่อสร้างโปรไฟล์ผู้ใช้ตามรหัสโฆษณา โมเดลแมชชีนเลิร์นนิงด้านเทคโนโลยีโฆษณาใช้ข้อมูลนี้เป็นอินพุตเพื่อเลือกโฆษณา ที่เกี่ยวข้องกับผู้ใช้และมีโอกาสสูงสุดที่จะทําให้เกิด Conversion
เราขอเสนอ API ต่อไปนี้เพื่อรองรับโฆษณาเพื่อกระตุ้นการติดตั้งแอปที่มีประสิทธิภาพ ซึ่งจะช่วยปรับปรุงความเป็นส่วนตัวของผู้ใช้โดยยกเลิกการพึ่งพาตัวระบุผู้ใช้ข้ามฝ่ายต่างๆ
- Protected App Signals API: API นี้มุ่งเน้นไปที่การจัดเก็บและการสร้างฟีเจอร์ที่ออกแบบโดยเทคโนโลยีโฆษณา ซึ่งแสดงถึงความสนใจที่อาจเกิดขึ้นของผู้ใช้ เทคโนโลยีโฆษณาจะจัดเก็บสัญญาณเหตุการณ์ต่อแอปที่กำหนดเอง เช่น การติดตั้งแอป การเปิดครั้งแรก การดำเนินการของผู้ใช้ (การเลื่อนระดับในเกม ความสำเร็จ) กิจกรรมการซื้อ หรือเวลาที่ใช้ในแอป ระบบจะเขียนและจัดเก็บสัญญาณไว้ในอุปกรณ์เพื่อป้องกันการรั่วไหลของข้อมูล และจะพร้อมใช้งานเฉพาะกับตรรกะเทคโนโลยีโฆษณาที่จัดเก็บสัญญาณที่กำหนดไว้ในระหว่างการประมูลที่ได้รับการปกป้องซึ่งทํางานในสภาพแวดล้อมที่ปลอดภัย
- Ad Selection API: API นี้ใช้เพื่อกำหนดค่าและเรียกใช้ การประมูลที่ได้รับการปกป้องซึ่งทำงานในTrusted Execution Environment (TEE) ซึ่งเทคโนโลยีโฆษณาจะดึงข้อมูลผู้สมัครรับเลือกเป็นโฆษณา ทำการอนุมาน คำนวณราคาเสนอ และทำการให้คะแนน เพื่อเลือกโฆษณาที่ "ชนะ" โดยใช้ทั้งสัญญาณแอปที่ได้รับการปกป้องและ ข้อมูลตามบริบทแบบเรียลไทม์ที่ผู้เผยแพร่โฆษณามอบให้
ต่อไปนี้เป็นภาพรวมระดับสูงของวิธีที่สัญญาณแอปที่ได้รับการปกป้องทำงานเพื่อรองรับ โฆษณาเพื่อการติดตั้งแอปที่เกี่ยวข้อง ส่วนต่อไปนี้ของเอกสารนี้จะให้รายละเอียดเพิ่มเติมเกี่ยวกับแต่ละขั้นตอน
- การดูแลจัดการสัญญาณ: เมื่อผู้ใช้ใช้แอปบนอุปกรณ์เคลื่อนที่ เทคโนโลยีโฆษณาจะดูแลจัดการสัญญาณ โดยจัดเก็บเหตุการณ์ในแอปที่กำหนดโดยเทคโนโลยีโฆษณาเพื่อแสดงโฆษณาที่เกี่ยวข้องโดยใช้ Protected App Signals API ระบบจะจัดเก็บเหตุการณ์เหล่านี้ไว้ในพื้นที่เก็บข้อมูลในอุปกรณ์ที่ได้รับการปกป้อง ซึ่งคล้ายกับกลุ่มเป้าหมายที่กำหนดเอง และจะเข้ารหัสก่อนส่ง ออกจากอุปกรณ์เพื่อให้เฉพาะบริการการเสนอราคาและการประมูลที่ทำงาน ภายในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ซึ่งมีการควบคุมความปลอดภัยและ ความเป็นส่วนตัวที่เหมาะสมเท่านั้นที่จะถอดรหัสเพื่อเสนอราคาและให้คะแนนโฆษณาได้
- การเข้ารหัสสัญญาณ: ระบบจะเตรียมสัญญาณตามช่วงเวลาที่กำหนดโดยใช้ ตรรกะเทคโนโลยีโฆษณาที่กำหนดเอง งานในเบื้องหลังของ Android จะดำเนินการตามตรรกะนี้เพื่อ ทำการเข้ารหัสในอุปกรณ์เพื่อสร้างเพย์โหลดของสัญญาณแอปที่ได้รับการปกป้อง ซึ่งสามารถใช้ในภายหลังแบบเรียลไทม์สำหรับการเลือกโฆษณาระหว่างการประมูลที่ได้รับการปกป้อง ระบบจะจัดเก็บเพย์โหลดอย่างปลอดภัยในอุปกรณ์จนกว่าจะส่งไป ประมูล
- การเลือกโฆษณา: SDK ของผู้ขายจะส่งเพย์โหลดที่เข้ารหัสของสัญญาณแอปที่ปกป้องความเป็นส่วนตัวและกำหนดค่าการประมูลที่ปกป้องความเป็นส่วนตัวเพื่อเลือกโฆษณาที่เกี่ยวข้องสำหรับผู้ใช้
ในการประมูล ตรรกะที่กำหนดเองของผู้ซื้อจะเตรียมสัญญาณ Protected
App พร้อมกับข้อมูลเชิงบริบทที่ผู้เผยแพร่โฆษณาให้ไว้ (ข้อมูล
ที่มักแชร์ในคำขอโฆษณา Open-RTB) เพื่อออกแบบ
ฟีเจอร์ที่มีไว้สำหรับการเลือกโฆษณา (การดึงข้อมูลโฆษณา การอนุมาน และการสร้างราคาเสนอ) ผู้ซื้อส่งโฆษณาไปยังผู้ขายเพื่อรับคะแนนสุดท้ายในการประมูลที่ได้รับการปกป้อง ซึ่งคล้ายกับ Protected Audience
- การดึงข้อมูลโฆษณา: ผู้ซื้อใช้สัญญาณแอปที่ได้รับการคุ้มครองและ ข้อมูลตามบริบทที่ผู้เผยแพร่โฆษณามอบให้เพื่อออกแบบฟีเจอร์ ที่เกี่ยวข้องกับความสนใจของผู้ใช้ ระบบจะใช้ฟีเจอร์เหล่านี้เพื่อจับคู่โฆษณา ที่ตรงกับเกณฑ์การกำหนดเป้าหมาย ระบบจะกรองโฆษณาที่ไม่อยู่ในงบประมาณออก จากนั้นระบบจะเลือกโฆษณา k อันดับแรกเพื่อเสนอราคา
- การเสนอราคา: ตรรกะการเสนอราคาที่กำหนดเองของผู้ซื้อจะเตรียมข้อมูลตามบริบทที่ผู้เผยแพร่โฆษณาให้ไว้และสัญญาณแอปที่ได้รับการคุ้มครองเพื่อออกแบบฟีเจอร์ที่ใช้เป็นอินพุตสำหรับโมเดลแมชชีนเลิร์นนิงของผู้ซื้อสำหรับการอนุมานและการเสนอราคาในโฆษณาที่พิจารณาภายในขอบเขตที่เชื่อถือได้ซึ่งรักษาความเป็นส่วนตัว จากนั้นผู้ซื้อจะส่งโฆษณาที่เลือกกลับไปให้ผู้ขาย
- การให้คะแนนผู้ขาย: ตรรกะการให้คะแนนที่กำหนดเองของผู้ขายจะให้คะแนนโฆษณา ที่ผู้ซื้อที่เข้าร่วมส่งมา และเลือกโฆษณาที่ชนะเพื่อส่ง กลับไปยังแอปเพื่อแสดงผล
- การรายงาน: ผู้เข้าร่วมการประมูลจะได้รับรายงานการชนะที่เกี่ยวข้องและรายงานการแพ้ เรากำลังพิจารณากลไกการรักษาความเป็นส่วนตัวเพื่อรวมข้อมูลสำหรับการฝึกโมเดลในรายงานโอกาสที่ชนะ
ไทม์ไลน์
ตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์ | เบต้า | |||
---|---|---|---|---|
ฟีเจอร์ | ไตรมาส 4 ปี 2023 | ไตรมาสที่ 1 ปี 2024 | ไตรมาสที่ 2 ปี 2024 | ไตรมาสที่ 3 ปี 2024 |
Signal Curation APIs | API พื้นที่เก็บข้อมูลในอุปกรณ์ |
ตรรกะโควต้าพื้นที่เก็บข้อมูลในอุปกรณ์ การอัปเดตตรรกะที่กำหนดเองในอุปกรณ์ทุกวัน |
ไม่มี | พร้อมใช้งานสำหรับอุปกรณ์ T+ 1% |
เซิร์ฟเวอร์ดึงข้อมูลโฆษณาใน TEE | MVP |
พร้อมใช้งานใน Google Cloud รองรับ Top K การนำ UDF ไปใช้จริง |
พร้อมใช้งานใน AWS การแก้ไขข้อบกพร่อง เมตริก และการตรวจสอบที่ได้รับความยินยอม |
|
บริการอนุมานใน TEE รองรับการเรียกใช้โมเดล ML และการใช้โมเดลดังกล่าวเพื่อการเสนอราคาใน TEE |
อยู่ระหว่างการพัฒนา |
พร้อมให้บริการใน Google Cloud ความสามารถในการติดตั้งใช้งานและสร้างต้นแบบโมเดล ML แบบคงที่โดยใช้ TensorFlow และ PyTorch |
พร้อมใช้งานใน AWS การติดตั้งใช้งานโมเดลที่พร้อมใช้งานจริงสำหรับโมเดล TensorFlow และ PyTorch การวัดและส่งข้อมูลทางไกล การแก้ไขข้อบกพร่องที่ได้รับความยินยอม และการตรวจสอบ |
|
การสนับสนุนการเสนอราคาและการประมูล ใน TEE |
พร้อมให้บริการใน Google Cloud |
การผสานรวมการดึงโฆษณา PAS-B&A และ TEE (ด้วยการเข้ารหัส gRPC และ TEE<>TEE) รองรับการดึงโฆษณาผ่านเส้นทางตามบริบท (รวมถึงการรองรับ B&A<>K/V ใน TEE) |
พร้อมใช้งานใน AWS การรายงานข้อบกพร่อง การแก้ไขข้อบกพร่อง เมตริก และการตรวจสอบที่ได้รับความยินยอม |
ดูแลจัดการสัญญาณแอปที่ได้รับการปกป้อง
สัญญาณคือการแสดงการโต้ตอบต่างๆ ของผู้ใช้ในแอป ซึ่งเทคโนโลยีโฆษณากำหนดว่ามีประโยชน์ต่อการแสดงโฆษณาที่เกี่ยวข้อง แอปหรือ SDK ที่ผสานรวมอาจจัดเก็บหรือลบสัญญาณแอปที่ได้รับการปกป้องซึ่งกำหนดโดยเทคโนโลยีโฆษณา ตามกิจกรรมของผู้ใช้ เช่น การเปิดแอป ความสำเร็จ กิจกรรมการซื้อ หรือ เวลาที่ใช้ในแอป ระบบจะจัดเก็บสัญญาณแอปที่ได้รับการปกป้องอย่างปลอดภัยในอุปกรณ์ และ เข้ารหัสก่อนที่จะส่งออกจากอุปกรณ์เพื่อให้เฉพาะบริการการเสนอราคาและการประมูล ที่ทำงานภายในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ซึ่งมีการควบคุมความปลอดภัย และความเป็นส่วนตัวที่เหมาะสมเท่านั้นที่สามารถถอดรหัสเพื่อใช้ในการเสนอราคาและการให้คะแนนโฆษณาได้ เช่นเดียวกับ Custom Audience API แอปหรือ SDK จะอ่านหรือตรวจสอบสัญญาณที่จัดเก็บไว้ในอุปกรณ์ไม่ได้ ไม่มี API สำหรับอ่านค่าสัญญาณ และ API ได้รับการออกแบบมาเพื่อหลีกเลี่ยงการรั่วไหลของสัญญาณ ตรรกะที่กำหนดเองของเทคโนโลยีโฆษณามี สิทธิ์เข้าถึงสัญญาณที่ดูแลจัดการเพื่อออกแบบฟีเจอร์ที่ทำหน้าที่เป็น พื้นฐานสำหรับการเลือกโฆษณาในการประมูลที่ได้รับการปกป้อง
Protected App Signals API
Protected App Signals API รองรับการจัดการสัญญาณโดยใช้ กลไกการมอบสิทธิ์ที่คล้ายกับกลไกที่ใช้สำหรับกลุ่มเป้าหมายที่กำหนดเอง Protected App Signals API ช่วยให้จัดเก็บสัญญาณในรูปแบบค่าสเกลาร์เดียว หรือเป็นอนุกรมเวลาได้ คุณใช้สัญญาณอนุกรมเวลาเพื่อจัดเก็บข้อมูลต่างๆ ได้ เช่น ระยะเวลาเซสชันของผู้ใช้ สัญญาณอนุกรมเวลาช่วยให้คุณบังคับใช้ความยาวที่กำหนดได้โดยใช้กฎการนำออกแบบเข้าก่อนออกก่อน ประเภทข้อมูลของสัญญาณสเกลาร์ หรือแต่ละองค์ประกอบของสัญญาณอนุกรมเวลาคืออาร์เรย์ไบต์ ระบบจะเพิ่มชื่อแพ็กเกจของแอปพลิเคชันที่จัดเก็บสัญญาณและ การประทับเวลาการสร้างของการเรียก API สัญญาณร้านค้าให้กับค่าแต่ละค่า ข้อมูลเพิ่มเติมนี้มีอยู่ใน JavaScript การเข้ารหัสสัญญาณ ตัวอย่างนี้ แสดงโครงสร้างของสัญญาณที่เป็นของเทคโนโลยีโฆษณาที่ระบุ
ตัวอย่างนี้แสดงสัญญาณสเกลาร์และสัญญาณอนุกรมเวลาที่เชื่อมโยง
กับ adtech1.com
- สัญญาณสเกลาร์ที่มีคีย์ค่า base64 เป็น "
A1c
" และค่าเป็น "c12Z
" ทริกเกอร์ที่เก็บสัญญาณ โดยcom.google.android.game_app
เมื่อวันที่ 1 มิถุนายน 2023 - รายการสัญญาณที่มีคีย์ "
dDE
" ซึ่งสร้างขึ้นโดยแอปพลิเคชัน 2 รายการที่แตกต่างกัน
เทคโนโลยีโฆษณาจะได้รับพื้นที่จำนวนหนึ่งเพื่อจัดเก็บสัญญาณในอุปกรณ์ สัญญาณจะมี TTL สูงสุดซึ่งจะกำหนดในภายหลัง
ระบบจะนำสัญญาณแอปที่ได้รับการปกป้องออกจากที่เก็บข้อมูลหากมีการถอนการติดตั้งแอปพลิเคชันที่สร้างสัญญาณ ถูกบล็อกไม่ให้ใช้ Protected App Signals API หรือหากผู้ใช้ล้างข้อมูลแอป
Protected App Signals API ประกอบด้วยส่วนต่างๆ ดังนี้
- API ของ Java และ JavaScript เพื่อเพิ่ม อัปเดต หรือนำสัญญาณออก
- JavaScript API เพื่อประมวลผลสัญญาณที่บันทึกไว้เพื่อเตรียมสัญญาณสำหรับการ สร้างฟีเจอร์เพิ่มเติมแบบเรียลไทม์ในระหว่างการประมูลที่ได้รับการปกป้องซึ่งทำงาน ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
เพิ่ม อัปเดต หรือนำสัญญาณออก
เทคโนโลยีโฆษณาสามารถเพิ่ม อัปเดต หรือนำสัญญาณออกได้ด้วย fetchSignalUpdates()
API
API นี้รองรับการมอบสิทธิ์คล้ายกับการมอบสิทธิ์กลุ่มเป้าหมายที่กำหนดเอง
ของ Protected Audience
หากต้องการเพิ่มสัญญาณ เทคโนโลยีโฆษณาของผู้ซื้อที่ไม่มี SDK ในแอปจะต้อง
ทำงานร่วมกับเทคโนโลยีโฆษณาที่มีอยู่ในอุปกรณ์ เช่น
พาร์ทเนอร์การวัดผลบนอุปกรณ์เคลื่อนที่ (MMP) และแพลตฟอร์มฝั่งซัพพลาย (SSP) Protected App
Signals API มีเป้าหมายที่จะสนับสนุนเทคโนโลยีโฆษณาเหล่านี้ด้วยการมอบโซลูชันที่ยืดหยุ่นสำหรับการ
จัดการสัญญาณแอปที่ปกป้องความเป็นส่วนตัวโดยการเปิดให้ผู้เรียกใช้ในอุปกรณ์เรียกใช้
การสร้างสัญญาณแอปที่ปกป้องความเป็นส่วนตัวในนามของผู้ซื้อ กระบวนการนี้เรียกว่าการมอบสิทธิ์และใช้ประโยชน์จาก fetchSignalUpdates()
API fetchSignalUpdates()
รับ URI และดึงข้อมูลรายการการอัปเดตสัญญาณ ตัวอย่างเช่น
fetchSignalUpdates()
จะส่งคำขอ GET ไปยัง URI ที่ระบุเพื่อเรียกข้อมูล
รายการการอัปเดตที่จะใช้กับที่เก็บข้อมูลสัญญาณในเครื่อง ปลายทาง URL ซึ่งเป็นของ
ผู้ซื้อจะตอบกลับด้วยรายการคำสั่ง JSON
คำสั่ง JSON ที่รองรับมีดังนี้
- put: แทรกหรือลบล้างค่าสเกลาร์สำหรับคีย์ที่ระบุ
- put_if_not_present: แทรกค่าสเกลาร์สำหรับคีย์ที่ระบุหากยังไม่มีการจัดเก็บค่า ตัวเลือกนี้อาจมีประโยชน์ เช่น ในการตั้งค่ารหัสการทดสอบสำหรับผู้ใช้ที่ระบุและหลีกเลี่ยงการลบล้างหากแอปพลิเคชันอื่นตั้งค่าไว้แล้ว
- append: เพิ่มองค์ประกอบลงในอนุกรมเวลาที่เชื่อมโยงกับคีย์ที่ระบุ พารามิเตอร์ maxSignals ระบุจำนวนสัญญาณสูงสุดในอนุกรมเวลา หากขนาดเกิน ระบบจะนำองค์ประกอบก่อนหน้าออก หากคีย์มีค่าสเกลาร์ ระบบจะแปลงคีย์เป็นอนุกรมเวลาโดยอัตโนมัติ
- remove: นำเนื้อหาที่เชื่อมโยงกับคีย์ที่ระบุออก
{
"put": {
"A1c": "c12Z",
"dDE": "d23d",
},
"put_if_not_present": {
"aA9": "a1zfC3"
}
"append": {
"bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
},
"remove": ["c0D"]
}
คีย์และค่าทั้งหมดจะแสดงใน Base64
คำสั่งที่แสดงไว้เหล่านี้มีไว้เพื่อระบุความหมายของการแทรก การเขียนทับ และการลบ สำหรับสัญญาณสเกลาร์ รวมถึงการแทรก การต่อท้าย และการเขียนทับแบบเต็มสำหรับสัญญาณ อนุกรมเวลา ต้องจัดการการลบและการเขียนทับเชิงความหมายในองค์ประกอบที่เฉพาะเจาะจงของสัญญาณอนุกรมเวลาในระหว่างกระบวนการเข้ารหัสและการบีบอัด เช่น ในระหว่างการเข้ารหัส ให้ละเว้นค่าในอนุกรมเวลาที่ค่าล่าสุดแทนที่หรือแก้ไขแล้ว และลบค่าเหล่านั้นในระหว่างกระบวนการบีบอัด
ระบบจะเชื่อมโยงสัญญาณที่จัดเก็บไว้กับแอปพลิเคชันที่ส่ง คำขอเรียกข้อมูล และผู้ตอบคำขอ (ซึ่งก็คือ "เว็บไซต์" หรือ "ต้นทาง" ของ เทคโนโลยีโฆษณาที่ลงทะเบียน) โดยอัตโนมัติ รวมถึงเวลาที่สร้างคำขอ สัญญาณทั้งหมด จะขึ้นอยู่กับการจัดเก็บในนามของเทคโนโลยีโฆษณาที่ลงทะเบียนใน Privacy Sandbox URI "site"/"origin" ต้องตรงกับข้อมูลของเทคโนโลยีโฆษณาที่ลงทะเบียน หากเทคโนโลยีโฆษณาที่ขอไม่ได้ลงทะเบียน ระบบจะปฏิเสธคำขอ
โควต้าพื้นที่เก็บข้อมูลและการนำออก
เทคโนโลยีโฆษณาแต่ละรายการมีพื้นที่จำกัดในอุปกรณ์ของผู้ใช้เพื่อจัดเก็บสัญญาณ โควต้านี้กำหนดไว้ต่อเทคโนโลยีโฆษณา ดังนั้นสัญญาณที่รวบรวมจากแอปต่างๆ จะใช้โควต้าเดียวกัน หากใช้โควต้าเกิน ระบบจะเพิ่มพื้นที่ว่างโดยนำค่าสัญญาณก่อนหน้าออกตามลำดับการเข้าก่อนออกก่อน เพื่อป้องกันไม่ให้ระบบดีดออกบ่อยเกินไป ระบบจะใช้ตรรกะการจัดกลุ่มเพื่ออนุญาตให้มีการใช้โควต้าเกินเล็กน้อยและเพื่อเพิ่มพื้นที่ว่างเมื่อมีการทริกเกอร์ตรรกะการดีดออก
การเข้ารหัสในอุปกรณ์สำหรับการส่งข้อมูล
เพื่อเตรียมสัญญาณสำหรับการเลือกโฆษณา ตรรกะที่กำหนดเองต่อผู้ซื้อจะมีการเข้าถึงที่ได้รับการปกป้อง ไปยังสัญญาณและเหตุการณ์ต่อแอปที่จัดเก็บไว้ งานพื้นหลังของระบบ Android จะทำงานทุกชั่วโมงเพื่อเรียกใช้ตรรกะการเข้ารหัสที่กำหนดเองต่อผู้ซื้อซึ่งดาวน์โหลดไปยังอุปกรณ์ ตรรกะการเข้ารหัสที่กำหนดเองต่อผู้ซื้อจะเข้ารหัสสัญญาณต่อแอป จากนั้น จะบีบอัดสัญญาณต่อแอปเป็นเพย์โหลดที่เป็นไปตาม โควต้าต่อผู้ซื้อ จากนั้นระบบจะเข้ารหัสเพย์โหลดภายในขอบเขตของ ที่เก็บข้อมูลอุปกรณ์ที่ได้รับการปกป้อง แล้วส่งไปยังบริการการเสนอราคาและการประมูล
เทคโนโลยีโฆษณากำหนดระดับการประมวลผลสัญญาณที่จัดการโดยตรรกะที่กำหนดเองของตนเอง เช่น คุณอาจตั้งค่าโซลูชันให้ทิ้งสัญญาณก่อนหน้า และรวบรวมสัญญาณที่คล้ายกันหรือเสริมกันจากแอปพลิเคชันต่างๆ เป็นสัญญาณใหม่ที่ใช้พื้นที่น้อยลง
หากผู้ซื้อไม่ได้ลงทะเบียนเครื่องมือเข้ารหัสสัญญาณ ระบบจะไม่เตรียมสัญญาณ และจะไม่ส่งสัญญาณที่คัดสรรบนอุปกรณ์ไปยังบริการการเสนอราคาและการประมูล
รายละเอียดเพิ่มเติมเกี่ยวกับโควต้าพื้นที่เก็บข้อมูล เพย์โหลด และคำขอจะพร้อมใช้งานในการอัปเดตในอนาคต นอกจากนี้ เราจะให้ข้อมูลเพิ่มเติมเกี่ยวกับวิธี ระบุฟังก์ชันที่กำหนดเอง
เวิร์กโฟลว์การเลือกโฆษณา
ข้อเสนอนี้จะอนุญาตให้โค้ดที่กำหนดเองของเทคโนโลยีโฆษณาเข้าถึงสัญญาณแอปที่ได้รับการปกป้องภายใน Protected Auction (Ad Selection API) ที่ทำงานใน TEE เท่านั้น เพื่อ รองรับความต้องการของ Use Case การติดตั้งแอปเพิ่มเติม ระบบจะ ดึงโฆษณาที่เป็นผู้สมัครในช่วงการประมูลที่ได้รับการปกป้องแบบเรียลไทม์ ซึ่งแตกต่างจากกรณีการใช้งานรีมาร์เก็ตติ้งที่เรารู้จักโฆษณาที่อาจแสดงก่อนการประมูล
ข้อเสนอนี้ใช้เวิร์กโฟลว์การเลือกโฆษณาที่คล้ายกับข้อเสนอ Protected Audience โดยมีการอัปเดตเพื่อรองรับกรณีการใช้งานการติดตั้งแอป เพื่อให้รองรับ ข้อกำหนดด้านการประมวลผลสำหรับการสร้างฟีเจอร์และการเลือกโฆษณาแบบเรียลไทม์ การประมูลสำหรับโฆษณาเพื่อกระตุ้นการติดตั้งแอปจึงต้องทำงานในบริการการเสนอราคาและการประมูล ที่ทำงานใน TEE การเข้าถึงสัญญาณแอปที่ได้รับการปกป้องในระหว่างการประมูลที่ได้รับการปกป้องไม่รองรับการประมูลในอุปกรณ์
เวิร์กโฟลว์การเลือกโฆษณามีดังนี้
- SDK ของผู้ขายจะส่งเพย์โหลดที่เข้ารหัสในอุปกรณ์ของสัญญาณ Protected App
- เซิร์ฟเวอร์ของผู้ขายจะสร้างการกำหนดค่าการประมูลและส่งไปยังบริการการเสนอราคาและการประมูลที่เชื่อถือได้ของผู้ขาย พร้อมกับเพย์โหลดที่เข้ารหัสเพื่อเริ่มเวิร์กโฟลว์การเลือกโฆษณา
- บริการการเสนอราคาและการประมูลของผู้ขายจะส่งเพย์โหลดไปยัง เซิร์ฟเวอร์ส่วนหน้าของผู้ซื้อที่เชื่อถือได้ซึ่งเข้าร่วม
- บริการเสนอราคาของผู้ซื้อจะเรียกใช้ตรรกะการเลือกโฆษณาฝั่งผู้ซื้อ
- ระบบจะเรียกใช้ตรรกะการให้คะแนนฝั่งผู้ขาย
- ระบบแสดงโฆษณาและเริ่มการรายงาน
เริ่มเวิร์กโฟลว์การเลือกโฆษณา
เมื่อแอปพลิเคชันพร้อมแสดงโฆษณา SDK เทคโนโลยีโฆษณา (โดยปกติคือ SSP)
จะเริ่มเวิร์กโฟลว์การเลือกโฆษณาโดยการส่งข้อมูลเชิงบริบทที่เกี่ยวข้องจาก
ผู้เผยแพร่โฆษณาและเพย์โหลดที่เข้ารหัสต่อผู้ซื้อเพื่อรวมไว้ในคำขอ
ที่จะส่งไปยังการประมูลที่ได้รับการปกป้องโดยใช้การเรียก getAdSelectionData
ซึ่งเป็น API เดียวกันที่ใช้สำหรับเวิร์กโฟลว์รีมาร์เก็ตติ้งและอธิบายไว้ในข้อเสนอการผสานรวมการเสนอราคาและการประมูลสำหรับ Android
ผู้ขายจะส่งรายชื่อผู้ซื้อที่เข้าร่วม
และเพย์โหลดที่เข้ารหัสของสัญญาณแอปที่ได้รับการปกป้องในอุปกรณ์เพื่อเริ่มการเลือกโฆษณา ด้วยข้อมูลนี้ เซิร์ฟเวอร์โฆษณาฝั่งผู้ขายจะเตรียม SelectAdRequest
สำหรับบริการ SellerFrontEnd ที่เชื่อถือได้
ผู้ขายจะกำหนดสิ่งต่อไปนี้
- เพย์โหลดที่ได้รับจาก
getAdSelectionData
ซึ่งมี สัญญาณแอปที่ได้รับการปกป้อง สัญญาณบริบทที่ใช้
auction_config.auction_signals
(สำหรับข้อมูลเกี่ยวกับการประมูล)auction_config.seller_signals
(สำหรับสัญญาณของผู้ขายauction_config.per_buyer_config["buyer"].buyer_signals
(สำหรับสัญญาณของผู้ซื้อ)
รายชื่อผู้ซื้อที่รวมอยู่ในการประมูลโดยใช้ฟิลด์
buyer_list
การดำเนินการตามตรรกะการเลือกโฆษณาฝั่งผู้ซื้อ
ในระดับสูง ตรรกะที่กำหนดเองของผู้ซื้อจะใช้ข้อมูลตามบริบทที่ผู้เผยแพร่โฆษณาและสัญญาณแอปที่ได้รับการคุ้มครองให้ไว้เพื่อเลือกและใช้ราคาเสนอในโฆษณาที่เกี่ยวข้อง สำหรับคำขอโฆษณา แพลตฟอร์มนี้ช่วยให้ผู้ซื้อจำกัดกลุ่มโฆษณาจำนวนมากที่พร้อมใช้งานให้เหลือเฉพาะโฆษณาที่เกี่ยวข้องมากที่สุด (โฆษณา k อันดับแรก) ซึ่งระบบจะคำนวณราคาเสนอ ก่อนที่จะส่งโฆษณากลับไปยังผู้ขายเพื่อเลือกขั้นสุดท้าย
ก่อนที่จะเสนอราคา ผู้ซื้อจะเริ่มต้นด้วยกลุ่มโฆษณาขนาดใหญ่ การคำนวณราคาเสนอสำหรับโฆษณาแต่ละรายการใช้เวลานานเกินไป ดังนั้นผู้ซื้อจึงต้องเลือกผู้สมัครรับเลือก k อันดับแรกจากกลุ่มขนาดใหญ่ก่อน จากนั้นผู้ซื้อต้องคำนวณราคาเสนอสำหรับผู้สมัครรับเลือก k อันดับแรกแต่ละราย จากนั้นระบบจะส่งโฆษณาและราคาเสนอเหล่านั้นกลับไปยังผู้ขายเพื่อเลือกขั้นสุดท้าย
- บริการ BuyerFrontEnd ได้รับคำขอโฆษณา
- บริการ BuyerFrontEnd จะส่งคำขอไปยังบริการเสนอราคาของผู้ซื้อ
บริการเสนอราคาของผู้ซื้อจะเรียกใช้ UDF ที่ชื่อ
prepareDataForAdRetrieval()
ซึ่งสร้างคำขอเพื่อรับผู้สมัครรับเลือก k อันดับแรกจากบริการดึงข้อมูลโฆษณา บริการเสนอราคาจะส่งคำขอนี้ไปยังปลายทางเซิร์ฟเวอร์การดึงข้อมูลที่กำหนดค่าไว้ - บริการดึงข้อมูลโฆษณาจะเรียกใช้
getCandidateAds()
UDF ซึ่งจะกรอง ลงไปจนถึงชุดโฆษณาผู้สมัครรับเลือก k อันดับแรก ซึ่งจะส่งไปยังบริการเสนอราคา ของผู้ซื้อ - บริการเสนอราคาของผู้ซื้อจะเรียกใช้
generateBid()
UDF ซึ่งเลือกผู้สมัครรับเลือกที่ดีที่สุด คำนวณราคาเสนอ แล้วส่งกลับไปยังบริการ BuyerFrontEnd - บริการ BuyerFrontEnd จะแสดงโฆษณาและราคาเสนอต่อผู้ขาย
ขั้นตอนการทำงานนี้มีรายละเอียดสำคัญหลายอย่าง โดยเฉพาะอย่างยิ่งในเรื่อง การสื่อสารระหว่างองค์ประกอบต่างๆ และวิธีที่แพลตฟอร์มให้บริการฟีเจอร์ต่างๆ เช่น ความสามารถในการคาดการณ์ด้วยแมชชีนเลิร์นนิงเพื่อดึงโฆษณา k อันดับแรก และการคำนวณราคาเสนอ
ก่อนที่จะดูรายละเอียดของส่วนต่างๆ ในแผนภาพนี้ มีข้อควรทราบที่สำคัญบางประการเกี่ยวกับสถาปัตยกรรมของ TEE
บริการเสนอราคาของผู้ซื้อมีบริการอนุมานอยู่ภายใน เทคโนโลยีโฆษณาสามารถอัปโหลดโมเดลแมชชีนเลิร์นนิงไปยังบริการเสนอราคาของผู้ซื้อได้ เราจะ จัดหา JavaScript API ให้เทคโนโลยีโฆษณาเพื่อใช้คาดการณ์หรือสร้างการฝัง จากโมเดลเหล่านี้ภายใน UDF ที่ทำงานในบริการเสนอราคาของผู้ซื้อ ซึ่งต่างจากบริการดึงข้อมูลโฆษณาตรงที่บริการเสนอราคาของผู้ซื้อไม่มีบริการค่าคีย์เพื่อจัดเก็บข้อมูลเมตาของโฆษณา
บริการดึงข้อมูลโฆษณามีบริการคีย์-ค่าอยู่ภายใน เทคโนโลยีโฆษณาสามารถ สร้างคู่คีย์-ค่าในบริการนี้จากเซิร์ฟเวอร์ของตนเองได้ โดยอยู่นอก ขอบเขตความเป็นส่วนตัว เราจะจัดหา JavaScript API ให้เทคโนโลยีโฆษณาอ่านจาก บริการคีย์-ค่านี้จากภายใน UDF ที่ทำงานในบริการดึงข้อมูลโฆษณา Ad Retrieval Service ไม่มีบริการอนุมาน ซึ่งต่างจากบริการเสนอราคาของผู้ซื้อ
คำถามหลักอย่างหนึ่งที่การออกแบบนี้ตอบคือวิธีสร้างการคาดการณ์ในเวลาดึงข้อมูลและเวลาเสนอราคา คำตอบสำหรับทั้ง 2 อย่างนี้อาจเกี่ยวข้องกับโซลูชันที่เรียกว่าการแยกตัวประกอบโมเดล
การแยกตัวประกอบโมเดล
การแยกตัวประกอบโมเดลเป็นเทคนิคที่ช่วยให้สามารถแบ่งโมเดลเดียวออกเป็นหลายส่วน แล้วรวมส่วนเหล่านั้นเข้าด้วยกันเพื่อสร้างการคาดการณ์ ในกรณีการใช้งานการติดตั้งแอป โมเดลมักใช้ข้อมูล 3 ประเภท ได้แก่ ข้อมูลผู้ใช้ ข้อมูลตามบริบท และข้อมูลโฆษณา
ในกรณีที่ไม่ได้แยกตัวประกอบ ระบบจะฝึกโมเดลเดียวกับข้อมูลทั้ง 3 ประเภท ในกรณีที่แยกตัวประกอบ เราจะแบ่งโมเดลออกเป็นหลายส่วน เฉพาะ ชิ้นส่วนที่มีข้อมูลผู้ใช้เท่านั้นที่ถือเป็นข้อมูลที่ละเอียดอ่อน ซึ่งหมายความว่าเฉพาะโมเดลที่มี ชิ้นส่วนของผู้ใช้เท่านั้นที่ต้องเรียกใช้ภายในขอบเขตความน่าเชื่อถือในบริการการอนุมานของบริการเสนอราคาของผู้ซื้อ
ซึ่งทำให้การออกแบบต่อไปนี้เป็นไปได้
- แบ่งโมเดลออกเป็นชิ้นส่วนส่วนตัว (ข้อมูลผู้ใช้) และชิ้นส่วนที่ไม่ใช่ส่วนตัวอย่างน้อย 1 ชิ้น (ข้อมูลตามบริบทและข้อมูลโฆษณา)
- ไม่บังคับ: ส่งชิ้นส่วนที่ไม่ใช่ส่วนตัวบางส่วนหรือทั้งหมดเป็นอาร์กิวเมนต์ไปยัง UDF
ที่ต้องทำการคาดการณ์ เช่น ระบบจะส่งการฝังตามบริบทไปยัง UDF ใน
per_buyer_signals
- ไม่บังคับ เทคโนโลยีโฆษณาสามารถสร้างโมเดลสำหรับชิ้นงานที่ไม่ใช่แบบส่วนตัว จากนั้น สร้างการฝังจากโมเดลเหล่านั้นลงในที่เก็บคีย์-ค่าของบริการดึงข้อมูลโฆษณา UDF ในบริการดึงข้อมูลโฆษณาสามารถดึงข้อมูลการฝังเหล่านี้ ได้ในขณะรันไทม์
- หากต้องการทำการคาดการณ์ระหว่าง UDF ให้รวมการฝังแบบส่วนตัวจาก บริการอนุมานกับการฝังแบบไม่เป็นส่วนตัวจากอาร์กิวเมนต์ฟังก์ชัน UDF หรือ ที่เก็บคีย์-ค่าด้วยการดำเนินการ เช่น ผลิตภัณฑ์แบบจุด นี่คือการคาดการณ์สุดท้าย
เมื่ออธิบายแล้ว เราจะมาดูรายละเอียดของ UDF แต่ละรายการกัน เราจะอธิบายว่าโมเดลเหล่านี้ทำอะไรบ้าง ผสานรวมกันอย่างไร และช่วยให้คาดการณ์ที่จำเป็นต่อการเลือกโฆษณาที่ติดอันดับและคำนวณราคาเสนอได้อย่างไร
prepareDataForAdRetrieval()
UDF
prepareDataForAdRetrieval()
ที่ทำงานในบริการเสนอราคาของผู้ซื้อมีหน้าที่
สร้างเพย์โหลดคำขอที่จะส่งไปยังบริการดึงข้อมูลโฆษณาเพื่อดึงโฆษณาผู้สมัครรับเลือก k อันดับแรก
prepareDataForAdRetrieval()
จะใช้ข้อมูลต่อไปนี้
- เพย์โหลดต่อผู้ซื้อที่ได้รับจาก
getAdSelectionData
เพย์โหลดนี้ มีสัญญาณแอปที่ได้รับการปกป้อง auction_signals
ของสัญญาณตามบริบท (สำหรับข้อมูลเกี่ยวกับการประมูล) และbuyer_signals
(สำหรับฟิลด์สัญญาณของผู้ซื้อ)
prepareDataForAdRetrieval()
ทำ 2 อย่างต่อไปนี้
- การสร้างฟีเจอร์: หากจำเป็นต้องมีการอนุมาน ณ เวลาที่ดึงข้อมูล ระบบจะแปลง สัญญาณขาเข้าไปเป็นฟีเจอร์เพื่อใช้ในระหว่างการเรียกใช้บริการอนุมาน เพื่อรับการฝังแบบส่วนตัวสำหรับการดึงข้อมูล
- คำนวณการฝังแบบส่วนตัวสำหรับการดึงข้อมูล: หากจำเป็นต้องมีการคาดคะเนการดึงข้อมูล ระบบจะเรียกใช้บริการอนุมานโดยใช้ฟีเจอร์เหล่านี้ และรับการฝังแบบส่วนตัวสำหรับการคาดคะเนในเวลาดึงข้อมูล
prepareDataForAdRetrieval()
การคืนสินค้า
- สัญญาณแอปที่ได้รับการปกป้อง: เพย์โหลดของสัญญาณที่เทคโนโลยีโฆษณาดูแลจัดการ
- สัญญาณเฉพาะการประมูล: สัญญาณฝั่งผู้ขายเฉพาะแพลตฟอร์ม และ
ข้อมูลเชิงบริบท เช่น
auction_signals
และper_buyer_signals
(รวมถึงการฝังเชิงบริบท) จากSelectAdRequest
ซึ่งคล้ายกับกลุ่มเป้าหมายที่มีการป้องกัน - สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติม เช่น การฝังส่วนตัวที่ดึงข้อมูล จากบริการอนุมาน
คำขอนี้จะถูกส่งไปยังบริการดึงข้อมูลโฆษณา ซึ่งจะทำการจับคู่ผู้สมัคร
และเรียกใช้ getCandidateAds()
UDF
getCandidateAds()
UDF
getCandidateAds()
ทํางานในบริการดึงข้อมูลโฆษณา โดยจะรับคำขอที่สร้างโดย prepareDataForAdRetrieval()
ในบริการเสนอราคาของผู้ซื้อ บริการจะดำเนินการ getCandidateAds()
ซึ่งดึงผู้สมัครรับการเสนอราคา k อันดับแรกโดยแปลงคำขอเป็นชุดคำค้นหา การดึงข้อมูล
และการดำเนินการตามตรรกะทางธุรกิจที่กำหนดเองและตรรกะการดึงข้อมูลอื่นๆ ที่กำหนดเอง
getCandidateAds()
จะใช้ข้อมูลต่อไปนี้
- สัญญาณแอปที่ได้รับการปกป้อง: เพย์โหลดของสัญญาณที่เทคโนโลยีโฆษณาดูแลจัดการ
- สัญญาณเฉพาะการประมูล: สัญญาณฝั่งผู้ขายเฉพาะแพลตฟอร์ม และ
ข้อมูลเชิงบริบท เช่น
auction_signals
และper_buyer_signals
(รวมถึงการฝังเชิงบริบท) จากSelectAdRequest
ซึ่งคล้ายกับกลุ่มเป้าหมายที่มีการป้องกัน - สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติม เช่น การฝังส่วนตัวที่ดึงข้อมูล จากบริการอนุมาน
getCandidateAds()
จะดำเนินการต่อไปนี้
- ดึงชุดผู้สมัครรับเลือกเป็นโฆษณาเริ่มต้น: ดึงโดยใช้เกณฑ์การกำหนดเป้าหมาย เช่น ภาษา ภูมิศาสตร์ ประเภทโฆษณา ขนาดโฆษณา หรืองบประมาณ เพื่อกรองผู้สมัครรับเลือกเป็นโฆษณา
- การดึงข้อมูลการฝังการดึงข้อมูล: หากต้องใช้การฝังจากบริการคีย์-ค่าเพื่อทําการคาดการณ์ขณะดึงข้อมูลสําหรับการเลือก k อันดับแรก จะต้องดึงข้อมูลจากการฝังจากบริการคีย์-ค่า
- การเลือกผู้สมัครรับเลือก k อันดับแรก: คำนวณคะแนนที่มีน้ำหนักเบาสำหรับชุดผู้สมัครรับเลือกโฆษณาที่กรองแล้วตามข้อมูลเมตาของโฆษณาที่ดึงมาจากที่เก็บคีย์-ค่า และข้อมูลที่ส่งจากบริการเสนอราคาของผู้ซื้อ และเลือกผู้สมัครรับเลือก k อันดับแรกตามคะแนนนั้น เช่น คะแนนอาจเป็นโอกาสในการ ติดตั้งแอปเมื่อเห็นโฆษณา
- การดึงข้อมูลการฝังการเสนอราคา: หากโค้ดการเสนอราคาต้องการการฝังจากบริการคีย์-ค่าเพื่อทำการคาดการณ์ขณะเสนอราคา ระบบอาจดึงข้อมูลดังกล่าวจากบริการคีย์-ค่า
โปรดทราบว่าคะแนนของโฆษณาอาจเป็นผลลัพธ์ของโมเดลการคาดการณ์ ซึ่งตัวอย่างเช่น คาดการณ์ความน่าจะเป็นที่ผู้ใช้จะติดตั้งแอป การสร้างคะแนนประเภทนี้เกี่ยวข้องกับการแยกตัวประกอบโมเดล เนื่องจาก getCandidateAds()
ทำงานในบริการการดึงข้อมูลโฆษณา และเนื่องจากบริการการดึงข้อมูลโฆษณาไม่มีบริการอนุมาน การคาดการณ์อาจสร้างขึ้นโดยการรวมสิ่งต่อไปนี้
- การฝังบริบทที่ส่งผ่านโดยใช้สัญญาณเฉพาะของการประมูล อินพุต
- การฝังส่วนตัวที่ส่งผ่านโดยใช้ข้อมูลสัญญาณเพิ่มเติม
- เทคโนโลยีโฆษณาแบบฝังที่ไม่ใช่แบบส่วนตัวได้สร้างขึ้นจากเซิร์ฟเวอร์ของตน เป็นบริการคีย์-ค่าของบริการดึงข้อมูลโฆษณา
โปรดทราบว่า generateBid()
UDF ที่ทำงานในบริการเสนอราคาของผู้ซื้ออาจใช้การแยกตัวประกอบโมเดลของตนเองด้วยเพื่อทำการคาดการณ์การเสนอราคา
หากจำเป็นต้องใช้การฝังจากบริการคีย์-ค่าเพื่อดำเนินการนี้
คุณต้องดึงข้อมูลมาตอนนี้
getCandidateAds()
การคืนสินค้า
- โฆษณาผู้สมัคร: โฆษณา k อันดับแรกที่จะส่งไปยัง
generateBid()
โฆษณาแต่ละรายการประกอบด้วย- URL การแสดงผล: ปลายทางสำหรับการแสดงผลครีเอทีฟโฆษณา
- ข้อมูลเมตา: ข้อมูลเมตาของโฆษณาเฉพาะเทคโนโลยีโฆษณาฝั่งซื้อ เช่น ข้อมูลเกี่ยวกับแคมเปญโฆษณาและเกณฑ์การกำหนดเป้าหมาย เช่น สถานที่ตั้งและภาษา ข้อมูลเมตาอาจมีการฝังที่ไม่บังคับซึ่งใช้เมื่อต้องใช้การแยกตัวประกอบโมเดลเพื่อเรียกใช้ การอนุมานระหว่างการเสนอราคา
- สัญญาณเพิ่มเติม: บริการดึงข้อมูลโฆษณาสามารถรวมข้อมูลเพิ่มเติม เช่น การฝังเพิ่มเติมหรือสัญญาณสแปม เพื่อใช้ใน
generateBid()
ได้ (ไม่บังคับ)
เรากำลังตรวจสอบวิธีอื่นๆ ในการแสดงโฆษณาเพื่อรับคะแนน ซึ่งรวมถึงการทำให้พร้อมใช้งานเป็นส่วนหนึ่งของSelectAdRequest
การเรียก โฆษณาเหล่านี้สามารถดึงข้อมูลได้โดยใช้คำขอราคาเสนอ RTB โปรดทราบว่าในกรณีดังกล่าว ระบบจะต้อง
ดึงโฆษณาโดยไม่มีสัญญาณแอปที่ได้รับการปกป้อง เราคาดว่าเทคโนโลยีโฆษณาจะประเมินข้อแลกเปลี่ยนก่อนเลือกตัวเลือกที่ดีที่สุด ซึ่งรวมถึงขนาดเพย์โหลดการตอบกลับ เวลาในการตอบสนอง ต้นทุน และความพร้อมใช้งานของสัญญาณ
generateBid()
UDF
เมื่อดึงชุดโฆษณาที่อาจเป็นไปได้และ Embedding ระหว่างการดึงข้อมูลแล้ว คุณก็พร้อมที่จะดำเนินการเสนอราคา ซึ่งจะทำงานในบริการเสนอราคาของผู้ซื้อ บริการนี้จะเรียกใช้ UDF ที่ผู้ซื้อระบุ generateBid()
เพื่อเลือกโฆษณาที่จะเสนอราคาจากโฆษณา k อันดับแรก แล้วส่งกลับพร้อมราคาเสนอ
generateBid()
จะใช้ข้อมูลต่อไปนี้
- โฆษณาที่แนะนำ: โฆษณา k อันดับแรกที่บริการดึงข้อมูลโฆษณาแสดง
- สัญญาณเฉพาะการประมูล: สัญญาณฝั่งผู้ขายเฉพาะแพลตฟอร์ม และ
ข้อมูลเชิงบริบท เช่น
auction_signals
และper_buyer_signals
(รวมถึงการฝังเชิงบริบท) จากSelectAdRequest
- สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติมที่จะใช้ในเวลาเสนอราคา
generateBid()
การติดตั้งใช้งานของผู้ซื้อจะดำเนินการ 3 อย่างต่อไปนี้
- การเปลี่ยนให้เป็นฟีเจอร์: เปลี่ยนสัญญาณให้เป็นฟีเจอร์เพื่อใช้ในระหว่าง การอนุมาน
- การอนุมาน: สร้างการคาดการณ์โดยใช้โมเดลแมชชีนเลิร์นนิงเพื่อ คำนวณค่าต่างๆ เช่น อัตราการคลิกผ่านและอัตรา Conversion ที่คาดการณ์ไว้
- การเสนอราคา: การรวมค่าที่อนุมานกับอินพุตอื่นๆ เพื่อคำนวณ ราคาเสนอสำหรับโฆษณาผู้มีสิทธิ์
generateBid()
การคืนสินค้า
- โฆษณาของผู้สมัคร
- จำนวนราคาเสนอที่คำนวณแล้ว
โปรดทราบว่า generateBid()
ที่ใช้สำหรับโฆษณาเพื่อกระตุ้นการติดตั้งแอปและที่ใช้สำหรับ
โฆษณารีมาร์เก็ตติ้งนั้นแตกต่างกัน
ส่วนต่อไปนี้จะอธิบายการสร้างฟีเจอร์ การอนุมาน และการเสนอราคาโดยละเอียด
การสร้างฟีเจอร์
generateBid()
สามารถเตรียมสัญญาณการประมูลให้เป็นฟีเจอร์ได้ ฟีเจอร์เหล่านี้
สามารถใช้ในระหว่างการอนุมานเพื่อคาดการณ์สิ่งต่างๆ เช่น อัตราการคลิกผ่านและ
อัตรา Conversion นอกจากนี้ เรายังกำลังศึกษาเมคานิซึมที่รักษาความเป็นส่วนตัวเพื่อ
ส่งข้อมูลบางส่วนในรายงานที่ชนะเพื่อใช้ในการฝึกโมเดล
การอนุมาน
ในขณะที่คำนวณราคาเสนอ การอนุมานกับโมเดลแมชชีนเลิร์นนิงอย่างน้อย 1 รายการเป็นเรื่องปกติ ตัวอย่างเช่น การคำนวณ eCPM ที่แท้จริงมักจะใช้ โมเดลเพื่อคาดการณ์อัตราการคลิกผ่านและอัตรา Conversion
ลูกค้าสามารถจัดหาโมเดลแมชชีนเลิร์นนิงจำนวนหนึ่งพร้อมกับgenerateBid()
การติดตั้งใช้งาน นอกจากนี้ เราจะจัดหา JavaScript API ภายใน
generateBid()
เพื่อให้ไคลเอ็นต์ทำการอนุมานที่รันไทม์ได้
การอนุมานจะดำเนินการในบริการเสนอราคาของผู้ซื้อ ซึ่งอาจส่งผลต่อเวลาในการตอบสนองและต้นทุนของการอนุมาน โดยเฉพาะอย่างยิ่งเนื่องจากตัวเร่งยังไม่พร้อมใช้งานใน TEE ลูกค้าบางรายจะพบว่าความต้องการของตนได้รับการตอบสนองด้วยโมเดลแต่ละรายการที่ทำงานใน บริการเสนอราคาของผู้ซื้อ ลูกค้าบางราย เช่น ลูกค้าที่มีโมเดลขนาดใหญ่มาก อาจต้องการพิจารณาตัวเลือกต่างๆ เช่น การแยกตัวประกอบโมเดล เพื่อลดต้นทุนและความหน่วงเวลาในการอนุมาน ณ เวลาเสนอราคา
เราจะให้ข้อมูลเพิ่มเติมเกี่ยวกับความสามารถในการอนุมาน เช่น รูปแบบโมเดลที่รองรับและขนาดสูงสุด ในการอัปเดตในอนาคต
ใช้การแยกตัวประกอบโมเดล
ก่อนหน้านี้เราได้อธิบายการแยกตัวประกอบโมเดลไปแล้ว ในเวลาเสนอราคา แนวทางที่เฉพาะเจาะจงคือ
- แบ่งโมเดลเดียวออกเป็นส่วนส่วนตัว (ข้อมูลผู้ใช้) และส่วนที่ไม่ใช่ส่วนตัว (ข้อมูลเชิงบริบทและข้อมูลโฆษณา) อย่างน้อย 1 ส่วน
- ส่งชิ้นส่วนที่ไม่ใช่ส่วนตัวไปยัง
generateBid()
ข้อมูลเหล่านี้อาจมาจากper_buyer_signals
หรือจากข้อมูลฝังที่เทคโนโลยีโฆษณานำมาคำนวณภายนอก จัดเก็บไว้ในที่เก็บคู่คีย์-ค่าของบริการดึงข้อมูล ดึงข้อมูลเมื่อถึงเวลาดึงข้อมูล และแสดงเป็นส่วนหนึ่งของสัญญาณเพิ่มเติม ซึ่งไม่รวมการฝังแบบส่วนตัวเนื่องจากไม่สามารถดึงข้อมูลจากภายนอกขอบเขตความเป็นส่วนตัวได้ - ใน
generateBid()
- ทำการอนุมานกับโมเดลเพื่อรับการฝังผู้ใช้แบบส่วนตัว
- รวมการฝังผู้ใช้แบบส่วนตัวกับการฝังตามบริบทจาก
per_buyer_signals
หรือโฆษณาที่ไม่ใช่แบบส่วนตัวและการฝังตามบริบทจากบริการดึงข้อมูลโดยใช้การดำเนินการ เช่น ผลิตภัณฑ์แบบจุด นี่คือ การคาดการณ์สุดท้ายที่ใช้คำนวณราคาเสนอได้
การใช้วิธีนี้จะช่วยให้คุณทำการอนุมานในเวลาเสนอราคาเทียบกับโมเดลที่อาจมีขนาดใหญ่เกินไปหรือทำงานช้าเกินไปในบริการเสนอราคาของผู้ซื้อได้
ตรรกะการให้คะแนนฝั่งผู้ขาย
ในขั้นตอนนี้ ระบบจะให้คะแนนโฆษณาที่มีราคาเสนอที่ได้รับจากผู้ซื้อที่เข้าร่วมทั้งหมด
เอาต์พุตของ generateBid()
จะส่งไปยังบริการประมูลของผู้ขาย
เพื่อเรียกใช้ scoreAd()
และ scoreAd()
จะพิจารณาโฆษณาครั้งละ 1 รายการเท่านั้น ตามคะแนนที่ได้ ผู้ขายจะเลือกโฆษณาที่ชนะเพื่อแสดงผลในอุปกรณ์
ตรรกะการให้คะแนนจะเหมือนกับที่ใช้สำหรับโฟลว์รีมาร์เก็ตติ้งของ Protected Audience และสามารถเลือกผู้ชนะในกลุ่มผู้สมัครรีมาร์เก็ตติ้งและการติดตั้งแอป ได้ ระบบจะเรียกใช้ฟังก์ชันนี้ 1 ครั้งสำหรับโฆษณาผู้สมัครแต่ละรายการที่ส่งในการประมูลที่ใช้ Protected Audience API ดูรายละเอียดได้ในคำอธิบายการเสนอราคาและการประมูล
รันไทม์ของโค้ดการเลือกโฆษณา
ในข้อเสนอ รหัสการเลือกโฆษณาสำหรับการติดตั้งแอปจะระบุในลักษณะเดียวกันกับ โฟลว์รีมาร์เก็ตติ้งของ Protected Audience โปรดดูรายละเอียดที่หัวข้อการกำหนดค่าการเสนอราคาและการประมูล โค้ดการเสนอราคาจะอยู่ในตำแหน่งที่เก็บข้อมูลระบบคลาวด์เดียวกันกับที่ใช้สำหรับการรีมาร์เก็ตติ้ง
การรายงาน
ข้อเสนอนี้ใช้ Reporting API เดียวกันกับข้อเสนอการรายงาน Protected Audience (เช่น reportImpression()
ซึ่งทําให้แพลตฟอร์มส่งรายงานผู้ขายและผู้ซื้อ)
กรณีการใช้งานทั่วไปอย่างหนึ่งสําหรับการรายงานฝั่งซื้อคือการรับข้อมูลการฝึก สําหรับโมเดลที่ใช้ในระหว่างการเลือกโฆษณา นอกเหนือจาก API ที่มีอยู่แล้ว แพลตฟอร์ม จะมีกลไกเฉพาะสำหรับการส่งออกข้อมูลระดับเหตุการณ์จาก แพลตฟอร์มไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณา เพย์โหลดขาออกเหล่านี้อาจรวมถึงข้อมูลผู้ใช้บางอย่าง
ในระยะยาว เรากำลังตรวจสอบโซลูชันที่รักษาความเป็นส่วนตัวเพื่อจัดการกับการฝึกโมเดลด้วยข้อมูลที่ใช้ในการประมูลที่ได้รับการปกป้องโดยไม่ต้องส่งข้อมูลผู้ใช้ระดับเหตุการณ์ออกนอกบริการที่ทำงานใน TEE เราจะแจ้งรายละเอียดเพิ่มเติม ในการอัปเดตครั้งต่อไป
ในระยะสั้น เราจะจัดหาวิธีชั่วคราวในการส่งออกข้อมูลที่มีการเพิ่มสัญญาณรบกวนจาก
generateBid()
ข้อเสนอเริ่มต้นของเราสำหรับเรื่องนี้มีดังต่อไปนี้ และเราจะพัฒนาข้อเสนอนี้ต่อไป
(รวมถึงการเปลี่ยนแปลงที่อาจไม่เข้ากันแบบย้อนหลัง) เพื่อตอบสนองต่อความคิดเห็นจากอุตสาหกรรม
ในทางเทคนิคแล้ว วิธีการทำงานมีดังนี้
- เทคโนโลยีโฆษณากําหนดสคีมาสําหรับข้อมูลที่ต้องการส่ง
- ใน
generateBid()
ผู้ใช้จะสร้างเพย์โหลดขาออกที่เลือก - แพลตฟอร์มจะตรวจสอบเพย์โหลดขาออกกับสคีมาและบังคับใช้ ขีดจำกัดขนาด
- แพลตฟอร์มจะเพิ่มสัญญาณรบกวนลงในเพย์โหลดขาออก
- ระบบจะรวมเพย์โหลดขาออกไว้ในรายงานการชนะในรูปแบบ Wire ซึ่งได้รับใน เซิร์ฟเวอร์เทคโนโลยีโฆษณา ถอดรหัส และใช้สำหรับการฝึกโมเดล
การกำหนดสคีมาของเพย์โหลดขาออก
เพย์โหลดขาออกต้องมีโครงสร้างที่แพลตฟอร์มเข้าใจได้ เพื่อให้แพลตฟอร์มบังคับใช้ข้อกำหนดด้านความเป็นส่วนตัวที่เปลี่ยนแปลงไปได้ เทคโนโลยีโฆษณาจะกำหนด โครงสร้างของเพย์โหลดขาออกโดยระบุไฟล์ JSON ของสคีมา แพลตฟอร์มจะประมวลผลสคีมาดังกล่าว และบริการการเสนอราคาและการประมูลจะเก็บข้อมูลดังกล่าวไว้เป็นความลับโดยใช้กลไกเดียวกันกับแหล่งข้อมูลเทคโนโลยีโฆษณาอื่นๆ เช่น UDF และโมเดล
เราจะจัดหาไฟล์ CDDL ที่กำหนดโครงสร้างของ JSON นั้น ไฟล์ CDDL จะมีชุดประเภทฟีเจอร์ที่รองรับ (เช่น ฟีเจอร์ที่เป็นบูลีน จำนวนเต็ม บัคเก็ต และอื่นๆ) ทั้งไฟล์ CDDL และสคีมาที่ระบุจะมีการควบคุมเวอร์ชัน
ตัวอย่างเช่น เพย์โหลดขาออกที่ประกอบด้วยฟีเจอร์บูลีนเดียว ตามด้วยฟีเจอร์กลุ่มที่มีขนาด 2 จะมีลักษณะดังนี้
egressPayload = {
features : [
{
type: "boolean_feature",
value: false
},
{
type: "bucket_feature",
size: 2,
value: [
{
value: false
},
{
value: true
}
]
}
]
}
ดูรายละเอียดเกี่ยวกับชุดประเภทฟีเจอร์ที่รองรับได้ที่ GitHub
สร้างเพย์โหลดขาออกใน generateBid()
สัญญาณแอปที่ได้รับการปกป้องทั้งหมดสำหรับผู้ซื้อรายหนึ่งๆ จะพร้อมใช้งานใน generateBid()
UDF เมื่อมีการสร้างฟีเจอร์เหล่านี้แล้ว เทคโนโลยีโฆษณาจะสร้างเพย์โหลดในรูปแบบ JSON
ระบบจะรวมเพย์โหลดขาออกนี้ไว้ในรายงานการชนะของผู้ซื้อเพื่อ
ส่งไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณา
อีกทางเลือกหนึ่งแทนการออกแบบนี้คือการคำนวณเวกเตอร์ขาออกจะเกิดขึ้นใน reportWin()
แทน generateBid()
แต่ละวิธีมีข้อดีข้อเสียแตกต่างกันไป และเราจะสรุปการตัดสินใจนี้เพื่อตอบสนองต่อความคิดเห็นในอุตสาหกรรม
ตรวจสอบความถูกต้องของเพย์โหลดขาออก
แพลตฟอร์มจะตรวจสอบเพย์โหลดขาออกที่สร้างโดยเทคโนโลยีโฆษณา การตรวจสอบ จะยืนยันว่าค่าฟีเจอร์ถูกต้องสำหรับประเภทของค่าดังกล่าว เป็นไปตามข้อจำกัดด้านขนาด และผู้ไม่ประสงค์ดีไม่ได้พยายามหลบเลี่ยงการควบคุมความเป็นส่วนตัวโดย การแพ็กข้อมูลเพิ่มเติมลงในเพย์โหลดขาออก
หากเพย์โหลดขาออกไม่ถูกต้อง ระบบจะทิ้งเพย์โหลดดังกล่าวจากอินพุต ที่ส่งไปยังรายงานผลลัพธ์โดยไม่มีการแจ้งเตือน เนื่องจากเราไม่ต้องการให้ข้อมูลการแก้ไขข้อบกพร่อง แก่ผู้ไม่ประสงค์ดีที่พยายามหลีกเลี่ยงการตรวจสอบ
เราจะจัดหา JavaScript API ให้เทคโนโลยีโฆษณาเพื่อยืนยันเพย์โหลดขาออกที่สร้างใน generateBid()
จะผ่านการตรวจสอบแพลตฟอร์ม
validate(payload, schema)
JavaScript API นี้มีไว้สำหรับผู้เรียกใช้เพื่อตรวจสอบว่าเพย์โหลดหนึ่งๆ
จะผ่านการตรวจสอบแพลตฟอร์มหรือไม่ การตรวจสอบจริงต้องทำในแพลตฟอร์มเพื่อป้องกัน generateBid()
UDF ที่เป็นอันตราย
เพิ่มสัญญาณรบกวนให้กับเพย์โหลดขาออก
แพลตฟอร์มจะเพิ่มสัญญาณรบกวนให้กับเพย์โหลดขาออกก่อนที่จะรวมไว้ในรายงานผลลัพธ์ เกณฑ์สัญญาณรบกวนเริ่มต้นจะอยู่ที่ 1% และค่านี้อาจเปลี่ยนแปลงไปเมื่อเวลาผ่านไป แพลตฟอร์มจะไม่ระบุว่าเพย์โหลดขาออก ใดมีการเพิ่มสัญญาณรบกวนหรือไม่
วิธีการเพิ่มสัญญาณรบกวนมีดังนี้
- แพลตฟอร์มจะโหลดคำจำกัดความของสคีมาสำหรับเพย์โหลดขาออก
- ระบบจะเลือกเพย์โหลดขาออก 1% เพื่อเพิ่มสัญญาณรบกวน
- หากไม่ได้เลือกเพย์โหลดขาออก ระบบจะเก็บค่าเดิมทั้งหมดไว้
- หากเลือกเพย์โหลดขาออก ระบบจะแทนที่ค่าของฟีเจอร์แต่ละรายการด้วยค่าที่ถูกต้องแบบสุ่มสำหรับประเภทฟีเจอร์นั้น (เช่น
0
หรือ1
สำหรับฟีเจอร์บูลีน)
การส่ง รับ และถอดรหัสเพย์โหลดขาออกสำหรับการฝึกโมเดล
ระบบจะรวมเพย์โหลดขาออกที่ผ่านการตรวจสอบแล้วและมีการเพิ่มสัญญาณรบกวนไว้ในอาร์กิวเมนต์ไปยัง
reportWin()
และส่งไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ซื้อภายนอกขอบเขตความเป็นส่วนตัว
เพื่อการฝึกโมเดล เพย์โหลดขาออกจะอยู่ในรูปแบบการส่งผ่านข้อมูล
รายละเอียดเกี่ยวกับรูปแบบการส่งข้อมูลสำหรับฟีเจอร์ทุกประเภทและสำหรับเพย์โหลดขาออก มีอยู่ใน GitHub
กำหนดขนาดของเพย์โหลดขาออก
ขนาดของเพย์โหลดขาออกเป็นบิตจะสร้างความสมดุลระหว่างยูทิลิตีและการลดข้อมูลให้เหลือน้อยที่สุด เราจะทำงานร่วมกับอุตสาหกรรมเพื่อกำหนดขนาดที่เหมาะสมผ่านการทดลอง ในระหว่างที่เราทำการทดสอบเหล่านั้น เราจะส่งออกข้อมูลชั่วคราวโดยไม่มีการจำกัดขนาดบิต ระบบจะนำข้อมูลขาออกเพิ่มเติมที่ไม่มีข้อจำกัดด้านบิต ไซส์ออกเมื่อการทดสอบเสร็จสมบูรณ์
วิธีการกำหนดขนาดมีดังนี้
- ในระยะแรก เราจะรองรับเพย์โหลดขาออก 2 รายการใน
generateBid()
ดังนี้egressPayload
: เพย์โหลดขาออกที่มีการจำกัดขนาดตามที่เราอธิบายไว้จนถึงตอนนี้ ในเอกสารนี้ ในตอนแรก ขนาดของเพย์โหลดขาออกนี้จะเป็น 0 บิต (ซึ่งหมายความว่าจะถูกนำออกเสมอในระหว่างการตรวจสอบ)temporaryUnlimitedEgressPayload
: เพย์โหลดขาออกแบบไม่จำกัดขนาดชั่วคราว สำหรับการทดสอบขนาด การจัดรูปแบบ การสร้าง และการประมวลผล เพย์โหลดขาออกนี้ใช้กลไกเดียวกันกับegressPayload
- เพย์โหลดขาออกแต่ละรายการจะมีไฟล์ JSON ของสคีมาของตัวเอง ดังนี้
egress_payload_schema.json
และtemporary_egress_payload_schema.json
- เรามีโปรโตคอลการทดสอบและชุดเมตริกสำหรับกำหนดอรรถประโยชน์ของโมเดล ที่ขนาดเพย์โหลดขาออกต่างๆ (เช่น 5, 10, ... บิต)
- จากผลการทดสอบ เราจะกำหนดขนาดเพย์โหลดขาออกโดยมี การแลกเปลี่ยนด้านยูทิลิตีและความเป็นส่วนตัวที่เหมาะสม
- เราตั้งค่าขนาดของ
egressPayload
จาก 0 บิตเป็นขนาดใหม่ - หลังจากระยะเวลาการย้ายข้อมูลที่กำหนด เราจะนำ
temporaryUnlimitedEgressPayload
ออก เหลือเพียงegressPayload
ที่มีขนาดใหม่
เรากำลังตรวจสอบแนวทางด้านเทคนิคเพิ่มเติมเพื่อจัดการการเปลี่ยนแปลงนี้
(เช่น การเข้ารหัส egressPayload
เมื่อเราเพิ่มขนาดจาก 0 บิต)
รายละเอียดดังกล่าว รวมถึงช่วงเวลาสำหรับการทดสอบและการนำ temporaryUnlimitedEgressPayload
ออก จะรวมอยู่ในการอัปเดตในภายหลัง
ต่อไปเราจะอธิบายโปรโตคอลการทดสอบที่เป็นไปได้เพื่อสรุปขนาดของ
egressPayload
เป้าหมายของเราคือการทำงานร่วมกับอุตสาหกรรมเพื่อหาขนาดที่สมดุลระหว่าง
ยูทิลิตีและการลดข้อมูลให้เหลือน้อยที่สุด อาร์ติแฟกต์ที่การทดสอบเหล่านี้จะสร้างขึ้นคือกราฟที่แกน x เป็นขนาดของเพย์โหลดการฝึกในหน่วยบิต และแกน y เป็นเปอร์เซ็นต์ของรายได้ที่โมเดลสร้างขึ้นที่ขนาดนั้นๆ เมื่อเทียบกับพื้นฐานที่ไม่มีการจำกัดขนาด
เราจะถือว่าเรากำลังฝึกโมเดล pInstall และแหล่งข้อมูลการฝึกของเรา
คือบันทึกและเนื้อหาของ temporaryUnlimitedegressPayload
ที่เรา
ได้รับเมื่อชนะการประมูล โปรโตคอลสำหรับเทคโนโลยีโฆษณาเกี่ยวข้องกับการทดสอบแบบออฟไลน์ก่อน
- กำหนดสถาปัตยกรรมของโมเดลที่จะใช้กับสัญญาณของแอปที่ได้รับการปกป้อง เช่น จะต้องพิจารณาว่าจะใช้การแยกตัวประกอบโมเดลหรือไม่
- กำหนดเมตริกสำหรับการวัดคุณภาพของโมเดล เมตริกที่แนะนำคือ AUC Loss และ Log Loss
- กำหนดชุดฟีเจอร์ที่จะใช้ในระหว่างการฝึกโมเดล
- ใช้สถาปัตยกรรมโมเดล เมตริกคุณภาพ และชุดฟีเจอร์การฝึก
ทำการศึกษาการตัดทอนเพื่อพิจารณาอรรถประโยชน์ที่ได้ต่อบิตสำหรับแต่ละ
โมเดลที่ต้องการใช้ใน PAS โปรโตคอลที่แนะนำสำหรับการศึกษาการตัดออก
มีดังนี้
- ฝึกโมเดลด้วยฟีเจอร์ทั้งหมดและวัดอรรถประโยชน์ ซึ่งเป็น พื้นฐานสำหรับการเปรียบเทียบ
- สําหรับฟีเจอร์แต่ละรายการที่ใช้ในการสร้างค่าพื้นฐาน ให้ฝึกโมเดลด้วยฟีเจอร์ทั้งหมดยกเว้นฟีเจอร์นั้น
- วัดอรรถประโยชน์ที่ได้ นำเดลต้ามาหารด้วยขนาดของฟีเจอร์ ในหน่วยบิต ซึ่งจะเป็นอรรถประโยชน์ที่คาดไว้ต่อบิตสำหรับฟีเจอร์นั้น
- กำหนดขนาดเพย์โหลดการฝึกที่สนใจสำหรับการทดลอง เราขอแนะนำ [5, 10, 15, ...,
size_of_all_training_features_for_baseline
] บิต แต่ละขนาดแสดงถึงขนาดที่เป็นไปได้สำหรับegressPayload
ที่การทดสอบจะประเมิน - สำหรับขนาดที่เป็นไปได้แต่ละขนาด ให้เลือกชุดฟีเจอร์ที่มีขนาดน้อยกว่าหรือเท่ากับขนาดนั้น ซึ่งจะเพิ่มอรรถประโยชน์ต่อบิตสูงสุด โดยใช้ผลการศึกษาแบบ Ablation
- ฝึกโมเดลสำหรับขนาดที่เป็นไปได้แต่ละขนาดและประเมินอรรถประโยชน์เป็น เปอร์เซ็นต์ของอรรถประโยชน์ของโมเดลพื้นฐานที่ฝึกกับฟีเจอร์ทั้งหมด
- พล็อตผลลัพธ์ในกราฟที่แกน x คือขนาดของเพย์โหลดการฝึกเป็นบิต และแกน y คือเปอร์เซ็นต์ของรายได้ที่โมเดลนั้นสร้างขึ้นเมื่อเทียบกับค่าพื้นฐาน
จากนั้น เทคโนโลยีโฆษณาสามารถทำซ้ำขั้นตอนที่ 5-8 ในการทดสอบการเข้าชมจริงได้ โดยใช้ข้อมูลฟีเจอร์
ที่ส่งผ่าน temporaryUnlimitedEgressPayload
เทคโนโลยีโฆษณาสามารถเลือกที่จะแชร์
ผลการทดสอบการเข้าชมแบบออฟไลน์และแบบเรียลไทม์กับ Privacy Sandbox
เพื่อแจ้งการตัดสินใจเกี่ยวกับขนาดของ egressPayload
ไทม์ไลน์สำหรับการทดสอบเหล่านี้ รวมถึงไทม์ไลน์สำหรับการตั้งค่าขนาดของ egressPayload
เป็นค่าผลลัพธ์อยู่นอกขอบเขตของเอกสารนี้
และจะมาในการอัปเดตในภายหลัง
มาตรการคุ้มครองข้อมูล
เราจะใช้การป้องกันหลายอย่างกับข้อมูลที่ส่งออก ซึ่งรวมถึง
- ทั้ง
egressPayload
และtemporaryUnlimitedEgressPayload
จะมีสัญญาณรบกวน - เพื่อลดและปกป้องข้อมูล
temporaryUnlimitedEgressPayload
จะ ใช้ได้เฉพาะในระยะเวลาของการทดสอบขนาด ซึ่งเราจะ กำหนดขนาดที่ถูกต้องสำหรับegressPayload
สิทธิ์
การควบคุมของผู้ใช้
- ข้อเสนอมีจุดประสงค์เพื่อให้ผู้ใช้มองเห็นรายการแอปที่ติดตั้ง ซึ่งจัดเก็บสัญญาณแอปที่ได้รับการปกป้องหรือกลุ่มเป้าหมายที่กำหนดเองอย่างน้อย 1 รายการ
- ผู้ใช้สามารถบล็อกและนำแอปออกจากรายการนี้ได้ การบล็อกและการนำออกจะดำเนินการต่อไปนี้
- ล้างสัญญาณแอปที่ได้รับการคุ้มครองและกลุ่มเป้าหมายที่กำหนดเองทั้งหมดที่เชื่อมโยงกับ แอป
- ป้องกันไม่ให้แอปจัดเก็บสัญญาณแอปที่ได้รับการปกป้องใหม่และกลุ่มเป้าหมายที่กำหนดเอง
- ผู้ใช้สามารถรีเซ็ตสัญญาณแอปที่ได้รับการปกป้องและ Protected Audience API ได้อย่างสมบูรณ์ เมื่อเกิดกรณีนี้ ระบบจะล้างสัญญาณแอปที่ได้รับการปกป้อง และกลุ่มเป้าหมายที่กำหนดเองที่มีอยู่ในอุปกรณ์
- ผู้ใช้สามารถเลือกไม่ใช้ Privacy Sandbox ใน Android ได้ทั้งหมด ซึ่งรวมถึง Protected App Signals API และ Protected Audience API
ในกรณีนี้ Protected Audience API และ Protected App Signals API
จะแสดงข้อความข้อยกเว้นมาตรฐาน:
SECURITY_EXCEPTION
สิทธิ์และการควบคุมของแอป
ข้อเสนอมีจุดประสงค์เพื่อให้แอปควบคุมสัญญาณของแอปที่ได้รับการปกป้องได้
- แอปสามารถจัดการการเชื่อมโยงกับสัญญาณแอปที่ได้รับการปกป้องได้
- แอปสามารถให้สิทธิ์แพลตฟอร์มเทคโนโลยีโฆษณาของบุคคลที่สามในการจัดการ สัญญาณแอปที่ปกป้องในนามของตนได้
การควบคุมแพลตฟอร์มเทคโนโลยีโฆษณา
ข้อเสนอนี้ระบุวิธีที่เทคโนโลยีโฆษณาสามารถควบคุมสัญญาณแอปที่ได้รับการปกป้องของตนเองได้ ดังนี้
- เทคโนโลยีโฆษณาทั้งหมดต้องลงทะเบียนกับ Privacy Sandbox และระบุโดเมน "เว็บไซต์" หรือ "ต้นทาง" ที่ตรงกับ URL ทั้งหมดสำหรับสัญญาณแอปที่ได้รับการปกป้อง
- เทคโนโลยีโฆษณาสามารถเป็นพาร์ทเนอร์กับแอปหรือ SDK เพื่อให้โทเค็นการยืนยันที่ใช้เพื่อยืนยันการสร้างสัญญาณแอปที่ปกป้อง เมื่อมอบหมายกระบวนการนี้ให้พาร์ทเนอร์ คุณจะกำหนดค่าการสร้างสัญญาณแอปที่ปกป้องความเป็นส่วนตัวให้ต้องมีการรับทราบจากเทคโนโลยีโฆษณาได้