לכל ad SDK שאתם משלבים באפליקציה שלכם יש עלות נסתרת. כל אחד מגדיל את גודל ה-binary, מאריך את זמן ה-cold start, מכניס קונפליקטים פוטנציאליים של תאימות ויוצר תלות נוספת שדורשת עדכון כשגרסאות מערכת הפעלה חדשות יוצאות. עבור publishers שמריצים חמישה, שמונה או אפילו שנים עשר SDK, ההשפעה המצטברת על ביצועי האפליקציה וחוויית המשתמש עלולה להיות משמעותית — והיא לעתים קרובות בלתי נראית כי היא מתרחשת בהדרגה.
העלות האמיתית של SDK bloat
כל מגה-בייט שמתווסף ל-binary של האפליקציה חשוב. מחקרים מראים באופן עקבי ששיעורי ההמרה של התקנות יורדים באופן מדיד עם כל מגה-בייט נוסף. בשווקים מתפתחים שבהם למשתמשים יש אחסון מוגבל וחיבורים איטיים יותר, ההשפעה חזקה עוד יותר. publisher שמוסיף שלושה ad SDK בסך הכול 15 מגה-בייט עשוי להפסיד יותר revenue מהתקנות שאבדו ממה שהוא מרוויח מהביקוש הנוסף שאותם SDK מספקים.
מעבר לגודל ההורדה, SDK צורכים משאבי ריצה משמעותיים בזמן אמת. כל SDK שמאותחל בעת השקת האפליקציה מוסיף ישירות לזמן ההפעלה הכולל שלכם. משתמשים שמחכים יותר משלוש שניות לטעינת אפליקציה נוטים באופן משמעותי יותר לנטוש אותה. וכל SDK שפועל ברקע צורך זיכרון וסוללה — משאבים שהמשתמשים מרגישים ושחנויות האפליקציות מענישות עליהם יותר ויותר.
ביקורת SDK
התחילו בביקורת של מערך ה-SDK הנוכחי שלכם. עבור כל ad SDK באפליקציה, מדדו שלושה דברים: גודל ה-binary שהוא מוסיף, ה-revenue שהוא מייצר וה-fill rate שלו. כמעט בוודאות תגלו שאחד או שניים מה-SDK אחראים לרוב ה-revenue שלכם, בעוד שכמה אחרים תורמים באופן שולי אבל מוסיפים עומס משמעותי.
כלל 80/20 חל כאן
ברוב אפליקציות ה-publishers, שניים עד שלושה ad SDK מייצרים 80 אחוז או יותר מסך ה-ad revenue. שאר ה-SDK ממלאים פערים אבל לעתים קרובות בעלות שעולה על תרומתם כשמביאים בחשבון את ההשפעה על הביצועים. המטרה היא לא לחסל את כל ה-SDK — אלא למצוא את הסט המינימלי שמביא את ה-revenue המקסימלי.
פתרונות בצד השרת
הדרך היעילה ביותר לצמצם את מספר ה-SDK מבלי לאבד מגוון ביקוש היא להעביר את איגום הביקוש מצד הלקוח לצד השרת. Open Bidding של Google, לדוגמה, מאפשר למספר demand partners להתחרות על המלאי שלכם ללא צורך ב-SDK הפרטיים שלהם באפליקציה. אתם מקבלים את הלחץ התחרותי של מספר מציעים עם הפשטות של אינטגרציית SDK יחידה.
גישת הביקוש המנוהל
שותף demand מנוהל לוקח את הרעיון הזה צעד קדימה. במקום לשלב מספר SDK בעצמכם, אתם משלבים נקודת חיבור אחת — דרך פלטפורמת ה-mediation הקיימת שלכם או דרך אינטגרציה קלילה בצד השרת. השותף המנוהל מאגם ביקוש מעשרות מקורות על התשתית שלו, והאפליקציה שלכם רואה רק מקור demand יחיד. התוצאה היא מגוון ביקוש רב יותר עם פחות עומס SDK.
ה-publishers החכמים ביותר לא שואלים "כמה SDK אני יכול להוסיף?" הם שואלים "מה מספר ה-SDK המינימלי שאני צריך כדי ללכוד את ה-revenue המקסימלי?" התשובה היא כמעט תמיד פחות ממה שיש להם כרגע.
צעדים מעשיים לצמצום SDK bloat
1. הסירו SDK שמתפקדים מתחת לציפיות
אם SDK מייצר פחות מ-5 אחוז מסך ה-ad revenue שלכם, שקלו ברצינות להסיר אותו. עלות הביצועים כנראה עולה על תרומת ה-revenue.
2. איחדו דרך mediation
השתמשו ב-adapters המובנים של פלטפורמת ה-mediation שלכם במקום אינטגרציות SDK עצמאיות כשהדבר אפשרי. Adapters של mediation הם בדרך כלל קלילים יותר מאינטגרציות SDK מלאות.
3. נצלו bidding בצד השרת
העבירו demand partners שתומכים ב-bidding בצד השרת למודל הזה. זה מסיר את ה-SDK שלהם מהאפליקציה שלכם תוך שמירה על הביקוש שלהם ב-waterfall.
4. השתמשו בשותף מנוהל עבור ביקוש long-tail
במקום לשלב חמישה SDK נישתיים עבור ביקוש אזורי או מתמחה, השתמשו בשותף מנוהל יחיד שמאגם את הביקוש הזה בצד השרת.
מדידת ההשפעה
לאחר צמצום מספר ה-SDK, עקבו אחרי שלושה מדדים: הקטנת גודל האפליקציה, שיפור זמן ההפעלה וסך ה-ad revenue. צמצום SDK שבוצע בצורה נכונה ומושכלת אמור להראות שיפורים מדידים וברורים בשני המדדים הראשונים ללא שינוי משמעותי — או אפילו שיפור ניכר — בשלישי, מכיוון שגודל אפליקציה קטן יותר מוביל באופן ישיר לשיעורי התקנה גבוהים יותר ולשימור משתמשים טוב יותר לאורך זמן.