SDK ที่บวมเกินไปกำลังทำลายแอปของคุณ: วิธีสร้างกลยุทธ์การสร้างรายได้ที่เบาและมีประสิทธิภาพ

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

ต้นทุนที่แท้จริงของ SDK ที่บวม

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

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

การตรวจสอบ SDK

เริ่มต้นด้วยการตรวจสอบ SDK stack ปัจจุบันของคุณ สำหรับ SDK โฆษณาแต่ละตัวในแอป ให้วัดสามสิ่ง: ขนาด binary ที่มันเพิ่ม รายได้ที่มันสร้าง และ fill rate ของมัน คุณเกือบจะแน่นอนว่าจะพบว่า SDK หนึ่งหรือสองตัวรับผิดชอบต่อรายได้ส่วนใหญ่ของคุณ ในขณะที่อีกหลายตัวมีส่วนร่วมเพียงเล็กน้อยแต่เพิ่มค่าใช้จ่ายด้านประสิทธิภาพอย่างมาก

กฎ 80/20 ใช้ได้ผล

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

โซลูชันฝั่งเซิร์ฟเวอร์

วิธีที่มีประสิทธิภาพที่สุดในการลดจำนวน SDK โดยไม่สูญเสียความหลากหลายของ demand คือการเปลี่ยนการรวม demand จากฝั่งไคลเอนต์ไปยังฝั่งเซิร์ฟเวอร์ ตัวอย่างเช่น Open Bidding ของ Google ช่วยให้พาร์ทเนอร์ด้าน demand หลายรายแข่งขันเพื่อ inventory ของคุณโดยไม่ต้องมี SDK แต่ละตัวในแอป คุณได้แรงกดดันการแข่งขันจากผู้เสนอราคาหลายรายพร้อมกับความเรียบง่ายของการรวม SDK ตัวเดียว

แนวทาง managed demand

พาร์ทเนอร์ managed demand นำแนวคิดนี้ไปไกลกว่าเดิม แทนที่จะรวม SDK หลายตัวด้วยตัวเอง คุณรวมจุดเชื่อมต่อเดียว — ผ่านแพลตฟอร์ม mediation ที่มีอยู่หรือผ่านการรวมฝั่งเซิร์ฟเวอร์ที่เบา พาร์ทเนอร์ managed จะรวม demand จากแหล่งต่างๆ มากมายบนโครงสร้างพื้นฐานของพวกเขา และแอปของคุณเห็นแค่แหล่ง demand เดียว ผลลัพธ์คือความหลากหลายของ demand ที่มากขึ้นโดยมีค่าใช้จ่าย SDK น้อยลง

ผู้เผยแพร่ที่ฉลาดที่สุดไม่ได้ถามว่า "ฉันเพิ่ม SDK ได้กี่ตัว" พวกเขาถามว่า "จำนวน SDK ขั้นต่ำที่ฉันต้องการเพื่อจับรายได้สูงสุดคือเท่าไร" คำตอบแทบจะเสมอน้อยกว่าที่พวกเขามีอยู่ในปัจจุบัน

ขั้นตอนปฏิบัติเพื่อลด SDK ที่บวม

1. ลบ SDK ที่มีประสิทธิภาพต่ำ

หาก SDK สร้างรายได้โฆษณารวมน้อยกว่า 5 เปอร์เซ็นต์ของคุณ ให้พิจารณาอย่างจริงจังในการลบออก ต้นทุนด้านประสิทธิภาพน่าจะสูงกว่าผลตอบแทนด้านรายได้

2. รวมศูนย์ผ่าน mediation

ใช้อะแดปเตอร์ในตัวของแพลตฟอร์ม mediation แทนการรวม SDK แบบแยกส่วนเมื่อทำได้ อะแดปเตอร์ mediation โดยทั่วไปเบากว่าการรวม SDK แบบเต็มรูปแบบ

3. ใช้ประโยชน์จาก server-side bidding

ย้ายพาร์ทเนอร์ด้าน demand ที่รองรับ server-side bidding ไปยังโมเดลนั้น การทำเช่นนี้จะลบ SDK ออกจากแอปของคุณในขณะที่ยังคง demand ของพวกเขาไว้ใน waterfall ของคุณ

4. ใช้พาร์ทเนอร์ managed สำหรับ demand เฉพาะทาง

แทนที่จะรวม SDK เฉพาะทางห้าตัวสำหรับ demand ระดับภูมิภาคหรือเฉพาะด้าน ให้ใช้พาร์ทเนอร์ managed เพียงรายเดียวที่รวม demand เหล่านั้นฝั่งเซิร์ฟเวอร์

การวัดผลกระทบ

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