כדי לקבל גישה לממשקי ה-API של הרלוונטיות והמדידה של ארגז החול לפרטיות ב-Chrome וב-Android, המפתחים צריכים להירשם במסגרת ארגז החול לפרטיות. נכללים בכך דוחות שיוך (Attribution), Protected Audience, Topics, צבירה פרטית ונפח אחסון משותף. רישום מפתחים מספק מנגנון לאימות הישויות שקוראות לממשקי ה-API האלה, ולאיסוף הנתונים הספציפיים למפתחים הנדרשים כדי להגדיר כראוי את ממשקי ה-API של ארגז החול לפרטיות ולהשתמש בהם. תהליך הרישום הזה מוסיף עוד שכבת הגנה, בנוסף להגבלות המבניות שנאכפות בכל API, על ידי הוספת שקיפות לגבי האנשים שאוספים את הנתונים ומפחית את הניסיונות לשימוש לרעה בממשקי ה-API כדי לאסוף יותר נתונים ממה שהתכוונתם. כדי לספק שקיפות שמאפשרת ביקורת, פרטי ההרשמה של החברה יהיו גלויים לכולם. חברות צריכות לתכנן לפחות חמישה שבועות להשלמת תהליך ההרשמה, מהמועד שבו הן משלחות את טופס ההרשמה. הנתון הזה כולל זמן לטיפול בבעיות בשליחת הטופס או בבעיות אחרות שעשויות להיות. העמידה בתנאים האלה לא כוללת שלבי הכנה פנימיים נוספים לפני שליחת הטופס.
לפני שמתחילים
לפני תחילת ההרשמה, חשוב לוודא שיש לכם מספר D-U-N-S של הארגון. זהו מספר ייחודי בן 9 ספרות שמסופק על ידי Dun & Bradstreet ומשמש לזיהוי העסק שלכם. הוא נבדק כחלק מתהליך אימות הרישום לארגז החול לפרטיות. אם לחברה שלך הונפקו כמה מספרי 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 בקנה מידה נרחב, תצטרכו לספק את כל המקורות שבהם אתם משתמשים.
- אם אתם מפתחי אפליקציות והאפליקציה שלכם שולחת קריאה ישירה לממשקי ה-API של Attribution, Protected Audience או שני ממשקי ה-API, עליכם לספק את האתר במהלך ההרשמה.
- אם אתם מפתחי אפליקציות ומעניקים לכם גישה מלאה לפונקציונליות המודעות ל-SDK, אין צורך לבצע את תהליך הרישום.
כל אתר או SDK שמפעילים את ממשקי ה-API של ארגז החול לפרטיות מחייבים רישום ייחודי וצריך לאמת אותם בנפרד. אפליקציות שמבצעות קריאה ישירה לממשקי ה-API של ארגז החול לפרטיות יכולות להיכלל ברישום אחד. אם אתם מתכננים להפעיל מספר ממשקי API, צריך לציין כל אחד מהם בתהליך הרישום. הערה: האתר שאיתו נרשמים הוא אותו האתר שישמש לאחזור מפתחות ההצפנה לשימוש ב-Topics ב-Android, ומפתח החתימה לשימוש ב-Protected Audience API ב-Android. מידע נוסף על נקודת הקצה להצפנה ב-Topics ב-Android ומידע נוסף על חתימת מפתחות של Protected Audience.
עדכון פרטי ההרשמה
אפשר לעדכן את פרטי ההרשמה באמצעות טופס ההרשמה. העדכונים יחליפו את התשובות הקודמות.
לוח הזמנים להרשמה
אחרי שתשלחו את טופס ההרשמה, נבדוק את הבקשה ונטפל בה. בסיום הבדיקה נשלח לך הודעת אישור באימייל עם מספר חשבון מפתח ייחודי וקובץ אימות (attestation). הקובץ צריך להיות זמין לציבור מהנתיב של /.well-known באתר שאליו הוא נרשם, תוך 30 ימים ממועד קבלת מזהה החשבון וקובץ האימות (attestation). מפתחי 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 אחת, צריך למלא את טופס התהליך של בקשת הרשמה למספר חשבונות בנוסף לטופס ההרשמה הרגיל להרשמה הראשונה שאתם מבקשים. לאחר השליחה, הבקשה תיבדק ותקבלו אימייל כשתהליך הבדיקה יסתיים.
אפשר לשלוח כמה הרשמות עם אותו מספר D-U-N-S
אם אתם מגישים בקשה למספר הרשמות באמצעות טופס הבקשה להרשמה למספר חשבונות, אפשר להשתמש באותו מספר D-U-N-S בכל הרשמה.
הפניה אוטומטית עם דיווח שיוך (Attribution)
נבחן תרחיש שבו אתר א' לא רשום אבל אתר ב' רשום. ARA יבצע פינג לכתובות URL להפניה אוטומטית, גם אם לא נרשם. כתוצאה מכך, ההפניה האוטומטית מ-siteA.com אל siteB.com תעבוד. עם זאת, מקורות וטריגרים יירשמו רק מטכנולוגיות פרסום רשומות.
הרשמה לשירות צבירת נתונים
יש כרגע תהליך רישום נפרד לרכיבי שרת ולממשקי API של לקוח (ל-Chrome ול-Android). כדי להשתמש בשירות הצבירה, חובה למלא את שני טופסי הרישום. אנחנו שואפים לייעל את התהליכים. נכון לעכשיו, לשירות הצבירה יש טופס נפרד. במהלך הרישום לשירות צבירת הנתונים, אתם תירשמו באמצעות אתר שעליו אותו אתר (סכימה, eTLD+1) יהיה רשום באמצעות רישום מפתחים.
כל הרשמה לשירות צבירה חייבת לכלול את מזהה חשבון AWS או את מזהה הפרויקט ב-GCP, שבו שירות הצבירה יופעל. אפשר לקשר כל חשבון AWS או GCP רק להרשמה אחת לשירות צבירה.
העלאה של קובץ אימות (attestation)
אחרי שתירשמו ותעברו את תהליך האימות, נשלח לכתובת האימייל שסיפקתם קובץ שמכיל את האימותים הספציפיים ל-API. תוכלו להטמיע את קובץ האימות תוך 30 יום ממועד הקבלה של מספר החשבון וקובץ האימות. בזמן הזה עדיין תהיה לך אפשרות לקרוא לממשקי ה-API במשך 30 יום, אבל במהלך התקופה הזו יהיה עליך לפעול בהתאם לשפת האימות.
כדי להשלים את ההרשמה, צריך להגדיר את הקובץ כזמין מהנתיב הציבורי של .well-known באתר שנרשם. לדוגמה, אם רושמים את https://example.com, צריך להציב את קובץ האימות (attestation) בכתובת https://example.com/.well-known/privacy-sandbox-attestations.json. אי אפשר להשתמש בהפניות HTTP כדי להציג את קובץ האימות (attestation). קובץ האימות חייב להיות בספרייה .well-known באתר. היא לא יכולה להפנות למיקום אחר (למשל, לתת-דומיין או לאתר אחר).
תצטרכו לפעול בהתאם לאימותים ולהשאיר את קובץ האימות בתוקף למשך תקופת הרישום. קובצי האימות מאומתים באופן שגרתי. אם לא תשמרו אותם למשך זמן ממושך, קריאות ל-API ייכשלו עד שהקובץ ישוחזר.
הערה:
- בארגז החול לפרטיות יופעל משימה בצד השרת כדי לאחזר את קובץ האימות מטכנולוגיות פרסום רשומות, וליצור רשימת היתרים על סמך תוכן הקובץ. לאחר מכן, רשימת ההיתרים הזו תסונכרן עם הדפדפן ועם מערכת ההפעלה. המשימה הזו לא תאחזר את הקובץ יותר מפעם בשעה.
- המטרה היא שקובץ האימות יהיה זמין לציבור. טכנולוגיות הפרסום אמורות לצפות לבקשות אחזור מגורמים חיצוניים, כולל חוקרים, רגולטורים ומשתמשים (מחוץ לבקשות האחזור מארגז החול לפרטיות). טכנולוגיות הפרסום חייבות להציג להן את אותו קובץ שהן מציגות ל-Google.
- כל קריאה ל-API לא תפעיל בקשת אחזור לקובץ האימות (attestation).
מפתחי אפליקציות ו-SDK צריכים לאשר את האימות בטופס ההרשמה ל-Topics API ב-Android, והם לא צריכים להגיש קובץ אימות (attestation) בשרת שלהם אלא אם הם משתמשים בממשקי API אחרים של ארגז החול לפרטיות.
צריך לעדכן את האימות (attestation) כדי להוסיף עוד ממשקי API
אם בהמשך תחליטו לכלול ממשקי API נוספים ברישום, תצטרכו לעדכן את הרישום. במסגרת התהליך הזה, יישלח אליך קובץ אימות (attestation) מעודכן שיהיה זמין מהנתיב .well-known באתר שלך, כדי שתהיה לך אפשרות לקרוא לממשקי ה-API החדשים.
עדכון לגרסה האחרונה של קובץ האימות (attestation)
כל החברות הרשומות צריכות לעדכן לגרסה האחרונה של קובץ האימות (attestation) שהן קיבלו מ-Google.
התוקף של קובצי האימות לא פג אחרי פרק זמן מוגדר. יכול להיות שקובצי אימות (attestation) חדשים או מעודכנים יסופקו מדי פעם כשמסגרת האימות (attestation) מתפתחת (לדוגמה, נוספים אימותים חדשים שספציפיים ל-API וכן הלאה).
שגיאות חד-פעמיות
הגישה תיחתך רק אם השרת שבודק את קובץ האימות לא מצליח שוב ושוב לאמת אותו. שגיאה אחת או בעיה אחת בהצגת המודעות לא יגרמו להסרת הגישה.
למידע נוסף, ראו GitHub על אימותים.
נתונים של מפתח Android
לישויות שמתכוונות להשתמש בממשקי ה-API של ארגז החול לפרטיות ב-Android, נשלח מספר חשבון רישום, שאפשר לכלול בהגדרות AdServices של האפליקציה. כך מפתחי האפליקציות יכולים לקבל שליטה פרטנית על טכנולוגיות הפרסום שהאפליקציה או ערכות ה-SDK שלהם מקיימים אינטראקציה איתן.