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

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

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

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

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

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

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

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

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

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

ไทม์ไลน์

ดูแลจัดการสัญญาณแอปที่ได้รับการคุ้มครอง

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

คําสั่งที่ระบุไว้ข้างต้นมีไว้เพื่อระบุความหมายของ "แทรก" "เขียนทับ" และ "ลบ" สําหรับสัญญาณเชิง scalar และ "แทรก" "ต่อท้าย" และ "เขียนทับทั้งชุด" สําหรับสัญญาณอนุกรมเวลา การจัดการความหมายของการลบและเขียนทับในองค์ประกอบที่เฉพาะเจาะจงของสัญญาณอนุกรมเวลาต้องดำเนินการในระหว่างกระบวนการเข้ารหัสและการบีบอัด เช่น ในระหว่างการเข้ารหัส จะต้องไม่สนใจค่าในอนุกรมเวลาที่มีค่าที่ใหม่กว่าเข้ามาแทนที่หรือแก้ไขแล้ว และลบค่าเหล่านั้นออกในระหว่างกระบวนการบีบอัด

ระบบจะเชื่อมโยงสัญญาณที่เก็บไว้กับแอปพลิเคชันที่ดึงข้อมูลคําขอโดยอัตโนมัติ รวมถึงผู้ตอบคําขอ ("เว็บไซต์" หรือ "ต้นทาง" ของเทคโนโลยีโฆษณาที่ลงทะเบียน) และเวลาสร้างคําขอ สัญญาณทั้งหมดต้องได้รับการจัดเก็บในนามของเทคโนโลยีโฆษณาที่ลงทะเบียนใน Privacy Sandbox โดย URI "site"/"origin" ต้องตรงกับข้อมูลของเทคโนโลยีโฆษณาที่ลงทะเบียน หากเทคโนโลยีโฆษณาที่ขอไม่ได้ลงทะเบียนไว้ ระบบจะปฏิเสธคําขอ

โควต้าพื้นที่เก็บข้อมูลและการลบออก

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

การเข้ารหัสในอุปกรณ์สำหรับการส่งข้อมูล

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UDF prepareDataForAdRetrieval()

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

prepareDataForAdRetrieval() จะรับข้อมูลต่อไปนี้

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

prepareDataForAdRetrieval() ทำงาน 2 อย่างดังนี้

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

prepareDataForAdRetrieval() ส่งคืนสินค้าโดยมีค่าธรรมเนียม

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

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

UDF getCandidateAds()

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

getCandidateAds() จะรับข้อมูลต่อไปนี้

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

getCandidateAds() ดำเนินการต่อไปนี้

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

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

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

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

getCandidateAds() แสดงผลดังนี้

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

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

UDF generateBid()

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

generateBid() จะรับข้อมูลต่อไปนี้

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

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

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

generateBid() ส่งคืนสินค้าโดยมีค่าธรรมเนียม

• โฆษณาของผู้สมัคร
• จํานวนราคาเสนอที่คำนวณแล้ว

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

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

การแสดงผล

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

การอนุมาน

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

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

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

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

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

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

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

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

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

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

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

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

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

การรายงาน

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

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

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

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

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

1. เทคโนโลยีโฆษณาจะกําหนดสคีมาสําหรับข้อมูลที่ต้องการให้ส่ง
2. ใน generateBid() ลูกค้าจะสร้างเพย์โหลดขาออกที่ต้องการ
3. แพลตฟอร์มจะตรวจสอบเพย์โหลดขาออกกับสคีมาและบังคับใช้ขีดจำกัดขนาด
4. แพลตฟอร์มจะเพิ่มสัญญาณรบกวนลงในเพย์โหลดขาออก
5. เพย์โหลดขาออกจะรวมอยู่ในรายงาน Conversion ในรูปแบบ 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() แต่ละแนวทางมีข้อดีข้อเสียต่างกันไป และเราจะตัดสินใจขั้นสุดท้ายโดยคำนึงถึงความคิดเห็นจากอุตสาหกรรม

ตรวจสอบเพย์โหลดขาออก

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

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

เราจะจัดเตรียม JavaScript API สําหรับเทคโนโลยีโฆษณาเพื่อให้แน่ใจว่าเพย์โหลดขาออกที่สร้างขึ้นใน generateBid() จะผ่านการตรวจสอบแพลตฟอร์ม

validate(payload, schema)

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

สร้างความสับสนให้กับเพย์โหลดขาออก

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

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

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

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

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

รายละเอียดเกี่ยวกับรูปแบบการเดินสายสำหรับฟีเจอร์ทุกประเภทและสำหรับเพย์โหลดขาออกมีอยู่ใน 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. กำหนดสถาปัตยกรรมของโมเดลที่จะใช้กับ Protected App Signals เช่น จะต้องพิจารณาว่าจะใช้การแยกโมเดลหรือไม่
2. กําหนดเมตริกสําหรับวัดคุณภาพโมเดล เมตริกที่แนะนําคือ AUC Loss และ Log Loss
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 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 เพื่อมอบโทเค็นการยืนยันที่จะใช้ในการยืนยันการสร้างสัญญาณแอปที่ได้รับการคุ้มครอง เมื่อมอบหมายกระบวนการนี้ให้พาร์ทเนอร์ คุณจะกำหนดค่าการสร้างสัญญาณแอปที่ได้รับการปกป้องให้กำหนดให้เทคโนโลยีโฆษณาต้องรับทราบได้