Open bidding მობილური აპლიკაციებისთვის header bidding-ის წინააღმდეგ: სრული სახელმძღვანელო

თუ აპლიკაციების მონეტიზაციის სფეროში გარკვეული დრო ხართ, აუცილებლად გსმენიათ ტერმინები "open bidding" და "header bidding" თითქმის როგორც სინონიმები. ორივეს ერთი და იგივე მიზანი აქვს — რეალურ დროში კონკურენციის შექმნა demand წყაროებს შორის, რათა eCPM-ები გაიზარდოს — მაგრამ ისინი სხვადასხვაგვარად მუშაობს კულისებში. ამ განსხვავებების გაგება არის თქვენი აპლიკაციისთვის სწორი მიდგომის არჩევის გასაღები.

რა არის header bidding?

Header bidding წარმოიშვა ვებ რეკლამიდან, სადაც გამომცემლები ამატებდნენ JavaScript კოდს თავიანთი ვებ გვერდების "header"-ში, რათა ერთდროულად მოეთხოვათ შეთავაზებები რამდენიმე demand პარტნიორისგან სარეკლამო გამოძახებამდე მათ მთავარ ad server-ში. ყველაზე მაღალი შეთავაზება იმარჯვებდა, რაც ქმნიდა ნამდვილ კონკურენციას და აღმოფხვრიდა თანმიმდევრული waterfall-ის პრობლემას, სადაც demand წყაროები გამოიძახება სათითაოდ.

მობილური აპლიკაციების კონტექსტში, header bidding მუშაობს კლიენტის მხარის SDK-ების მეშვეობით. ყოველ მონაწილე demand პარტნიორს აქვს SDK ინტეგრირებული თქვენს აპლიკაციაში. როცა სარეკლამო შესაძლებლობა ჩნდება, ყველა SDK გამოიძახება ერთდროულად, თითოეული აბრუნებს შეთავაზებას და ყველაზე მაღალი შეთავაზება იმარჯვებს. AppLovin MAX და Unity LevelPlay ორივე მხარს უჭერს ამ მოდელს in-app bidding ფუნქციების მეშვეობით.

რა არის open bidding?

Open bidding (ყოფილი Exchange Bidding) არის Google-ის სერვერის მხარის ალტერნატივა. იმის ნაცვლად, რომ აუქციონები ჩატარდეს მომხმარებლის მოწყობილობაზე რამდენიმე SDK-ის მეშვეობით, open bidding აუქციონს ატარებს Google-ის სერვერებზე. Demand პარტნიორები უკავშირდებიან Google-ის ინფრასტრუქტურას და წარადგენენ შეთავაზებებს სერვერიდან სერვერამდე, რაც ამოიღებს კლიენტის მხარეზე ცალკეული SDK ინტეგრაციის საჭიროებას.

Open bidding ხელმისაწვდომია Google Ad Manager-ის მეშვეობით და უზრუნველყოფს წვდომას Google-ის ვრცელ demand ეკოსისტემაზე, ასევე მესამე მხარის exchange-ებზე, რომლებიც შეუერთდნენ პროგრამას.

ძირითადი განსხვავებები

ლატენტობა

ეს არის ყველაზე მნიშვნელოვანი პრაქტიკული განსხვავება. კლიენტის მხარის header bidding-ისთვის საჭიროა, რომ თითოეულმა SDK-მ შეასრულოს ქსელის გამოძახება, დაამუშაოს აუქციონი და დააბრუნოს შეთავაზება — ყველაფერი მომხმარებლის მოწყობილობაზე. რაც მეტი SDK გაქვთ, მით მეტი დამუშავების დრო. Open bidding მუშაობს სერვერიდან სერვერამდე, რაც, როგორც წესი, უფრო სწრაფია და არ მოიხმარს მოწყობილობის რესურსებს. აპლიკაციებისთვის, სადაც რეკლამის ჩატვირთვის სიჩქარე პირდაპირ გავლენას ახდენს მომხმარებლის გამოცდილებაზე, ეს მნიშვნელოვანია.

SDK-ის სირთულე

