ในข้อเสนอ 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 ดังนี้
การเข้ารหัสข้อมูล
เมื่อใช้ B&A ข้อมูลของ Protected Audience เช่น กลุ่มเป้าหมายที่กำหนดเองและจำนวนราคาเสนอจะไหลจากอุปกรณ์ ผ่านเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ขาย ไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ซื้อ และย้อนกลับไปยังอุปกรณ์ ด้วยเหตุนี้ แพลตฟอร์มจะเข้ารหัสข้อมูลไปยังบริการของ Protected Audience และจะถอดรหัสได้โดยบริการที่ได้รับการยืนยันแล้วเท่านั้น อ่านข้อมูลเพิ่มเติมเกี่ยวกับกลยุทธ์การเข้ารหัสได้ที่ GitHub
สถาปัตยกรรมและขั้นตอนการประมูล
ข้อเสนอนี้รวมถึงความต้องการคอมโพเนนต์ใหม่ๆ จำนวนมากตามรายละเอียดใน GitHub รวมถึงการรับส่งข้อมูลจากอุปกรณ์ไปยัง B&A
ในระดับสูง โฟลว์ของข้อมูลมีคำอธิบายดังนี้
- ผู้ขายจะรวบรวมข้อมูลจาก Protected Audience โดยใช้
getAdSelectionData
API ในอุปกรณ์ - SDK ในอุปกรณ์จะส่งคำขอไปยังบริการโฆษณาของผู้ขาย คำขอนี้มีเพย์โหลดตามบริบทและ
ProtectedAudienceInput
ที่เข้ารหัส - บริการโฆษณาของผู้ขายจะส่งคำขอไปยังบริการการเสนอราคาแบบเรียลไทม์ (RTB) ของผู้ซื้อที่ทำงานนอก TEE เพื่อรับโฆษณาตามบริบทของผู้สมัคร จากนั้นจึงให้คะแนนและเลือกโฆษณาตามบริบทที่ชนะ
- บริการโฆษณาของผู้ขายส่งคำขอไปยังบริการ SellerFrontEnd ที่ทำงานใน TEE
- บริการ SellerFrontEnd ส่งคำขอที่มีข้อมูลเฉพาะของผู้ซื้อไปยังบริการ BuyerFrontEnd
- ผู้ซื้อใช้บริการจัดการคีย์/มูลค่าและบริการการเสนอราคาของตนเอง ซึ่งจะสร้างราคาเสนอสําหรับตัวเลือกโฆษณาที่มาจากอุปกรณ์สําหรับกลุ่มเป้าหมายที่กําหนดเองทั้งหมดที่พิจารณาสําหรับรีมาร์เก็ตติ้ง
- บริการ SellerFrontEnd จะอ่านจากบริการจัดการคีย์/ค่าของตนและให้คะแนนโฆษณาที่ผู้สมัคร ผลลัพธ์จะถูกเข้ารหัส และส่งไปยังบริการโฆษณาของผู้ขาย
- บริการโฆษณาของผู้ขายจะแสดงผลการชนะที่เข้ารหัส รวมถึงผลลัพธ์ตามบริบท (ไม่บังคับ) ไปยัง SDK ในอุปกรณ์
- ในอุปกรณ์ ผู้ขายจะดึงโฆษณาที่ชนะโดยใช้
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
การเพิ่มประสิทธิภาพเหล่านี้
รวมถึง
- การเพิ่ม
ad_render_id
ในCustomAudience
เพื่อให้ส่งโดยใช้adSelectionData
แทนการใช้ URI และข้อมูลเมตาในการแสดงโฆษณา เทคโนโลยีโฆษณาช่วยเพิ่มประสิทธิภาพให้กับสิ่งนี้ได้มากยิ่งขึ้นด้วยการไม่ส่งข้อมูลโฆษณาในadSelectionData
ระบบจะรองรับตัวเลือกนี้ในCustomAudience API
สำหรับรุ่นต่อๆ ไป - ตรวจสอบว่าไม่ได้ส่ง
user_bidding_signals
ในadSelectionData
แต่เทคโนโลยีโฆษณาจะดึงข้อมูลuser_bidding_signals
จากเซิร์ฟเวอร์คีย์/ค่าของตนแทนได้ - อนุญาตให้ผู้ซื้อให้ความสำคัญกับ
CustomAudience
- อนุญาตให้ผู้ซื้อระบุลำดับความสำคัญของผู้ขาย
- สร้าง
adSelectionData
ในที่เก็บข้อมูลแบบคงที่ 2-3 รายการเพื่อจำกัดการรั่วไหลของบิตพร้อมกับลดขนาดเพย์โหลด
การเพิ่มประสิทธิภาพขนาดจะดำเนินการโดยปฏิบัติตามข้อกังวลที่อยู่ในการพิจารณาด้านความเป็นส่วนตัว
ข้อควรพิจารณาในการต่อต้านการละเมิด
ดังที่กล่าวไว้ในข้อพิจารณาด้านความเป็นส่วนตัว adSelectionData
สร้างขึ้นโดยใช้ข้อมูลของผู้ซื้อทั้งหมดในอุปกรณ์
ซึ่งจะเป็นการเปิดระบบนิเวศให้กับเอนทิตีที่อาจเป็นอันตรายซึ่งอาจเพิ่มข้อมูลผู้ซื้อที่ฉ้อโกงเข้ามา อาจทำให้ประสิทธิภาพลดลง เพิ่มเพย์โหลดเพิ่มต้นทุน เป็นต้น
เพื่อต่อต้านการละเมิด adSelectionData
เราขอแนะนำมาตรการต่อไปนี้
- อนุญาตให้
CustomAudience
ระบุผู้ขายที่ได้รับอนุมัติและลำดับความสำคัญของผู้ขายได้อย่างชัดเจน - อนุญาตให้ SSP ระบุโควต้าผู้ซื้อ ลำดับความสำคัญของผู้ซื้อ และโควต้าต่อผู้ซื้ออย่างชัดแจ้งในเพย์โหลดที่สร้างขึ้น
- มีกลไกให้ SSP กำหนดจำนวนผู้ซื้อสูงสุดต่อการโทรหรือขนาดสูงสุดต่อผู้ซื้อ
มาตรการเหล่านี้ออกแบบมาเพื่อช่วยให้เทคโนโลยีโฆษณากำหนดเทคโนโลยีโฆษณาอื่นๆ ที่ทำงานร่วมกันด้วย และเพื่อกำหนดขีดจำกัดที่ยอมรับได้สำหรับเพย์โหลด adSelectionData
ที่จำเป็นต้องใช้ในการประมวลผล เราขอเสนอให้ผู้ขายสามารถระบุรายชื่อ
ผู้ซื้อนี้และลำดับความสำคัญในการเรียกแยกต่างหาก ข้อกำหนดนี้จะมีค่าคงที่ตลอดช่วงเวลาเพื่อหลีกเลี่ยงการแสดงข้อมูลเพิ่มเติมเกี่ยวกับผู้ใช้ผ่านการเรียกซ้ำๆ
การบรรเทาปัญหาที่กล่าวถึงข้างต้นอยู่ระหว่างการหารือและอาจมีการเปลี่ยนแปลงเมื่อเวลาผ่านไป ตามที่กล่าวไว้ก่อนหน้านี้ การบรรเทาปัญหาทั้งหมดที่เกี่ยวข้องกับการป้องกันการละเมิดและข้อจำกัดด้านขนาดต้องเป็นไปตามข้อควรพิจารณาเกี่ยวกับความเป็นส่วนตัว