Protected App Signals เพื่อรองรับโฆษณาเพื่อการติดตั้งแอปที่เกี่ยวข้อง

ข้อเสนอนี้ขึ้นอยู่กับขั้นตอนการลงทะเบียน Privacy Sandbox และ และการรับรอง ดูข้อมูลเพิ่มเติมเกี่ยวกับเอกสารรับรองได้ที่ ไปยังลิงก์เอกสารรับรองที่ให้ไว้ การอัปเดตข้อเสนอนี้ในอนาคตจะ อธิบายข้อกำหนดในการเข้าถึงระบบนี้

โฆษณาเพื่อการติดตั้งแอปบนอุปกรณ์เคลื่อนที่ หรือที่เรียกว่าโฆษณาการได้ผู้ใช้ใหม่ โฆษณาบนอุปกรณ์เคลื่อนที่ที่ออกแบบมาเพื่อกระตุ้นให้ผู้ใช้ดาวน์โหลดแอปบนอุปกรณ์เคลื่อนที่ เหล่านี้ โดยทั่วไปโฆษณาจะแสดงต่อผู้ใช้ตามความสนใจและข้อมูลประชากร และ มักปรากฏในแอปบนอุปกรณ์เคลื่อนที่อื่นๆ เช่น เกม โซเชียลมีเดีย และข่าว แอป เมื่อผู้ใช้คลิกโฆษณาเพื่อการติดตั้งแอป ระบบจะนําผู้ใช้ไปยัง App Store เพื่อดาวน์โหลดแอป

เช่น ผู้ลงโฆษณาที่พยายามเพิ่มยอดการติดตั้งใหม่ให้อุปกรณ์เคลื่อนที่เครื่องใหม่ แอปจัดส่งอาหารในสหรัฐอเมริกาอาจกำหนดเป้าหมายโฆษณาไปยังผู้ใช้ สถานที่ตั้งอยู่ในสหรัฐอเมริกาและเคยมีส่วนร่วมกับการจัดส่งอาหารอื่นๆ แอป

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

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

1. Protected App Signals API: ศูนย์กลางอยู่ที่พื้นที่เก็บข้อมูลและ การสร้างฟีเจอร์ทางวิศวกรรมของเทคโนโลยีโฆษณาที่แสดงถึงศักยภาพของผู้ใช้ ความสนใจ เทคโนโลยีโฆษณาจะจัดเก็บสัญญาณเหตุการณ์ต่อแอปแบบกำหนดด้วยตนเอง เช่น แอป การติดตั้ง การเปิดครั้งแรก การกระทำของผู้ใช้ (การเล่นเกมผ่านด่าน รางวัลพิเศษ) กิจกรรมการซื้อ หรือเวลาในแอป ระบบจะเขียนและจัดเก็บสัญญาณไว้ใน อุปกรณ์เพื่อป้องกันการรั่วไหลของข้อมูล และพร้อมให้บริการแก่ ตรรกะเทคโนโลยีโฆษณาที่จัดเก็บสัญญาณที่ระบุระหว่างการประมูลที่มีการคุ้มครอง ทำงานในสภาพแวดล้อมที่ปลอดภัย
2. API การเลือกโฆษณา: จะมี API สำหรับกำหนดค่าและเรียกใช้ การประมูลที่มีการป้องกันที่ทำงานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ที่เทคโนโลยีโฆษณาดึงข้อมูลผู้สมัคร ใช้การอนุมาน คำนวณราคาเสนอ คะแนนเพื่อเลือก "ผู้ชนะ" โฆษณาที่ใช้ทั้งสัญญาณแอปที่มีการป้องกันและ ข้อมูลบริบทแบบเรียลไทม์จากผู้เผยแพร่โฆษณา

โฟลว์ชาร์ตที่แสดงสัญญาณแอปที่มีการป้องกันและเวิร์กโฟลว์การเลือกโฆษณาใน Privacy Sandbox ใน Android

ต่อไปนี้เป็นภาพรวมระดับสูงเกี่ยวกับวิธีการทำงานของสัญญาณแอปที่มีการป้องกัน โฆษณาเพื่อการติดตั้งแอปที่เกี่ยวข้อง เนื้อหาในส่วนต่อไปนี้ของเอกสารนี้ให้ข้อมูลเพิ่มเติม รายละเอียดเกี่ยวกับแต่ละขั้นตอน

