Protected Audience: מדריך השילוב

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

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

תהליך העבודה של השילוב עם Protected Audience כולל 4 שלבים עיקריים שמופעלים על ידי סוגים שונים של שותפים בתחום טכנולוגיות הפרסום:

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

התרשים הבא מדגים את השלבים האלה:

תהליך העבודה של ניהול קהלים מותאמים אישית ובחירת מודעות ב-Protected Audience API.
תהליך העבודה של ניהול קהלים בהתאמה אישית ובחירת מודעות ב-Protected Audience.

הסברים על המונחים

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

דרישות מוקדמות, שיתוף פעולה עם שותף לשילוב מוצרי Google והגדרה

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

תרשים שמציג את מדריך ההשקה של תכונות Protected Audience.
מדריך להשקת תכונות של Protected Audience

היכרות עם Protected Audience

השלב הראשון הוא להכיר את ממשקי ה-API והשירותים של Protected Audience.

  1. כדאי להתחיל בקריאת הצעת העיצוב כדי להכיר את Protected Audience API ואת היכולות שלו.
  2. במדריך למפתחים מוסבר איך לשלב את הקוד ואת קריאות ה-API שדרושים לתרחישי השימוש שלכם, ואת השירותים שנדרשים לשילוב עם Protected Audience.
  3. שליחת משוב בנוגע לעיצוב ולהטמעה של Protected Audience APIs, שירותים ומסמכים.
  4. כדאי להירשם לקבלת עדכונים כדי להתעדכן בתכונות האחרונות של ארגז החול לפרטיות.

הגדרה ובדיקה של אפליקציות לדוגמה

אחרי שתכירו את היסודות של Protected Audience שפורטו קודם, כדאי להגדיר ולבדוק את האפליקציות לדוגמה.

  1. כשמוכנים להתחיל בשילוב, צריך להגדיר את סביבת הפיתוח עם גרסת הטרום-השקה למפתחים של ארגז החול לפרטיות.
  2. מגדירים את נקודות הקצה הנדרשות של השרת. כדי להתחיל את התהליך הזה, אפשר להשתמש בדוגמאות ל-mocks עם פתרון בדיקת ה-API המועדף עליכם.
  3. כדי להכיר את התהליך של ניהול קהלים מותאמים אישית, בחירת מודעות ודיווח על חשיפות, אפשר ליצור עותק של הקוד ולהריץ אותו באפליקציה לדוגמה שלנו.

התקשרות עם שותפה לשילוב מוצרי Google

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

הגדרה של גרסת בטא (זמינה ברבעון 4)

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

שיקולים אדריכליים

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

מודעות רימרקטינג וקהלים נשמרים במכשיר

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

תהליכי הבידינג והמכרז מתבצעים במכשיר

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

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

אסטרטגיית נתונים

פלטפורמות טכנולוגיות פרסום צריכות לקחת בחשבון את סוגי הנתונים שמשמשים במכרזים. כיום, המידע הזה נאסף ממקורות שונים ואז מרוכז בשרת. במכרזים של Protected Audience API יש כמה דרכים להעביר את הנתונים האלה. לדוגמה: אותות בזמן אמת כמו התקציב שנותר מגיעים משירות של זוגות מפתח/ערך כאותות מהימנים, ואילו אותות לפי הקשר כמו השעה ביום נשלחים ממוכרים בזמן הפעלת מכרז. האותות האלה מוסברים בפירוט רב יותר בקטעים הרלוונטיים במדריך הזה.

יצירת הפתרון

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

קונים: בניית קהל

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

אם יש לכם SDK משלכם באפליקציה של המפרסם, אתם יכולים להטמיע את הקוד הזה ישירות באמצעות joinCustomAudience().

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

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

קמפיין רימרקטינג לדוגמה: עיצוב קהל בהתאמה אישית

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

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

הגדרה ואב-טיפוס

שיקולים לגבי העיצוב

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

כתובת URL של לוגיקת הבידינג

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

אותות בידינג של משתמשים

