ปรับปรุงเวลาในการตอบสนองในการประมูลของ Protected Audience API

ทุกคนควรตรวจสอบว่า Protected Audience API ทำงานได้อย่างมีประสิทธิภาพ

• ผู้ที่ท่องเว็บต้องการให้เว็บไซต์โหลดได้อย่างรวดเร็ว ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์ ควรสร้างด้วย Protected Audience API อย่างมีประสิทธิภาพเพื่อไม่ให้ใช้ทรัพยากรแบบจำกัดของอุปกรณ์มากเกินไป เช่น ทรัพยากรการประมวลผลหรือเครือข่าย ซึ่งจำเป็นต่อการโหลด เว็บไซต์และโฆษณาที่ฝังไว้
• ผู้เผยแพร่โฆษณาต้องการให้เว็บไซต์โหลดได้อย่างรวดเร็ว เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่มีประสิทธิภาพและตอบสนองได้ดี ผู้เผยแพร่โฆษณายังต้องการโฆษณาที่มีประสิทธิภาพเพื่อเพิ่มรายได้ให้ได้สูงสุดด้วย
• ผู้ลงโฆษณาและเทคโนโลยีโฆษณาต้องการให้โฆษณาแสดงอย่างรวดเร็วเพื่อมอบ ประโยชน์สูงสุด

เอกสารนี้ระบุแนวทางปฏิบัติแนะนำบางส่วนสำหรับการติดตั้งใช้งาน Protected Audience API เพื่อให้มั่นใจว่าเว็บไซต์ของคุณจะทำงานได้อย่างมีประสิทธิภาพสูงสุด

แนวทางปฏิบัติแนะนำสำหรับผู้ซื้อ (ผู้เสนอราคา)

โปรดทําตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อให้แน่ใจว่าคุณได้เพิ่มประสิทธิภาพเพื่อประสิทธิภาพการประมูลที่ใช้ Protected Audience API

เจ้าของกลุ่มความสนใจน้อยลง

เพื่อปกป้องผู้เสนอราคา Protected Audience API ในลักษณะเดียวกับที่เบราว์เซอร์ปกป้องต้นทางต่างๆ บนเว็บโดยใช้การแยกเว็บไซต์ เบราว์เซอร์จะใช้ทรัพยากรที่มีค่าใช้จ่ายสูง (เช่น กระบวนการของระบบปฏิบัติการ) เพื่อ ปกป้องเจ้าของกลุ่มความสนใจแต่ละราย

การมีเจ้าของกลุ่มความสนใจจำนวนน้อยที่สุดจึงเป็นสิ่งสำคัญอย่างยิ่งเพื่อลดค่าใช้จ่ายของทรัพยากรที่มีราคาสูงมากเหล่านี้ หลีกเลี่ยงการมีกลุ่มความสนใจที่แตกต่างกันซึ่งเป็นของโดเมนย่อยต่างๆ เช่น หาก adtech.example มีกลุ่มความสนใจที่ cats.adtech.example และ dogs.adtech.example เป็นเจ้าของ เบราว์เซอร์น่าจะใช้กระบวนการแยกกัน 2 กระบวนการเพื่อเรียกใช้สคริปต์การเสนอราคา

กลุ่มความสนใจเสนอราคาน้อยลง

เบราว์เซอร์ต้องทำการตั้งค่าและเตรียมการที่สำคัญก่อนที่จะเรียกใช้สคริปต์ generateBid() ของผู้ซื้อ เช่น การตั้งค่าสภาพแวดล้อมการเรียกใช้ JavaScript ใหม่ที่สะอาด รวมถึงการแยกวิเคราะห์และโหลดโค้ด generateBid()

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

กรองกลุ่มความสนใจออกจากการเสนอราคาในบริการคีย์/ค่า

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

นำสภาพแวดล้อมการดำเนินการ JavaScript กลับมาใช้ใหม่

ก่อนที่เบราว์เซอร์จะเรียกใช้ generateBid() ได้ เบราว์เซอร์ต้องเริ่มต้นสภาพแวดล้อมการเรียกใช้ JavaScript ใหม่ ซึ่งอาจใช้เวลานานพอสมควร เทียบเท่ากับเวลาที่ generateBid() ขั้นต่ำใช้ในการดำเนินการ คุณประหยัดเวลานี้ได้โดยใช้โหมดการดำเนินการแบบจัดกลุ่มตามต้นทางหรือแบบบริบทที่หยุดชั่วคราว