• การดูแลจัดการสัญญาณ: ขณะที่ผู้ใช้ใช้แอปบนอุปกรณ์เคลื่อนที่ เทคโนโลยีโฆษณาจะดูแลจัดการสัญญาณ โดยจัดเก็บเหตุการณ์ของแอปที่กำหนดโดยเทคโนโลยีโฆษณาสำหรับการแสดงโฆษณาที่เกี่ยวข้องโดยใช้ Protected App Signals API เหตุการณ์เหล่านี้จัดเก็บไว้ในอุปกรณ์ที่ได้รับการคุ้มครอง พื้นที่เก็บข้อมูล ซึ่งคล้ายกับกลุ่มเป้าหมายที่กำหนดเอง และจะได้รับการเข้ารหัสก่อนที่จะ ออกจากอุปกรณ์โดยที่มีเฉพาะบริการเสนอราคาและประมูลที่ทำงานอยู่ ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้และมีการรักษาความปลอดภัยที่เหมาะสม การควบคุมความเป็นส่วนตัวสามารถถอดรหัสสำหรับการเสนอราคาและการให้คะแนนโฆษณา
• การเข้ารหัสสัญญาณ: มีการเตรียมสัญญาณตามช่วงเวลาที่กำหนดไว้โดย ตรรกะเทคโนโลยีโฆษณาที่กำหนดเอง งานในเบื้องหลังของ Android จะดำเนินการกับตรรกะนี้ ทำการเข้ารหัสในอุปกรณ์เพื่อสร้างเพย์โหลดของสัญญาณแอปที่มีการป้องกัน ที่สามารถใช้แบบเรียลไทม์สำหรับการเลือกโฆษณาในระหว่าง การประมูล ระบบจะเก็บเพย์โหลดไว้อย่างปลอดภัยในอุปกรณ์จนกว่าจะมีการส่ง การประมูล
• การเลือกโฆษณา: ในการเลือกโฆษณาที่เกี่ยวข้องสำหรับผู้ใช้ SDK ผู้ขาย ส่งเพย์โหลดที่เข้ารหัสของสัญญาณแอปที่มีการป้องกันและกำหนดค่า การประมูลที่มีการคุ้มครอง ในการประมูลนั้น ผู้ซื้อจะเตรียมฟังก์ชันการป้องกัน สัญญาณของแอปพร้อมข้อมูลบริบทที่ได้จากผู้เผยแพร่โฆษณา (ข้อมูล โดยทั่วไปจะแชร์ในคำขอโฆษณา Open-RTB) เพื่อกำหนด ฟีเจอร์ที่มีไว้สำหรับการเลือกโฆษณา (การดึงข้อมูล การอนุมาน และราคาเสนอ รุ่นใหม่) เช่นเดียวกับ Protected Audience ผู้ซื้อจะส่งโฆษณาไปที่ เพื่อให้ได้คะแนนสุดท้ายในการประมูลที่มีการป้องกัน
  • การดึงข้อมูลโฆษณา: ผู้ซื้อใช้สัญญาณแอปที่มีการป้องกันและ ข้อมูลบริบทที่ผู้เผยแพร่โฆษณาให้ไว้แก่ฟีเจอร์ด้านวิศวกรรม เกี่ยวข้องกับความสนใจของผู้ใช้ ฟีเจอร์เหล่านี้ใช้เพื่อจับคู่โฆษณา ที่ตรงกับเกณฑ์การกำหนดเป้าหมาย โฆษณาที่ไม่ได้อยู่ในงบประมาณจะถูกกรองออก จากนั้น ระบบจะเลือกโฆษณา k ระดับบนสุดสำหรับการเสนอราคา
  • การเสนอราคา: ผู้ซื้อ ตรรกะการเสนอราคาที่กำหนดเองจะเตรียมฟังก์ชัน ข้อมูลบริบทที่ได้จากผู้เผยแพร่โฆษณาและสัญญาณแอปที่มีการป้องกันสำหรับวิศวกร ฟีเจอร์ที่ใช้เป็นอินพุตของโมเดลแมชชีนเลิร์นนิงของผู้ซื้อสำหรับ การอนุมานและการเสนอราคาสำหรับโฆษณาของผู้สมัครรับเลือกตั้งภายในการรักษาความเป็นส่วนตัวที่เชื่อถือได้ บ้างก็ได้ จากนั้นผู้ซื้อจะส่งคืนโฆษณาที่เลือกไว้ให้กับผู้ขาย
  • การให้คะแนนผู้ขาย: ผู้ขาย โฆษณาคะแนนตรรกะการให้คะแนนที่กำหนดเอง ที่ส่งโดยผู้ซื้อที่เข้าร่วม และเลือกโฆษณาที่ชนะให้ส่ง เพื่อกลับไปยังแอปเพื่อแสดงภาพ
• การรายงาน: ผู้เข้าร่วมการประมูลจะได้รับรายงานการชนะที่เกี่ยวข้องและ หรือรายงานการสูญเสียพื้นที่เก็บข้อมูล เรากำลังสำรวจกลไกการรักษาความเป็นส่วนตัวสำหรับ สำหรับการฝึกโมเดลในรายงานที่ชนะ

ไทม์ไลน์

	ตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์			เบต้า
ฟีเจอร์	ไตรมาส 4 ปี 2023	ไตรมาส 1 ปี 2024	ไตรมาส 2 ปี 2024	ไตรมาส 3 ปี 2024
API การดูแลจัดการสัญญาณ	API พื้นที่เก็บข้อมูลในอุปกรณ์	ตรรกะโควต้าพื้นที่เก็บข้อมูลในอุปกรณ์ การอัปเดตรายวันเกี่ยวกับตรรกะที่กำหนดเองในอุปกรณ์	ไม่มี	ใช้ได้กับอุปกรณ์ T+ 1%
เซิร์ฟเวอร์การดึงข้อมูลโฆษณาใน TEE	ผู้เล่นยอดเยี่ยม	พร้อมใช้งานใน GCP การสนับสนุนสำหรับ K ยอดนิยม การผลิต UDF	พร้อมใช้งานบน AWS การแก้ไขข้อบกพร่อง เมตริก และการตรวจสอบที่ได้รับความยินยอม
บริการอนุมานใน TEE รองรับการเรียกใช้โมเดล ML และใช้สำหรับการเสนอราคาใน TEE	อยู่ระหว่างการพัฒนา	พร้อมใช้งานใน GCP ความสามารถในการติดตั้งใช้งานและ สร้างต้นแบบโมเดล ML แบบคงที่โดยใช้ Tensorflow และ PyTorch	พร้อมใช้งานบน AWS การทำให้โมเดลใช้งานได้จริงสำหรับโมเดล Tensorflow และ PyTorch การตรวจวัดระยะไกล การแก้ไขข้อบกพร่องที่ได้รับความยินยอม และการตรวจสอบ
การสนับสนุนการเสนอราคาและการประมูล ใน TEE	พร้อมใช้งานบน GCP	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 ประกอบด้วยส่วนต่างๆ ต่อไปนี้

• Java และ JavaScript API เพื่อเพิ่ม อัปเดต หรือนำสัญญาณออก
• JavaScript API เพื่อประมวลผลสัญญาณที่มีอยู่เพื่อเตรียมพร้อมสำหรับ ฟีเจอร์ทางวิศวกรรมเพิ่มเติมสำหรับแบบเรียลไทม์ระหว่างที่การประมูลที่มีการคุ้มครองทำงานอยู่ ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)

เพิ่ม อัปเดต หรือนำสัญญาณออก

เทคโนโลยีโฆษณาสามารถเพิ่ม อัปเดต หรือนำสัญญาณออกได้ด้วย fetchSignalUpdates() API API นี้รองรับการมอบสิทธิ์ที่คล้ายกับกลุ่มเป้าหมายที่กำหนดเองของ Protected Audience การมอบสิทธิ์

