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

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

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

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

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

התרשים הבא ממחיש את השלבים הבאים:

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

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

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

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

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

מדריך השקה לתכונות של Protected Audience API.

היכרות עם Protected Audience

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פיתוח הפתרון

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

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

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

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

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

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

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

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

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

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

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

שיקולי עיצוב

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

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

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

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

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

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

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

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

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

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

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

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

רשימת נתוני מודעות

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

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

• אפשר לעדכן את הרשימה AdData בשתי דרכים:
  • כשבאפליקציה יש פעילות גלויה בחזית, היא יכולה להתחיל את הרשימה כשהיא מצטרפת למשתמש לקהל בהתאמה אישית.
  • במהלך עדכון יומי, האחזור הופעל ברקע. המכשיר שולח בקשה למספר daily_update_url שכלול בשיחה עם joinCustomAudience, ומצפה לקבל תשובה שכוללת רשימה מעודכנת של AdData.
• ניתן לבקש מידע נוסף על מודעות במהלך המכרז. לפני המכרז, המכשיר שולח בקשה לשירות ה-key-value של הקונים שסופק בשדה trustedBiddingData של joinCustomAudience. שירות מפתח/ערך הוא שירות חדש, שהוא חלק מההטמעה של Protected Audience אצל הקונים. פרטים נוספים על השירות הזה מוסברים בהמשך מסמך זה.
• מומלץ לכלול מזהה קריאייטיב למודעה כדי לבצע פעולות מסוימות בקריאייטיבים ספציפיים. לדוגמה, מפרסמים יכולים להשהות נכסי קריאייטיב מסוימים, ואתם רוצים לשלוף את מזהי הקריאייטיב האלה משירות מפתח-ערך בזמן אמת, ולאחר מכן לבצע התאמה למודעות ברשימה 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 API היא לתמוך בתהליך בחירת הרשת (Mediation) ב-Waterfall. האזור הזה בשלבי פיתוח. כשמידע נוסף יהיה זמין. בינתיים, כדאי לעיין בהצעה לתכנון של תהליך בחירת הרשת (Mediation) ב-Waterfall ב'קהל מוגן'.

מפיצים: הגדר את המכרז

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

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

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

שיקולי עיצוב

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

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

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

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

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

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

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

קונים: בידינג למיקום מודעה

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

• הקונה יכול להוסיף את הלוגיקה שלו לבידינג לפונקציה generateBid() של JavaScript שמוצגת מהפרמטר 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 שמתייחס למידע לפי הקשר.

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

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

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