ყოველი header bidding პარტნიორი მოითხოვს SDK ინტეგრაციას თქვენს აპლიკაციაში. მეტი SDK ნიშნავს უფრო დიდ აპლიკაციის binary-ს, მეტ პოტენციალს SDK-ებს შორის კონფლიქტებისთვის და მეტ მომსახურების ხარჯებს, როცა SDK-ების განახლება აუცილებელია. Open bidding მოითხოვს მხოლოდ Google Mobile Ads SDK-ს, ხოლო demand პარტნიორები უკავშირდებიან სერვერის მხარეს. ეს მნიშვნელოვნად ამცირებს ტექნიკურ სირთულეს.

Demand-ის მრავალფეროვნება

Header bidding ისეთი პლატფორმების მეშვეობით, როგორიცაა AppLovin MAX, გაძლევთ წვდომას ფართო სარეკლამო ქსელების სპექტრზე, რომელთაგან თითოეულს აქვს საკუთარი სარეკლამო ურთიერთობები და demand. Open bidding გაძლევთ წვდომას Google-ის demand-ზე პლუს მონაწილე exchange-ებზე, მაგრამ მონაწილე პარტნიორების რაოდენობა უფრო მცირეა, ვიდრე ის, რაც ხელმისაწვდომია კლიენტის მხარის bidding-ის მეშვეობით. ოპტიმალური მიდგომა ხშირად მოიცავს ორივეს.

გამჭვირვალობა

კლიენტის მხარის header bidding გაძლევთ სრულ ხილვადობას თითოეული პარტნიორის შეთავაზებაზე რეალურ დროში. შეგიძლიათ ზუსტად ნახოთ რა შემოგთავაზა თითოეულმა ქსელმა, ვინ გაიმარჯვა და რატომ. Open bidding უზრუნველყოფს ანგარიშგებას GAM-ის მეშვეობით, მაგრამ აუქციონი ხდება Google-ის სერვერებზე, რაც გაძლევთ ოდნავ ნაკლებ დეტალურ რეალურ დროში ხილვადობას bidding პროცესზე.

რომელი უნდა აირჩიოთ?

გულწრფელი პასუხი: ყველაზე წარმატებული გამომცემლები იყენებენ ორივეს. აი პრაქტიკული ჩარჩო:

გამოიყენეთ open bidding GAM-ის მეშვეობით, როგორც თქვენი მთავარი აუქციონის მექანიზმი. ის უზრუნველყოფს ძლიერ demand-ს მინიმალური SDK ზედნადები ხარჯებით და რეკლამის სწრაფი ჩატვირთვით. შემდეგ შეავსეთ კლიენტის მხარის bidding-ით ორი-სამი საუკეთესო ქსელიდან თქვენი mediation პლატფორმის მეშვეობით (AppLovin MAX ან Unity LevelPlay), რათა უზრუნველყოთ demand-ის მაქსიმალური მრავალფეროვნება.

გამომცემლები, რომლებიც ქმნიან ყველაზე მაღალ სარეკლამო შემოსავალს, არ ირჩევენ open bidding-სა და header bidding-ს შორის — ისინი აერთიანებენ ორივეს ჰიბრიდულ მიდგომაში, რომელიც მაქსიმალურად ზრდის კონკურენციას და ტექნიკურ სირთულეს ინარჩუნებს მართვადად.

ჰიბრიდული მიდგომა პრაქტიკაში

ტიპიურ ჰიბრიდულ კონფიგურაციაში, თქვენი waterfall გამოიყურება ასე: open bidding GAM-ის მეშვეობით კონკურენციას უწევს ორ-სამ in-app bidding ქსელს. მის ქვეშ გაქვთ ტრადიციული waterfall ჩანაწერები ქსელებისთვის, რომლებიც არ უჭერენ მხარს რეალურ დროში bidding-ს. მართული demand პარტნიორი შეიძლება იყოს ამ stack-ის ნებისმიერ დონეზე, უზრუნველყოფს დამატებით კონკურენციას, რაც სარგებელს მოუტანს თქვენს საერთო yield-ს.

მთავარია არ გართულდეს ზედმეტად. დაიწყეთ open bidding-ით GAM-ის მეშვეობით, დაამატეთ თქვენი mediation პლატფორმის საუკეთესო bidding პარტნიორები და იმუშავეთ მართულ პარტნიორთან, რათა შეავსოთ ხარვეზები. შემდეგ ოპტიმიზაცია გააკეთეთ მონაცემების მიხედვით.