หากต้องการเพิ่มสัญญาณ เทคโนโลยีโฆษณาของผู้ซื้อที่ไม่มีข้อมูล SDK ในแอปจะต้อง ทำงานร่วมกับเทคโนโลยีโฆษณาที่มีตัวตนในอุปกรณ์ เช่น อุปกรณ์เคลื่อนที่ พาร์ทเนอร์การวัดผล (MMP) และแพลตฟอร์มฝั่งซัพพลาย (SSP) แอปที่ได้รับการคุ้มครอง Signals API มีเป้าหมายที่จะสนับสนุนเทคโนโลยีโฆษณาเหล่านี้ด้วยการมอบโซลูชันที่ยืดหยุ่นสำหรับ การจัดการสัญญาณแอปที่มีการป้องกันโดยการเปิดใช้ผู้โทรในอุปกรณ์เพื่อเรียกใช้ การสร้างสัญญาณแอปที่มีการป้องกันในนามของผู้ซื้อ กระบวนการนี้เรียกว่า และใช้ประโยชน์จาก fetchSignalUpdates() API fetchSignalUpdates() จะรับ URI และดึงรายการการอัปเดตสัญญาณ ขออธิบายให้เห็นภาพ fetchSignalUpdates() จะออกคำขอ GET ไปยัง URI ที่ระบุเพื่อเรียก รายการอัปเดตที่จะใช้กับพื้นที่เก็บข้อมูลสัญญาณในเครื่อง ปลายทางของ URL ที่เป็นของ ผู้ซื้อตอบกลับด้วยรายการคำสั่ง JSON

คำสั่ง JSON ที่รองรับ ได้แก่

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

{
   "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 ทุกชั่วโมงเพื่อเรียกใช้ตรรกะการเข้ารหัสที่กำหนดเองต่อผู้ซื้อ ซึ่งดาวน์โหลดไปยัง อุปกรณ์ ตรรกะการเข้ารหัสที่กำหนดเองต่อผู้ซื้อจะเข้ารหัสสัญญาณต่อแอป และ แล้วบีบอัดสัญญาณต่อแอปลงในเพย์โหลดที่สอดคล้องกับ ต่อผู้ซื้อ ระบบจะเข้ารหัสเพย์โหลดภายในขอบเขตของ พื้นที่เก็บข้อมูลของอุปกรณ์ที่มีการป้องกัน แล้วส่งไปยังบริการเสนอราคาและประมูล

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

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

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

เวิร์กโฟลว์การเลือกโฆษณา

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

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

วันที่

เวิร์กโฟลว์การเลือกโฆษณาใน Privacy Sandbox ใน Android

เวิร์กโฟลว์การเลือกโฆษณามีดังนี้

1. SDK ของผู้ขายส่งเปย์โหลดที่มีการป้องกันในอุปกรณ์ที่เข้ารหัส สัญญาณของแอป
2. เซิร์ฟเวอร์ของผู้ขายสร้างการกำหนดค่าการประมูลแล้วส่งไปยัง บริการเสนอราคาที่เชื่อถือได้และบริการประมูลของผู้ขาย ควบคู่กับการเข้ารหัส เพย์โหลด เพื่อเริ่มต้นเวิร์กโฟลว์การเลือกโฆษณา
3. บริการเสนอราคาและประมูลของผู้ขายจะส่งข้อมูลเพย์โหลดไปยัง เซิร์ฟเวอร์ฟรอนท์เอนด์ของผู้ซื้อที่เชื่อถือได้ที่เข้าร่วม
4. บริการการเสนอราคาของผู้ซื้อจะเรียกใช้ตรรกะการเลือกโฆษณาฝั่งซื้อ
   1. การดำเนินการตรรกะการเรียกโฆษณาฝั่งผู้ซื้อ
   2. การดำเนินการตามตรรกะการเสนอราคาฝั่งผู้ซื้อ
5. ดำเนินการตรรกะการให้คะแนนฝั่งขาย
6. โฆษณาจะแสดงผลและเริ่มต้นการรายงาน

เริ่มเวิร์กโฟลว์การเลือกโฆษณา

เมื่อแอปพลิเคชันพร้อมแสดงโฆษณาแล้ว 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 บนสุด) ซึ่งจะมีการคำนวณราคาเสนอ ก่อนจะส่งโฆษณาให้ผู้ขายเพื่อขอเลือกในขั้นสุดท้าย

วันที่

ตรรกะการดำเนินการเลือกโฆษณาฝั่งผู้ซื้อใน Privacy Sandbox ใน Android

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

หมายเหตุ: ขั้นตอนนี้เป็นการผสมผสานระหว่างโค้ดเฟรมเวิร์กและฟังก์ชันที่ผู้ใช้กำหนด (UDF) ที่มีตรรกะทางธุรกิจของผู้ซื้อ UDF เหล่านี้มีการใช้งานใน JavaScript หรือ WASM ขั้นตอนในระดับสูงมีดังนี้

1. บริการ BuyerFrontEnd ได้รับคำขอโฆษณา
2. บริการ BuyerFrontEnd จะส่งคำขอไปยังบริการการเสนอราคาของผู้ซื้อ บริการเสนอราคาของผู้ซื้อเรียกใช้ UDF ชื่อ prepareDataForAdRetrieval() ซึ่งจะสร้างคำขอเพื่อให้ได้ผู้สมัคร k อันดับสูงสุดจากการดึงข้อมูลโฆษณา บริการ บริการการเสนอราคาจะส่งคำขอนี้ไปยังการดึงข้อมูลที่กำหนดค่าไว้ ปลายทางของเซิร์ฟเวอร์
3. บริการดึงข้อมูลโฆษณาเรียกใช้ getCandidateAds() UDF จนถึงชุดของโฆษณา K ที่ดีที่สุด ซึ่งจะส่งไปให้ผู้ซื้อ บริการเสนอราคา
4. บริการเสนอราคาของผู้ซื้อจะเรียกใช้ UDF ของ generateBid() ซึ่งจะเลือก ที่ดีที่สุด คำนวณราคาเสนอ แล้วส่งกลับไปยัง BuyerFrontEnd service.
5. บริการ BuyerFrontEnd จะส่งกลับโฆษณาและราคาเสนอไปยังผู้ขาย

มีรายละเอียดที่สำคัญหลายอย่างเกี่ยวกับขั้นตอนนี้ โดยเฉพาะเกี่ยวกับ วิธีที่ส่วนต่างๆ เชื่อมต่อกัน และวิธีที่แพลตฟอร์มมอบฟีเจอร์ต่างๆ เช่น ความสามารถในการคาดการณ์แมชชีนเลิร์นนิงสำหรับการเรียกโฆษณาอันดับสูงสุด k และคำนวณราคาเสนอ

ก่อนที่เราจะพูดถึงเรื่องนี้อย่างละเอียด มีบางส่วนที่สำคัญ หมายเหตุทางสถาปัตยกรรมเกี่ยวกับ TEE ในแผนภาพด้านบน

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

