ปรับปรุงเวลาในการตอบสนองในการประมูลของ 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() ใช้เวลานานเกินไป

ขั้นตอนถัดไปคือ

เราต้องการพูดคุยกับคุณเพื่อให้แน่ใจว่าเราได้สร้าง API ที่เหมาะสำหรับทุกคน

พูดคุยเกี่ยวกับ API

API นี้จะได้รับการจัดทำเอกสารและอภิปรายต่อสาธารณะเช่นเดียวกับ Privacy Sandbox API อื่นๆ

ทดลองใช้ API

คุณจะทดสอบและเข้าร่วมในการพูดคุยเกี่ยวกับ Protected Audience API ได้