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

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

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

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

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

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

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

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

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

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

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

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

הסבר על Protected Audience

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

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

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

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

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

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

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

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

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

שיקולים ארכיטקטוניים

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

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

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

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

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

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

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

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

פיתוח הפתרון

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

קונים: יצירת קהל

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כחלק מההטמעה של Protected Audience, לקונים יש גישה למידע בזמן אמת במהלך המכרז משירות של מפתח/ערך. כמנגנון זמני, הקונה והמוכר יכולים לאחזר את אותות הבידינג האלה מכל שירות, כולל שירות שהם מפעילים בעצמם. הדוגמה הנפוצה ביותר היא חיפוש הסכום שנותר בתקציב הפרסום. במהלך הפיתוח, אפשר ליצור מודל מק"ט של השירות הזה ולפתח תוך התבססות על נקודת הקצה הזו. הוראות ההגדרה מפורטות בספרייה 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. האזור הזה נמצא בפיתוח, ונוסיף מידע כשיהיה לנו. בינתיים, תוכלו לעיין בהצעת העיצוב לתהליך בחירת הרשת (Mediation) ב-Waterfall בקהל מוגן.

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

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

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

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

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

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

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

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

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

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

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

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

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

מוכרים: מתן ציונים ובחירת המודעה הזוכה

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

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

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

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

נתוני דירוג של ספקים

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

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

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

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

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

מוכרים: עיבוד של מודעה

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

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

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

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

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

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

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