บริการดึงโฆษณามีบริการคีย์-ค่าเป็นการภายใน เทคโนโลยีโฆษณา แสดงคู่คีย์-ค่าลงในบริการนี้จากเซิร์ฟเวอร์ของตัวเองภายนอก พรมแดนความเป็นส่วนตัว เราจะมี JavaScript API สำหรับเทคโนโลยีโฆษณาให้อ่าน บริการคีย์-ค่านี้จากภายใน UDF ที่ทำงานในบริการดึงข้อมูลโฆษณา บริการดึงข้อมูลโฆษณาไม่มี บริการอนุมาน

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

การแยกตัวประกอบโมเดล

การแยกตัวประกอบโมเดลคือเทคนิคที่ทําให้สามารถแยกพารามิเตอร์ จำลองเป็นชิ้นส่วนต่างๆ แล้วนำมารวมกันเป็นการคาดการณ์ ใน กรณีการใช้งานการติดตั้งแอป โมเดลมักจะใช้ข้อมูล 3 ประเภท ได้แก่ ผู้ใช้ ข้อมูลบริบท และข้อมูลโฆษณา

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

ทำให้การออกแบบต่อไปนี้เป็นไปได้

1. แบ่งโมเดลออกเป็นส่วนส่วนตัว (ข้อมูลผู้ใช้) และอีกอย่างน้อย 1 รายการ โฆษณาแบบไม่เป็นส่วนตัว (ข้อมูลบริบทและข้อมูลโฆษณา)
2. (ไม่บังคับ) ส่งส่วนที่ไม่เป็นส่วนตัวบางส่วนหรือทั้งหมดเป็นอาร์กิวเมนต์ไปยัง UDF ที่ต้องคาดการณ์ ตัวอย่างเช่น การฝังตามบริบท ซึ่งผ่านไปยัง UDF ในper_buyer_signals
3. เทคโนโลยีโฆษณาสามารถสร้างโมเดลสำหรับชิ้นงานที่ไม่เป็นส่วนตัวได้ แสดงการฝังจากโมเดลเหล่านั้นลงในบริการดึงข้อมูลโฆษณา ที่จัดเก็บคีย์-ค่า UDF ในบริการดึงข้อมูลโฆษณาสามารถดึงข้อมูลการฝังเหล่านี้ได้ ขณะรันไทม์
4. เพื่อทำการคาดการณ์ในระหว่าง UDF ให้รวมการฝังส่วนตัวจาก บริการอนุมานที่มีการฝังแบบไม่เป็นส่วนตัวจากอาร์กิวเมนต์ฟังก์ชัน UDF หรือ ที่จัดเก็บคีย์-ค่าที่มีการดำเนินการเหมือนผลิตภัณฑ์จุด ขั้นสุดท้าย การคาดคะเน

เราจะอธิบาย UDF แต่ละรายการอย่างละเอียดมากขึ้น เราจะอธิบาย พวกเขาทำอย่างไร ผสานรวมอย่างไร และจะทำการคาดการณ์ที่จำเป็นสำหรับ เลือกโฆษณา k อันดับสูงสุดและคำนวณราคาเสนอ

UDF ของ prepareDataForAdRetrieval()

prepareDataForAdRetrieval() ที่ทำงานในบริการการเสนอราคาของผู้ซื้อคือ มีหน้าที่สร้างเพย์โหลดคำขอที่จะส่งไปยังโฆษณา บริการดึงข้อมูลเพื่อดึงโฆษณาที่มีผู้สมัครรับเลือกตั้ง K สูงสุด

prepareDataForAdRetrieval() จะใช้ข้อมูลต่อไปนี้

• เพย์โหลดต่อผู้ซื้อที่ได้รับจาก getAdSelectionData เพย์โหลดนี้ มีสัญญาณแอปที่มีการป้องกัน
• สัญญาณบริบท auction_signals (สำหรับข้อมูลเกี่ยวกับการประมูล) และ buyer_signals (สำหรับ ผู้ซื้อ สัญญาณ)

prepareDataForAdRetrieval() ทำ 2 สิ่งต่อไปนี้

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

prepareDataForAdRetrieval() ส่งคืน:

• สัญญาณแอปที่มีการปกป้อง: เพย์โหลดสัญญาณที่ดูแลจัดการโดยเทคโนโลยีโฆษณา
• สัญญาณเฉพาะการประมูล: สัญญาณฝั่งขายเฉพาะแพลตฟอร์ม และ ข้อมูลบริบท เช่น auction_signals และ per_buyer_signals (รวมถึงการฝังตามบริบท) จาก SelectAdRequest ซึ่งคล้ายกับ กลุ่มเป้าหมายที่มีการป้องกัน
• สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติม เช่น การฝังส่วนตัวที่ดึงมา จากบริการอนุมาน

คำขอนี้ถูกส่งไปยังบริการเรียกดูโฆษณาซึ่งจับคู่ตัวเลือก จากนั้นจึงเรียกใช้ UDF ของ getCandidateAds()

UDF ของ getCandidateAds()

getCandidateAds() ทำงานในบริการดึงข้อมูลโฆษณา ได้รับคำขอ สร้างโดย prepareDataForAdRetrieval() ในบริการการเสนอราคาของผู้ซื้อ บริการเรียกใช้ getCandidateAds() ซึ่งจะดึงตัวเลือกอันดับสูงสุดสำหรับ โดยการแปลงคำขอเป็นชุดของคำค้นหา การดึงข้อมูล และเรียกใช้ตรรกะทางธุรกิจที่กำหนดเองและตรรกะการดึงข้อมูลที่กำหนดเองอื่นๆ

getCandidateAds() จะใช้ข้อมูลต่อไปนี้

• สัญญาณแอปที่มีการปกป้อง: เพย์โหลดสัญญาณที่ดูแลจัดการโดยเทคโนโลยีโฆษณา
• สัญญาณเฉพาะการประมูล: สัญญาณฝั่งขายเฉพาะแพลตฟอร์ม และ ข้อมูลบริบท เช่น auction_signals และ per_buyer_signals (รวมถึงการฝังตามบริบท) จาก SelectAdRequest ซึ่งคล้ายกับ กลุ่มเป้าหมายที่มีการป้องกัน
• สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติม เช่น การฝังส่วนตัวที่ดึงมา จากบริการอนุมาน

getCandidateAds() ทำสิ่งต่อไปนี้

