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

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

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

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

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

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

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

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

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

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

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

הסבר על Protected Audience

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פיתוח הפתרון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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