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

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

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

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

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

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

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

เราจึงขอแนะนำให้ตั้งค่าส่วนหัวการควบคุมแคชในสคริปต์ทั้งหมด

ใช้ซ้ำ 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 ควบคู่ไปกับกิจกรรมอื่นๆ วิธีที่ดีที่สุดคือโทรหา runAdAuction() โดยเร็วที่สุด เนื่องจากอินพุตบางอย่างของ runAdAuction() อาจไม่พร้อมใช้งานตั้งแต่เนิ่นๆ เช่น อินพุตที่ส่งกลับไปยังเบราว์เซอร์ในการตอบสนองตามบริบท เบราว์เซอร์จึงอนุญาตให้เรียกใช้ runAdAution() ก่อนที่จะพร้อมใช้งาน และระบุอินพุตเหล่านี้ในภายหลังโดยใช้ Promise ของ JavaScript คุณควรเรียกใช้ runAdAuction() เมื่อทราบอินพุต interestGroupBuyers เพื่อให้ได้เวลาในการตอบสนองในการประมูลต่ำที่สุด ซึ่งจะช่วยให้การประมูลหลายส่วนเริ่มต้นได้ทันที รวมถึงการดึงข้อมูลสัญญาณการเสนอราคาแบบเรียลไทม์ของผู้เสนอราคา

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

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

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

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

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

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

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

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

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

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

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

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

ทดลองใช้ API

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