הקונים יכולים להשתמש ב-UserBiddingSignals כדי להעביר למכרזים עתידיים במכשיר מידע שיש למפרסם או לקונה עצמו על המשתמש. המידע הזה יכול לכלול:

  • קהלים אחרים שהמשתמש נוסף אליהם.
  • תובנות מאינטראקציה ישירה (First-Party) שיש למפרסם לגבי המשתמש.

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

  • העלאה או הורדה של הצעות מחיר על סמך אותות בידינג.
  • סינון מודעות ספציפיות מהמכרז.

נתוני בידינג מהימנים

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

השדה TrustedBiddingData מורכב מכתובת URL ומקבוצת מפתחות. אלה כמה דברים שכדאי לקחת בחשבון כשמעצבים את מבנה המפתחות שבו רוצים להשתמש:

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

רשימת AdData

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

הקונים מחליטים כמה מידע לכלול לגבי כל מודעה. כדאי לקחת בחשבון את הדברים הבאים:

  • יש 2 דרכים לעדכן את הרשימה AdData:
    • כשהאפליקציה מציגה פעילות בגורם הקדמי, היא יכולה ליצור את הרשימה כשהיא מוסיפה משתמש לקהל מותאם אישית.
    • במהלך עדכון יומי, האחזור מתחיל ברקע. המכשיר שולח בקשה ל-daily_update_url שכלול בקריאה joinCustomAudience ומצפה לתשובה שכוללת רשימה מעודכנת של AdData.
  • אפשר לבקש מידע נוסף על מודעות בזמן המכרז. לפני המכרז, המכשיר שולח בקשה לשירות מפתח-ערך של הקונים שסופק בשדה trustedBiddingData של joinCustomAudience. שירות המפתח-ערך הוא שירות חדש שמהווה חלק מההטמעה של קהלים מוגנים בצד הקונים. בהמשך המאמר מפורטים פרטים נוספים על השירות הזה.
  • הוספה של מזהה קריאייטיב למודעה יכולה לעזור לכם לבצע פעולות מסוימות בקריאייטיבים ספציפיים. לדוגמה, מפרסמים עשויים להשהות קריאייטיבים ספציפיים, ואתם רוצים לשלוף את מזהי הקריאייטיבים האלה משירות בזמן אמת של זוגות מפתח/ערך, ואז להתאים אותם למודעות ברשימה AdData.

AdData צריך לכלול render_url. כתובת ה-URL של המודעה המוצלחת לרשימת רימרקטינג משמשת להצגת המודעה. הנה כמה דברים שכדאי לקחת בחשבון:

  • לכתובת ה-URL של הרינדור יש סף אנונימיות k, לכן כדאי להימנע מהכללת פרמטרים צרים. מידע נוסף על ערך הסף הזה של k-anonymity יפורסם במועד מאוחר יותר.
  • כתובת ה-URL הזו צריכה להכיל את כל המידע שנדרש כדי להציג את המודעה. לדוגמה, אם רוצים להציג מוצרים ספציפיים, אפשר להטמיע מזהי מוצרים כפרמטרים בכתובת ה-URL.

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

שעת ההפעלה ומועד התפוגה

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

  • משתמש לא פעיל (למשל, משתמש שלא הייתה לו אינטראקציה עם האפליקציה של המפרסם ב-7 הימים האחרונים)
    • בכל פעם שהמשתמש פותח את האפליקציה, הקונה יכול להתקשר אל joinCustomAudience ולהגדיר את activation_time כחותמת זמן ל-7 ימים בעתיד.
    • הקהל עומד בדרישות להגשת הצעות מחיר אם חלפו 7 ימים מאז שהמשתמש פתח את האפליקציה בפעם האחרונה.
  • קהל עונתי (קהל שתקף רק במהלך מסגרת זמן ספציפית בעתיד הקרוב)
    • קונים יכולים להתחיל להגדיר מראש קהלים בהתאמה אישית שיוכלו להשתתף בבידינג רק במהלך תקופה שנקבעה מראש בעתיד (הקרוב).
    • לדוגמה, אם למפרסם יש קמפיין לסוף הקיץ בארצות הברית בשנת 2022, הקונה שלו יכול להתקשר למספר joinCustomAudience ולהגדיר את activation_time ליום שבת, 20 באוגוסט 2022. אם הקמפיין פועל רק למשך שבוע אחד, הקונה יכול להגדיר את תאריך התפוגה ל-27 באוגוסט 2022. אחרי התאריך הזה, הפלטפורמה תסנן את הקהל המותאם אישית במהלך בחירת המודעות, ובסופו של דבר הוא יוסר.