1. ดึงข้อมูลตัวเลือกโฆษณาชุดแรก: ดึงข้อมูลโดยใช้เกณฑ์การกำหนดเป้าหมาย เช่น ภาษา ภูมิศาสตร์ ประเภทโฆษณา ขนาดโฆษณา หรืองบประมาณ เพื่อกรองตัวเลือกโฆษณา
2. การดึงข้อมูลที่ฝังในการดึงข้อมูล: ในกรณีที่การฝังจากบริการคีย์-ค่ามีลักษณะดังนี้ ที่จำเป็นในการคาดคะเนเวลาดึงข้อมูลสำหรับการเลือก k สูงสุด ที่ดึงมาจากบริการคีย์-ค่า
3. การเลือกผู้สมัคร k อันดับสูงสุด: คำนวณคะแนนคร่าวๆ สำหรับ ชุดของตัวเลือกโฆษณาตามข้อมูลเมตาของโฆษณาที่ดึงมาจากแหล่งเก็บคีย์-ค่า และข้อมูลที่ส่งจากบริการเสนอราคาของผู้ซื้อ และเพื่อเลือก โดยพิจารณาจากคะแนนดังกล่าว ตัวอย่างเช่น คะแนนอาจเป็นโอกาส ติดตั้งแอปที่กำหนดจากโฆษณา
4. การดึงข้อมูลการฝังการเสนอราคา: หากมีการฝังจากบริการคีย์-ค่า ที่จำเป็นสำหรับการพยากรณ์เวลาในการเสนอราคา อาจเป็นได้ว่า ที่ดึงมาจากบริการคีย์-ค่า

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

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

โปรดทราบว่า UDF ของ generateBid() ที่ทำงานในบริการการเสนอราคาของผู้ซื้ออาจ นอกจากนี้ยังใช้ตัวประกอบรูปแบบของตัวเองในการเสนอราคา การคาดการณ์ หากบริการคีย์-ค่าต้องมีการฝังเพื่อดำเนินการดังกล่าว จะต้องดึงข้อมูลตอนนี้

getCandidateAds() ส่งคืน:

• โฆษณาที่เป็นตัวเลือก: โฆษณา k อันดับแรกที่จะส่งไปยัง generateBid() โฆษณาแต่ละรายการ ประกอบด้วย
  • URL ในการแสดงผล: ปลายทางสําหรับการแสดงผลครีเอทีฟโฆษณา
  • ข้อมูลเมตา: ข้อมูลเมตาของโฆษณาเกี่ยวกับเทคโนโลยีโฆษณาเฉพาะฝั่งซื้อ ตัวอย่างเช่น รายการนี้ อาจมีข้อมูลเกี่ยวกับแคมเปญโฆษณาและเกณฑ์การกำหนดเป้าหมาย เช่น สถานที่และภาษา ข้อมูลเมตาอาจมีหรือไม่มีก็ได้ การฝังที่ใช้เมื่อต้องเรียกใช้การแยกตัวประกอบโมเดล ในระหว่างการเสนอราคา
• สัญญาณเพิ่มเติม: บริการดึงข้อมูลโฆษณา (ไม่บังคับ) อาจมี ข้อมูลเพิ่มเติม เช่น การฝังเพิ่มเติม หรือสัญญาณสแปมที่จะใช้ ใน generateBid()

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

UDF ของ generateBid()

เมื่อคุณได้ดึงชุดโฆษณาของผู้สมัครและการฝังระหว่าง คุณก็พร้อมที่จะดำเนินการเสนอราคาแล้ว ซึ่งจะทำงานในการเสนอราคาของผู้ซื้อ service. บริการนี้เรียกใช้ generateBid() ที่ผู้ซื้อระบุ UDF เพื่อเลือกโฆษณาที่จะเสนอราคาจาก k ด้านบน แล้วแสดงโฆษณาพร้อมกับราคาเสนอ

generateBid() จะใช้ข้อมูลต่อไปนี้

• โฆษณาที่ต้องการ: โฆษณา k รายการแรกที่แสดงโดยการดึงข้อมูลโฆษณา service.
• สัญญาณเฉพาะการประมูล: สัญญาณฝั่งขายเฉพาะแพลตฟอร์ม และ ข้อมูลบริบท เช่น auction_signals และ per_buyer_signals (รวมถึงการฝังตามบริบท) จาก SelectAdRequest
• สัญญาณเพิ่มเติม: ข้อมูลเพิ่มเติมที่จะใช้ขณะเสนอราคา

การใช้งาน generateBid() ของผู้ซื้อจะทำ 3 สิ่งต่อไปนี้

• Feturization: เปลี่ยนสัญญาณเป็นฟีเจอร์สำหรับใช้ระหว่าง การอนุมาน
• การอนุมาน: สร้างการคาดการณ์โดยใช้โมเดลแมชชีนเลิร์นนิงเพื่อ คำนวณมูลค่าต่างๆ เช่น อัตราการคลิกผ่านที่คาดการณ์ และอัตรา Conversion
• การเสนอราคา: การรวมค่าอนุมานเข้ากับข้อมูลอื่นๆ เพื่อคำนวณ เสนอราคาสำหรับโฆษณาผู้สมัคร

generateBid() ส่งคืน:

• โฆษณาที่เป็นตัวเลือก
• ราคาเสนอที่คำนวณได้

โปรดทราบว่า generateBid() จะใช้สำหรับโฆษณาเพื่อการติดตั้งแอป และโฆษณาที่ใช้สำหรับ โฆษณารีมาร์เก็ตติ้งนั้นแตกต่างออกไป

ส่วนต่อไปนี้จะอธิบายคุณสมบัติ การอนุมาน และการเสนอราคาใน รายละเอียด

การปรับคุณสมบัติ

generateBid() สามารถเตรียมสัญญาณการประมูลในฟีเจอร์ต่างๆ ได้ ฟีเจอร์เหล่านี้ ใช้ในระหว่างการอนุมานเพื่อคาดการณ์สิ่งต่างๆ เช่น การคลิกผ่าน อัตรา Conversion นอกจากนี้ เรายังกำลังสำรวจกลไกการรักษาความเป็นส่วนตัวเพื่อ ส่งบางรายการในรายงานการชนะ เพื่อใช้ในการฝึกโมเดล

การอนุมาน

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

ลูกค้าสามารถจัดหาโมเดลแมชชีนเลิร์นนิงจำนวนมาก การใช้งาน generateBid() นอกจากนี้เรายังจะจัดเตรียม JavaScript API ภายใน generateBid() เพื่อให้ลูกค้าทำการอนุมานขณะรันไทม์ได้

