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

ในข้อเสนอ 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

วันที่

ในระดับสูง การถ่ายโอนข้อมูลจะอธิบายดังนี้

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

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 เพื่อกำหนดจำนวนผู้ซื้อสูงสุดต่อการโทร 1 ครั้ง หรือ ขนาดสูงสุดต่อผู้ซื้อ 1 ราย

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

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