რეკლამის მედიაციის პლატფორმების შეცვლა: ნაბიჯ-ნაბიჯ მიგრაციის სახელმძღვანელო გამომცემლებისთვის

როდის დადგება მედიაციის პლატფორმის მიგრაციის დრო?

რეკლამის მედიაციის პლატფორმების შეცვლა მობილური გამომცემლისთვის ყველაზე მნიშვნელოვანი გადაწყვეტილებებიდან ერთ-ერთია. მედიაციის ფენა აკონტროლებს, რომელ რეკლამებს ხედავენ თქვენი მომხმარებლები, რამდენს გამოიმუშავებთ თითო შთაბეჭდილებაზე და რამდენად გლუვად მიმდინარეობს თქვენი რეკლამის გამოცდილება. მიგრაცია რეალურ რისკს ატარებს, მაგრამ სუბოპტიმალურ პლატფორმაზე დარჩენა ყოველდღიურად მზარდ კომბინირებულ ხარჯს ქმნის.

მკაფიო სიგნალები, რომ დადგა გადაადგილების შეფასების დრო:

• eCPM-ის ვარდნა ბაზრის ახსნის გარეშე: თუ თქვენი eCPM მცირდება, ხოლო ინდუსტრიის ბენჩმარქები სტაბილური რჩება, თქვენს მიმდინარე პლატფორმას შეიძლება ჰქონდეს მოთხოვნის ხარვეზები ან ოპტიმიზაციის პრობლემები, რომლებიც ახალმა მოთამაშეებმა გადაჭრეს.
• სხვა ადგილას ბიდინგის უკეთესი მხარდაჭერა: თუ თქვენი მიმდინარე პლატფორმა 3 ბიდინგ-პარტნიორს უჭერს მხარს, მაგრამ კონკურენტი 8-ს, თქვენ აუქციონის სიმჭიდროვეს (და შემოსავალს) კარგავთ.
• SDK-ის დეპრეცირება: როდესაც თქვენი მედიაციის პლატფორმა SDK-ის მხარდაჭერის დასრულებას ან ახალი ფუნქციების შეჩერებას აცხადებს, მიგრაცია სავალდებულოა. ეს "თუ"-ს კი არ ეხება, არამედ "როდის"-ს.
• რეკლამის ფორმატების ნაკლებობა: თუ თქვენი პლატფორმა არ უჭერს მხარს app open ads-ს, rewarded interstitials-ს ან native bidding-ს, ხოლო კონკურენტები ამას სთავაზობენ, ყოველი ნაკლული ფორმატი დაკარგულ შემოსავალს წარმოადგენს.
• ანგარიშგების შეზღუდვები: თუ ვერ იღებთ დეტალურ eCPM მონაცემებს ქსელის, გეოგრაფიის, რეკლამის ერთეულისა და ფორმატის მიხედვით, ბრმად ფრინავთ. თანამედროვე პლატფორმები ამას სტანდარტულად გთავაზობენ.

მიგრაციის დაგეგმვა: პარალელური ტესტირების მიდგომა

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

პარალელური სტრატეგია შემდეგნაირად მუშაობს:

• ფაზა 1 (დაყენება): ახალი მედიაციის SDK-ის ინტეგრირება არსებულ SDK-თან ერთად. ორივე პლატფორმაში იდენტური რეკლამის ერთეულების, მოთხოვნის წყაროებისა და მინიმალური ფასების კონფიგურაცია.
• ფაზა 2 (ტრაფიკის გაყოფა): ტრაფიკის 10–20%-ის გადამისამართება ახალ პლატფორმაზე, ხოლო 80–90%-ის შენახვა არსებულ პლატფორმაზე. გაყოფის კონტროლისთვის გამოიყენეთ remote config დროშა ან A/B ტესტირების ფრეიმვორქი.
• ფაზა 3 (მონიტორინგი): ორივე პლატფორმის ერთდროული მუშაობა სულ მცირე 2 კვირის განმავლობაში, eCPM-ის, შევსების მაჩვენებლის, დაყოვნებისა და კრაშ-მაჩვენებლის შედარება გაყოფაში.
• ფაზა 4 (მასშტაბირება): თუ ახალი პლატფორმა ძველს აღემატება ან თანაბარია, თანდათან გაზარდეთ ტრაფიკის წილი: 20%-იდან 50%-მდე, 80%-მდე, 100%-მდე.
• ფაზა 5 (გასუფთავება): ძველი მედიაციის SDK-ისა და დაკავშირებული კონფიგურაციების წაშლა, როდესაც ტრაფიკის 100% სულ მცირე ერთი კვირის განმავლობაში სტაბილური შესრულებით ახალ პლატფორმაზე იქნება.

