ในข้อเสนอ Protected Audience เริ่มต้น การเสนอราคาและการประมูลสําหรับ ความต้องการโฆษณารีมาร์เก็ตติ้งจะดำเนินการภายในอุปกรณ์ ข้อกำหนดนี้สามารถเรียกได้ ในการประมวลผลที่อาจไม่ได้ผลจริงๆ ในการดำเนินการกับอุปกรณ์ กำลังจำกัดในการประมวลผล หรืออาจช้าเกินไปในการเลือกและแสดงโฆษณาเนื่องจาก เวลาในการตอบสนองของเครือข่าย
ข้อเสนอบริการเสนอราคาและประมูล (B&A) ระบุวิธีที่ช่วยให้ การประมวลผล 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 กลุ่มเป้าหมายที่กำหนดเอง (รวมถึงโฆษณาผู้สมัคร สำหรับแคมเปญรีมาร์เก็ตติ้ง) จะยังคงได้รับการจัดการในอุปกรณ์โดยใช้ API การจัดการกลุ่มเป้าหมายในลักษณะที่มีการดำเนินการประมูลในอุปกรณ์ จาก มุมมอง SSP, คำขอจะยังคงมีการทริกเกอร์ในอุปกรณ์ และเอกสารนี้ อธิบายถึง API ใหม่ที่จะนำมาใช้ สำหรับทุกฝ่าย การรายงาน ผลการประมูลยังคงเริ่มต้นจากอุปกรณ์หลังจากที่การเรียก B&A สิ้นสุดลง
ความแตกต่างสำคัญนั้นมาพร้อมกับ URL การเสนอราคา การให้คะแนน และการรายงาน
ดำเนินการตรรกะการสร้าง แทนที่จะเรียกใช้การเสนอราคา การประมูล และการรายงาน
ตรรกะบนอุปกรณ์, generateBid()
, scoreAd()
, reportResult()
และ
ดำเนินการตรรกะ reportWin()
ใน TEE ตรรกะการเสนอราคาของผู้ซื้อและของผู้ขาย
ตรรกะการให้คะแนนจะเกิดขึ้นในสภาพแวดล้อม B&A ของตนเอง โดยอยู่ตรงกลางของ
ขั้นตอนการประมูลที่ใช้ Protected Audience API
การเข้ารหัสข้อมูล
เมื่อใช้ B&A, ข้อมูล Protected Audience เช่น กลุ่มเป้าหมายที่กำหนดเองและราคาเสนอ จำนวนที่ไหลจากอุปกรณ์ ผ่านเซิร์ฟเวอร์เทคโนโลยีโฆษณาของผู้ขาย ให้แก่เทคโนโลยีโฆษณาของผู้ซื้อ และย้อนกลับไปยังอุปกรณ์ แพลตฟอร์มจึงเข้ารหัส ไปยังบริการ Protected Audience และสามารถถอดรหัสได้โดย บริการที่ผ่านการรับรองแล้ว อ่านเพิ่มเติมเกี่ยวกับกลยุทธ์การเข้ารหัสใน GitHub
สถาปัตยกรรมและขั้นตอนการประมูล
ข้อเสนอนี้รวมไปถึงความต้องการใช้องค์ประกอบใหม่หลายรายการ ตามรายละเอียดเกี่ยวกับ GitHub รวมถึงโฟลว์ข้อมูลจากอุปกรณ์ไปยัง B&A
ในระดับสูง การถ่ายโอนข้อมูลจะอธิบายดังนี้
- ในอุปกรณ์ ผู้ขายจะรวบรวมข้อมูลจาก Protected Audience โดยใช้
getAdSelectionData
API - SDK ในอุปกรณ์จะส่งคำขอไปยังโฆษณาของผู้ขาย
service [บริการ] คำขอนี้รวมถึงเพย์โหลดตามบริบทและ
ProtectedAudienceInput
ที่เข้ารหัส - บริการโฆษณาของผู้ขายจะส่งคำขอไปยังผู้ซื้อ การเสนอราคาแบบเรียลไทม์ (RTB) ที่ทำงานนอก TEE เพื่อรับโฆษณาตามบริบทของผู้สมัคร จากนั้น แล้วเลือกโฆษณาตามบริบท ที่มีประสิทธิภาพสูงสุด
- บริการโฆษณาของผู้ขายส่งคำขอไปยัง SellerFrontEnd บริการที่ทำงานใน TEE
- บริการ SellerFrontEnd จะส่งคำขอพร้อมข้อมูลเฉพาะผู้ซื้อไปยัง บริการ BuyerFrontEnd
- ผู้ซื้อใช้บริการคีย์/ค่าและการเสนอราคาของตนเอง บริการ ซึ่งจะสร้างราคาเสนอสำหรับตัวเลือกโฆษณาที่มาจาก อุปกรณ์สำหรับกลุ่มเป้าหมายที่กำหนดเองทั้งหมดที่พิจารณาสำหรับรีมาร์เก็ตติ้ง
- บริการ SellerFrontEnd อ่านจากคีย์/ค่า บริการ และให้คะแนนโฆษณาที่เป็นตัวเลือก ผลลัพธ์ได้รับการเข้ารหัส และส่งคืนไปยังบริการโฆษณาของผู้ขาย
- บริการโฆษณาของผู้ขายจะส่งคืนผลลัพธ์ที่ชนะที่เข้ารหัส และสามารถเลือก ผลลัพธ์ตามบริบท ไปยัง SDK ในอุปกรณ์
- บนอุปกรณ์ ผู้ขายจะดึงโฆษณาที่ชนะด้วยการใช้
processAdSelectionResult
API ซึ่งถอดรหัสการตอบกลับจากโฆษณาของผู้ขาย service.
คำอธิบายโดยละเอียดของแต่ละขั้นตอนและวิธีเข้ารหัสข้อมูล GitHub โค้ดสำหรับคอมโพเนนต์เหล่านี้จะพร้อมใช้ ผ่านโอเพนซอร์ส โค้ดที่ระบุจะจัดการการรวมคำขอจาก บริการ SellerFrontEnd ไปยังบริการ BuyerFrontEnd
การทำให้ระบบคลาวด์ใช้งานได้
เทคโนโลยีโฆษณาจะทำให้บริการ B&A ใช้งานได้บนระบบคลาวด์สาธารณะที่รองรับ ของ Google การติดตั้งใช้งานเหล่านี้จะได้รับการจัดการโดยเทคโนโลยีโฆษณาที่ มีหน้าที่กำหนดวัตถุประสงค์ระดับการให้บริการ
เรียกใช้การประมูล
ขั้นตอนแรกของการประมูล 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 ในอุปกรณ์ยังคงต้องเรียกใช้
reportImpression()
และ reportInteraction()
API กำลังใช้
สร้าง AdSelectionId
ระหว่างขั้นตอน B&A แล้ว บีคอนที่สร้างขึ้นสำหรับ
การรายงานการโต้ตอบและ URL ที่เกี่ยวข้องจะรวมอยู่ใน
การตอบกลับที่เข้ารหัส ดังนั้นระหว่างการถอดรหัสการตอบกลับที่กิจกรรมและ URL
จะจัดเก็บไว้ในอุปกรณ์
ข้อพิจารณาเกี่ยวกับข้อมูลส่วนบุคคล
การเสนอราคาสำหรับเบราว์เซอร์และ ข้อเสนอ API การประมูลใน GitHub อธิบายถึง มีการพิจารณาเรื่องความเป็นส่วนตัวอย่างไร ข้อเสนอนี้ใช้แท็กของ Chrome ชื่อที่ใช้ แต่ Android ก็ใช้หลักการเดียวกัน
ระบบจะเข้ารหัส adSelectionData
เพื่อให้มั่นใจว่าข้อมูลที่อยู่ระหว่างการส่งสามารถเข้าถึงได้เท่านั้น
ไปยัง PPAPI และเซิร์ฟเวอร์ที่เชื่อถือได้ เพื่อลดความเสี่ยงในการรั่วไหลของข้อมูลเนื่องจาก
มีการเปลี่ยนแปลงขนาด adSelectionData
รายการ เราวางแผนที่จะสร้าง adSelectionData
เดียวกัน
สำหรับการเรียกไปยัง getAdSelectionData
API ทั้งหมด ซึ่งหมายความว่า
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 เพื่อกำหนดจำนวนผู้ซื้อสูงสุดต่อการโทร 1 ครั้ง หรือ ขนาดสูงสุดต่อผู้ซื้อ 1 ราย
มาตรการเหล่านี้ออกแบบมาเพื่อให้เทคโนโลยีโฆษณาระบุว่าเทคโนโลยีโฆษณาใด
ทำงานร่วมกัน และเพื่อกำหนดขีดจำกัดที่ยอมรับได้ในadSelectionData
เพย์โหลดที่
จะต้องประมวลผล เราจะเสนอให้ผู้ขายสามารถระบุ
รายการผู้ซื้อนี้และลำดับความสำคัญในการโทรแยกต่างหาก ข้อกำหนดนี้จะเป็น
คงที่ตลอดช่วงเวลาบางช่วงเพื่อหลีกเลี่ยงการเปิดเผยข้อมูลเพิ่มเติม
เกี่ยวกับผู้ใช้ผ่านการโทรซ้ำๆ
การผ่อนปรนชั่วคราวที่กล่าวถึงข้างต้นนี้อยู่ระหว่างการหารือและอาจมีการเปลี่ยนแปลงอย่างต่อเนื่อง ดังที่กล่าวไว้ก่อนหน้านี้ การลดความเสี่ยงทั้งหมดเพื่อป้องกันการละเมิดและขนาด ต้องเป็นไปตามข้อพิจารณาเกี่ยวกับข้อมูลส่วนบุคคล