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

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

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

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

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

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

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

เมื่อใช้ B&A ข้อมูลกลุ่มเป้าหมายที่มีการป้องกัน เช่น กลุ่มเป้าหมายที่กำหนดเองและจำนวนเงินเสนอจะไหลจากอุปกรณ์ผ่านเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ขายไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ซื้อ และกลับไปที่อุปกรณ์ ด้วยเหตุนี้ แพลตฟอร์มจึงเข้ารหัสข้อมูลที่ส่งไปยังบริการ 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 จะอ่านจาก Key/Value service และประเมินโฆษณาที่เลือก ระบบจะเข้ารหัสผลลัพธ์และส่งกลับไปยังบริการโฆษณาของผู้ขาย
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 ที่สร้างขึ้นในระหว่างขั้นตอนการทดสอบและรับรอง บีคอนที่สร้างขึ้นสำหรับการรายงานการโต้ตอบและ URL ที่เกี่ยวข้องจะอยู่ในคําตอบที่เข้ารหัส ดังนั้นในระหว่างการถอดรหัสคําตอบ ระบบจะจัดเก็บการแมปเหตุการณ์และ URL ไว้ในอุปกรณ์

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

ข้อเสนอ Browser Bidding & Auction API ใน GitHub อธิบายถึงการพิจารณาด้านความเป็นส่วนตัว ข้อเสนอนี้ใช้การเรียกชื่อของ Chrome แต่หลักการเดียวกันนี้ใช้กับ Android ได้

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

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