გადასვლამდე საჭირო მონაცემები

ნებისმიერი მიგრაციის დაწყებამდე, ექსპორტი გაუკეთეთ და დააფიქსირეთ ყოვლისმომცველი საბაზისო მონაცემები თქვენი მიმდინარე პლატფორმიდან. ეს მონაცემები ორი მიზნით გამოიყენება: ის ახალი პლატფორმის შეფასებისთვის შედარების ბენჩმარქებს გთავაზობს და ახალი waterfall-ის ან ბიდინგის საწყისი კონფიგურაციის საფუძველია.

აუცილებელი მონაცემების წერტილები

• eCPM ისტორია ქსელის და გეოგრაფიის მიხედვით: მინიმუმ, ბოლო 90 დღის ყოველდღიური eCPM ქვეყნის ან ქვეყნების ჯგუფის მიხედვით დაყოფილი, თითოეული მოთხოვნის წყაროსთვის. ეს გეტყვით, რომელი ქსელები რომელ ბაზრებში მუშაობს კარგად და ახალი waterfall-ის დალაგებას განსაზღვრავს.
• შევსების მაჩვენებელი ქსელის და რეკლამის ფორმატის მიხედვით: მაღალი eCPM-ის, მაგრამ 5%-იანი შევსების მქონე ქსელი განსხვავებულ წვლილს შეაქვს, ვიდრე ზომიერი eCPM-ისა და 90%-იანი შევსების ქსელი. ზუსტი კონფიგურაციისთვის ორივე მეტრიკაა საჭირო.
• შთაბეჭდილების მოცულობა რეკლამის ერთეულის მიხედვით: გაიგეთ, რომელი რეკლამის განთავსებები ყველაზე მეტ შთაბეჭდილებას ქმნის. ეს არის თქვენი ყველაზე დიდი გავლენის მქონე ერთეულები, რომლებიც ბოლოს უნდა გადაიტანოთ რისკის მინიმიზაციისთვის.
• დაყოვნების მონაცემები: თუ ხელმისაწვდომია, დააფიქსირეთ საშუალო რეკლამის ჩატვირთვის დრო და ვადის ამოწურვის მაჩვენებელი ქსელის მიხედვით. ეს ახალ პლატფორმაში შესაბამისი ვადის მნიშვნელობების დასაყენებლად გეხმარებათ.
• შემოსავალი კვირის დღისა და დღის დროის მიხედვით: რეკლამის ბაზრებს კვირეული და ყოველდღიური ციკლები აქვს. ამ შაბლონის დაფიქსირება უზრუნველყოფს, რომ ნორმალურ ციკლურ ცვლილებას მიგრაციასთან დაკავშირებულ ცვლილებად არ ჩათვლით.

სასარგებლო დამატებითი მონაცემები

• კოჰორტის მიხედვით ARPDAU მომხმარებლის დონეზე
• სესიის დონეზე რეკლამის სიხშირის მონაცემები
• კრაშ და ANR მაჩვენებლები, რეკლამის SDK-ის აქტივობასთან კორელაციაში
• დეტალური bid-დონის ჟურნალები, თუ თქვენი მიმდინარე პლატფორმა ამას გვთავაზობს

ნაბიჯ-ნაბიჯ მიგრაციის პროცესი

ნაბიჯი 1: ახალი მედიაციის SDK-ის დაყენება

დაამატეთ ახალი მედიაციის SDK და ყველა საჭირო ადაპტერის SDK თქვენს პროექტში. ჯერ ძველ SDK-ს ნუ წაშლით. ორივე პარალელური ტესტირების ფაზის განმავლობაში ერთად იარსებებს. ძირითადი ქმედებები:

• core mediation SDK-ის dependency-ის დამატება
• გამოყენებას დაგეგმილი თითოეული მოთხოვნის წყაროსთვის ადაპტერის SDK-ების დამატება
• ახალი SDK-ის ინიციალიზაცია Application class-ში ან AppDelegate-ში, remote config დროშის მიღმა
• Build-ის კომპილაციის შემოწმება ძველ და ახალ SDK-ებს შორის კონფლიქტების გარეშე

ნაბიჯი 2: რეკლამის ერთეულებისა და მოთხოვნის წყაროების კონფიგურაცია

ახალი პლატფორმის dashboard-ში, ხელახლა შექმენით რეკლამის ერთეულის კონფიგურაცია:

