გამოსცადეთ AdMob-ის რეკლამები VPN-ზე ანგარიშის რისკის გარეშე

გსურთ იცოდეთ, გაუძლებს თუ არა თქვენი რეკლამის ინტეგრაცია იმ ქსელს, რომელიც თქვენს მომხმარებლებს რეალურად აქვთ. VPN შორეული გასასვლელის ხელახლა შექმნის უმარტივესი გზაა. შეცდომა ის არის, რომ ეს ექსპერიმენტი შემოსავლის ექსპერიმენტად მივიჩნიოთ.

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

ამიტომ ჩაატარეთ ის კავშირის ტესტად დოკუმენტირებული თანმიმდევრობით და ცოცხალი მარაგი სრულიად მის გარეთ შეინახეთ. ქვემოთ მოცემული ნაბიჯები ყოველ build-ში გასამეორებელია.

გადაწყვიტეთ, რისთვის არის ტესტი

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

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

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

აფრენამდე: დაარეგისტრირეთ მოწყობილობა, არა მისამართი

Google-ის სატესტო რეკლამების დოკუმენტაცია ორ მხარდაჭერილ გზას გვთავაზობს. გამოიყენეთ დემო რეკლამის ერთეულები იმ ფორმატისთვის, რომელსაც ინტეგრირებთ, ან საკუთარი ერთეულები ფიზიკური მოწყობილობის სატესტო მოწყობილობად რეგისტრაციით. ორივე დოკუმენტირებულია პლატფორმისა და SDK თაობის მიხედვით, და Next-Gen და Legacy გიდები ურთიერთშენაცვლებადი არ არის.

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

RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))

დაადასტურეთ რეგისტრაცია ქსელის შეცვლამდე, თორემ ვერ გაარჩევთ წარუმატებელ შევსებას იმ მოწყობილობაზე მიწოდებული ცოცხალი რეკლამისგან, რომელიც არასდროს დარეგისტრირებულა. თუ რეკლამა აჩვენებს Test Ad ეტიკეტს, მოთხოვნა სატესტო მარაგში გავიდა; თუ არა, სხვა რამეს უყურებთ და არ უნდა შეეხოთ.

შეასრულეთ თანმიმდევრობა ფიქსირებული რიგით

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

ჯერ საბაზისო ხაზი. გამორთული VPN-ით ჩატვირთეთ განთავსება და დაადასტურეთ, რომ სატესტო რეკლამა ჩნდება. დაიჭირეთ მოთხოვნა logcat-ში adb logcat | grep -i ads -ით და ჩაწერეთ პასუხის კოდი. შევსების არარსებობა საბაზისო ხაზზე VPN-ის პრობლემა არ არის.

შემდეგ დაუკავშირდით და გაიმეორეთ. იგივე build, იგივე ერთეული, იგივე განთავსება, VPN ჩართული. დაიჭირეთ იგივე ლოგის სტრიქონები. რასაც ეძებთ, განსხვავებაა: შევსება, რომელიც დროის ამოწურვად იქცევა, მოთხოვნა, რომელიც არასდროს გადის, შეცდომის კოდი, რომელიც იცვლება. შევსებად დარჩენილი შევსება გეუბნებათ, რომ ამ გზაზე ინტეგრაცია რიგზეა და ტესტი დასრულდა.

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

მედიაცია ცალკე ტესტია

მედიირებულ რეკლამებს Google-ის Test Ad ეტიკეტი არ აქვს, რაც მათ ყველაზე მარტივ ადგილად აქცევს იმაზე დაჭერისთვის, რაზეც არ უნდა დაეჭირა. მედიაციის სტეკის თითოეულ ქსელს თავისი სატესტო რეჟიმი და თავისი კონფიგურაცია აქვს, და Google-ის სატესტო კონფიგურაცია მათზე არ ვრცელდება.

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

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

დაბრუნება და გამოშვების კარიბჭე

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

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

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