เมื่อไหร่ถึงเวลาย้ายแพลตฟอร์ม Mediation ของคุณ?
การเปลี่ยนแพลตฟอร์มมีเดียชันโฆษณาเป็นหนึ่งในการตัดสินใจที่สำคัญที่สุดที่ผู้เผยแพร่บนมือถือสามารถทำได้ เลเยอร์มีเดียชันควบคุมว่าผู้ใช้ของคุณเห็นโฆษณาอะไร คุณได้รับเท่าไหร่ต่อการแสดงผลแต่ละครั้ง และประสบการณ์โฆษณาทำงานราบรื่นเพียงใด การย้ายมีความเสี่ยงจริง แต่การอยู่บนแพลตฟอร์มที่ไม่เหมาะสมก็มีค่าใช้จ่ายที่สะสมทุกวัน
สัญญาณชัดเจนว่าถึงเวลาประเมินการย้าย:
- eCPM ลดลงโดยไม่มีคำอธิบายจากตลาด: ถ้า eCPM ของคุณลดลงขณะที่ค่าเฉลี่ยอุตสาหกรรมยังคงที่ แพลตฟอร์มปัจจุบันของคุณอาจมีช่องว่างด้านอุปสงค์หรือปัญหาการปรับแต่งที่ผู้ใหม่แก้ไขแล้ว
- การสนับสนุนการเสนอราคาที่ดีกว่าที่อื่น: ถ้าแพลตฟอร์มปัจจุบันของคุณสนับสนุนพาร์ทเนอร์การเสนอราคา 3 รายแต่คู่แข่งสนับสนุน 8 ราย คุณกำลังทิ้งความหนาแน่นของการประมูลและรายได้ไว้บนโต๊ะ
- การยุติ SDK: เมื่อแพลตฟอร์มมีเดียชันของคุณประกาศสิ้นสุดอายุการใช้งานของ SDK หรือหยุดพัฒนาฟีเจอร์อย่างจริงจัง การย้ายไม่ใช่ทางเลือก แต่เป็นเรื่องของเวลา
- รูปแบบโฆษณาที่ขาดหาย: ถ้าแพลตฟอร์มของคุณไม่รองรับโฆษณาเปิดแอป interstitial แบบมีรางวัล หรือ native bidding ในขณะที่คู่แข่งทำได้ รูปแบบที่ขาดหายแต่ละอย่างแทนถึงรายได้ที่หายไป
- ข้อจำกัดในการรายงาน: ถ้าคุณไม่สามารถรับข้อมูล eCPM แบบละเอียดตามเครือข่าย พื้นที่ ยูนิตโฆษณา และรูปแบบได้ คุณกำลังบินตาบอด แพลตฟอร์มสมัยใหม่ให้สิ่งนี้เป็นมาตรฐาน
การวางแผนการย้าย: วิธีการทดสอบแบบขนาน
กฎพื้นฐานของการย้ายมีเดียชันคือไม่ทำการเปลี่ยนแปลงอย่างกะทันหัน วิธีการทดสอบแบบขนานปกป้องฐานรายได้ของคุณในขณะที่ยืนยันประสิทธิภาพของแพลตฟอร์มใหม่ด้วยทราฟฟิกจริง
กลยุทธ์แบบขนานทำงานดังนี้:
- เฟส 1 (การตั้งค่า): รวม SDK มีเดียชันใหม่ควบคู่กับ SDK เดิม กำหนดค่ายูนิตโฆษณา แหล่งอุปสงค์ และราคาพื้นที่เหมือนกันในทั้งสองแพลตฟอร์ม
- เฟส 2 (แบ่งทราฟฟิก): นำทราฟฟิก 10–20% ไปยังแพลตฟอร์มใหม่ในขณะที่รักษา 80–90% ไว้บนแพลตฟอร์มเดิม ใช้ flag การกำหนดค่าระยะไกลหรือเฟรมเวิร์ก A/B testing เพื่อควบคุมการแบ่ง
- เฟส 3 (ติดตาม): รันทั้งสองแพลตฟอร์มพร้อมกันอย่างน้อย 2 สัปดาห์ เปรียบเทียบ eCPM อัตราการเติมเต็ม ความหน่วง และอัตราการขัดข้องทั่วทั้งการแบ่ง
- เฟส 4 (ขยาย): ถ้าแพลตฟอร์มใหม่ตรงกับหรือเกินกว่าแพลตฟอร์มเดิม ค่อยๆ เพิ่มส่วนแบ่งทราฟฟิกของมัน: 20% เป็น 50% เป็น 80% เป็น 100%
- เฟส 5 (ทำความสะอาด): ลบ SDK มีเดียชันเก่าและการกำหนดค่าที่เกี่ยวข้องออกเมื่อ 100% ของทราฟฟิกอยู่บนแพลตฟอร์มใหม่อย่างน้อยหนึ่งสัปดาห์โดยมีประสิทธิภาพที่เสถียร
ข้อมูลที่ต้องการก่อนการเปลี่ยน
ก่อนเริ่มการย้ายใดๆ ส่งออกและบันทึกข้อมูลพื้นฐานที่ครอบคลุมจากแพลตฟอร์มปัจจุบันของคุณ ข้อมูลนี้ตอบสนองสองวัตถุประสงค์: ให้เกณฑ์มาตรฐานการเปรียบเทียบสำหรับการประเมินแพลตฟอร์มใหม่ และแจ้งการกำหนดค่าเริ่มต้นของ waterfall ใหม่หรือการตั้งค่าการเสนอราคาของคุณ
จุดข้อมูลที่จำเป็น
- eCPM ในอดีตตามเครือข่ายและภูมิศาสตร์: อย่างน้อย 90 วันที่ผ่านมาของ eCPM รายวันสำหรับแต่ละแหล่งอุปสงค์แยกตามประเทศหรือกลุ่มประเทศ สิ่งนี้บอกคุณว่าเครือข่ายใดทำงานได้ดีในตลาดใด
- อัตราการเติมเต็มตามเครือข่ายและรูปแบบโฆษณา: เครือข่ายที่มี eCPM สูงแต่อัตราการเติมเต็ม 5% มีส่วนร่วมต่างจากเครือข่ายที่มี eCPM ปานกลางและอัตราการเติมเต็ม 90% ต้องการทั้งสองเมตริกสำหรับการกำหนดค่าที่แม่นยำ
- ปริมาณการแสดงผลตามยูนิตโฆษณา: เข้าใจว่าตำแหน่งโฆษณาใดสร้างการแสดงผลมากที่สุด เหล่านี้คือยูนิตที่มีผลกระทบสูงสุดของคุณและควรย้ายเป็นลำดับสุดท้ายเพื่อลดความเสี่ยง
- ข้อมูลความหน่วง: หากมี บันทึกเวลาโหลดโฆษณาเฉลี่ยและอัตราการหมดเวลาต่อเครือข่าย สิ่งนี้ช่วยตั้งค่าระยะเวลาหมดเวลาที่เหมาะสมในแพลตฟอร์มใหม่
- รายได้ตามวันในสัปดาห์และเวลาของวัน: ตลาดโฆษณามีรอบรายสัปดาห์และรายวัน การมีรูปแบบนี้ที่บันทึกไว้ช่วยให้คุณไม่เข้าใจผิดว่าการเปลี่ยนแปลงแบบวนซ้ำปกติเป็นการเปลี่ยนแปลงที่เกี่ยวข้องกับการย้าย
ข้อมูลที่มีประโยชน์เพิ่มเติม
- ARPDAU ระดับผู้ใช้ตาม cohort
- ข้อมูลความถี่โฆษณาระดับเซสชัน
- อัตราการขัดข้องและ ANR ที่สัมพันธ์กับกิจกรรม SDK โฆษณา
- บันทึกระดับ bid แบบละเอียดหากแพลตฟอร์มปัจจุบันของคุณให้ไว้
กระบวนการย้ายทีละขั้นตอน
ขั้นตอนที่ 1: ติดตั้ง SDK มีเดียชันใหม่
เพิ่ม SDK มีเดียชันใหม่และ SDK adapter ที่จำเป็นทั้งหมดในโปรเจกต์ของคุณ ยังไม่ต้องลบ SDK เก่า ทั้งสองจะอยู่ร่วมกันในช่วงการทดสอบแบบขนาน การดำเนินการหลัก:
- เพิ่ม dependency ของ SDK มีเดียชันหลัก
- เพิ่ม SDK adapter สำหรับแต่ละแหล่งอุปสงค์ที่คุณวางแผนจะใช้
- เริ่มต้น SDK ใหม่ใน Application class หรือ AppDelegate ของคุณ โดยมี flag การกำหนดค่าระยะไกลเป็นเงื่อนไข
- ตรวจสอบว่า build คอมไพล์ได้โดยไม่มีความขัดแย้งระหว่าง SDK เก่าและใหม่
ขั้นตอนที่ 2: กำหนดค่ายูนิตโฆษณาและแหล่งอุปสงค์
ในแดชบอร์ดของแพลตฟอร์มใหม่ สร้างการกำหนดค่ายูนิตโฆษณาของคุณใหม่:
- สร้างยูนิตโฆษณาที่ตรงกับตำแหน่งที่มีอยู่ของคุณ (รูปแบบเดียวกัน ช่วงการรีเฟรชเดียวกันสำหรับ banner)
- เพิ่มแหล่งอุปสงค์ทั้งหมดพร้อม app ID และ placement ID ของแต่ละรายการ
- ตั้งราคาพื้นเริ่มต้นตามข้อมูล eCPM ในอดีตจากแพลตฟอร์มเก่า
- เปิดใช้งาน bidding สำหรับแหล่งทั้งหมดที่รองรับ กำหนดค่า waterfall entries สำหรับส่วนที่เหลือ
ขั้นตอนที่ 3: ดำเนินการแบ่งทราฟฟิก
ใช้ระบบการกำหนดค่าระยะไกล (Firebase Remote Config, ระบบ feature flag ของคุณเอง หรือ toggle ฝั่งเซิร์ฟเวอร์ง่ายๆ) เพื่อควบคุมว่า SDK มีเดียชันใดจัดการแต่ละเซสชัน:
- เมื่อเปิดแอป ตรวจสอบ flag ระยะไกลเพื่อกำหนดว่า SDK ใดใช้งานอยู่สำหรับเซสชันนี้
- ขอโฆษณาผ่าน SDK ที่ใช้งานอยู่เท่านั้นตลอดทั้งเซสชัน อย่าผสม SDK ภายในเซสชันเดียวกัน
- บันทึกว่า SDK ใดใช้งานอยู่ใน analytics ของคุณเพื่อให้คุณสามารถแบ่งกลุ่มข้อมูลประสิทธิภาพได้อย่างชัดเจน
ขั้นตอนที่ 4: รันแบบขนานอย่างน้อยสองสัปดาห์
สองสัปดาห์คือระยะเวลาประเมินขั้นต่ำ ระยะเวลานี้จับรูปแบบวันธรรมดาและวันหยุดสุดสัปดาห์ คำนึงถึงความผันผวนของอุปสงค์ และให้เวลา algorithm การเสนอราคาเรียนรู้ inventory ของคุณ ในช่วงนี้:
- ติดตาม eCPM อัตราการเติมเต็ม และรายได้รวมรายวันสำหรับทั้งสองกลุ่ม
- ติดตามเมตริกความเสถียรของแอป (อัตราการขัดข้อง อัตรา ANR) ในทั้งสองกลุ่ม
- ดูปัญหาประสบการณ์ผู้ใช้ (การโหลดโฆษณาช้า กรอบโฆษณาว่างเปล่า โฆษณาเต็มหน้าจอที่ไม่คาดคิด)
- อย่าทำการเปลี่ยนแปลงการกำหนดค่าให้กับแพลตฟอร์มใดๆ ในช่วงนี้เว้นแต่บางอย่างจะเสียหายอย่างชัดเจน
ขั้นตอนที่ 5: เปรียบเทียบและตัดสินใจ
หลังจากช่วงขนาน เปรียบเทียบสองแพลตฟอร์มในมิติเหล่านี้:
- รายได้ต่อ DAU: เมตริกหลัก ถ้าแพลตฟอร์มใหม่สร้างรายได้เท่ากันหรือสูงกว่าต่อผู้ใช้งานรายวัน มันผ่านการทดสอบหลัก
- อัตราการเติมเต็ม: อัตราการเติมเต็มที่สูงกว่าหมายถึงการแสดงผลที่สร้างรายได้มากขึ้น แพลตฟอร์มใหม่ที่มีอัตราการเติมเต็มสูงกว่า 5% และ eCPM ที่คล้ายกันเป็นผู้ชนะที่ชัดเจน
- ความหน่วง: การโหลดโฆษณาที่เร็วกว่าหมายถึง viewability ที่ดีกว่าและประสบการณ์ผู้ใช้ที่ดีกว่า
- ความเสถียร: ถ้า SDK ใหม่เพิ่มอัตราการขัดข้อง อาจไม่คุ้มกับการเพิ่มรายได้
ขั้นตอนที่ 6: เปลี่ยนและทำความสะอาด
เมื่อคุณตัดสินใจใช้แพลตฟอร์มใหม่แล้ว เพิ่มทราฟฟิกเป็น 100% ติดตามอีก 5–7 วัน จากนั้นลบ SDK เก่าออกทั้งหมด อัปเดตรายการ dependency ของคุณ ลบโค้ด initialization เก่า และล้าง logic เงื่อนไขที่เกี่ยวข้องกับการแบ่งทราฟฟิก
ข้อผิดพลาดทั่วไปในการย้ายมีเดียชัน
แม้แต่การย้ายที่วางแผนไว้อย่างดีก็ยังพบปัญหา การตระหนักถึงข้อผิดพลาดทั่วไปช่วยให้คุณหลีกเลี่ยงหรือฟื้นตัวจากปัญหาได้อย่างรวดเร็ว:
- การสูญเสียข้อมูลการปรับแต่งในอดีต: Algorithm การเสนอราคาบนแพลตฟอร์มเก่ามีข้อมูลเกี่ยวกับ inventory ของคุณเป็นเดือนๆ แพลตฟอร์มใหม่เริ่มจากศูนย์ คาดว่าจะมีประสิทธิภาพที่ต่ำกว่าในช่วง 1–2 สัปดาห์ขณะที่ algorithm เรียนรู้
- ความขัดแย้งของ SDK: การรัน SDK มีเดียชันสองตัวพร้อมกันอาจทำให้เกิดความขัดแย้งของ dependency โดยเฉพาะถ้าทั้งสองรวม SDK แหล่งอุปสงค์เดียวกันในเวอร์ชันต่างกัน ทดสอบอย่างละเอียดใน staging build ก่อน deploy ไปยัง production
- ราคาพื้นที่ไม่ตรงกัน: การตั้งราคาพื้นสูงเกินไปบนแพลตฟอร์มใหม่ทำให้อัตราการเติมเต็มลดลง การตั้งต่ำเกินไปทิ้งเงินไว้บนโต๊ะ ใช้ข้อมูลในอดีตของคุณเป็นจุดเริ่มต้นและปรับหลังจากสัปดาห์แรก
- การเปรียบเทียบช่วงเวลาที่ไม่เท่ากัน: ตลาดโฆษณามีความผันผวน การเปรียบเทียบสัปดาห์ที่ 1 ของแพลตฟอร์มใหม่กับสัปดาห์ที่ 1 ของแพลตฟอร์มเก่าจากสามเดือนที่แล้วไม่ใช่การเปรียบเทียบที่ถูกต้อง การทดสอบแบบขนานขจัดปัญหานี้
- รีบร้อนตามกำหนดเวลา: แรงกดดันในการแสดงผลลัพธ์ที่รวดเร็วนำไปสู่ข้อสรุปที่รีบเร่ง สองสัปดาห์ของข้อมูลแบบขนานคือขั้นต่ำ สี่สัปดาห์ดีกว่าสำหรับผู้เผยแพร่ที่มีทราฟฟิกมาก
การย้ายจาก AdMob Mediation ไปยัง Google Ad Manager
หนึ่งในเส้นทางการย้ายที่พบบ่อยที่สุดคือการย้ายจากมีเดียชัน AdMob ไปยังแพลตฟอร์ม Google Ad Manager แบบเต็ม การอัปเกรดนี้ขับเคลื่อนโดยฟีเจอร์ที่เหนือกว่าของ GAM สำหรับผู้เผยแพร่ในระดับใหญ่:
- การสนับสนุนดีลตรง: GAM อนุญาตให้แคมเปญที่ขายตรงแข่งขันกับอุปสงค์แบบโปรแกรมซึ่ง AdMob mediation ไม่รองรับ
- การรายงานขั้นสูง: GAM ให้การรายงานแบบละเอียดตาม line item, ผู้โฆษณา, creative และมิติที่กำหนดเอง
- Open Bidding: server-side bidding ของ GAM รองรับพาร์ทเนอร์ exchange ที่หลากหลายกว่า client-side mediation ของ AdMob
- กฎการกำหนดราคาแบบรวม: ตั้งราคาพื้นตามภูมิศาสตร์ อุปกรณ์ และรูปแบบสำหรับแหล่งอุปสงค์ทั้งหมดจากอินเทอร์เฟซเดียว
การย้ายเฉพาะนี้เป็นหนึ่งที่ RevenueFlex ดำเนินการบ่อยครั้ง การเปลี่ยนจากมีเดียชัน AdMob ไปยังการตั้งค่า GAM ที่จัดการครบวงจรเกี่ยวข้องกับการสร้างการกำหนดค่าโฆษณาทั้งหมดของคุณใหม่ใน GAM การแมปแหล่งอุปสงค์ การกำหนดราคาพื้นใหม่ตามประสิทธิภาพในอดีต และการรันการประเมินแบบขนานเพื่อยืนยันความเป็นกลางของรายได้หรือการปรับปรุง ผู้เผยแพร่ที่ทำการเปลี่ยนผ่านนี้ด้วยการวางแผนที่เหมาะสมมักจะเห็นรายได้เพิ่มขึ้น 10–25% เมื่อ GAM waterfall ได้รับการปรับแต่งอย่างเต็มที่
การย้ายมีเดียชันไม่ใช่โปรเจกต์สุดสัปดาห์ เป็นกระบวนการหลายสัปดาห์ที่ต้องการการวางแผนอย่างรอบคอบ การทดสอบแบบขนานอย่างมีวินัย และความอดทนในขณะที่ algorithm ใหม่เรียนรู้ inventory ของคุณ แต่สำหรับผู้เผยแพร่บนแพลตฟอร์มที่มีประสิทธิภาพต่ำ ผลกระทบด้านรายได้ระยะยาวจากการเปลี่ยนทำให้ความพยายามระยะสั้นคุ้มค่า