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

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

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

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

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

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

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

โฟลว์ชาร์ตที่แสดงสัญญาณ Protected App Signals และเวิร์กโฟลว์การเลือกโฆษณาใน 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 รองรับการผลิต UDF ระดับ K สูงสุด	พร้อมใช้งานใน AWS การแก้ไขข้อบกพร่อง เมตริก และการตรวจสอบที่ได้รับความยินยอม
บริการการอนุมานใน TEE การรองรับการเรียกใช้โมเดล ML และการนำไปใช้สำหรับการเสนอราคาใน TEE	อยู่ระหว่างการพัฒนา	พร้อมใช้งานใน GCP ความสามารถในการทำให้ใช้งานได้และสร้างต้นแบบโมเดล ML แบบคงที่โดยใช้ Tensorflow และ PyTorch	พร้อมใช้งานบน AWS การติดตั้งใช้งานโมเดลเวอร์ชันที่ใช้งานจริงสำหรับโมเดล Tensorflow และ PyTorch การตรวจวัดระยะไกล การแก้ไขข้อบกพร่องที่ได้รับความยินยอม และการตรวจสอบ
การสนับสนุนการเสนอราคาและการประมูล ใน TEE	พร้อมใช้งานใน GCP	PAS-B&A และ TEE Ad Retrieval Integration (ที่มี 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 ของสัญญาณ Store ข้อมูลเพิ่มเติมนี้มีอยู่ใน 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) Protected App Signals API มีจุดมุ่งหมายเพื่อสนับสนุนเทคโนโลยีโฆษณาเหล่านี้ด้วยการนำเสนอโซลูชันที่ยืดหยุ่นสำหรับการจัดการสัญญาณของแอปที่มีการป้องกันโดยให้ผู้โทรของอุปกรณ์สามารถเรียกใช้ การสร้างสัญญาณแอปที่มีการป้องกันในนามของผู้ซื้อ กระบวนการนี้เรียกว่าการมอบสิทธิ์และใช้ประโยชน์จาก fetchSignalUpdates() API fetchSignalUpdates() จะใช้ URI และเรียกข้อมูลรายการอัปเดตสัญญาณ เพื่อเป็นตัวอย่างภาพ fetchSignalUpdates() ออกคำขอ GET ไปยัง URI ที่ระบุเพื่อดึงรายการการอัปเดตเพื่อใช้กับพื้นที่เก็บข้อมูลสัญญาณในเครื่อง ปลายทาง URL ที่ผู้ซื้อเป็นเจ้าของจะตอบกลับด้วยรายการคำสั่ง JSON

คำสั่ง JSON ที่รองรับมีดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UDF ของ prepareDataForAdRetrieval()

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

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

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

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

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

prepareDataForAdRetrieval() ส่งคืน:

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

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

UDF ของ getCandidateAds()

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

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

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

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

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

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

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

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

getCandidateAds() ส่งคืน:

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

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

UDF ของ generateBid()

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

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

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

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

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

generateBid() ส่งคืน:

• โฆษณาที่เป็นผู้สมัคร
• ราคาเสนอที่คำนวณได้

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

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

การเจริญเติบโต

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

การอนุมาน

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

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

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

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

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

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

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

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

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

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

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

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

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

การรายงาน

ข้อเสนอนี้ใช้ API การรายงานเดียวกันกับข้อเสนอการรายงานของ Protected Audience (เช่น 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()

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

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

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

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

สิทธิ์

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

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

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

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

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

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

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

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