group-by-originโหมดนี้สามารถนำสภาพแวดล้อมการดำเนินการกลับมาใช้ใหม่ได้ในกรณีที่มีการเข้าร่วมกลุ่มความสนใจในต้นทางเดียวกัน และไม่น่าจะต้องมีการเปลี่ยนแปลงสคริปต์การเสนอราคา ดูข้อมูลเพิ่มเติมได้ที่group-by-originคำอธิบายในคำอธิบาย โหมดบริบทที่หยุดชั่วคราวสามารถนำสภาพแวดล้อมการดำเนินการทั้งหมดกลับมาใช้ใหม่ได้ แต่อาจต้องมีการเปลี่ยนแปลงสคริปต์การเสนอราคา หากต้องการดูข้อมูลเพิ่มเติม โปรดดูfrozen-contextคำอธิบายในคำอธิบาย

นำสคริปต์การเสนอราคากลับมาใช้ซ้ำ

หากเป็นไปได้ ให้ใช้สคริปต์การเสนอราคาเดียวกันสำหรับกลุ่มความสนใจ วิธีนี้ช่วยให้เบราว์เซอร์ไม่ต้องดาวน์โหลด แยกวิเคราะห์ และคอมไพล์สคริปต์หลายรายการ (ซึ่งทำให้เกิดคำขอเครือข่ายเพิ่มเติม) ผู้เสนอราคายังคงแยกความแตกต่างของการเสนอราคาตามข้อมูลกลุ่มความสนใจ (เช่น name หรือ userBiddingSignals) ได้ในขณะที่ใช้สคริปต์เดียวกัน

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

โปรดทราบว่าเบราว์เซอร์จะโหลดสคริปต์การเสนอราคาในระหว่างเวลาเสนอราคา (สำหรับ generateBid()) และในระหว่างเวลาการรายงาน (สำหรับ reportWin()) หากไม่ได้ตั้งค่าส่วนหัวการควบคุมแคช เบราว์เซอร์จะดึงข้อมูลสคริปต์เดียวกัน 2 ครั้ง โดยครั้งละ 1 ช่วงเวลา

ดังนั้น เราขอแนะนำให้ตั้งค่าส่วนหัว Cache-Control ในสคริปต์ทั้งหมด

ใช้ซ้ำ trustedBiddingSignalsUrls

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

สามารถรวมการดึงสัญญาณการเสนอราคาที่เชื่อถือได้ เมื่อมีการนำ trustedBiddingSignalsUrl ไปใช้ซ้ำในกลุ่มความสนใจหลายกลุ่ม ใช้ trustedBiddingSignalsUrl เดียวกันสำหรับกลุ่มความสนใจทั้งหมดเมื่อเป็นไปได้

ระบุส่วนหัวการควบคุมแคช HTTP ที่เหมาะสมเพื่อให้มั่นใจว่าการดึงสัญญาณการเสนอราคาที่เชื่อถือได้จะได้รับการแคชในช่องโฆษณาทั้งหมดในหน้าเว็บหนึ่งๆ หลีกเลี่ยงการตั้งค่า trustedBiddingSignalsSlotSizeMode เป็น slot-size เนื่องจากจะป้องกันการแคชในช่องโฆษณาทั้งหมดเมื่อขนาดของช่องแตกต่างกันเนื่องจาก URL ที่ขอจะแตกต่างกัน

การดึงข้อมูลสัญญาณการเสนอราคาที่เชื่อถือได้แบบเรียลไทม์ขนาดเล็ก

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

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

ระบบควรจัดเก็บสัญญาณที่อัปเดตได้ทุกวันหรือนานกว่านั้นไว้ใน กลุ่มความสนใจและอัปเดตโดยใช้การอัปเดตรายวัน

อย่าแสดงสัญญาณการเสนอราคาที่เชื่อถือได้สำหรับกลุ่มความสนใจที่กรองออกตามที่อธิบายไว้ในส่วน "กรองกลุ่มความสนใจจากการเสนอราคาในบริการคีย์/ค่า"

จัดลำดับความสำคัญของกลุ่มความสนใจ

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

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

โปรดทราบว่าเมื่อเบราว์เซอร์เรียกใช้กลุ่มความสนใจจากลำดับความสำคัญสูงสุดไปต่ำสุด กลุ่มความสนใจจากต้นทางการเข้าร่วมที่แตกต่างกันอาจแทรกสลับกัน ซึ่งอาจทำให้การเพิ่มประสิทธิภาพ group-by-origin ไม่ได้ผล

