การเสนอราคาและบริการประมูล

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

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

Google จะจัดหาองค์ประกอบของ B&A และเปิดให้ใช้งานในรูปแบบโอเพนซอร์ส เทคโนโลยีโฆษณาที่สนใจจะโฮสต์อินสแตนซ์ของตนกับผู้ให้บริการระบบคลาวด์สาธารณะที่รองรับได้ อ่านข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอ B&A ได้ใน GitHub โปรดทราบว่าวันที่ที่แสดงในเอกสารดังกล่าวแสดงถึงการใช้งาน Chrome และเราจะเผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวมกับ Android ในอนาคต เอกสารนี้ทำหน้าที่เป็นข้อมูลเบื้องต้น เกี่ยวกับ B&A และ API ใหม่ที่ Android จะมีให้เพื่อโต้ตอบกับ B&A เราจะโพสต์ข้อมูลทางเทคนิคเพิ่มเติมเกี่ยวกับวิธีใช้ API ใหม่เหล่านี้ในการอัปเดตในอนาคต

สถานที่ให้บริการที่พัก

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

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

ความแตกต่างที่สำคัญขึ้นอยู่กับตำแหน่งที่ใช้ตรรกะการสร้าง URL สำหรับการเสนอราคา การให้คะแนน และการรายงาน แทนที่จะเรียกใช้ตรรกะในการเสนอราคา การประมูล และการรายงานในอุปกรณ์ ระบบจะเรียกใช้ตรรกะ generateBid(), scoreAd(), reportResult() และ reportWin() ใน TEE ตรรกะการเสนอราคาของผู้ซื้อและตรรกะการให้คะแนนผู้ขายจะดำเนินการภายในสภาพแวดล้อม B&A ของตนเองในระหว่างขั้นตอนการประมูลของ Protected Audience ดังนี้

ขั้นตอนการประมูล Protected Audience

การเข้ารหัสข้อมูล

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

สถาปัตยกรรมและขั้นตอนการประมูล

ข้อเสนอนี้รวมถึงความต้องการคอมโพเนนต์ใหม่ๆ จำนวนมากตามรายละเอียดใน GitHub รวมถึงการรับส่งข้อมูลจากอุปกรณ์ไปยัง B&A

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

ในระดับสูง โฟลว์ของข้อมูลมีคำอธิบายดังนี้

1. ผู้ขายจะรวบรวมข้อมูลจาก Protected Audience โดยใช้ getAdSelectionData API ในอุปกรณ์
2. SDK ในอุปกรณ์จะส่งคำขอไปยังบริการโฆษณาของผู้ขาย คำขอนี้มีเพย์โหลดตามบริบทและ ProtectedAudienceInput ที่เข้ารหัส
3. บริการโฆษณาของผู้ขายจะส่งคำขอไปยังบริการการเสนอราคาแบบเรียลไทม์ (RTB) ของผู้ซื้อที่ทำงานนอก TEE เพื่อรับโฆษณาตามบริบทของผู้สมัคร จากนั้นจึงให้คะแนนและเลือกโฆษณาตามบริบทที่ชนะ
4. บริการโฆษณาของผู้ขายส่งคำขอไปยังบริการ SellerFrontEnd ที่ทำงานใน TEE
5. บริการ SellerFrontEnd ส่งคำขอที่มีข้อมูลเฉพาะของผู้ซื้อไปยังบริการ BuyerFrontEnd
6. ผู้ซื้อใช้บริการจัดการคีย์/มูลค่าและบริการการเสนอราคาของตนเอง ซึ่งจะสร้างราคาเสนอสําหรับตัวเลือกโฆษณาที่มาจากอุปกรณ์สําหรับกลุ่มเป้าหมายที่กําหนดเองทั้งหมดที่พิจารณาสําหรับรีมาร์เก็ตติ้ง
7. บริการ SellerFrontEnd จะอ่านจากบริการจัดการคีย์/ค่าของตนและให้คะแนนโฆษณาที่ผู้สมัคร ผลลัพธ์จะถูกเข้ารหัส และส่งไปยังบริการโฆษณาของผู้ขาย
8. บริการโฆษณาของผู้ขายจะแสดงผลการชนะที่เข้ารหัส รวมถึงผลลัพธ์ตามบริบท (ไม่บังคับ) ไปยัง SDK ในอุปกรณ์
9. ในอุปกรณ์ ผู้ขายจะดึงโฆษณาที่ชนะโดยใช้ processAdSelectionResult API ซึ่งถอดรหัสการตอบกลับจากบริการโฆษณาของผู้ขาย

คำอธิบายโดยละเอียดของแต่ละขั้นตอนและวิธีการเข้ารหัสข้อมูลที่พบได้ใน GitHub โค้ดสำหรับคอมโพเนนต์เหล่านี้ จะพร้อมใช้งานผ่านโอเพนซอร์ส โค้ดที่ให้ไว้จะจัดการการรวมศูนย์คำขอจากบริการ SellerFrontEnd ไปยังบริการ BuyerFrontEnd

การทำให้ระบบคลาวด์ใช้งานได้

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

เรียกใช้การประมูล

