בדיקה והפצה של האפליקציה

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

בדיקות עם התנועה של Google

כשתהיו מוכנים להתחיל לבדוק את התנועה שנשלחת מ-Google, צרו קשר עם נציג Authorized Buyers. תתבקשו לספק פרטים שונים, כמו:

  • פרטים ליצירת קשר עם הנדסה. אם הבדיקה לא תתבצע כמצופה ויש בעיות הנדסיות שצריך לטפל בהן, נשתמש בפרטים ליצירת קשר כדי לתקשר ישירות עם הצוות שלך.
  • כתובת URL שתומכת ב-SSL ומגיבה לבקשות ב-RTB.
  • כתובת URL תואמת SSL של שרת התאמת קוד של קובצי Cookie, אם בחרתם להשתמש בפונקציונליות הזו.
  • המיקום הפיזי (מדינה, מדינה) של שרתי ה-RTB, כדי לשפר את התקשורת עם השרתים של Google.
  • ה-QPS המקסימלי (בשאילתה לשנייה) שאתם מוכנים להציג מכל מיקום פיזי בסיום הבדיקה.
  • התאריך שבו שרתי RTB / Cookie Code Adjust פעילים לצורך בדיקה. Google תשלח בקשות RTB לשרתים שלכם או זמן קצר לאחר מכן.
  • זמן האחזור המשוער שבו השרתים שלך ישתמשו לצורך עיבוד בקשות RTB.
  • מפתחות PGP למידע על פענוח המחיר בדואר.
  • מוודאים שטירגוט מראש מוגדר בממשק המשתמש של הטירגוט מראש.

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

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

זמן האחזור שנדרש לשימוש ב-Real-time Bidder הוא 80 עד 1,000 אלפיות השנייה, שנמדד מהרגע ש-Google שולחת את השיחה ועד לרגע ש-Google מקבלת תשובה. המועד האחרון הזה תלוי בפורמט ובסוג המכרז. חשוב לבדוק את הערך המדויק בשדה tmax או response_deadline_ms בבקשה להצעת המחיר.

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

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