מגישי הצעות מחיר יכולים להשתמש במשאב pretargetingConfigs
כדי לקבל בקשות להצעות מחיר רק לחשיפות שתואמות לקריטריונים שלהם לטירגוט.אפשר להגדיר בו-זמנית עד 10 הגדרות של טירגוט מראש.
כל הגדרה של טירגוט מראש מפיצה בקשות להצעות מחיר בין כל נקודות הקצה. הבקשות להצעת מחיר לא תמיד מחולקות באופן שווה בין כל נקודות הקצה. לדוגמה, בתצורה של טירגוט מראש למזהים גיאוגרפיים ספציפיים באזור נתון, ייתכן שיהיו פחות התאמות במיקומי מסחר שרחוקים יותר מהאזור הזה. נקודות קצה שקרובות למיקומי מסחר רחוקים יותר עשויות לקבל פחות בקשות להצעות מחיר.
שיטות מומלצות
כדי לקבל בקשות להצעות מחיר, עליך ליצור לפחות הגדרה אחת של מיקוד מראש. ריכזנו כאן כמה טיפים לניהול ההגדרות של הטירגוט מראש:
- היקף
טירגוט מראש הוא כמו סינון. עליך להשתמש בקריטריונים של מיקוד מראש כדי לסנן בקשות להצעות מחיר שרלוונטיות לתרחיש לדוגמה שלך. אם לא תגדירו קריטריונים כלשהם של מיקוד מראש, תוכלו לקבל בקשות להצעות מחיר לכל החשיפות.
אם לא מתקבלות מספיק בקשות להצעות מחיר שקשורות להגדרה מסוימת של טירגוט מראש, מומלץ להרחיב את הקריטריונים של הטירגוט מראש.
- לוגיקה
ערכים בשדות הטירגוט ברמה העליונה מעובדים באמצעות
OR
לוגי. המשמעות היא שתוכלו לקבל בקשות להצעות מחיר שכוללות לפחות אחד מהערכים שאתם מציינים בשדה ברמה העליונה. לדוגמה, אם בתצורת הטירגוט מראש יש ערכיlanguageCodes
en
,de
ו-sv
, יכול להיות שתקבלו בקשות להצעות מחיר עם השפה שזוהתה:en
,de
אוsv
.שדות שונים מעובדים באמצעות
AND
לוגי. יתקבלו רק בקשות להצעות מחיר עם התאמה לערך אחד לפחות בכל שדה של מיקוד מראש שהגדרתם. לדוגמה, אם בהגדרות האישיות שלך יש ערכיlanguageCodes
en
,de
ו-sv
והערךPERSONAL_COMPUTER
הואincludedPlatforms
, יתקבלו רק בקשות להצעות מחיר שזוהתה בהן השפהen
,de
אוsv
וסוג המכשירPERSONAL_COMPUTER
.בגלל הערך הלוגי
AND
בשדות של טירגוט מראש, אי אפשר לכלול קריטריונים סותרים. לדוגמה, אם מוסיפים את אותו הערך ב-includedIds
וב-excludedIds
בקריטריונים שלNumericTargetingDimensions
, תתקבל שגיאה.- חפיפה
בקשות להצעות מחיר יכולות להיות כשירות לכמה הגדרות של טירגוט מראש.
אפשר ליצור עד 10 הגדרות של טירגוט מראש כדי לטרגט סוגים שונים של מלאי. יכולות להיות חפיפה בין הגדרות הטירגוט מראש, כך שבקשה יחידה להצעת מחיר עשויה להתאים לכמה תצורות של טירגוט מראש. במקרה כזה, השדה
billing_id
של הבקשה להצעת מחיר מכיל אתbillingId
של כל אחת מההגדרות הרלוונטיות. אם הבקשה מכילה כמה מזהי חיוב, צריך לציין בשדהbilling_id
של התגובה להצעת המחיר את מזהה החיוב שעליו רוצים להגיש הצעות מחיר.
מזהים גיאוגרפיים
יש מזהים גיאוגרפיים שלא ניתן לטרגט מסיבות הקשורות למדיניות. לדוגמה, לא ניתן לטרגט לאזורים מסוימים עם אוכלוסיות קטנות כי זה יפר את מדיניות הפרטיות שלנו. המדיניות שלנו עשויה להשתנות. אם תציינו מזהה גיאוגרפי ב-geoTargeting
של ההגדרה של הטירגוט מראש, שיהפוך ללא חוקי במועד מאוחר יותר, המזהה יופיע בשדה invalidGeoIds
באותו הזמן. למזהים גיאוגרפיים מתחת ל-invalidGeoIds
אין השפעה על הטירגוט. אם מזהה גרפי ב-invalidGeoIds
מקבל תוקף, הוא מתווסף לשדה geoTargeting
של הגדרת הטירגוט מראש.
בקובץ geo-table.csv מופיעים המזהים הגיאוגרפיים שניתן למקד אליהם, ומתעדכן מדי פעם תוך כדי הוספה והסרה של מזהים.
מספר הבקשות להצעת מחיר
עליכם להגדיר את מספר ה-QPS המקסימלי של נקודות הקצה של מגישי הצעות המחיר, ולאפשר למערכת מכסת היתרונות המרכזיים לנהל את התנועה שנשלחת לנקודות הקצה שלכם לכל אחת מההגדרות של הטירגוט מראש.
הנה תרחישי קצה שבהם כדאי לנהל את מספר QPS מקסימלי ברמת הגדרת הטירגוט מראש באמצעות maximumQps
:
- מתקבלות יותר מדי בקשות
- אם מערכת מכסות היתרונות המרכזיים שולחת מספר חריג של בקשות להצעות מחיר לנקודות הקצה של מגישי הצעות המחיר, בהתאם להגדרה מסוימת של טירגוט מראש, אפשר להשתמש ב-
maximumQps
כדי לשנות את מספר הבקשות באופן ידני. - בדיקת הגדרות של מלאי חדש
- אם אתם מנסים לתמוך במלאי חדש של שטחי פרסום, כמו פורמט חדש של קריאייטיב, תוכלו להטמיע הגדרה של טירגוט מראש שמטרגטת רק את המלאי הזה עם ערך נמוך של
maximumQps
.
במלאי שטחי פרסום שמטורגט באמצעות כמה הגדרות של טירגוט מראש, הבקשות להצעות מחיר נשלחות לנקודות הקצה של מגיש הצעות המחיר, כולל billingId
של כל הגדרה, כל עוד לפחות אחת מההגדרות לא הגיעה למגבלה של maximumQps
.