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

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

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

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

บริการ B&A มีส่วนเกี่ยวข้องอย่างไร

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

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

ความแตกต่างที่สำคัญคือตําแหน่งที่เรียกใช้ตรรกะการเสนอราคา การให้คะแนน และการสร้าง URL การรายงาน แทนที่จะเรียกใช้ตรรกะการเสนอราคา การประมูล และการรายงาน ในอุปกรณ์ ระบบจะเรียกใช้ตรรกะของ generateBid(), scoreAd(), reportResult() และ reportWin() ใน TEE ระบบจะเรียกใช้ตรรกะการเสนอราคาของผู้ซื้อและตรรกะการให้คะแนนของผู้ขายภายในสภาพแวดล้อม B&A ของตนเอง ซึ่งอยู่ตรงกลางโฟลว์การประมูล 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 service ที่ทำงานใน 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 ที่สร้างขึ้นในระหว่างขั้นตอนการยินยอมและให้สิทธิ์ Beacon ที่สร้างขึ้นสำหรับ การรายงานการโต้ตอบและ URL ที่เกี่ยวข้องจะอยู่ใน การตอบกลับที่เข้ารหัส ดังนั้นในระหว่างการถอดรหัสการตอบกลับ ระบบจะจัดเก็บเหตุการณ์และการแมป URL ไว้ในอุปกรณ์

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

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

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

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