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

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

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

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

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

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

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

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

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

ไทม์ไลน์

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

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

Protected App Signals API

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

ตัวอย่างนี้แสดงสัญญาณสเกลาร์และสัญญาณอนุกรมเวลาที่เชื่อมโยง กับ adtech1.com

• สัญญาณสเกลาร์ที่มีคีย์ค่า base64 เป็น "A1c" และค่าเป็น "c12Z" ทริกเกอร์ที่เก็บสัญญาณ โดย com.google.android.game_app เมื่อวันที่ 1 มิถุนายน 2023
• รายการสัญญาณที่มีคีย์ "dDE" ซึ่งสร้างขึ้นโดยแอปพลิเคชัน 2 รายการที่แตกต่างกัน

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

ระบบจะนำสัญญาณแอปที่ได้รับการปกป้องออกจากที่เก็บข้อมูลหากมีการถอนการติดตั้งแอปพลิเคชันที่สร้างสัญญาณ ถูกบล็อกไม่ให้ใช้ Protected App Signals API หรือหากผู้ใช้ล้างข้อมูลแอป

Protected App Signals API ประกอบด้วยส่วนต่างๆ ดังนี้

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

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

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

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

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

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

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

คีย์และค่าทั้งหมดจะแสดงใน Base64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

prepareDataForAdRetrieval() UDF

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

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

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

prepareDataForAdRetrieval() ทำ 2 อย่างต่อไปนี้

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

prepareDataForAdRetrieval() การคืนสินค้า

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

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

getCandidateAds() UDF

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

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

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

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

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

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

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

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

getCandidateAds() การคืนสินค้า

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

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

generateBid() UDF

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

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

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

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

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

generateBid() การคืนสินค้า

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

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

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

การสร้างฟีเจอร์

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

การอนุมาน

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

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

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

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

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

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

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

การรายงาน

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

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

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

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

ในทางเทคนิคแล้ว วิธีการทำงานมีดังนี้

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

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

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

เราจะจัดหาไฟล์ CDDL ที่กำหนดโครงสร้างของ JSON นั้น ไฟล์ CDDL จะมีชุดประเภทฟีเจอร์ที่รองรับ (เช่น ฟีเจอร์ที่เป็นบูลีน จำนวนเต็ม บัคเก็ต และอื่นๆ) ทั้งไฟล์ CDDL และสคีมาที่ระบุจะมีการควบคุมเวอร์ชัน

ตัวอย่างเช่น เพย์โหลดขาออกที่ประกอบด้วยฟีเจอร์บูลีนเดียว ตามด้วยฟีเจอร์กลุ่มที่มีขนาด 2 จะมีลักษณะดังนี้

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

ดูรายละเอียดเกี่ยวกับชุดประเภทฟีเจอร์ที่รองรับได้ที่ GitHub

สร้างเพย์โหลดขาออกใน generateBid()

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

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

ตรวจสอบความถูกต้องของเพย์โหลดขาออก

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

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

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

validate(payload, schema)

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

เพิ่มสัญญาณรบกวนให้กับเพย์โหลดขาออก

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

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

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

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

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

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

เราจะใช้การป้องกันหลายอย่างกับข้อมูลที่ส่งออก ซึ่งรวมถึง

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

สิทธิ์

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

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

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

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

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

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

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

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