તમારું ખાતું જોખમમાં મૂક્યા વિના VPN પર AdMob જાહેરાતોની કસોટી કરો
ઉપકરણ VPN પર હોય ત્યારે AdMob ની કસોટી કરવા માટેનું રનબુક: ટેસ્ટ ઉપકરણ નોંધો, એક વિનંતી પકડો, લેબલ ચકાસો અને રિલીઝ પહેલાં સફાઈ કરો.
તમે જાણવા માંગો છો કે તમારું જાહેરાત એકીકરણ તમારા વપરાશકર્તાઓ પાસે ખરેખર હોય તે નેટવર્ક પર ટકી રહે છે કે નહીં. દૂરના એક્ઝિટને ફરી ઊભો કરવાનો સૌથી સહેલો રસ્તો VPN છે. ભૂલ એ છે કે એ પ્રયોગને આવકનો પ્રયોગ ગણવો.
એક્ઝિટ દેશ બદલવાથી નવો પ્રેક્ષકવર્ગ બનતો નથી, અને તમારા પોતાના ટેપ લાયક ટ્રાફિકમાં ફેરવાતા નથી. તે ફક્ત વિનંતીનો માર્ગ બદલે છે.
તેથી દસ્તાવેજીકૃત ક્રમ સાથે તેને કનેક્ટિવિટી કસોટી તરીકે ચલાવો, અને જીવંત ઇન્વેન્ટરીને તેની સંપૂર્ણ બહાર રાખો. નીચેનાં પગલાં દરેક બિલ્ડમાં પુનરાવર્તન કરવા યોગ્ય છે.
કસોટી શેના માટે છે તે નક્કી કરો
બે પ્રશ્નો ભેગા થઈ જાય છે. પ્રથમ એ છે કે આપેલા નેટવર્ક માર્ગથી વિનંતી બિલકુલ સેવા પામે છે કે નહીં, જે એકીકરણ અને કનેક્ટિવિટીનો પ્રશ્ન છે. બીજો એ છે કે તે દેશના ખરા વપરાશકર્તાઓ કેટલું કમાશે, જે રિપોર્ટિંગ અને વ્યવસાયનો પ્રશ્ન છે જેનો જવાબ SDK તમારા વતી આપી શકતું નથી.
ફક્ત પ્રથમ જ ડેવલપમેન્ટ ઉપકરણથી કસોટી કરી શકાય છે. અંદાજિત કમાણી રિપોર્ટિંગ સમયગાળો પૂરો થાય તે પહેલાં પણ બદલાઈ શકે છે, તેથી જાતે બનાવેલા પ્રયોગ દરમિયાન જોયેલી સંખ્યા લાયક આવકનો પુરાવો પણ નથી અને બીજા કોઈ માટે આગાહી પણ નથી.
કનેક્ટ કરતાં પહેલાં પ્રશ્ન લખો: ઉદાહરણ તરીકે, આ બિલ્ડમાં ઉપકરણ જર્મનીથી બહાર જાય ત્યારે બેનર વિનંતી ભરણ આપે છે કે નહીં. જો તમને આવકનો આંકડો જવાબ જોઈએ છે, તો અહીં જ અટકો, કારણ કે કોઈ પણ VPN ગોઠવણી એવો આંકડો આપતી નથી.
ઉડાન પહેલાં: ઉપકરણ નોંધો, સરનામું નહીં
Google નું ટેસ્ટ-જાહેરાત દસ્તાવેજીકરણ બે સમર્થિત માર્ગો આપે છે. તમે જે ફોર્મેટનું એકીકરણ કરો છો તેના માટે ડેમો જાહેરાત એકમો વાપરો, અથવા ભૌતિક ઉપકરણને ટેસ્ટ ઉપકરણ તરીકે નોંધીને તમારા પોતાના એકમો વાપરો. બંને દરેક પ્લેટફોર્મ અને દરેક SDK પેઢી માટે દસ્તાવેજીકૃત છે, અને Next-Gen અને Legacy માર્ગદર્શિકાઓ એકબીજાના બદલામાં વાપરી શકાતી નથી.
નોંધણી એ ઉપકરણ ઓળખકર્તા છે, અને તેનો નેટવર્ક સરનામા સાથે કોઈ સંબંધ નથી. ફોનનો ટ્રાફિક ક્યાંથી બહાર જાય છે તે બદલવાથી કંઈ નોંધાતું નથી. Android પર ઓળખકર્તા SDK લોગ કરે છે, અને તમે તેને કોડમાં લાગુ કરો છો:
RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("YOUR_TEST_DEVICE_ID"))
નેટવર્ક બદલતાં પહેલાં નોંધણીની પુષ્ટિ કરો, નહીં તો નિષ્ફળ ભરણ અને જે ઉપકરણ કદી નોંધાયું જ નહોતું તેને આપવામાં આવેલી જીવંત જાહેરાત વચ્ચે તમે ભેદ કરી શકશો નહીં. જો જાહેરાત Test Ad લેબલ દર્શાવે, તો વિનંતી ટેસ્ટ ઇન્વેન્ટરીમાંથી ગઈ છે; જો ન દર્શાવે, તો તમે બીજું કંઈક જોઈ રહ્યા છો અને તેને ટેપ કરવું ન જોઈએ.
ક્રમ નિશ્ચિત ક્રમમાં ચલાવો
નેટવર્ક સિવાય બધું સ્થિર રાખો. એ જ બિલ્ડ, એ જ જાહેરાત એકમ, એ જ સ્થાન, એ જ એપ સ્થિતિ. બે ચલ બદલશો તો તમને કંઈ શીખવા મળશે નહીં.
પહેલાં બેઝલાઇન. VPN ડિસ્કનેક્ટ કરીને સ્થાન લોડ કરો અને ટેસ્ટ જાહેરાત દેખાય છે તેની પુષ્ટિ કરો. logcat માં adb logcat | grep -i ads વડે વિનંતી પકડો અને પ્રતિસાદ કોડ નોંધો. બેઝલાઇન પર ભરણ ન મળવું તે VPN ની સમસ્યા નથી.
પછી જોડાઓ અને પુનરાવર્તન કરો. એ જ બિલ્ડ, એ જ એકમ, એ જ સ્થાન, VPN ચાલુ. એ જ લોગ લાઇનો પકડો. તમે જે શોધી રહ્યા છો તે તફાવત છે: ટાઇમઆઉટમાં ફેરવાતું ભરણ, કદી બહાર ન નીકળતી વિનંતી, બદલાતો એરર કોડ. ભરણ રહેતું ભરણ તમને કહે છે કે તે માર્ગ પર એકીકરણ ઠીક છે અને કસોટી પૂરી થઈ.
પર્યાવરણ નોંધો. SDK આવૃત્તિ, એડેપ્ટર આવૃત્તિઓ, બિલ્ડ પ્રકાર, જાહેરાત ફોર્મેટ, એક્ઝિટ દેશ અને જોયેલું પરિણામ. તે નોંધ વિના આગળની વ્યક્તિ પ્રયોગ શૂન્યથી પુનરાવર્તિત કરે છે અને એ જ પુરાવાઓમાંથી અલગ તારણ પર પહોંચે છે.
મિડિયેશન અલગ કસોટી છે
મિડિયેટેડ જાહેરાતો Google નું Test Ad લેબલ ધરાવતી નથી, જે તેમને એવી વસ્તુ પર ક્લિક કરવાનું સૌથી સહેલું સ્થળ બનાવે છે જે તમારે ન કરવું જોઈએ. મિડિયેશન સ્ટેકનું દરેક નેટવર્ક પોતાની ટેસ્ટ સ્થિતિ અને પોતાની ગોઠવણી ધરાવે છે, અને Google ની ટેસ્ટ ગોઠવણી તેમના સુધી લંબાતી નથી.
એડેપ્ટરોને એક વખતે એક તપાસો, એડેપ્ટરની પોતાની ટેસ્ટ સ્થિતિ ચાલુ રાખીને, અને લોગ પરથી પુષ્ટિ કરો કે કયા નેટવર્કે જાહેરાત સેવ કરી. જો તમે કહી શકતા નથી કે કયા એડેપ્ટરે ભરણ કર્યું અને એ ટેસ્ટ ક્રિએટિવ હતું કે નહીં, તો ઇમ્પ્રેશનને જીવંત ઇન્વેન્ટરી ગણો અને તેને છોડી દો.
અહીં જ અમાન્ય-ટ્રાફિક નીતિનું મહત્ત્વ છે. સ્વ-ક્લિક, પુનરાવર્તિત ઇમ્પ્રેશન, સ્વયં-ચાલિત ક્રિયાપ્રતિક્રિયાઓ અને છેતરપિંડીભર્યો ટ્રાફિક બધું આવરી લેવાય છે, અને શું થાય છે તે જોવા માટેનું અનિશ્ચિત ક્લિક બરાબર એ જ પેટર્ન છે જે તે નિયમો વર્ણવે છે.
રોલબેક અને રિલીઝ ગેટ
ટેસ્ટ ગોઠવણી શિપ થવી ન જોઈએ. રિલીઝ બિલ્ડ પહેલાં ડેમો જાહેરાત એકમોને પ્રોડક્શન એકમોથી બદલો, ટેસ્ટ ઉપકરણ યાદી દૂર કરો અને ફક્ત ડેવલપમેન્ટ માટેના બધા ફ્લેગ કાઢી નાખો. મેમરી પર ભરોસો કરવાને બદલે રિલીઝ વેરિઅન્ટમાં ટેસ્ટ ઓળખકર્તાઓ grep કરો; ખોવાયેલી એન્ટ્રી એક શાંત નિષ્ફળતા છે જે ફક્ત ખૂટતી આવક તરીકે દેખાય છે.
પછી વિરુદ્ધ દિશા ચકાસો: રિલીઝ બિલ્ડને નોંધાયેલા ટેસ્ટ ઉપકરણ પર ઇન્સ્ટોલ કરો અને પુષ્ટિ કરો કે વિનંતી હવે ટેસ્ટ ટ્રાફિક તરીકે ગણાતી નથી. જો તે હજી લેબલ દર્શાવે, તો ગોઠવણીમાં કંઈક બચી ગયું છે.
પછી એક દસ્તાવેજીકૃત ટેસ્ટ માર્ગ રાખો જેથી આગળનો નેટવર્ક પ્રશ્ન જીવંત ઇન્વેન્ટરીને અડ્યા વિના જવાબી શકાય. ટેસ્ટ જાહેરાતો કદી ખાતાના રિપોર્ટમાં દેખાતી નથી, તેથી સ્વચ્છ વિભાજન રિપોર્ટિંગની ચોકસાઈમાં કંઈ ખર્ચતું નથી અને તમને પુનરાવર્તનયોગ્ય નિદાન આપે છે.