קונים ומוכרים: בחירת מודעות

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

  1. המוכרים מגדירים שיטת גישור.
  2. המוכרים מגדירים את המכרז ומתחילים את תהליך בחירת המודעות.
  3. הקונים מוזמנים להשתתף במכרז באמצעות ההגדרה שהמוכר הגדיר. הלוגיקה של הבידינג של הקונה מופעלת כדי לבחור מודעה והצעת מחיר.
  4. הלוגיקה של המוכר מופעלת כדי לתת ניקוד למועמדים ולבחור מודעה מנצחת.

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

מוכרים: הגדרה של אסטרטגיית גישור

התכונה Protected Audience נועדה לתמוך בתהליך בחירת הרשת ב-Waterfall. האזור הזה נמצא בפיתוח, ומידע נוסף יסופק כשהוא יהיה זמין. בשלב הזה, אפשר לעיין בהצעת העיצוב לתהליך בחירת הרשת ב-Waterfall בקהל מוגן.

מוכרים: הגדרת המכרז

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

הגדרה ואב-טיפוס

  • מוֹכר יכול להגדיר מכרז ולהתחיל אותו על ידי הגדרת אובייקט AdSelectionConfig ושימוש ב-API‏ AdSelection. מפעילים את המכרז על ידי הפעלת selectAds().
  • פרטים על ההטמעה ועל השימוש ב-API זמינים במדריך למפתחים.

שיקולים לגבי העיצוב

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

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

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

  • יכול להיות שהרבה קונים יצרו קהלים בהתאמה אישית במכשיר, ולכן המוכרים צריכים להשתמש בשדה custom audience buyers כדי לציין את הקונים הספציפיים שרוצים לכלול בתהליך. יש הרבה דרכים ליצור את הרשימה הזו. הנה כמה דוגמאות:

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

  • המוֹכר יכול להעביר מידע לתהליך בכמה דרכים:

    • השדה ad selection signals זמין לכל הקונים ולמוֹכר שמשתתפים במכרז בסביבת זמן הריצה הפרטית. הוא משמש כדי לספק מידע על הזדמנות הפרסום, כמו גודל המודעה ופורמט המודעה.
    • השדה אותות לכל קונה מועבר לקונה ספציפי כדי שישמש אותו בתהליך הבידינג. המידע הזה מסופק על ידי הקונה, ואתם כמוכרים צריכים לחשוב איך להשיג את המידע הזה במכשיר לשימוש במהלך בחירת המודעות.
    • השדה seller signals הוא הדרך האחרונה שבה המוכר יכול להעביר מידע לתהליך. אתם, כמוכרים, משתמשים באותות האלה כשאתם מדרגים ומסננים מודעות, למשל כשאתם מפעילים בדיקה של בטיחות המותג.

קונים: בידינג על משבצת פרסום

הגדרה ואב-טיפוס

  • הקונים יכולים להוסיף את לוגיקת הבידינג שלהם לפונקציית JavaScript‏ generateBid() שמוצגת מתוך קבוצת הפרמטרים biddingLogicUrl כשיוצרים CustomAudience. אתם יכולים להגדיר שירות מדומה באמצעות המפרט שסופק, או להטמיע את נקודת הקצה הזו בשרת אמיתי.
  • פרטים על ההטמעה ועל השימוש ב-API זמינים במדריך למפתחים.

שיקולים לגבי העיצוב

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