การอนุมานทํางานในบริการการเสนอราคาของผู้ซื้อ การดำเนินการนี้อาจส่งผลต่อการอนุมาน เวลาในการตอบสนองและค่าใช้จ่าย โดยเฉพาะอย่างยิ่งเนื่องจาก Accelerator ยังไม่มีให้บริการใน TEE ลูกค้าบางรายจะพบความต้องการของตนเองผ่านโมเดลแต่ละแบบที่ทำงานใน บริการเสนอราคาของผู้ซื้อ ลูกค้าบางราย ตัวอย่างเช่น ลูกค้าที่มีขนาดใหญ่มาก โมเดล – อาจลองพิจารณาตัวเลือกต่างๆ เช่น การแยกตัวประกอบโมเดลเพื่อลด ค่าใช้จ่ายการอนุมานและเวลาในการตอบสนอง ณ เวลาที่เสนอราคา

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

ใช้การแยกตัวประกอบโมเดล

ก่อนหน้านี้ เราได้อธิบายเรื่องการแยกตัวประกอบโมเดล ณ เวลาเสนอราคา ฟิลด์ วิธีการคือ

1. แบ่งรูปแบบหนึ่งๆ ออกเป็นส่วนส่วนตัว (ข้อมูลผู้ใช้) และอีกรายการหนึ่งหรือ เนื้อหาที่ไม่เป็นส่วนตัวเพิ่มเติม (ข้อมูลตามบริบทและข้อมูลโฆษณา)
2. ส่งเนื้อหาที่ไม่เป็นส่วนตัวไปยัง generateBid() ซึ่งอาจมาจาก per_buyer_signals หรือจากการฝังที่เทคโนโลยีโฆษณาคำนวณภายนอก ปรากฏในที่เก็บคีย์-ค่าของบริการดึงข้อมูล ดึงข้อมูลเมื่อดึงข้อมูล เวลา และส่งคืนเป็นส่วนหนึ่งของสัญญาณเพิ่มเติม ลักษณะที่ไม่เข้าข่าย การฝังส่วนตัว เนื่องจากข้อมูลดังกล่าวไม่สามารถดึงมาจากภายนอกความเป็นส่วนตัวได้ ขอบเขต
3. ใน generateBid():
   1. ดำเนินการอนุมานกับโมเดลเพื่อรับการฝังส่วนตัวของผู้ใช้
   2. รวมการฝังส่วนตัวของผู้ใช้กับการฝังตามบริบทจาก per_buyer_signals หรือโฆษณาที่ไม่ใช่แบบส่วนตัวและการฝังบริบทจาก บริการดึงข้อมูลโดยใช้การดำเนินการอย่างเช่น ผลคูณ นี่คือ การคาดการณ์สุดท้ายที่ใช้คำนวณราคาเสนอ

เมื่อใช้วิธีการนี้ คุณจะทำการอนุมานได้ในขณะเสนอราคา โมเดลที่มีขนาดใหญ่หรือช้าเกินกว่าที่จะดำเนินการกับผู้ซื้อ บริการเสนอราคา

ตรรกะการให้คะแนนฝั่งขาย

ในขั้นตอนนี้ โฆษณาที่มีราคาเสนอที่ได้รับจากผู้ซื้อที่เข้าร่วมทั้งหมด ได้คะแนน เอาต์พุตของ generateBid() จะส่งไปยังบริการประมูลของผู้ขาย เรียกใช้ scoreAd() และ scoreAd() จะพิจารณาโฆษณาเพียงครั้งละ 1 รายการ สถานที่ตั้ง ในการให้คะแนน ผู้ขายจะเลือกโฆษณาที่ชนะเพื่อกลับไปยังอุปกรณ์สำหรับ ในการแสดงภาพ

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

รันไทม์ของโค้ดการเลือกโฆษณา

ในข้อเสนอได้ระบุรหัสการเลือกโฆษณาสำหรับการติดตั้งแอปไว้ใน เช่นเดียวกับขั้นตอนรีมาร์เก็ตติ้งของ Protected Audience โปรดดูรายละเอียดที่ การเสนอราคาและการกำหนดค่าการประมูล โค้ดการเสนอราคาจะ ได้ในตำแหน่งพื้นที่เก็บข้อมูลระบบคลาวด์เดียวกันกับรายการที่ใช้อยู่ สำหรับรีมาร์เก็ตติ้ง

การรายงาน

ข้อเสนอนี้ใช้ API การรายงานเดียวกันกับการรายงานกลุ่มเป้าหมายที่มีการป้องกัน ข้อเสนอ (เช่น reportImpression() ซึ่งเรียกให้แพลตฟอร์มแสดง ส่งรายงานของผู้ขายและผู้ซื้อ)

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

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

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

โดยทางเทคนิค วิธีการทำงานมีดังนี้

1. เทคโนโลยีโฆษณาจะกำหนดสคีมาของข้อมูลที่ต้องการส่ง
2. ใน generateBid() นักเรียนจะสร้างเพย์โหลดข้อมูลขาออกตามที่ต้องการ
3. แพลตฟอร์มจะตรวจสอบเพย์โหลดขาออกกับสคีมาและบังคับใช้ ขีดจำกัดขนาด
4. แพลตฟอร์มจะเพิ่มสัญญาณรบกวนในเพย์โหลดขาออก
5. เพย์โหลดขาออกรวมอยู่ในรายงานผู้ชนะในรูปแบบสายไฟ ได้รับเมื่อ เซิร์ฟเวอร์เทคโนโลยีโฆษณา ถอดรหัส และใช้สำหรับการฝึกโมเดล

การกำหนดสคีมาของเพย์โหลดข้อมูลขาออก

เพื่อให้แพลตฟอร์มบังคับใช้ข้อกำหนดด้านความเป็นส่วนตัวที่เปลี่ยนแปลงไป เพย์โหลดขาออกต้อง ในแบบที่แพลตฟอร์มเข้าใจได้ เทคโนโลยีโฆษณาจะกำหนด ของเพย์โหลดขาออกด้วยการระบุไฟล์ 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 นี้มีไว้สำหรับผู้โทรเพื่อระบุว่าเพย์โหลดหนึ่งๆ หรือไม่ จะผ่านการตรวจสอบแพลตฟอร์ม คุณต้องทำการตรวจสอบจริงในแพลตฟอร์มเพื่อ ป้องกัน UDF ที่เป็นอันตราย generateBid()

