שאלות נפוצות¶

השאלות מתויגות לפי קהל יעד: [קונה] לקוני מדיה ומנהלי קמפיינים, [DevOps] למהנדסי פלטפורמה, [שניהם] לשאלות משותפות.

[קונה] למה אחוז הכיסוי שלי מתחת ל-100%?¶

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

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

בדקו את רשת רעננות הנתונים ב-/import כדי לראות בדיוק אילו תאים חסרים. ראו ייבוא נתונים.

[קונה] מה ההבדל בין "בזבוז" ל"אחוז זכייה נמוך"?¶

בזבוז = בקשות הצעת מחיר שהמכרז שלכם דחה מבלי להציע הצעה. זהו QPS ששילמתם עליו אך לא יכולתם להשתמש בו כלל. תקנו זאת עם פרה-טרגוט.

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

שניהם מופיעים במשפך אך דורשים פעולות שונות. ראו הבנת משפך ה-QPS שלך.

[קונה] האם אפשר לבטל שינוי פרה-טרגוט?¶

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

[קונה] באיזו תדירות כדאי לייבא נתונים מחדש?¶

מדי יום. ייבוא אוטומטי מ-Gmail מטפל בזה באופן אוטומטי. אם אתם מייבאים ידנית, עשו זאת פעם ביום לאחר הגעת הדוחות. נתונים מיושנים משמעותם החלטות מיושנות.

[קונה] מה האופטימייזר בעצם משנה?¶

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

[DevOps] למה שער בדיקת התקינות בזמן ריצה נכשל?¶

בדקו את יומני תהליך העבודה: gh run view <id> --log-failed. חפשו FAIL מול BLOCKED:

FAIL = משהו נשבר. זמן קצוב של רעננות נתונים ובעיות SET statement_timeout הם גורמים נפוצים. ראו פתרון בעיות.
BLOCKED = תלות חסרה, לא בהכרח באג בקוד. דוגמאות: אין נתוני איכות לקונה הזה, להצעה אין billing_id. השוו מול הרצות קודמות כדי להבחין בין רגרסיות לפערים קיימים מראש.

[DevOps] למה נקודת הקצה של רעננות הנתונים איטית?¶

השאילתה סורקת את rtb_daily (~84M שורות) ו-rtb_bidstream (~21M שורות). אם תוכנית השאילתה מתדרדרת לסריקה רצפית במקום להשתמש באינדקסים (buyer_account_id, metric_date DESC), זה ייקח דקות.

תיקון: ודאו שהשאילתות משתמשות בדפוס generate_series + EXISTS (14 חיפושי אינדקס במקום סריקת טבלה מלאה). ראו פעולות מסד נתונים.

[DevOps] כיצד אבדוק איזו גרסה פרוסה?¶

curl -sS https://scan.rtb.cat/api/health | jq -r '.git_sha,.version'

פקודה זו מחזירה את ה-git SHA ותגית התמונה. השוו מול יומן ה-commits שלכם.

[DevOps] כיצד אפרוס תיקון?¶

דחפו ל-unified-platform
המתינו שה-build-and-push.yml יסתיים בהצלחה
הפעילו את deploy.yml דרך gh workflow run עם confirm=DEPLOY
אמתו עם /api/health

ראו פריסה לתהליך המלא.

[DevOps] משתמשים תקועים בלולאת התחברות. מה לעשות?¶

בדקו את Cloud SQL Proxy: sudo docker ps | grep cloudsql. אם הוא למטה, הפעילו אותו מחדש, המתינו 10 שניות, ואז הפעילו מחדש את קונטיינר ה-API. ראו פתרון בעיות לתהליך המלא.

[שניהם] מאיפה מגיעים הנתונים של Cat-Scan?¶

ייצוא CSV מ-Google Authorized Buyers. אין API לדוחות. נתונים מגיעים דרך העלאת CSV ידנית או קליטה אוטומטית מ-Gmail. ראו ייבוא נתונים.

[שניהם] האם בטוח לייבא מחדש את אותו CSV?¶

כן. כל שורה עוברת גיבוב והסרת כפילויות. ייבוא חוזר לעולם לא סופר פעמיים.

[שניהם] אילו שפות ממשק המשתמש תומך?¶

אנגלית, הולנדית וסינית (פשוטה). בורר השפה נמצא בסרגל הצד.