תכנון לוגיקת הבידינג

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

העברת נתוני בידינג על מלאי שטחי פרסום

אותות בידינג בזמן אמת עם שירותים של זוגות מפתח/ערך

כקונים, אתם יכולים לאחזר אותות בזמן אמת במהלך מכרז משירות של זוגות מפתח/ערך שבבעלותכם. אפשר למצוא הטמעה ראשונית של השירות הזה במאגר ארגז החול לפרטיות הציבורי, או ליצור שירות משלכם. כתובת ה-URL של השירות הזה מצוינת כ-trustedBiddingUrl בקהל מותאם אישית, והפלטפורמה מנסה לאחזר את הנתונים ולהפוך אותם לזמינים לפונקציה generateBid עם trusted_bidding_signals parameter. אתם צריכים ליצור מבנה מפתחות משלכם.

אותות הקשריים ואותות המשתמשים

לפונקציה generateBid יש גישה לאותות נוספים של משתמשים כשהיא מריצה את המכרז במכשיר. האותות האלה מועברים בשדות contextual_signals ו-per_buyer_signals. כל השדות האלה הם אובייקטים בפורמט JSON, והפורמט שלהם צריך להיות מוגדר על ידי הקונים והמוכרים.

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

השדה per_buyer_signals זמין ללוגיקת הבידינג. המוכר מגדיר את הערכים האלה כשהוא יוצר את הגדרת המכרז. קונים ומוכרים צריכים לשתף פעולה כדי לוודא שהנתונים האלה נמצאים במכשיר ומועברים ללוגיקה של הצעת המחיר. דוגמאות לשימושים בשדה הזה:

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

מוכרים: המערכת מדרגת את המודעות ובוחרת את המודעה הזוכה

הגדרה ואב-טיפוס

  • המוֹכר יכול להוסיף את לוגיקת הניקוד שלו לפונקציית ה-JavaScript‏ scoreAd() שמוצגת מהפרמטר scoringLogicUrl שהוגדר כשבונים את AdSelectionConfig. אתם יכולים להגדיר שירות מדומה באמצעות המפרט שסופק, או להטמיע את נקודת הקצה הזו בשרת אמיתי.
  • פרטים על ההטמעה ועל השימוש ב-API זמינים במדריך למפתחים.

עיצוב לוגיקה של ניקוד

המוֹכרים מטמיעים לוגיקה של ניקוד ב-JavaScript, שמופעלת במכשיר. במדריך למפתחים יש מידע על החתימה הנדרשת ופרטים על הפרמטרים השונים שמועברים במהלך המכרז. בנוסף, ללוגיקת הניקוד במכשיר יש גישה למידע נוסף שמועבר כפרמטרים לפונקציה scoreAd.

נתונים של דירוג היצע שטחי הפרסום

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

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

אותות הקשריים ואותות המשתמשים

לפונקציה scoreAd יש גישה לאותות נוספים של משתמשים כשהיא מריצה את המכרז במכשיר. האותות האלה מועברים לפונקציית הניקוד באמצעות השדה contextual_signal. השדה הזה מכיל אובייקטים בפורמט JSON שהוגדר על ידי קונים ומוכרים.

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

מוכרים: הצגת מודעה

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

דיווח על תוצאות של חשיפות

הגדרה ואב-טיפוס

  • הקונים והמוכרים יכולים להוסיף לוגיקה של דיווח לפונקציית reportWin() JavaScript שמוצגת מהפרמטר biddingLogicUrl או scoringLogicUrl בהתאמה. אתם יכולים להגדיר שירות מדומה באמצעות המפרט שסופק, או להטמיע את נקודת הקצה הזו בשרת אמיתי.
  • פרטים על ההטמעה ועל השימוש ב-API זמינים במדריך למפתחים.

שיקולים לגבי העיצוב

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

בנוסף, ארגז החול לפרטיות מספק Attribution Reporting API לניהול דוחות ברמת האירוע ודוחות מצטברים. פרטים נוספים זמינים במדריך לשילוב.