ყოველი სარეკლამო SDK, რომელსაც თქვენს აპლიკაციაში აინტეგრირებთ, ფარულ ხარჯებს ატარებს. თითოეული მათგანი ზრდის binary size-ს, აგრძელებს cold start-ის დროს, შესაძლო თავსებადობის კონფლიქტებს იწვევს და კიდევ ერთ დამოკიდებულებას ქმნის, რომელიც განახლებას მოითხოვს ახალი ოპერაციული სისტემის ვერსიების გამოშვებისას. გამომცემლებისთვის, რომლებიც ხუთ, რვა ან თორმეტ SDK-ს იყენებენ, კუმულაციური გავლენა აპლიკაციის მუშაობასა და მომხმარებლის გამოცდილებაზე შეიძლება მნიშვნელოვანი იყოს — და ხშირად უხილავია, რადგან თანდათანობით ხდება.
SDK-ის გადატვირთვის რეალური ფასი
ყოველი მეგაბაიტი, რომელიც თქვენი აპლიკაციის binary-ს ემატება, მნიშვნელოვანია. კვლევები თანმიმდევრულად აჩვენებს, რომ აპლიკაციის ინსტალაციის კონვერსიის მაჩვენებლები შესამჩნევად იკლებს ჩამოტვირთვის ზომის ყოველ დამატებით მეგაბაიტთან ერთად. განვითარებად ბაზრებზე, სადაც მომხმარებლებს შეზღუდული მეხსიერება და ნელი კავშირი აქვთ, გავლენა კიდევ უფრო გამოხატულია. გამომცემელი, რომელიც სამ სარეკლამო SDK-ს ამატებს ჯამში 15 მეგაბაიტით, შესაძლოა შემცირებული ინსტალაციებიდან მეტ შემოსავალს კარგავდეს, ვიდრე ამ SDK-ების მიერ მოწოდებული დამატებითი მოთხოვნიდან იძენს.
ჩამოტვირთვის ზომის გარდა, SDK-ები მუშაობის რესურსებს მოიხმარს. ყოველი SDK, რომელიც აპლიკაციის გაშვებისას ინიციალიზდება, თქვენს გაშვების დროს ზრდის. მომხმარებლები, რომლებიც სამ წამზე მეტს ელოდებიან აპლიკაციის ჩატვირთვას, მნიშვნელოვნად უფრო ხშირად ტოვებენ მას. და ყოველი SDK, რომელიც ფონურ რეჟიმში მუშაობს, მეხსიერებასა და ბატარეას მოიხმარს — რესურსებს, რომლებსაც მომხმარებლები ამჩნევენ და რომელთა გამოც პლატფორმის აპლიკაციების მაღაზიები სულ უფრო მეტად აჯარიმებენ.
SDK-ის აუდიტი
დაიწყეთ თქვენი მიმდინარე SDK სტეკის აუდიტით. თქვენს აპლიკაციაში ყოველი სარეკლამო SDK-ისთვის გაზომეთ სამი რამ: binary size, რომელსაც ამატებს, შემოსავალი, რომელსაც გამოიმუშავებს, და მისი fill rate. თითქმის აუცილებლად აღმოაჩენთ, რომ ერთი ან ორი SDK პასუხისმგებელია თქვენი შემოსავლების უმეტესობაზე, ხოლო რამდენიმე სხვა მინიმალურად წვლილს შეაქვს, მაგრამ მნიშვნელოვან დატვირთვას ამატებს.
80/20 წესი მოქმედებს
გამომცემლების უმეტესი აპლიკაციებში ორიდან სამ სარეკლამო SDK სარეკლამო შემოსავლების 80 პროცენტს ან მეტს გამოიმუშავებს. დანარჩენი SDK-ები ხარვეზებს ავსებს, მაგრამ ხშირად ისეთ ფასად, რომელიც აღემატება მათ წვლილს, როდესაც მუშაობაზე გავლენას გაითვალისწინებთ. მიზანი არ არის ყველა SDK-ის აღმოფხვრა — მიზანია იმ მინიმალური ნაკრების პოვნა, რომელიც მაქსიმალურ შემოსავალს უზრუნველყოფს.
სერვერული გადაწყვეტილებები
SDK-ების რაოდენობის შემცირების ყველაზე ეფექტური გზა მოთხოვნის მრავალფეროვნების დაკარგვის გარეშე არის მოთხოვნის აგრეგაციის კლიენტის მხრიდან სერვერის მხარეზე გადატანა. მაგალითად, Google-ის Open Bidding საშუალებას აძლევს მრავალ მოთხოვნის პარტნიორს კონკურენცია გაუწიონ თქვენს ინვენტარს მათი ინდივიდუალური SDK-ების თქვენს აპლიკაციაში ინტეგრაციის გარეშე. თქვენ იღებთ მრავალი ბიდერის კონკურენტულ ზეწოლას ერთი SDK ინტეგრაციის სიმარტივით.
მართული მოთხოვნის მიდგომა
მართული მოთხოვნის პარტნიორი ამ კონცეფციას უფრო შორს მიჰყავს. მრავალი SDK-ის თავად ინტეგრაციის ნაცვლად, თქვენ ერთ შეერთების წერტილს აინტეგრირებთ — თქვენი არსებული mediation პლატფორმის მეშვეობით ან მსუბუქი სერვერული ინტეგრაციით. მართული პარტნიორი ათობით წყაროდან აგრეგირებს მოთხოვნას თავის ინფრასტრუქტურაზე, და თქვენი აპლიკაცია მხოლოდ ერთ მოთხოვნის წყაროს ხედავს. შედეგია მეტი მოთხოვნის მრავალფეროვნება ნაკლები SDK-ის დატვირთვით.
ყველაზე ჭკვიანი გამომცემლები არ კითხულობენ „რამდენი SDK შემიძლია დავამატო?“ ისინი კითხულობენ „რა არის SDK-ების მინიმალური რაოდენობა, რომელიც მჭირდება მაქსიმალური შემოსავლის მისაღებად?“ პასუხი თითქმის ყოველთვის იმაზე ნაკლებია, რაც ამჟამად აქვთ.
SDK-ის გადატვირთვის შემცირების პრაქტიკული ნაბიჯები
1. წაშალეთ არაეფექტური SDK-ები
თუ SDK თქვენი სარეკლამო შემოსავლების 5 პროცენტზე ნაკლებს გამოიმუშავებს, სერიოზულად განიხილეთ მისი ამოშლა. მუშაობის ხარჯი სავარაუდოდ აღემატება შემოსავლის წვლილს.
2. კონსოლიდაცია mediation-ით
გამოიყენეთ თქვენი mediation პლატფორმის ჩაშენებული ადაპტერები დამოუკიდებელი SDK ინტეგრაციების ნაცვლად, სადაც ეს შესაძლებელია. mediation ადაპტერები, როგორც წესი, უფრო მსუბუქია, ვიდრე სრული SDK ინტეგრაციები.
3. გამოიყენეთ სერვერული bidding
გადაიყვანეთ მოთხოვნის პარტნიორები, რომლებიც სერვერულ bidding-ს მხარს უჭერენ, ამ მოდელზე. ეს მათ SDK-ს თქვენი აპლიკაციიდან ამოშლის, ხოლო მათ მოთხოვნას თქვენს waterfall-ში ინარჩუნებს.
4. გამოიყენეთ მართული პარტნიორი ნიშური მოთხოვნისთვის
რეგიონული ან სპეციალიზებული მოთხოვნისთვის ხუთი ნიშური SDK-ის ინტეგრაციის ნაცვლად, გამოიყენეთ ერთი მართული პარტნიორი, რომელიც ამ მოთხოვნას სერვერის მხარეზე აგრეგირებს.
გავლენის გაზომვა
SDK-ების რაოდენობის შემცირების შემდეგ, დააკვირდით სამ მეტრიკას: აპლიკაციის ზომის შემცირება, გაშვების დროის გაუმჯობესება და სარეკლამო შემოსავლების ჯამი. კარგად განხორციელებული SDK-ის შემცირება უნდა აჩვენოს შესამჩნევი გაუმჯობესებები პირველ ორში, მესამეში მნიშვნელოვანი ცვლილების გარეშე — ან თუნდაც გაუმჯობესებით — რადგან შემცირებული აპლიკაციის ზომა იწვევს ინსტალაციის უფრო მაღალ მაჩვენებლებსა და მომხმარებლის უკეთეს შენარჩუნებას.