รายละเอียดการออกแบบบริการเสนอราคาและบริการประมูลสําหรับ Android จะอธิบายการดําเนินการและขั้นตอนการส่งข้อมูลของการประมูลใน Android โดยใช้เซิร์ฟเวอร์การเสนอราคาและประมูลที่เชื่อถือได้ ระบบจะเข้ารหัสข้อมูลระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์โดยใช้การเข้ารหัสคีย์สาธารณะแบบไฮบริดแบบ 2 ทิศทางเพื่อให้มั่นใจว่าข้อมูลระหว่างการรับส่งจะได้รับการจัดการโดย API ที่รักษาความเป็นส่วนตัวและเซิร์ฟเวอร์ที่เชื่อถือได้เท่านั้น
หากต้องการเรียกใช้การประมูลตามที่อธิบายไว้ก่อนหน้านี้ เทคโนโลยีโฆษณาของผู้ขายในอุปกรณ์ต้องทําตามขั้นตอนต่อไปนี้
- รวบรวมและเข้ารหัสข้อมูลสำหรับการประมูลเซิร์ฟเวอร์
- ส่งคำขอไปยังบริการผู้ขายที่ไม่น่าเชื่อถือ
- ได้รับการตอบกลับจากบริการผู้ขายที่ไม่น่าเชื่อถือ
- ถอดรหัสคำตอบการประมูลที่ใช้ Protected Audience และดูผลการประมูล
Protected Audience จะเปิดตัว 2 API ใหม่เพื่อรองรับการประมูลบนเซิร์ฟเวอร์ ดังนี้
getAdSelectionData
API จะรวบรวมข้อมูลสำหรับการประมูลของเซิร์ฟเวอร์และสร้างเพย์โหลดที่เข้ารหัสซึ่งมีข้อมูลการประมูล เซิร์ฟเวอร์การเสนอราคาและการประมูลใช้เพย์โหลดนี้เพื่อเรียกใช้การประมูล สร้างผลการประมูล และแสดงผลการประมูล- ไคลเอ็นต์เทคโนโลยีโฆษณาในอุปกรณ์สามารถเรียกใช้
persistAdSelectionResult
API เพื่อถอดรหัสผลลัพธ์ที่เกิดจากการประมูลของเซิร์ฟเวอร์และรับ URL การนําเสนอโฆษณาที่ชนะ
เทคโนโลยีโฆษณาของผู้ขายในอุปกรณ์ต้องผสานรวมและสร้างสิ่งต่อไปนี้เพื่อเรียกใช้การประมูล
- รวบรวมและเข้ารหัสข้อมูลสำหรับผู้ขายในการประมูลของเซิร์ฟเวอร์: เทคโนโลยีโฆษณาควรเรียกใช้
getAdSelectionData
API เพื่อรับเพย์โหลดที่เข้ารหัส - ส่งคำขอไปยังบริการผู้ขายที่ไม่น่าเชื่อถือ: คำขอ
HTTP POST
หรือPUT
ที่มีเพย์โหลดที่เข้ารหัสซึ่งgetAdSelectionData
API สร้างขึ้นไปยังบริการผู้ขายที่ไม่น่าเชื่อถือและข้อมูลที่จําเป็นสำหรับบริการผู้ขายที่ไม่น่าเชื่อถือในการสร้างผลการค้นหาตามบริบท - รับการตอบกลับจากบริการผู้ขายที่ไม่น่าเชื่อถือ: การตอบกลับจากบริการผู้ขายที่ไม่น่าเชื่อถือจะมีผลการประมูล Protected Audience ที่เข้ารหัสและผลการประมูลตามบริบท
- ถอดรหัสการตอบกลับการประมูลของกลุ่มเป้าหมายที่มีการป้องกันและรับผลการประมูล:
หากต้องการถอดรหัสผลการประมูลของกลุ่มเป้าหมายที่มีการป้องกัน เทคโนโลยีโฆษณาของผู้ขายควรเรียกใช้
persistAdSelectionResult
API ผลลัพธ์ที่persistAdSelectionResult
สร้างขึ้นจะช่วยให้เทคโนโลยีโฆษณาระบุได้ว่าโฆษณาตามบริบทหรือโฆษณากลุ่มเป้าหมายที่ได้รับการคุ้มครองชนะการประมูลหรือไม่ รวมถึง URI ของโฆษณากลุ่มเป้าหมายที่ได้รับการคุ้มครองที่ชนะ หากมี
ฟีเจอร์ที่รองรับการประมูลของเซิร์ฟเวอร์
เรามุ่งมั่นที่จะรองรับฟีเจอร์ทั้งหมดที่ใช้ได้กับการประมูลในอุปกรณ์ ไทม์ไลน์สำหรับการรองรับฟีเจอร์เหล่านี้ในการประมูลเซิร์ฟเวอร์มีดังนี้
การประมูลในอุปกรณ์ |
การประมูลของเซิร์ฟเวอร์ |
|||
ตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์ |
เบต้า |
ตัวอย่างสำหรับนักพัฒนาซอฟต์แวร์ |
เบต้า |
|
การรายงาน Conversion ที่ชนะระดับเหตุการณ์ |
ไตรมาส 1 ปี 2023 |
ไตรมาส 3 ปี 2023 |
ไม่มี |
ไตรมาส 4 ปี 2023 |
ไตรมาส 1 ปี 2023 |
ไตรมาส 4 ปี 2023 |
ไม่มี |
ไตรมาส 1 ปี 24 |
|
ไตรมาส 2 ปี 2023 |
ไตรมาส 3 ปี 2023 |
ไม่มี |
ไตรมาส 4 ปี 2023 |
|
ไตรมาส 2 ปี 2023 |
ไตรมาส 1 ปี 2024 |
ไม่มี |
ไม่มี |
|
ไตรมาส 2 ปี 2023 |
ไตรมาส 3 ปี 2023 |
ไม่มี |
ไตรมาส 4 ปี 2023 |
|
ไตรมาส 3 ปี 2023 |
ไตรมาส 4 ปี 2023 |
ไม่มี |
ไตรมาส 4 ปี 2023 |
|
การเรียกเก็บเงินที่ไม่ใช่ CPM |
ไตรมาส 3 ปี 2023 |
ไตรมาส 4 ปี 2023 |
||
การรายงาน |
ไตรมาส 3 ปี 2023 |
ไตรมาส 4 ปี 2023 |
ไตรมาส 3 ปี 2023 |
ไตรมาส 4 ปี 2023 |
การสื่อกลางในการเสนอราคาแบบเปิด |
ไม่มี |
ไม่มี |
ไม่มี |
ไตรมาส 1 ปี 2024 |
ไตรมาส 2 ปี 2023 |
ไตรมาส 1 ปี 2024 |
ไม่มี |
ไตรมาส 1 ปี 2024 |
|
การจัดการสกุลเงิน |
ไม่มี |
ไม่มี |
ไม่มี |
ไตรมาส 1 ปี 2024 |
การผสานรวม K-anon |
ไม่มี |
ไตรมาส 1 ปี 2024 |
ไม่มี |
ไตรมาส 1 ปี 2024 |
การผสานรวมการรวมข้อมูลส่วนตัว |
ไม่มี |
ไม่มี |
ไม่มี |
ไตรมาส 3 ปี 2024 |
เรียกใช้การประมูลของเซิร์ฟเวอร์โดยใช้ Protected Audience API
ในแทร็กเวอร์ชันตัวอย่างสําหรับนักพัฒนาซอฟต์แวร์ AdSelectionManager จะแสดง API ใหม่ 2 รายการ ได้แก่ getAdSelectionData
และ persistAdSelectionResult
API เหล่านี้ช่วยให้ SDK ของเทคโนโลยีโฆษณาผสานรวมกับเซิร์ฟเวอร์การเสนอราคาและการประมูลได้
รวบรวมและเข้ารหัสข้อมูลสำหรับการประมูลเซิร์ฟเวอร์
getAdSelectionData
API จะสร้างอินพุตที่จําเป็นสําหรับคอมโพเนนต์การเสนอราคาและการประมูล เช่น BuyerInput
และ ProtectedAudienceInput
และเข้ารหัสข้อมูลก่อนที่จะแสดงผลลัพธ์ต่อผู้เรียกใช้ ข้อมูลนี้ประกอบด้วยข้อมูลจากผู้ซื้อทั้งหมดที่อยู่ในอุปกรณ์เพื่อป้องกันไม่ให้ข้อมูลรั่วไหลไปยังแอปต่างๆ อ่านข้อมูลเพิ่มเติมเกี่ยวกับการตัดสินใจนี้ในส่วนข้อควรพิจารณาด้านความเป็นส่วนตัว และกลยุทธ์ในการเพิ่มประสิทธิภาพในส่วนข้อควรพิจารณาเกี่ยวกับขนาด
หากต้องการเข้าถึง API คุณต้องเปิดใช้การเข้าถึง Protected Audience API และต้องกำหนดสิทธิ์ ACCESS_ADSERVICES_CUSTOM_AUDIENCE
ในไฟล์ Manifest ของผู้เรียกใช้
public class AdSelectionManager {
public void getAdSelectionData(
GetAdSelectionDataRequest getAdSelectionDataRequest,
Executor executor,
OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}
GetAdSelectionDataRequest
- ผู้เรียกต้องตั้งค่าช่อง
seller
ในคำขอ เนื่องจากระบบจะใช้ช่องนี้เพื่อเรียกใช้การตรวจสอบการลงทะเบียนก่อนดำเนินการตามคำขอ - คุณจะป้อนหรือไม่ป้อนข้อมูลในช่อง
coordinatorOriginUri
ก็ได้- หากตั้งค่าไว้ ค่านี้ควรเท่ากับรูปแบบ ชื่อโฮสต์ และพอร์ตของ URL ของเครื่องมือประสานงานที่กําหนดค่าไว้ขณะติดตั้งใช้งานเซิร์ฟเวอร์ B&A ของผู้ขาย
- ผู้ประสานงานต้องอยู่ในรายชื่อผู้ประสานงานที่อนุมัติแล้ว
ผู้ให้บริการ URI ต้นทางของ URI ค่าเริ่มต้น Google Cloud https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.gcp.privacysandboxservices.com ใช่ Amazon Web Services https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com ไม่ - หากไม่ได้ระบุต้นทางของคอออรดിനเตอร์ ระบบจะใช้คอออรดിനเตอร์เริ่มต้น
- แม้ว่า URL ของ Coordinator จะไม่มีการเปลี่ยนแปลง แต่เราขอแนะนําอย่างยิ่งให้ใช้กลไกในการจัดการ URL นี้แบบไดนามิก วิธีนี้ช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลง URL ในอนาคตจะดำเนินการได้โดยไม่ต้องมีการเผยแพร่ SDK เวอร์ชันใหม่
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
หลังจากตรวจสอบคําขอแล้ว ระบบจะประกอบข้อมูลผู้ซื้อในอุปกรณ์เป็น BuyerInput
และ ProtectedAudienceInput
จากนั้นระบบจะเข้ารหัสออบเจ็กต์เพย์โหลดสุดท้ายโดยใช้การเข้ารหัสคีย์สาธารณะแบบไฮบริดแบบ 2 ทิศทาง
GetAdSelectionDataOutcome
GetAdSelectionDataOutcome
สร้างขึ้นจากผลลัพธ์ของ getAdSelectionData
API ซึ่งประกอบด้วยข้อมูลต่อไปนี้
adSelectionId
: จำนวนเต็มแบบทึบเพื่อระบุการเรียกใช้getAdSelectionData
ครั้งนี้ ไคลเอ็นต์เทคโนโลยีโฆษณาควรเก็บค่าadSelectionId
นี้ไว้เนื่องจากค่าดังกล่าวทำหน้าที่เป็นพอยน์เตอร์ไปยังการเรียกใช้getAdSelectionData
persistAdSelectionResult
API ต้องใช้ตัวระบุนี้เพื่อถอดรหัสผลการประมูลจากเซิร์ฟเวอร์การเสนอราคาและเซิร์ฟเวอร์การประมูล และreportImpression
และreportEvent
API ต้องใช้ตัวระบุนี้ด้วยadSelectionData
: นี่คือข้อมูลการประมูลที่เข้ารหัส ซึ่งเซิร์ฟเวอร์การเสนอราคาและการประมูลต้องใช้เพื่อทำการประมูล โดยเมธอดนี้มีข้อมูลต่อไปนี้- ข้อมูลกลุ่มเป้าหมายที่กําหนดเองที่กรองตามการกําหนดความถี่สูงสุด ตัวกรองการติดตั้งแอป และข้อกําหนดการประมูลของเซิร์ฟเวอร์สําหรับกลุ่มเป้าหมายที่กําหนดเอง
- ในเวอร์ชันในอนาคต รายงานจะมีข้อมูลการติดตั้งแอป
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
ข้อผิดพลาด ข้อยกเว้น และการจัดการความล้มเหลว
หากการสร้างข้อมูลการเลือกโฆษณาไม่สําเร็จเนื่องจากเหตุผลต่างๆ เช่น อาร์กิวเมนต์ไม่ถูกต้อง การหมดเวลา หรือการใช้ทรัพยากรมากเกินไป การเรียกกลับ OutcomeReceiver.onError()
จะส่ง AdServicesException
ที่มีลักษณะการทํางานต่อไปนี้
- หาก
getAdSelectionData
เริ่มต้นด้วยอาร์กิวเมนต์ที่ไม่ถูกต้องAdServicesException
จะระบุสาเหตุเป็น IllegalArgumentException - ข้อผิดพลาดอื่นๆ ทั้งหมดจะได้รับ
AdServicesException
โดยมีสาเหตุเป็นIllegalStateException
ส่งคำขอไปยังบริการผู้ขายที่ไม่น่าเชื่อถือ
เมื่อใช้ AdSelectionData
SDK ในอุปกรณ์จะส่งคําขอไปยังบริการโฆษณาของผู้ขายได้โดยใส่ข้อมูลในคําขอ POST
หรือ PUT
ดังนี้
fetch('https://www.example-ssp.com/auction', {
method: "PUT",
body: data,
...
})
SDK ในอุปกรณ์มีหน้าที่รับผิดชอบในการเข้ารหัสข้อมูลนี้ เราขอแนะนำให้ใช้โซลูชันที่ประหยัดพื้นที่ เช่น ส่งคำขอไปยังบริการโฆษณาของผู้ขายในรูปแบบ multipart/form-data
ได้รับการตอบกลับจากบริการผู้ขายที่ไม่น่าเชื่อถือ
ตามที่อธิบายไว้ในคําอธิบายการเสนอราคาและเซิร์ฟเวอร์การประมูล เมื่อบริการผู้ขายที่ไม่น่าเชื่อถือได้รับคําขอ ระบบจะเรียกใช้ผู้ซื้อที่เป็นพาร์ทเนอร์สําหรับโฆษณาตามบริบท
บริการผู้ขายที่ไม่น่าเชื่อถือจะส่งต่อ adSelectionData
และ AuctionConfig
ที่เข้ารหัสไปยังบริการ SellerFrontEnd ของเซิร์ฟเวอร์การเสนอราคาและประมูลที่ทำงานใน TEE
เมื่อการประมูลกลุ่มเป้าหมายที่ได้รับการปกป้องเสร็จสมบูรณ์ บริการ SellerFrontEnd จะเข้ารหัสผลการประมูลและแสดงผลเป็นการตอบกลับบริการของผู้ขายที่ไม่น่าเชื่อถือ
บริการผู้ขายที่ไม่น่าเชื่อถือจะส่งการตอบกลับไปยังอุปกรณ์ที่มีโฆษณาตามบริบทและ / หรือผลการประมูล Protected Audience ที่เข้ารหัส
เมื่อได้รับการตอบกลับ โค้ดเทคโนโลยีโฆษณาของผู้ขายในอุปกรณ์อาจเลือกที่จะใช้เฉพาะโฆษณาตามบริบทในการตอบกลับ หรือหากเห็นว่าการได้รับผลลัพธ์ของ Protected Audience มีประโยชน์เพิ่มเติม ก็อาจเลือกที่จะถอดรหัสผลลัพธ์ของ Protected Audience โดยการเรียกใช้ PersistAdSelectionResult
API
PersistAdSelectionResult API
หากต้องการถอดรหัสผลลัพธ์ของ Protected Audience เทคโนโลยีโฆษณาของผู้ขายสามารถเรียกใช้ Protected Audience API persistAdSelectionResult
รายการที่ 2 ได้ API จะถอดรหัสผลลัพธ์และแสดง AdSelectionOutcome
ซึ่งเป็นออบเจ็กต์เดียวกับที่แสดงผลจากการประมูลในอุปกรณ์ในวันนี้
หากต้องการเข้าถึง API ผู้เรียกต้องเปิดใช้การเข้าถึง Protected Audience API และกำหนดสิทธิ์ ACCESS_ADSERVICES_CUSTOM_AUDIENCE
ในไฟล์ Manifest
public void persistAdSelectionResult(
PersistAdSelectionResultRequest persistAdSelectionResultRequest,
Executor executor,
OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}
PersistAdSelectionResultRequest
ผู้เรียกต้องตั้งค่าต่อไปนี้ในคำขอ
public final class PersistAdSelectionResultRequest {
Public setAdSelectionId(long adSelectionId);
public setSeller(AdTechIdentifier seller);
public setAdSelectionResult(byte[] adSelectionResult);
}
adSelectionId
: ตัวระบุแบบทึบซึ่งสร้างขึ้นจากการเรียกgetAdSelectionData
ที่มีผลลัพธ์ที่ผู้โทรต้องการถอดรหัสseller
: คุณต้องตั้งค่าตัวระบุเทคโนโลยีโฆษณาของผู้ขายในคําขอเพื่อเรียกใช้การตรวจสอบการลงทะเบียนก่อนดำเนินการตามคําขอadSelectionResult
: ผลการประมูลที่เข้ารหัสซึ่งสร้างโดยเซิร์ฟเวอร์การเสนอราคาและการประมูลที่ผู้เรียกต้องการถอดรหัส
การตอบกลับ AdSelectionOutcome
หากมีผู้ชนะในกลุ่มเป้าหมายที่ได้รับการคุ้มครอง AdSelectionOutcome
จะแสดงผล URI การแสดงโฆษณาที่ชนะ เมื่อถอดรหัส adSelectionResult
แล้ว ระบบจะเก็บข้อมูลการรายงานไว้ภายใน ฟังก์ชัน Callback ของ OutcomeReceiver.onResult()
จะแสดงผล AdSelectionOutcome
ที่มีข้อมูลต่อไปนี้
URI
: หากมีโฆษณา Protected Audience ที่ชนะ ระบบจะแสดง URL การนําเสนอโฆษณาของโฆษณาที่ชนะ หากไม่มีผู้ชนะ Protected Audience ระบบจะแสดงผล Uri.EMPTYadSelectionId
:adSelectionId
ที่เชื่อมโยงกับการประมูลเซิร์ฟเวอร์นี้
ข้อผิดพลาด ข้อยกเว้น และการจัดการความล้มเหลว
หากการสร้างข้อมูลการเลือกโฆษณาไม่สําเร็จเนื่องจากเหตุผลต่างๆ เช่น อาร์กิวเมนต์ไม่ถูกต้อง การหมดเวลา หรือการใช้ทรัพยากรมากเกินไป การเรียกกลับ OutcomeReceiver.onError()
จะส่ง AdServicesException
ที่มีลักษณะการทํางานต่อไปนี้
- หาก
getAdSelectionData
เริ่มต้นด้วยอาร์กิวเมนต์ที่ไม่ถูกต้องAdServicesException
จะระบุIllegalArgumentException
เป็นสาเหตุ - ข้อผิดพลาดอื่นๆ ทั้งหมดจะได้รับ
AdServicesException
โดยมีสาเหตุเป็นIllegalStateException
ข้อควรพิจารณาด้านความเป็นส่วนตัว
adSelectionData
ได้รับการเข้ารหัสเพื่อให้มั่นใจว่าข้อมูลระหว่างการส่งจะมีเพียง PPAPI และเซิร์ฟเวอร์ที่เชื่อถือเท่านั้นที่เข้าถึงได้
แม้ว่าจะมีการเข้ารหัส แต่การรั่วไหลของข้อมูลอาจเกิดขึ้นได้เนื่องจากขนาดของ adSelectionData
ขนาดadSelectionData
อาจแตกต่างกันไปตามปัจจัยต่อไปนี้
- การเปลี่ยนแปลงข้อมูล
CustomAudience
ในอุปกรณ์ - การเปลี่ยนแปลงตรรกะการกรอง
CustomAudience
- การเปลี่ยนแปลงอินพุตเพื่อโทร
getAdSelectionData
การเปลี่ยนแปลงขนาด adSelectionData
สามารถใช้ในการสร้างตัวระบุข้ามแอปตามที่กล่าวถึงในการสนทนาเกี่ยวกับการรั่วไหล 1 บิต การบรรเทาผลกระทบหลายอย่างที่ใช้ได้กับการรั่วไหล 1 บิตจะใช้ได้กับกรณีนี้ด้วย
เพื่อจัดการข้อมูลรั่วเหล่านี้ เราวางแผนที่จะสร้าง adSelectionData
เดียวกันสําหรับการเรียกใช้ getAdSelectionData
API ทั้งหมด ในรุ่นแรกๆ ระบบจะใช้CustomAudiences
ทั้งหมดในอุปกรณ์เพื่อสร้าง adSelectionData
และระบบจะเพิ่มค่าให้กับเพย์โหลดที่เข้ารหัสเพื่อปกปิดความหลากหลายของขนาด นอกจากนี้ เราจะจํากัดอิทธิพลของพารามิเตอร์อินพุต GetAdSelectionData
ที่มีต่อ adSelectionData
ที่สร้างขึ้น
อย่างไรก็ตาม การสร้าง adSelectionData
เดียวกันสําหรับเทคโนโลยีโฆษณาทั้งหมดโดยใช้ข้อมูลการประมูลในอุปกรณ์ทั้งหมดจะสร้างเพย์โหลดขนาดใหญ่ที่ตอนนี้ต้องโอนในการเรียกใช้เซิร์ฟเวอร์เทคโนโลยีโฆษณาทุกครั้ง การใช้กลุ่มเป้าหมายที่กำหนดเองทั้งหมดในอุปกรณ์เพื่อสร้างเพย์โหลดการประมูลยังเปิดโอกาสให้ระบบนิเวศถูกละเมิดจากบุคคลที่เป็นอันตรายด้วย เราได้อธิบายข้อกังวลเหล่านี้ไว้ในส่วนการเพิ่มประสิทธิภาพขนาดและการลดการใช้ในทางที่ผิดด้านล่าง
การเพิ่มประสิทธิภาพขนาด
SDK ไคลเอ็นต์เทคโนโลยีโฆษณาควรจัดแพ็กเกจไบต์ที่เข้ารหัสของ adSelectionData
ไว้ในHTTP PUT/POST
การเรียกแบบตามบริบทที่ส่งไปยังเซิร์ฟเวอร์เทคโนโลยีโฆษณา หากต้องการลดเวลาในการตอบสนองและต้นทุนในการส่งข้อมูลไปกลับ คุณจะต้องลดขนาด adSelectionData
ให้ได้มากที่สุดโดยไม่ส่งผลกระทบต่อยูทิลิตี
เราวางแผนที่จะสำรวจและอาจเปิดตัวการเพิ่มประสิทธิภาพต่อไปนี้ในรุ่นที่กำลังจะเปิดตัวเพื่อลดขนาด adSelectionData
เพย์โหลดที่สร้างขึ้นในกลุ่มขนาดที่แน่นอนของที่เก็บข้อมูลพร้อมการถอดรหัส: เราขอแนะนำให้ใช้การแบ่งกลุ่มที่เก็บข้อมูลขนาดคงที่สำหรับเพย์โหลดที่สร้างขึ้นเพื่อลดการสูญเสียจากขนาดที่ต่างกันไป แต่ก็ยังคงอนุญาตให้ใช้เพย์โหลดที่เล็กลงได้ การกำหนดจำนวนที่เก็บข้อมูลให้น้อย เช่น 7 จะทำให้มีข้อมูลสุ่มรั่วไหลน้อยกว่า 3 บิตต่อการเรียกใช้
getAdSelectionData
หากข้อมูลในอุปกรณ์มีขนาดใหญ่เกินขนาดที่เก็บข้อมูลสูงสุด ระบบจะใช้กลยุทธ์ที่กล่าวถึงด้านล่าง เช่น ค่าลําดับความสําคัญ เพื่อตัดสินใจว่าจะทิ้งข้อมูลใด
การกําหนดค่าผู้ซื้อ: เรากําลังประเมินความเป็นไปได้ในการอนุญาตให้ผู้ซื้อกําหนดค่าเพย์โหลดต่อผู้ซื้อ การกําหนดค่านี้จะมีประโยชน์ในการระบุการประมูลที่ผู้ซื้อสนใจเข้าร่วม ในระหว่างการลงทะเบียน เทคโนโลยีโฆษณาของผู้ซื้ออาจลงทะเบียนปลายทางที่กลุ่มเป้าหมายที่ได้รับการคุ้มครองจะดึงข้อมูลการกำหนดค่าเพย์โหลดตามช่วงเวลาปกติทุกวันได้ หากเป็นไปได้ หรือ API ที่รักษาความเป็นส่วนตัวจะแสดง API เพื่ออนุญาตให้เทคโนโลยีโฆษณาของผู้ซื้อลงทะเบียนปลายทางนี้
จากนั้นจะใช้การกําหนดค่านี้เพื่อประเมินการมีส่วนร่วมของผู้ซื้อใน
adSelectionData
ที่สร้างขึ้นสําหรับคําขอgetAdSelectionData
แต่ละรายการการกําหนดค่าเพย์โหลดของผู้ซื้อจะช่วยให้ผู้ซื้อระบุสิ่งต่อไปนี้ได้
- รายชื่อผู้ขายที่ได้รับอนุญาต: ระบบจะเพิ่ม CustomAudiences ของผู้ซื้อลงในเพย์โหลดก็ต่อเมื่อผู้ขายในรายการที่อนุญาตเป็นผู้เริ่มการเรียก
getAdSelectionData
เราจะดึงข้อมูลการกำหนดค่าเพย์โหลดเป็นรายวันเพื่อให้รายการที่อนุญาตเป็นข้อมูลล่าสุดอยู่เสมอ - ขีดจำกัดขนาดต่อผู้ขาย: ผู้ซื้อสามารถระบุขีดจำกัดขนาดต่อผู้ขายเพื่อกำหนดขนาดข้อมูลที่ส่งในเพย์โหลดเมื่อผู้ขายรายหนึ่งเริ่มการประมูล ซึ่งจะมีประโยชน์หากผู้ซื้อต้องการทุ่มเททรัพยากรมากขึ้นในการประมวลผลข้อมูลการประมูลจากผู้ขายบางราย SellerFrontendService จะส่งต่อเฉพาะข้อมูลที่เจาะจงผู้ซื้อไปยัง BuyerFrontendService แต่ละรายการ ดังนั้นการกำหนดขีดจำกัดขนาดต่อผู้ขายจะช่วยให้ผู้ซื้อควบคุมปริมาณข้อมูลที่ส่งผ่านและประมวลผลโดย BuyerFrontendService ของเซิร์ฟเวอร์การเสนอราคาและเซิร์ฟเวอร์การประมูลสำหรับการประมูลที่ผู้ขายดำเนินการได้อย่างชัดเจน
- รายชื่อผู้ขายที่ได้รับอนุญาต: ระบบจะเพิ่ม CustomAudiences ของผู้ซื้อลงในเพย์โหลดก็ต่อเมื่อผู้ขายในรายการที่อนุญาตเป็นผู้เริ่มการเรียก
การกำหนดค่าผู้ขาย: เรากำลังประเมินความเป็นไปได้ของการกำหนดค่าการประมูลต่อผู้ขาย ซึ่งจะช่วยให้ผู้ขายกำหนดพารามิเตอร์การประมูลเพื่อควบคุมขนาดเพย์โหลดและผู้เข้าร่วมการประมูลได้ ในระหว่างการลงทะเบียน เทคโนโลยีโฆษณาของผู้ขายจะระบุปลายทางจากที่ Protected Audience สามารถดึงข้อมูลการกำหนดค่าการประมูลต่อผู้ขายได้เป็นระยะๆ ตามปกติได้ หากเป็นไปได้ จากนั้นจะใช้การกําหนดค่านี้เพื่อกําหนดองค์ประกอบและขีดจํากัดของ
adSelectionData
ที่สร้างขึ้นสําหรับคําขอgetAdSelectionData
แต่ละรายการการกำหนดค่าต่อผู้ขายจะคล้ายกับการกำหนดค่าผู้ซื้อ โดยจะช่วยให้ผู้ขายระบุชุดผู้ซื้อที่คาดว่าจะเห็นในการประมูล และระบุขีดจํากัดการมีส่วนร่วมต่อผู้ซื้อในขนาดของเพย์โหลด
การกําหนดค่าการประมูลของผู้ขายจะช่วยให้ผู้ขายระบุสิ่งต่อไปนี้ได้
- รายชื่อผู้ซื้อที่อนุญาต: สำหรับการประมูลที่ผู้ขายรายหนึ่งเริ่มขึ้น เฉพาะผู้ซื้อในรายการที่อนุญาตเท่านั้นที่จะมีส่วนร่วมใน CustomAudiences สำหรับการประมูล คุณต้องอัปเดตการกําหนดค่าการประมูลทุกวันเพื่อให้รายการที่อนุญาตเป็นปัจจุบันกับรายการที่อนุญาตของผู้ซื้อฝั่งเซิร์ฟเวอร์
- ขีดจำกัดขนาดต่อผู้ซื้อ: ผู้ขายสามารถระบุขีดจำกัดต่อผู้ซื้อเพื่อควบคุมขนาดข้อมูลที่ผู้ซื้อแต่ละรายอัปโหลดลงในเพย์โหลดที่จะส่งไปยัง SellerFrontendService หากผู้ซื้อมีจํานวนเกินขีดจํากัดต่อผู้ซื้อ ระบบจะใช้ลําดับความสําคัญของ CustomAudience ที่ตั้งไว้ในการกำหนดค่าเพย์โหลดของผู้ซื้อเพื่อรับข้อมูลในขีดจํากัดที่คาดไว้
- ลําดับความสําคัญต่อผู้ซื้อ: อนุญาตให้ผู้ขายกําหนดลําดับความสําคัญต่อผู้ซื้อ ระบบจะใช้ลําดับความสําคัญของผู้ซื้อเพื่อระบุข้อมูลผู้ซื้อที่ควรเก็บไว้ในเพย์โหลดหากขนาดเพย์โหลดเกินขีดจํากัดขนาดเพย์โหลด
- ขีดจำกัดขนาดสูงสุดของเพย์โหลด: ผู้ขายแต่ละรายอาจมีการจัดสรรทรัพยากรที่แตกต่างกันและอาจต้องการกำหนดขีดจำกัดขนาดสูงสุดสำหรับเพย์โหลดการประมูลต่อคำขอ ขีดจํากัดขนาดสูงสุดจะเป็นไปตามที่เก็บข้อมูลขนาดคงที่ซึ่ง Protected Audience API กำหนด
การเปลี่ยนแปลงกลุ่มเป้าหมายที่กำหนดเอง
- ระบุลําดับความสําคัญของกลุ่มเป้าหมายที่กําหนดเอง: อนุญาตให้ผู้ซื้อระบุลําดับความสําคัญของค่าในกลุ่มเป้าหมายที่กําหนดเอง ระบบจะใช้ช่อง
priority
เพื่อระบุกลุ่มเป้าหมายที่กำหนดเองซึ่งควรรวมอยู่ในการประมูลหากกลุ่มเป้าหมายที่กำหนดเองของผู้ซื้อมีจำนวนเกินขีดจํากัดต่อผู้ขายหรือต่อผู้ซื้อ ค่าลําดับความสําคัญที่ไม่ได้ระบุในกลุ่มเป้าหมายที่กําหนดเองจะเป็น0.0
โดยค่าเริ่มต้น
- ระบุลําดับความสําคัญของกลุ่มเป้าหมายที่กําหนดเอง: อนุญาตให้ผู้ซื้อระบุลําดับความสําคัญของค่าในกลุ่มเป้าหมายที่กําหนดเอง ระบบจะใช้ช่อง
การเปลี่ยนแปลงข้อมูลเพย์โหลด
- ลดข้อมูลที่ส่งในเพย์โหลด: ตามที่ระบุไว้ในการเพิ่มประสิทธิภาพเพย์โหลดของบริการการเสนอราคาและการประมูล เพย์โหลดที่สูงขึ้นจะขับเคลื่อนโดยข้อมูล
ads
กลุ่มเป้าหมายที่กำหนดเอง สัญญาณการเสนอราคาของผู้ใช้ สัญญาณ Android น้ำหนักบรรทุกที่สูงขึ้นอาจลดลงได้ในกรณีต่อไปนี้- ให้ลูกค้าส่งรหัสการแสดงโฆษณา (แทนออบเจ็กต์โฆษณา) ในเพย์โหลด
- การที่ลูกค้าไม่ส่งข้อมูลโฆษณาในเพย์โหลด
- ไม่ส่งสัญญาณการเสนอราคาของผู้ใช้ในเพย์โหลดไคลเอ็นต์
- ลดข้อมูลที่ส่งในเพย์โหลด: ตามที่ระบุไว้ในการเพิ่มประสิทธิภาพเพย์โหลดของบริการการเสนอราคาและการประมูล เพย์โหลดที่สูงขึ้นจะขับเคลื่อนโดยข้อมูล
แม้ว่ากลยุทธ์ที่กล่าวถึงข้างต้นจะช่วยให้นักเทคโนโลยีโฆษณากําหนดการกําหนดค่าเพื่อจัดการองค์ประกอบและขีดจํากัดของadSelectionData
ได้ แต่ก็อาจกลายเป็นปัจจัยในการปรับขนาดadSelectionData
ด้วยการเปลี่ยนพารามิเตอร์การกําหนดค่า เพื่อหลีกเลี่ยงปัญหานี้ Protected Audience จะดึงข้อมูลการกําหนดค่าจากปลายทางที่กําหนดค่าไว้ทุกวัน
การเพิ่มประสิทธิภาพเวลาในการตอบสนอง
เพื่อให้การประมูลเซิร์ฟเวอร์มีประสิทธิภาพตามที่ต้องการ เราจำเป็นต้องตรวจสอบว่า getAdSelectionData
API และ persistAdSelectionResult
API มีเวลาในการตอบสนองต่ำต่อการเรียกใช้ แม้ว่าเราจะมุ่งมั่นที่จะรองรับฟีเจอร์สําหรับ API ในปี 2023 แต่รุ่นต่อๆ ไปจะมุ่งเน้นที่การทดสอบประสิทธิภาพเวลาในการตอบสนองและการเพิ่มประสิทธิภาพสําหรับ API
เรากำลังสำรวจกลยุทธ์ต่อไปนี้เพื่อรักษาเวลาในการตอบสนองให้อยู่ในขีดจำกัดที่ยอมรับได้
การสร้างข้อมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครองล่วงหน้าตามผู้ขาย: เนื่องจากการกำหนดค่าการประมูลของผู้ขายและการกำหนดค่าเพย์โหลดของผู้ซื้อจะเสถียรเป็นระยะเวลานาน (รายวัน) แพลตฟอร์มจึงสามารถประมวลผลและจัดเก็บข้อมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครองที่มีสิทธิ์ล่วงหน้า
ซึ่งจะทำให้แพลตฟอร์มต้องสร้างกลไกในการตรวจสอบการอัปเดตกลุ่มเป้าหมายที่กำหนดเองและแก้ไขข้อมูลกลุ่มเป้าหมายที่ได้รับการปกป้องซึ่งสร้างขึ้นล่วงหน้าตามการอัปเดต นอกจากนี้ แพลตฟอร์มจะต้องประกาศ SLO เกี่ยวกับความล่าช้าที่เทคโนโลยีโฆษณาอาจพบระหว่างการอัปเดตกลุ่มเป้าหมายที่กำหนดเองกับการเห็นการเปลี่ยนแปลงใน
adSelectionData
ที่สร้างขึ้นสำหรับการประมูลของเซิร์ฟเวอร์เนื่องจากอุปกรณ์มีรูปแบบการประมวลผลทรัพยากรแบบจํากัดที่มีลําดับความสําคัญของกระบวนการที่แตกต่างกัน เราจึงตระหนักดีว่าการจัดเตรียมสถานที่ตั้งก่อนการสร้างนี้ต้องมีความน่าเชื่อถือสูงและรับประกัน SLO
การสร้างข้อมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครองล่วงหน้าจะอิงตามข้อมูลต่อไปนี้
- ผู้ขายเลือกใช้การสร้างข้อมูล Protected Audience ล่วงหน้า
- ผู้ซื้อที่มีสิทธิ์เข้าร่วมการประมูลที่ผู้ขายรายหนึ่งเริ่ม
- การระบุกลุ่มเป้าหมายที่กำหนดเองต่อผู้ซื้อ ซึ่งจะเป็นส่วนหนึ่งของเพย์โหลดโดยอิงตามข้อมูลต่อไปนี้
- ขีดจำกัดขนาดต่อผู้ซื้อ ลำดับความสำคัญต่อผู้ซื้อ และขีดจำกัดขนาดสูงสุดที่กําหนดไว้ในการกำหนดค่าผู้ขาย
- ขีดจํากัดขนาดต่อผู้ขาย ลําดับความสําคัญของกลุ่มเป้าหมายที่กําหนดเองในการกําหนดค่าผู้ซื้อ
การใช้การกรองเชิงลบอย่างเต็มรูปแบบ: หากผู้ขายต้องการ แพลตฟอร์มจะคํานวณ
adSelectionData
ล่วงหน้าได้โดยการสร้างข้อมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครองล่วงหน้า และใช้การกรองเชิงลบกับคําเรียกgetAdSelectionData
ที่สําคัญ วิธีนี้จะช่วยให้ผู้ขายสามารถปรับสมดุลเวลาในการตอบสนองที่ต่ำลงในขณะที่ยอมรับข้อมูลล้าสมัยในการกรองเชิงลบแพลตฟอร์มสามารถให้การสนับสนุนนี้ได้โดยระบุตัวเลือกเริ่มต้นในการกำหนดค่าผู้ขายที่มีขีดจำกัดความล้าสมัยและตัวเลือกการลบล้างใน
getAdSelectionData
เพื่อให้มีการคำนวณล่าสุดหากจำเป็น หรือแพลตฟอร์มอาจให้ API เริ่มต้นเพิ่มเติมที่จะเรียกใช้ก่อนgetAdSelectionData
เพื่ออุ่นเครื่องการประมูลการคํานวณเพย์โหลดสําหรับการประมูลหลายรายการ: ในบางสถานการณ์ คุณอาจต้องใช้ API ที่มีประสิทธิภาพในการตอบสนองเวลาในการตอบสนอง แต่ข้อมูลจะล้าสมัยมากขึ้น แพลตฟอร์มอาจใช้ API เริ่มต้นเพื่อคํานวณเพย์โหลดทั้งหมดและระบุข้อมูลอ้างอิงไปยังเพย์โหลดที่ประมวลผลแล้วให้แก่ผู้เรียกใช้
สำหรับการเรียก
getAdSelectionData
ในภายหลัง ผู้เรียกอาจระบุการอ้างอิงไปยังเพย์โหลดที่คำนวณไว้ล่วงหน้าเพื่อใช้ในการสร้างadSelectionData
กลยุทธ์ทั้ง 3 อย่างที่กล่าวถึงข้างต้นยังอยู่ในขั้นเริ่มต้นของการสํารวจ และอธิบายทิศทางที่แพลตฟอร์มอาจนําไปใช้เพิ่มประสิทธิภาพเวลาในการตอบสนอง เราจะเสนอกลยุทธ์เพิ่มเติมต่อไปขณะที่สำรวจโปรไฟล์เวลาในการตอบสนองโดยละเอียดของ API และข้อกําหนดด้านเทคโนโลยีโฆษณา
การลดและระบุการละเมิด
ดังที่กล่าวไว้ในข้อควรพิจารณาด้านความเป็นส่วนตัว adSelectionData
สร้างขึ้นโดยใช้ข้อมูลผู้ซื้อทั้งหมดในอุปกรณ์
อย่างไรก็ตาม หากมีการใช้ข้อมูลผู้ซื้อทั้งหมดในอุปกรณ์เพื่อสร้างเอาต์พุต adSelectionData
บุคคลที่เป็นอันตรายอาจแอบอ้างเป็นข้อมูลผู้ซื้อและสร้างข้อมูลผู้ซื้อที่เป็นการฉ้อโกงเพื่อลดประสิทธิภาพของ Android, เพิ่มปริมาณข้อมูลเพื่อเพิ่มต้นทุนสําหรับเทคโนโลยีโฆษณาในการประมูลหรือเสนอราคา และอื่นๆ
การบรรเทา
การวัดผลบางอย่างที่กล่าวถึงในส่วนการพิจารณาขนาด เช่น การกําหนดค่าเพย์โหลดของผู้ซื้อซึ่งมีผู้ขายในรายการที่อนุญาตและการกําหนดค่าการประมูลของผู้ขายซึ่งมีผู้ซื้อในรายการที่อนุญาต จะช่วยยกเว้นข้อมูลที่คาดไม่ถึงในเพย์โหลด
มาตรการอื่นๆ ที่ต้องพิจารณาขนาด เช่น อนุญาตให้ SSP ระบุลําดับความสําคัญของผู้ซื้อ การวางโควต้าต่อผู้ซื้อในเพย์โหลดที่สร้างขึ้น และการตั้งค่าขนาดสูงสุดต่อเพย์โหลดการประมูลยังช่วยลดผลกระทบจากการขยายขนาดเพย์โหลดที่เป็นอันตรายได้อีกด้วย มาตรการเหล่านี้มีไว้เพื่อให้เทคโนโลยีโฆษณากําหนดเทคโนโลยีโฆษณาที่จะทํางานร่วมกัน และกำหนดขีดจํากัดที่ยอมรับได้ของเพย์โหลดที่จำเป็นต้องประมวลผล
ดังที่ได้กล่าวไว้ก่อนหน้านี้ การบรรเทาทั้งหมดที่นำมาใช้ในการป้องกันการละเมิดและข้อจำกัดด้านขนาดต้องเป็นไปตามข้อควรพิจารณาด้านความเป็นส่วนตัว
การระบุเอนทิตีที่เป็นอันตราย
แม้ว่าการบรรเทาความเสี่ยงที่กล่าวถึงข้างต้นจะช่วยปกป้องการสร้าง adSelectionData
สำหรับการประมูลของเซิร์ฟเวอร์ แต่ก็ไม่ได้ช่วยระบุตัวตนที่เป็นอันตรายหรือปกป้องแพลตฟอร์มจากการละเมิด เช่น การสร้างกลุ่มเป้าหมายที่กำหนดเองจำนวนมากอย่างที่ไม่เคยมีมาก่อนจากผู้ซื้อ
เราจำเป็นต้องหากลไกในการระบุตัวตนที่เป็นอันตราย ระบุเวกเตอร์การละเมิด และระบุแรงจูงใจในการโจมตีที่เฉพาะเจาะจง เพื่อให้แพลตฟอร์มมีเสถียรภาพและมีประสิทธิภาพ ในรุ่นต่อๆ ไป เราจะเปิดตัวคําอธิบายที่อธิบายรายละเอียดเกี่ยวกับเวกเตอร์การละเมิดที่อาจเกิดขึ้นและการป้องกันที่มีไว้เพื่อรับมือกับเวกเตอร์เหล่านั้น