בדקו מודעות AdMob על גבי VPN בלי לסכן את החשבון

אתם רוצים לדעת אם שילוב המודעות שלכם שורד את הרשת שיש למשתמשים שלכם בפועל. 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, גרסאות מתאמים, סוג בנייה, פורמט מודעה, מדינת יציאה והתוצאה שנצפתה. בלי התיעוד הזה האדם הבא יחזור על הניסוי מאפס ויגיע למסקנה אחרת מאותן ראיות.

תיווך הוא בדיקה נפרדת

מודעות מתווכות אינן נושאות את התווית Test Ad של Google, מה שהופך אותן למקום הקל ביותר ללחוץ על משהו שלא כדאי. לכל רשת במחסנית התיווך יש מצב בדיקה משלו והגדרה משלו, ותצורת הבדיקה של Google אינה חלה עליהן.

בדקו את המתאמים אחד אחד, עם מצב הבדיקה של המתאם עצמו פעיל, ואמתו ביומן איזו רשת הגישה את המודעה. אם אינכם יכולים לומר איזה מתאם מילא והאם היה זה קריאייטיב בדיקה, התייחסו לחשיפה כמלאי חי והניחו לה.

כאן גם חשובה המדיניות בדבר תעבורה לא חוקית. לחיצות עצמיות, חשיפות חוזרות, אינטראקציות אוטומטיות ותעבורה מטעה כולן מכוסות, ולחיצה לא בטוחה כדי לראות מה יקרה היא בדיוק הדפוס שהכללים האלה מתארים.

חזרה לאחור ושער הפרסום

תצורת בדיקה לא צריכה להישלח. לפני בניית פרסום החליפו יחידות מודעות לדוגמה ביחידות ייצור, הסירו את רשימת מכשירי הבדיקה ומחקו כל דגל המיועד לפיתוח בלבד. חפשו בגרסת הפרסום את מזהי הבדיקה במקום לסמוך על הזיכרון; רשומה תועה היא כשל שקט שמופיע רק כהכנסה חסרה.

אחר כך אמתו בכיוון ההפוך: התקינו את בניית הפרסום על מכשיר בדיקה רשום ואמתו שהבקשה אינה נחשבת עוד לתעבורת בדיקה. אם התווית עדיין מוצגת, משהו בתצורה שרד.

לאחר מכן שמרו נתיב בדיקה מתועד אחד כדי שאפשר יהיה לענות על שאלת הרשת הבאה בלי לגעת במלאי החי. מודעות בדיקה אינן מופיעות לעולם בדוחות החשבון, כך שהפרדה נקייה אינה עולה דבר בדיוק הדיווח ומקנה לכם אבחון שניתן לחזור עליו.