ทำให้เพย์โหลดขาออกส่งเสียง

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

วิธีการเพิ่มเสียงมีดังนี้

1. แพลตฟอร์มจะโหลดการกำหนดสคีมาสำหรับเพย์โหลดขาออก
2. ระบบจะเลือกเพย์โหลดขาออก 1% เพื่อทำเสียงรบกวน
3. หากไม่ได้เลือกเพย์โหลดขาออก ระบบจะเก็บรักษาค่าเดิมทั้งหมดไว้
4. หากเลือกเพย์โหลดขาออก ระบบจะแทนที่ค่าของแต่ละฟีเจอร์ด้วย ค่าที่ใช้ได้แบบสุ่มสำหรับประเภทฟีเจอร์นั้นๆ (เช่น 0 หรือ 1 สำหรับ ฟีเจอร์บูลีน)

การส่ง การรับ และการถอดรหัสเพย์โหลดขาออกสำหรับการฝึกโมเดล

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

รายละเอียดเกี่ยวกับรูปแบบสายไฟสำหรับองค์ประกอบทุกประเภทและเพย์โหลดขาออก มีให้ใช้งานใน GitHub

กำหนดขนาดเพย์โหลดข้อมูลขาออก

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

วิธีการระบุขนาดมีดังนี้

1. ในขั้นต้น เราจะรองรับเพย์โหลดขาออก 2 รายการใน generateBid() ดังนี้
   1. egressPayload: เพย์โหลดขาออกที่จำกัดขนาดที่เราได้อธิบายไว้จนถึงขณะนี้ ในเอกสารนี้ ในขั้นต้น ขนาดของเพย์โหลดขาออกนี้จะเป็น 0 บิต (หมายความว่าจะถูกนำออกเสมอระหว่างการตรวจสอบความถูกต้อง)
   2. temporaryUnlimitedEgressPayload: ข้อมูลขาออกชั่วคราวที่ไม่จำกัดขนาด เพย์โหลดสำหรับการทดสอบขนาด การจัดรูปแบบ การสร้าง และการประมวลผล ของเพย์โหลดขาออกนี้จะใช้กลไกเดียวกับ egressPayload
2. เพย์โหลดขาออกแต่ละรายการเหล่านี้จะมีไฟล์ JSON ของสคีมาของตัวเอง egress_payload_schema.json และ temporary_egress_payload_schema.json
3. เรามีโปรโตคอลการทดสอบและชุดเมตริกสำหรับกำหนดโมเดล ยูทิลิตีที่ขนาดเพย์โหลดขาออกขนาดต่างๆ (เช่น 5, 10, ... บิต)
4. จากผลการทดสอบ เรากำหนดขนาดเพย์โหลดขาออกด้วยพารามิเตอร์ ประโยชน์หรือความเป็นส่วนตัว
5. เราตั้งค่าขนาดของ egressPayload จาก 0 บิตเป็นขนาดใหม่
6. หลังจากระยะเวลาการย้ายข้อมูลที่กำหนดไว้ เราจะนำ temporaryUnlimitedEgressPayload ออก เหลือเพียง egressPayload ด้วยขนาดใหม่

เรากำลังตรวจสอบข้อกำหนดทางเทคนิคเพิ่มเติมสำหรับจัดการการเปลี่ยนแปลงนี้ (เช่น การเข้ารหัส egressPayload เมื่อเราเพิ่มขนาดจาก 0 บิต) รายละเอียดเหล่านั้น -- พร้อมด้วยช่วงเวลาสำหรับการทดสอบ และการนำ temporaryUnlimitedEgressPayload -- จะรวมอยู่ในการอัปเดตในภายหลัง

ต่อไป เราจะอธิบายโปรโตคอลการทดสอบที่เป็นไปได้สำหรับการกำหนดขนาดของ egressPayload เป้าหมายของเราคือการทำงานร่วมกับอุตสาหกรรมต่างๆ เพื่อหาขนาดที่เหมาะสม ยูทิลิตีและขอบเขตการใช้ข้อมูล สิ่งประดิษฐ์ที่การทดลองเหล่านี้จะสร้างขึ้นคือ โดยแกน x คือขนาดของเพย์โหลดการฝึกในหน่วยบิต และ แกน y คือเปอร์เซ็นต์ของรายได้ที่เกิดจากโมเดลในขนาดดังกล่าวเมื่อเปรียบเทียบ ให้เป็นเกณฑ์พื้นฐานที่ไม่จำกัดขนาด

เราจะสมมติว่าเรากำลังฝึกโมเดล pInstall และแหล่งที่มาของข้อมูลการฝึก คือบันทึกและเนื้อหาของtemporaryUnlimitedegressPayloadที่เรา ที่จะได้รับเมื่อเราชนะการประมูล โปรโตคอลสำหรับเทคโนโลยีโฆษณาเกี่ยวข้องกับการทำงานแบบออฟไลน์ก่อน การทดสอบ:

1. กำหนดสถาปัตยกรรมของโมเดลที่จะใช้กับแอปที่มีการป้องกัน สัญญาณ ตัวอย่างเช่น พวกเขาจะต้องพิจารณาว่าจะ ใช้การแยกตัวประกอบโมเดล
2. กำหนดเมตริกสำหรับการวัดคุณภาพของโมเดล เมตริกที่แนะนำคือการสูญเสียจาก AUC และไฟล์บันทึก
3. กำหนดชุดฟีเจอร์ที่จะใช้ระหว่างการฝึกโมเดล
4. การใช้สถาปัตยกรรมโมเดล เมตริกคุณภาพ และชุดฟีเจอร์การฝึกดังกล่าว ดำเนินการศึกษาการชำระบัญชีเพื่อพิจารณาค่าสาธารณูปโภคที่เพิ่มขึ้นสำหรับแต่ละบิต รูปแบบที่ต้องการใช้ใน PAS ระเบียบการที่แนะนำสำหรับการศึกษาเรื่องการจลาจล คือ
   1. ฝึกโมเดลด้วยฟีเจอร์ทั้งหมดและวัดผลยูทิลิตี นี่คือ เกณฑ์พื้นฐานเพื่อเปรียบเทียบ
   2. สำหรับแต่ละฟีเจอร์ที่ใช้สร้างเกณฑ์พื้นฐาน ให้ฝึกโมเดลด้วย ยกเว้นฟีเจอร์ดังกล่าว
   3. วัดยูทิลิตีที่ได้ หารเดลต้าด้วยขนาดขององค์ประกอบ เป็นบิต นี่คือประโยชน์ที่ระบบคาดหวังว่าจะได้รับต่อผู้ใช้สำหรับฟีเจอร์นั้น