ขั้นตอนแรกของการประมูล B&A คือการรวบรวมข้อมูลจากกลุ่มเป้าหมายที่กำหนดเองในอุปกรณ์ และเข้ารหัสเพื่อส่งไปยังการประมูลฝั่งเซิร์ฟเวอร์ หากต้องการดำเนินการ ให้ใช้ getAdSelectionData API:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

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

API นี้แสดงผลออบเจ็กต์ AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

เมื่อใช้ AdSelectionData นี้ SDK ในอุปกรณ์จะสามารถส่งคำขอไปยังบริการโฆษณาผู้ขายโดยรวมข้อมูลไว้ในคำขอ POST หรือ PUT

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

SDK ในอุปกรณ์มีหน้าที่ในการเข้ารหัสข้อมูลนี้ ขอแนะนำให้ใช้โซลูชันที่ประหยัดพื้นที่ได้ เช่น การส่งคำขอไปยังบริการโฆษณาของผู้ขายเป็น multipart/form-data

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

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

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

การรายงาน

ระบบจะสร้าง URL การรายงานในบริการ B&A การใช้คำสั่ง ping ไปยัง URL เหล่านั้นเพื่อรายงานการแสดงผลและการโต้ตอบสำหรับการประมูลจะยังคงต้องถูกเรียกใช้ในอุปกรณ์ SDK ในอุปกรณ์จะยังคงต้องเรียกใช้ API ของ reportImpression() และ reportInteraction() โดยใช้ AdSelectionId ที่สร้างขึ้นระหว่างขั้นตอน B&A บีคอนที่สร้างขึ้นเพื่อการรายงานการโต้ตอบและ URL ที่เกี่ยวข้องจะอยู่ในการตอบกลับที่เข้ารหัส ดังนั้นระหว่างการถอดรหัสของการตอบสนองนั้นจะจัดเก็บเหตุการณ์และการแมป URL ไว้ในอุปกรณ์

ข้อพิจารณาเกี่ยวกับความเป็นส่วนตัว

ข้อเสนอ API การเสนอราคาและการประมูลเบราว์เซอร์ใน GitHub อธิบายวิธีพิจารณาข้อควรพิจารณาเกี่ยวกับความเป็นส่วนตัว ข้อเสนอนี้ใช้คำนามของ Chrome แต่ก็ใช้หลักการเดียวกันกับ Android

ระบบจะเข้ารหัส adSelectionData เพื่อให้แน่ใจว่ามีเพียง PPAPI และเซิร์ฟเวอร์ที่เชื่อถือได้เท่านั้นที่จะเข้าถึงข้อมูลระหว่างการส่งได้ เราวางแผนที่จะสร้าง adSelectionData เดียวกันสำหรับการเรียก getAdSelectionData API ทั้งหมดเพื่อลดความเสี่ยงจากข้อมูลรั่วไหลเนื่องจากการเปลี่ยนแปลงขนาด adSelectionData ซึ่งหมายความว่า CustomAudience ทั้งหมดในอุปกรณ์ใช้เพื่อสร้าง adSelectionData นอกจากนี้ เรายังวางแผนที่จะจำกัดอิทธิพลของพารามิเตอร์อินพุต GetAdSelectionData ใน adSelectionData ที่สร้างขึ้น

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

ข้อควรพิจารณาเกี่ยวกับขนาด

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

1. การเพิ่ม ad_render_id ใน CustomAudience เพื่อให้ส่งโดยใช้ adSelectionData แทนการใช้ URI และข้อมูลเมตาในการแสดงโฆษณา เทคโนโลยีโฆษณาช่วยเพิ่มประสิทธิภาพให้กับสิ่งนี้ได้มากยิ่งขึ้นด้วยการไม่ส่งข้อมูลโฆษณาใน adSelectionData ระบบจะรองรับตัวเลือกนี้ใน CustomAudience API สำหรับรุ่นต่อๆ ไป
2. ตรวจสอบว่าไม่ได้ส่ง user_bidding_signals ใน adSelectionData แต่เทคโนโลยีโฆษณาจะดึงข้อมูล user_bidding_signals จากเซิร์ฟเวอร์คีย์/ค่าของตนแทนได้
3. อนุญาตให้ผู้ซื้อให้ความสำคัญกับ CustomAudience
4. อนุญาตให้ผู้ซื้อระบุลำดับความสำคัญของผู้ขาย
5. สร้าง adSelectionData ในที่เก็บข้อมูลแบบคงที่ 2-3 รายการเพื่อจำกัดการรั่วไหลของบิตพร้อมกับลดขนาดเพย์โหลด

การเพิ่มประสิทธิภาพขนาดจะดำเนินการโดยปฏิบัติตามข้อกังวลที่อยู่ในการพิจารณาด้านความเป็นส่วนตัว

ข้อควรพิจารณาในการต่อต้านการละเมิด

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

ซึ่งจะเป็นการเปิดระบบนิเวศให้กับเอนทิตีที่อาจเป็นอันตรายซึ่งอาจเพิ่มข้อมูลผู้ซื้อที่ฉ้อโกงเข้ามา อาจทำให้ประสิทธิภาพลดลง เพิ่มเพย์โหลดเพิ่มต้นทุน เป็นต้น

เพื่อต่อต้านการละเมิด adSelectionData เราขอแนะนำมาตรการต่อไปนี้

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

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

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