כדי לקבל גישה לממשקי ה-API של הרלוונטיות והמדידה של ארגז החול לפרטיות ב-Chrome וב-Android, המפתחים צריכים להירשם במסגרת ארגז החול לפרטיות. נכללים בכך דוחות שיוך (Attribution), Protected Audience, Topics, צבירה פרטית ונפח אחסון משותף. רישום מפתחים מספק מנגנון לאימות הישויות שקוראים לממשקי ה-API האלה, ולאיסוף הנתונים הספציפיים למפתחים הנדרשים כדי להגדיר כראוי את ממשקי ה-API של ארגז החול לפרטיות ולהשתמש בהם. תהליך הרישום הזה מוסיף עוד שכבת הגנה, בנוסף להגבלות המבניות שנאכפות בכל API, על ידי הוספת שקיפות לגבי האנשים שאוספים את הנתונים ומפחית את הניסיונות לשימוש לרעה בממשקי ה-API כדי לאסוף יותר נתונים ממה שהתכוונתם. כדי לשמור על שקיפות שניתן לבדוק, פרטי ההרשמה של החברה יהיו גלויים לכולם. חברות צריכות לתכנן לפחות חמישה שבועות להשלמת תהליך ההרשמה, מהמועד שבו הן משלחות את טופס ההרשמה. הזמן הזה כולל זמן לטיפול בבעיות שעשויות להתעורר בשליחת הטופס או בבעיות אחרות. הזמן הזה לא כולל את זמן ההכנה הפנימי הנוסף שעשוי להידרש לחברות לפני שליחת הטופס.
לפני שמתחילים
לפני תחילת ההרשמה, חשוב לוודא שיש לכם מספר D-U-N-S של הארגון. זהו מספר ייחודי בן תשע ספרות שמסופק על ידי Dun & Bradstreet ומשמש לזיהוי העסק. המספר נבדק כחלק מתהליך האימות של ההרשמה ל-Privacy Sandbox. אם לחברה שלך הונפקו כמה מספרי D-U-N-S, יש לציין את המספר ברמה הגבוהה ביותר שמייצג את הישות התאגידית הכוללת. אם העסק שלכם הוא לא ישות משפטית, לא תוכלו לקבל מספר D-U-N-S.
כדי לבדוק אם לחברה שלכם כבר הוקצה מספר D-U-N-S, או כדי לקבל מספר D-U-N-S חדש, שולחים בקשה באמצעות טופס ההרשמה. ל-Google יש תהליך בקשה מזורז של Dun &Bradstreet, שזמין למטרה הזו. אחרי שליחת הבקשה, נשלח לך אימייל עם קישור ייחודי לשימוש חד-פעמי לדף הנחיתה הספציפי ל-Google, שבו עליך לשלוח את פרטי העסק. אם לא תשלחו את המידע עד הסוף, תצטרכו לבקש קישור נוסף מ-Google.
קבלת מספר D-U-N-S כאדם פרטי
אם אתם אנשים פרטיים שלא משויכים לארגון, או לארגון שלכם אין אפשרות לקבל מספר D-U-N-S, תוכלו להירשם כאדם פרטי בטופס ההרשמה. כל המידע (למעט פרטים אישיים מזהים) שנאסף במהלך ההרשמה למפתחים עשוי להיכלל בדוחות של ארגז החול לפרטיות. הדוחות האלה יהיו זמינים לכולם.
איך להירשם
כדי להירשם, המפתחים צריכים למלא את טופס ההרשמה. הטופס מבקש את הפרטים הבאים:
- פרטים ליצירת קשר עם העסק
- מספר D-U-N-S של הארגון
- ממשקי ה-API שבהם בכוונתך להשתמש ומידע על הגדרת ה-API
המפתחים צריכים גם להסכים לאישורים לגבי השימוש שלהם בממשקי ה-API של ארגז החול לפרטיות שנרשמו.
רישום האתר, ה-SDK ל-Android או האפליקציה ל-Android
במהלך ההרשמה, עליכם לספק אתר או SDK (או שניהם) שישמשו אתכם לקריאה לממשקי ה-API.
אופן ההרשמה תלוי באופן שבו נקראים ממשקי ה-API של ארגז החול לפרטיות:
- אם אתם מפתחי אינטרנט והאתר שלכם קורא לממשקי ה-API של ארגז החול לפרטיות ישירות, עליכם לציין את האתר שלכם במהלך ההרשמה.
- אם אתם מפתחים של Android SDK, עליכם לציין את שם ה-SDK שלכם במהלך ההרשמה. אם ב-SDK נעשה שימוש ב-Attribution Reporting, ב-Protected Audience API או בשניהם, צריך לרשום גם את האתר. אפליקציות שמשתמשות ב-SDK שלכם לא צריכות להירשם בנפרד, אלא אם הן קוראות לממשקי ה-API של ארגז החול לפרטיות ישירות מהקוד שלהן. אם אתם רוצים לבדוק את Attribution Reporting API ב-Android בקנה מידה נרחב באופן מיידי, תצטרכו לספק את כל המקורות שבהם אתם משתמשים.
- אם אתם מפתחי אפליקציות והאפליקציה שלכם שולחת קריאה ישירה ל-Attribution Reporting, ל-Protected Audience או לשני ממשקי ה-API, עליכם לספק את האתר במהלך ההרשמה.
- אם אתם מפתחי אפליקציות ואתם מעניקים גישה מלאה לפונקציונליות המודעות שלכם ל-SDK, אין צורך לבצע את תהליך הרישום.
כל אתר או SDK שמפעילים את ממשקי ה-API של ארגז החול לפרטיות מחייבים רישום ייחודי וצריך לאמת אותם בנפרד. אפליקציות שמבצעות קריאה ישירה לממשקי ה-API של ארגז החול לפרטיות יכולות להיכלל ברישום אחד. אם אתם מתכננים לבצע קריאות לכמה ממשקי API, עליכם לציין כל אחד מהם במהלך תהליך ההרשמה. הערה: האתר שבו תירשמו הוא אותו אתר שבו נעשה שימוש כדי לאחזר את מפתחות ההצפנה לשימוש ב-Topics ב-Android ואת מפתח החתימה לשימוש ב-Protected Audience ב-Android. מידע נוסף על נקודת הקצה להצפנה ב-Topics ב-Android ומידע נוסף על חתימת מפתחות של Protected Audience.
עדכון פרטי ההרשמה
אפשר לעדכן את פרטי ההרשמה באמצעות טופס ההרשמה. עדכונים יחליפו את התשובות הקודמות.
ציר הזמן להרשמה
אחרי שליחת טופס ההרשמה, נבדוק את הבקשה ונעבד אותה. לאחר השלמת הבדיקה, נשלח לך הודעת אישור באימייל עם מספר חשבון מפתח ייחודי וקובץ אימות (attestation). הקובץ צריך להיות זמין לכולם מהנתיב /.well-known באתר שבו הוא נרשם, תוך 30 יום ממועד קבלת מזהה החשבון וקובץ האימות. מפתחי Android יכולים לספק למפתחי אפליקציות את מזהה הרישום כדי שתהיה להם אפשרות להגדיר בקרת גישה מפורטת. למידע נוסף, אפשר לעיין במסמכים של Android בנושא הגדרת שירותי מודעות שספציפיים ל-API.
הערה: בדיקות ההרשמה מסתיימות אחרי שממלאים את טופס ההרשמה במלואו. כדי לזרז את התהליך, חשוב להזין מידע נכון בטופס המקורי ולהגיב במהירות לפניות מצוות התמיכה הטכנית של Google.
הרשמה לסביבות פיתוח שונות
סביבות ה-staging, הבטא, בקרת האיכות והבדיקה ייכללו באופן אוטומטי אם הן משתמשות באותו אתר שבו משתמשת סביבת הייצור. אפשר לבדוק את הקוד ברמה המקומית בלי להירשם. לצורך בדיקה מקומית, אנחנו מספקים למפתחים אפשרות לשינוי מברירת המחדל מ-Chrome 116 באמצעות דגל Chrome ומפנה CLI:
- דגל:
chrome://flags/#privacy-sandbox-enrollment-overrides - CLI:
--privacy-sandbox-enrollment-overrides=https://example.com,https://example.co.uk,...
מגבלות
כשקובעים את מבנה הרישום של הארגון, חשוב לשים לב למגבלות הבאות של רישום מפתחים:
- אפשר לקשר אתר אחד להרשמה אחת בלבד.
- רישום אחד מכיל אתר אחד בלבד.
- מגבלות ספציפיות ל-SDK:
- הרשמה אחת יכולה להכיל כמה ערכות SDK.
- אפשר לקשר כל SDK רק להרשמה אחת.
- מותר להירשם לתוכנית כמה פעמים, אבל ההרשמות צריכות להיות למוצרים או לתחומי עסק עצמאיים שהוקמו בבירור וניתנים לאימות באופן ציבורי (כלומר, יש אתר ציבורי תואם שמסביר על המוצר הספציפי). אי אפשר להירשם כמה פעמים לאותו מוצר. האימותים חלים על כל הרשמה בנפרד.
- באמצעות רישום ברמת האתר, הרשמה יחידה יכולה לכלול מקורות ללא הגבלה, כל עוד הם מאותו אתר. עם זאת, אם מקור הדיווח הוא אחד למגבלה של קצב יצירת המקור (Chrome, Android), אתם בדרך כלל מוגבלים למקור אחד לכל בעל תוכן דיגיטלי.
מספר הרשמות לישות אחת
ישויות מורכבות יותר שיש להן כמה מוצרים ייחודיים יכולות להגיש בקשה לכמה הרשמות. לדוגמה, אם לחברה שלכם יש פעילות של SSP ופעילות של DSP, יכול להיות שאתם זכאים להירשם לכמה תוכניות.
לכל מוצר חייבים להיות אתרים נפרדים שמהם ניתן לקרוא לממשקי ה-API. תצטרכו לספק ייצוג ציבורי לכל מוצר שאתם מבקשים להירשם אליו (לדוגמה, קישור לאתר גלוי לכולם שמסביר על המוצר).
אם רוצים לרשום יותר מאתר אחד או ערכת SDK אחת, צריך למלא את טופס התהליך של בקשת הרשמה למספר חשבונות בנוסף לטופס ההרשמה הרגיל להרשמה הראשונה שאתם מבקשים. לאחר השליחה, הבקשה תיבדק ותקבלו אימייל כשתהליך הבדיקה יסתיים.
שליחת מספר הרשמות עם אותו מספר DUNS
אם אתם מגישים בקשה למספר הרשמות באמצעות טופס הבקשה להרשמה למספר חשבונות, אפשר להשתמש באותו מספר D-U-N-S בכל הרשמה.
הפניה אוטומטית עם דוחות שיוך (Attribution)
ניקח לדוגמה תרחיש שבו אתר א' לא רשום אבל אתר ב' רשום. ARA יבצע פינג לכתובות URL להפניה אוטומטית, גם אם לא נרשם. כתוצאה מכך, ההפניה האוטומטית מ-siteA.com אל siteB.com תפעל. עם זאת, מקורות וטריגרים יירשמו רק מטכנולוגיות פרסום רשומות.
הרשמה ל-Aggregation Service
יש כרגע תהליך רישום נפרד לרכיבי שרת ולממשקי API של לקוח (ל-Chrome ול-Android). צריך למלא את שני טופסי ההרשמה כדי להשתמש בשירות הצבירה. אנחנו רוצים לייעל את התהליכים. נכון לעכשיו, לשירות הצבירה יש טופס נפרד. במהלך ההרשמה לשירות צבירת הנתונים, אתם תירשמו באמצעות אתר חייב להיות אותו אתר (סכמה, eTLD+1) שרשום באמצעות רישום מפתחים.
כל הרשמה לשירות צבירה חייבת לכלול את המזהה של חשבון AWS או את חשבון השירות של GCP, שבו שירות הצבירה יופעל. לטכנולוגיות הפרסום יש גמישות שמאפשרת לקשר כמה אתרים לחשבון אחד או כמה חשבונות לאתר אחד, לצרכים שונים של בדיקות, תפעול וחיסכון בעלויות.
העלאה של קובץ אימות (attestation)
אחרי שתירשמו ותעברו את תהליך האימות, נשלח לכתובת האימייל שסיפקתם קובץ שמכיל את האימותים הספציפיים ל-API. יהיו לכם 30 יום ממועד קבלת מזהה החשבון וקובץ האימות כדי להשלים את מיקום קובץ האימות. במהלך פרק הזמן הזה, עדיין תוכלו לבצע קריאות ל-API למשך 30 יום, אבל עליכם לפעול בהתאם לשפת האימות במהלך פרק הזמן הזה.
כדי להשלים את ההרשמה, צריך להפוך את הקובץ לזמין מהנתיב הציבורי .well-known באתר שנרשם. לדוגמה, אם רושמים את https://example.com, צריך להציב את קובץ האימות (attestation) בכתובת https://example.com/.well-known/privacy-sandbox-attestations.json. אי אפשר להשתמש בהפניות אוטומטיות מסוג HTTP כדי להציג את קובץ האימות. קובץ האימות צריך להיות ממוקם בתיקייה .well-known באתר. היא לא יכולה להפנות למיקום אחר (למשל, לתת-דומיין או לאתר אחר).
עליכם לפעול בהתאם לאישורים ולשמור את קובץ האימות במיקום שלו למשך כל תקופת ההרשמה. קובצי האימות עוברים אימות באופן סדיר, ואם הם לא יישמרו למשך זמן רב, קריאות ל-API ייכשלו עד שהקובץ ישוחזר.
הערה:
- ארגז החול לפרטיות מריץ משימה בצד השרת כדי לאחזר את קובץ האימות מטכנולוגיות הפרסום הרשמות, וליצור רשימת היתרים על סמך תוכן הקובץ. לאחר מכן, רשימת ההיתרים הזו תסונכרן עם הדפדפן ועם מערכת ההפעלה. המשימה הזו לא תאחזר את הקובץ יותר מפעם בשעה.
- המטרה היא שקובץ האימות יהיה זמין לציבור. טכנולוגיית הפרסום אמורה לצפות לקבל בקשות אחזור מסוימות מגורמים חיצוניים, כולל חוקרים, רשויות רגולטוריות ומשתמשים (מעבר לבקשות האחזור מהתשתית של ארגז החול לפרטיות). טכנולוגיות הפרסום חייבות להציג להן את אותו קובץ שהן מציגות ל-Google.
- כל קריאה ל-API לא תפעיל בקשת אחזור לקובץ האימות (attestation).
בנוגע לאימות של Topics ב-Android, מפתחי אפליקציות ו-SDK צריכים לאשר את האימות בטופס ההרשמה, ולא צריכים להציב קובץ אימות בשרת שלהם, אלא אם הם משתמשים בממשקי API אחרים של ארגז החול לפרטיות.
עדכון האימות כדי להוסיף ממשקי API נוספים
אם תחליטו לכלול ממשקי API נוספים בהרשמה במועד מאוחר יותר, תצטרכו לעדכן את ההרשמה. במסגרת התהליך הזה, יישלח אליך קובץ אימות (attestation) מעודכן שיהיה זמין מהנתיב .well-known באתר שלך, כדי שתהיה לך אפשרות לקרוא לממשקי ה-API החדשים.
עדכון לגרסה האחרונה של קובץ האימות (attestation)
כל החברות הרשומות צריכות לעדכן לגרסה האחרונה של קובץ האימות (attestation) שהן קיבלו מ-Google.
תוקף קובצי האימות לא פג אחרי פרק זמן מסוים. יכול להיות שקובצי אימות (attestation) חדשים או מעודכנים יסופקו מדי פעם כשמסגרת האימות (attestation) מתפתחת (לדוגמה, נוספים אימותים חדשים שספציפיים ל-API וכן הלאה).
שגיאות חד-פעמיות
הגישה תיחתך רק אם השרת שבודק את קובץ האימות לא מצליח שוב ושוב לאמת אותו. שגיאה אחת או בעיה אחת בהצגה לא יגרמו להסרת הגישה.
למידע נוסף, עיינו במאמר GitHub על אימותים.
נתונים של מפתחי Android
ישויות שמתכוונות להשתמש בממשקי ה-API של Sandbox לפרטיות ב-Android מקבלות מזהה חשבון הרשמה, שאפשר לכלול בהגדרת AdServices של האפליקציה. כך מפתחי האפליקציות יכולים לקבל שליטה פרטנית על טכנולוגיות הפרסום שהאפליקציה או ערכות ה-SDK שלהם מקיימים אינטראקציה איתן.