5. กำหนดขนาดเพย์โหลดการฝึกที่สนใจเพื่อการทดสอบ พ แนะนำ [5, 10, 15, ..., size_of_all_training_features_for_baseline] บิต แต่ละขนาดแสดงขนาดที่เป็นไปได้สำหรับ egressPayload ที่ จะประเมิน
6. สำหรับแต่ละขนาดที่เป็นไปได้ ให้เลือกชุดฟีเจอร์ที่น้อยกว่าหรือเท่ากับ ขนาดที่ใช้ประโยชน์ได้สูงสุดต่อบิตโดยใช้ผลการศึกษาการจลาจล
7. ฝึกโมเดลสำหรับแต่ละขนาดที่เป็นไปได้และประเมินยูทิลิตีของโมเดลเป็น เปอร์เซ็นต์ของประโยชน์จากโมเดลพื้นฐานที่ฝึกกับฟีเจอร์ทั้งหมด
8. พล็อตผลลัพธ์บนกราฟโดยแกน x เป็นขนาดของการฝึก เพย์โหลดเป็นบิต และแกน y คือเปอร์เซ็นต์ของรายได้ที่เกิดจาก รูปแบบนั้นเทียบกับเกณฑ์พื้นฐาน

ถัดไป เทคโนโลยีโฆษณาสามารถทำซ้ำขั้นตอนที่ 5-8 ในการทดสอบการเข้าชมแบบสด โดยใช้ฟีเจอร์ ข้อมูลที่ส่งผ่าน temporaryUnlimitedEgressPayload เทคโนโลยีโฆษณาเลือกแชร์ได้ ผลการทดสอบการเข้าชมแบบออฟไลน์และแบบเรียลไทม์ด้วย Privacy Sandbox เพื่อแจ้งการตัดสินใจเกี่ยวกับขนาดของ egressPayload

ลำดับเวลาสำหรับการทดสอบเหล่านี้ รวมถึงลำดับเวลาในการกำหนดขนาด ของ egressPayload ให้กับค่าผลลัพธ์ อยู่นอกเหนือขอบเขตของเอกสารนี้ และจะมีการอัปเดตในภายหลัง

มาตรการการคุ้มครองข้อมูล

เราจะใช้การป้องกันหลายอย่างกับข้อมูลขาออก ซึ่งได้แก่

1. ระบบจะส่งเสียงเตือนทั้ง egressPayload และ temporaryUnlimitedEgressPayload
2. สำหรับขอบเขตและการปกป้องข้อมูล temporaryUnlimitedEgressPayload จะ ใช้ได้กับช่วงการทดสอบขนาดเท่านั้น โดยเราจะ กำหนดขนาดที่ถูกต้องสำหรับ egressPayload

สิทธิ์

การควบคุมของผู้ใช้

• ข้อเสนอนี้มีจุดประสงค์เพื่อให้ผู้ใช้ได้เห็นรายชื่อแอปที่ติดตั้ง ที่เก็บสัญญาณแอปที่มีการป้องกันหรือกลุ่มเป้าหมายที่กำหนดเองอย่างน้อย 1 รายการ
• ผู้ใช้จะบล็อกและนำแอปออกจากรายการนี้ได้ การบล็อกและการนำออกจะ ดังต่อไปนี้:
  • ล้างสัญญาณของแอปที่มีการป้องกันและกลุ่มเป้าหมายที่กำหนดเองทั้งหมดที่เชื่อมโยงกับแอป แอปนั้น
  • ป้องกันไม่ให้แอปจัดเก็บสัญญาณแอปที่มีการป้องกันและสัญญาณที่กำหนดเองใหม่ กลุ่มเป้าหมาย
• ผู้ใช้สามารถรีเซ็ตสัญญาณของแอป Protected และ Protected ได้ Audience API อย่างสมบูรณ์ ในกรณีนี้ แอปที่มีการป้องกันที่มีอยู่ ระบบจะล้างสัญญาณและกลุ่มเป้าหมายที่กำหนดเองในอุปกรณ์
• ผู้ใช้สามารถเลือกไม่ใช้ Privacy Sandbox ได้อย่างสมบูรณ์ Android ซึ่งมี Protected App Signals API และ Protected Audience API ในกรณีดังกล่าว กลุ่มเป้าหมายที่มีการป้องกันและสัญญาณของแอปที่มีการป้องกัน API แสดงข้อความข้อยกเว้นมาตรฐาน: SECURITY_EXCEPTION

สิทธิ์และการควบคุมแอป

ข้อเสนอนี้มีจุดประสงค์เพื่อให้แอปควบคุมสัญญาณของแอปที่มีการป้องกัน

• แอปสามารถจัดการการเชื่อมโยงด้วยสัญญาณแอปที่มีการป้องกัน
• แอปให้สิทธิ์แพลตฟอร์มเทคโนโลยีโฆษณาบุคคลที่สามในการจัดการได้ สัญญาณของแอปที่มีการป้องกันในนามของแอป

การควบคุมแพลตฟอร์มเทคโนโลยีโฆษณา

ข้อเสนอนี้ระบุวิธีที่เทคโนโลยีโฆษณาจะควบคุมสัญญาณแอปที่มีการป้องกัน

• เทคโนโลยีโฆษณาทั้งหมดต้องลงทะเบียนกับ Privacy Sandbox และระบุ "เว็บไซต์" หรือ "ต้นทาง" โดเมนที่ตรงกับ URL ทั้งหมดสำหรับสัญญาณของแอปที่มีการป้องกัน
• เทคโนโลยีโฆษณาสามารถเป็นพาร์ทเนอร์กับแอปหรือ SDK เพื่อมอบโทเค็นการยืนยันที่ ใช้เพื่อยืนยันการสร้างสัญญาณของแอปที่มีการป้องกัน เมื่อกระบวนการนี้ มอบสิทธิ์ให้กับพาร์ทเนอร์แล้ว สามารถกำหนดค่าการสร้างสัญญาณแอปที่มีการป้องกันเป็น ต้องรับทราบจากเทคโนโลยีโฆษณา