แนวทางปฏิบัติแนะนำสำหรับผู้ขาย

ตรวจสอบว่าคุณกำลังตรวจสอบและเพิ่มประสิทธิภาพเพื่อประสิทธิภาพการประมูลที่ใช้ Protected Audience API

ส่งการประมูลพร้อมกัน

การเชื่อมต่อเครือข่ายที่ทันสมัยและโปรเซสเซอร์แบบมัลติคอร์ทำงานได้ดีในการทำกิจกรรมหลายอย่างพร้อมกัน เบราว์เซอร์สามารถดำเนินการประมูลที่ใช้ Protected Audience API ไปพร้อมกับกิจกรรมอื่นๆ ได้ ซึ่งทำได้ดีที่สุดโดยการโทรหา runAdAuction() โดยเร็วที่สุด เนื่องจากทราบว่าอินพุตบางอย่างใน runAdAuction() อาจไม่พร้อมใช้งานตั้งแต่เนิ่นๆ เช่น อินพุตที่ส่งกลับไปยังเบราว์เซอร์ในการตอบกลับตามบริบท เบราว์เซอร์จึงอนุญาตให้เรียกใช้ runAdAution() ก่อนที่อินพุตจะพร้อมใช้งาน และให้ระบุอินพุตเหล่านี้ในภายหลังโดยใช้ JavaScript Promises หากต้องการให้การประมูลมีเวลาในการตอบสนองต่ำที่สุดเท่าที่จะเป็นไปได้ คุณควรเรียกใช้ runAdAuction() เมื่อทราบอินพุต interestGroupBuyers ซึ่งจะช่วยให้การประมูลหลายส่วนเริ่มต้นได้ทันที รวมถึงการดึงสัญญาณการเสนอราคาแบบเรียลไทม์ของผู้เสนอราคา

ตรวจสอบการประมูล

รวบรวมเมตริกเกี่ยวกับการประมูล เบราว์เซอร์สามารถรายงานper-buyerเมตริกเวลาในการตอบสนองต่อผู้ขาย ซึ่งให้ข้อมูลเชิงลึกมากมายเกี่ยวกับระยะเวลาที่ใช้ในการประมูลของผู้ขาย ผู้ขายสามารถใช้เมตริกเหล่านี้เพื่อหาวิธีเพิ่มประสิทธิภาพการประมูล รวมถึงให้ข้อมูลเกี่ยวกับวิธีตั้งค่าการหมดเวลาที่มีประสิทธิภาพมากที่สุด ผู้ขายสามารถแชร์เมตริกเวลาในการตอบสนองของผู้ซื้อที่เฉพาะเจาะจงกับผู้ซื้อเพื่อช่วยให้ผู้ซื้อเพิ่มประสิทธิภาพได้ต่อไป

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

ป้องกันสคริปต์ราคาเสนอที่ทำงานช้า

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

ผู้ขายควรใช้ perBuyerCumulativeTimeouts เพื่อป้องกันการประมูลที่ช้า และยังคงยอมรับราคาเสนอเมื่อการประมูลช้าและถึงการหมดเวลา การใช้ perBuyerCumulativeTimeouts ดีกว่าการใช้ perBuyerTimeouts และ perBuyerGroupLimits เนื่องจาก perBuyerCumulativeTimeouts ไม่ได้กำหนดจำนวนกลุ่มความสนใจหรือความเร็วของ generateBid() (เช่น กลุ่มความสนใจจำนวนมากที่เสนอราคาอย่างรวดเร็วและกลุ่มความสนใจจำนวนน้อยที่เสนอราคาอย่างช้าๆ สามารถเสนอราคาให้เสร็จก่อนหมดเวลาได้)

การใช้ฟิลด์การกำหนดค่าการประมูล signal เพื่อใช้การหมดเวลาการประมูลโดยรวมยังเป็นวิธีที่ดีในการป้องกันการประมูลที่ยาวนานเกินไปในกรณีที่การดึงสัญญาณการให้คะแนนที่เชื่อถือได้และการดำเนินการ scoreAd() ใช้เวลานานเกินไป

What's next?

We want to engage in conversations with you to ensure we build an API that works for everyone.

Discuss the API

Like other Privacy Sandbox APIs, this API is documented and discussed publicly.

Experiment with the API

You can experiment and participate in conversation about the Protected Audience API.