• შეექმენით რეკლამის ერთეულები, რომლებიც შეესაბამება თქვენს არსებულ განთავსებებს (იგივე ფორმატი, ბანერებისთვის განახლების იგივე ინტერვალი)
• დაამატეთ ყველა მოთხოვნის წყარო მათი შესაბამისი app ID-ებითა და placement ID-ებით
• ძველი პლატფორმის eCPM ისტორიის საფუძველზე დააყენეთ საწყისი მინიმალური ფასები
• ჩართეთ ბიდინგი ყველა მხარდამჭერი წყაროსთვის; დანარჩენებისთვის კი waterfall ჩანაწერების კონფიგურაცია გაუკეთეთ

ნაბიჯი 3: ტრაფიკის გაყოფის განხორციელება

გამოიყენეთ remote configuration სისტემა (Firebase Remote Config, საკუთარი feature flag სისტემა, ან მარტივი server-side toggle), რათა გააკონტროლოთ, რომელი მედიაციის SDK ამუშავებს თითოეულ სესიას:

• აპლიკაციის გაშვებისას, შეამოწმეთ remote დროშა, რათა განსაზღვროთ, რომელი SDK აქტიურია ამ სესიისთვის
• მოითხოვეთ რეკლამები მხოლოდ მთელი სესიის განმავლობაში აქტიური SDK-ის მეშვეობით. ნუ შეურევთ SDK-ებს ერთ სესიაში.
• ჩაწერეთ, რომელი SDK აქტიურია თქვენს ანალიტიკაში, რათა შეგეძლოთ შესრულების მონაცემების სუფთა სეგმენტირება

ნაბიჯი 4: პარალელური გაშვება მინიმუმ ორი კვირის განმავლობაში

ორი კვირა მინიმალური შეფასების პერიოდია. ეს ხანგრძლივობა ჭერს სამუშაო კვირისა და შაბათ-კვირის შაბლონებს, ითვალისწინებს მოთხოვნის რყევას და ბიდინგის ალგორითმებს თქვენი ინვენტარის შესწავლის დროს აძლევს. ამ პერიოდში:

• ყოველდღიურად თვალი ადევნეთ eCPM-ს, შევსების მაჩვენებელს და მთლიან შემოსავალს ორივე ჯგუფისთვის
• ყოველ ორ ჯგუფში გამოავლინეთ აპლიკაციის სტაბილობის მეტრიკები (კრაშ-მაჩვენებელი, ANR-მაჩვენებელი)
• დააკვირდით მომხმარებლის გამოცდილების პრობლემებს (ნელი რეკლამის ჩატვირთვა, ცარიელი რეკლამის ჩარჩოები, მოულოდნელი სრულეკრანიანი რეკლამები)
• ამ პერიოდში არ შეცვალოთ კონფიგურაცია არცერთ პლატფორმაში, გარდა იმ შემთხვევებისა, როდესაც რაღაც აშკარად გაუმართავია

ნაბიჯი 5: შედარება და გადაწყვეტილება

პარალელური პერიოდის შემდეგ, შეადარეთ ორი პლატფორმა ამ განზომილებებში:

• შემოსავალი DAU-ზე: მთავარი მეტრიკა. თუ ახალი პლატფორმა ყოველდღიური აქტიური მომხმარებლისგან ტოლ ან მეტ შემოსავალს ქმნის, ის ძირითად ტესტს გადის.
• შევსების მაჩვენებელი: შევსების მაღალი მაჩვენებელი ნიშნავს მეტი შთაბეჭდილების მონეტიზაციას. 5%-ით მაღალი შევსებისა და მსგავსი eCPM-ის მქონე ახალი პლატფორმა აშკარა გამარჯვებულია.
• დაყოვნება: რეკლამის სწრაფი ჩატვირთვა ნიშნავს უკეთეს viewability-სა და მომხმარებლის გამოცდილებას.
• სტაბილობა: თუ ახალი SDK კრაშ-მაჩვენებელს ზრდის, შეიძლება შემოსავლის ზრდა არ ღირდეს.

ნაბიჯი 6: სრული გადასვლა და გასუფთავება

ახალ პლატფორმაზე გადაწყვეტილების მიღების შემდეგ, ტრაფიკი გაზარდეთ 100%-მდე, კიდევ 5–7 დღე დააკვირდით, შემდეგ კი მთლიანად ამოიღეთ ძველი SDK. განაახლეთ dependency-ების სია, ამოიღეთ ძველი ინიციალიზაციის კოდი და გაასუფთავეთ ტრაფიკის გაყოფასთან დაკავშირებული ყველა პირობითი ლოგიკა.

მედიაციის მიგრაციაში გავრცელებული ხარვეზები

კარგად დაგეგმილი მიგრაციებიც კი პრობლემებს წააწყდება. გავრცელებული ხარვეზების ცოდნა დაგეხმარებათ მათ თავიდან აცილებაში ან სწრაფ გამოსწორებაში:

• ისტორიული ოპტიმიზაციის მონაცემების დაკარგვა: ძველ პლატფორმაზე ბიდინგის ალგორითმებს თქვენი ინვენტარის თვეობით მონაცემები აქვს. ახალი პლატფორმა ცივი ეკიდება. მოელოდეთ 1–2 კვირიანი სუბოპტიმალური შესრულებას ალგორითმების სწავლისას.
• SDK-ის კონფლიქტები: ორი მედიაციის SDK-ის ერთდროულ გამოყენებას შეიძლება dependency კონფლიქტები გამოიწვიოს, განსაკუთრებით თუ ორივე შეიცავს ერთიდაიგივე მოთხოვნის წყაროს SDK-ებს სხვადასხვა ვერსიებში. სრულად გატესტეთ staging build-ში production-ში გაშვებამდე.
• არათანხვედრილი მინიმალური ფასები: ახალ პლატფორმაში ძალიან მაღალი floor-ების დაყენება კლავს შევსების მაჩვენებელს. ძალიან დაბლის დაყენება ტოვებს ფულს მაგიდაზე. გამოიყენეთ ისტორიული მონაცემები საწყის წერტილად და პირველი კვირის შემდეგ მიუწყვეთ.
• არათანაბარი დროის პერიოდების შედარება: რეკლამის ბაზრები რყეობს. სამი თვის წინანდელ ძველ პლატფორმის პირველ კვირასთან ახალი პლატფორმის პირველი კვირის შედარება ვალიდური შედარება არ არის. პარალელური ტესტირება ამ პრობლემას გამორიცხავს.
• ვადის დაჩქარება: სწრაფი შედეგების ჩვენების ზეწოლა ნაადრევ დასკვნებამდე მიდის. ორი კვირის პარალელური მონაცემები მინიმუმია. ოთხი კვირა უკეთესია მნიშვნელოვანი ტრაფიკის მქონე გამომცემლებისთვის.

AdMob Mediation-იდან Google Ad Manager-ზე მიგრაცია

ყველაზე გავრცელებული მიგრაციის გზა AdMob mediation-იდან სრულ Google Ad Manager პლატფორმაზე გადასვლაა. ეს განახლება GAM-ის მასშტაბური გამომცემლებისთვის უპირატესი ფუნქციებით არის გამოწვეული:

• პირდაპირი გარიგებების მხარდაჭერა: GAM საშუალებას იძლევა პირდაპირ გაყიდულ კამპანიებს programmatic მოთხოვნასთან ერთად კონკურენცია გაუწიონ, რისი მხარდაჭერაც AdMob mediation-ს არ გააჩნია
• გაფართოებული ანგარიშგება: GAM გრანულარულ ანგარიშგებას გთავაზობს line item-ის, რეკლამის განმთავსებლის, კრეატივისა და პერსონალური განზომილებების მიხედვით
• Open Bidding: GAM-ის server-side ბიდინგი exchange პარტნიორების უფრო ფართო სპექტრს უჭერს მხარს, ვიდრე AdMob-ის client-side mediation
• ერთიანი ფასწარმოქმნის წესები: ყველა მოთხოვნის წყაროს განმავლობაში გეო, მოწყობილობისა და ფორმატის გრანულარობით დააყენეთ მინიმალური ფასები ერთი ინტერფეისიდან

ეს კონკრეტული მიგრაცია ხშირად RevenueFlex-ს ევალება. AdMob mediation-იდან სრულად მართულ GAM კონფიგურაციაზე გადასვლა მოიცავს GAM-ში მთელი რეკლამის კონფიგურაციის ხელახლა შექმნას, მოთხოვნის წყაროების მაპინგს, ისტორიული შესრულების საფუძველზე ახალი მინიმალური ფასების დადგენას და შემოსავლის ნეიტრალობის ან გაუმჯობესების დასადასტურებლად პარალელური შეფასების ჩატარებას. გამომცემლები, რომლებიც ამ გადასვლას სათანადო დაგეგმვით ახორციელებენ, ჩვეულებრივ ხედავენ 10–25%-იან შემოსავლის ზრდას GAM waterfall-ის სრული ოპტიმიზაციის შემდეგ.

მედიაციის მიგრაცია არ არის შაბათ-კვირის პროექტი. ეს მრავალკვირიანი პროცესია, რომელიც საჭიროებს ფრთხილ დაგეგმვას, დისციპლინირებულ პარალელურ ტესტირებას და მოთმინებას, სანამ ახალი ალგორითმები თქვენს ინვენტარს ისწავლიან. მაგრამ სუბოპტიმალური პლატფორმის მქონე გამომცემლებისთვის, შეცვლის გრძელვადიანი შემოსავლის გავლენა მოკლევადიან ძალისხმევას ამართლებს.