בעדכונים האלה נשתף סיכום של התפתחויות חדשות ועדכונים לגבי הצעות העיצוב, שאלות מרכזיות ומשוב שקיבלנו, ועדכונים לגבי הגרסאות המקדמות למפתחים.
אלבומים חדשים
השקה של Developer Preview 7
הגרסה הזו היא ציון דרך חשוב ומהווה את הבסיס לגרסאות הבטא הבאות של ארגז החול לפרטיות. הגרסה הזו כוללת פונקציונליות נוספת: תמיכה ברשימת הרשתות בתהליך בחירת הרשת של Protected Audience, הפניה אוטומטית מסוג daisy-chain לדיווח על אירוע דוחות שיוך (Attribution) ושינויים נוספים ב-API.
נמשיך לעדכן את המשאבים של Developer Preview כשנוציא תכונות חדשות בחודשים הקרובים. אנחנו ממליצים לכם להירשם לקבלת עדכונים לגבי היוזמה.
גרסת הבטא של מרץ 2023 זמינה
הגרסה הזו מייצגת את הזמינות של ממשקי API של ארגז החול לפרטיות במכשירים ציבוריים, והיא מקבילה מבחינה פונקציונלית ל-Developer Preview 6. מפתחים יכולים לגשת לממשקי ה-API במהדורות הבטא דרך Extension SDK.
עדכון על ציר הזמן לגרסאות טרום-השקה למפתחים
כל התאריכים והפרטים כפופים לשינויים
לכל גרסת בטא וגרסת בטא למפתחים יהיו נתוני גרסה ומדריכים מפורטים שמתארים איזו פונקציונליות היא זמינה בכל גרסה.
התכונות האלה זמינות עכשיו:
- Developer Preview 7 – כולל פונקציונליות שמאפשרת לתכנן שילוב באמצעות ממשקי API רלוונטיים,כולל זמן הריצה של ה-SDK, Topics, Protected Audience וממשקי API לדיווח על שיוך (Attribution).
- תוכנית בטא שזמינה לבדיקה מוגבלת בסביבת הייצור. גרסת הבטא שפורסמה במרץ 2023 מייצגת את הזמינות של ממשקי ה-API של ארגז החול לפרטיות במכשירים ציבוריים, והיא זהה מבחינה פונקציונלית לתצוגה המקדימה למפתחים 6.
בתחילת 2023:
- הגרסה היציבה הראשונה של ממשקי ה-API לשמירה על הפרטיות, בקרב אחוז קטן של מכשירי Android 13.
עד 2023:
- גרסאות נוספות של תצוגות מקדימות למפתחים וגרסאות יציבות של ממשקי API עם פונקציונליות נוספת. הרחבה למספר גדול יותר של משתמשים ומכשירי Android.
תזכורת: כשהכרזנו על 'ארגז החול לפרטיות' ב-Android בפברואר, הדגשנו שאנחנו מתכננים לתמוך בתכונות הקיימות של פלטפורמת המודעות למשך שנתיים לפחות בזמן שאנחנו מתכננים, מפתחים ובודקים את הפתרונות החדשים האלה. בנוסף, אנחנו מתכוונים להודיע מראש על שינויים עתידיים.
עדכונים לגבי הצעה לעיצוב
בקטע הזה מתוארים כמה עדכונים ספציפיים להצעות העיצוב.
ממשקי Reflection API
בהצעה המקורית שלנו לתכנון של זמן הריצה ל-SDK, ביקשנו משוב על ההצעה שלנו למנוע גישה לשיקוף ולקריאה לממשקי API, במטרה לעזור למפתחי SDK למנוע פגיעה מערכות SDK אחרות.
קיבלנו משוב חשוב לגבי תרחישי שימוש שהושפעו, ולאחר בדיקה נוספת של התועלת והסיכונים, נאפשר שימוש בהשתקפות (reflection) והפעלה של ממשקי API בסביבת זמן הריצה של ה-SDK. עדכנו את הצעת העיצוב שלנו בהתאם.
עם זאת, ל-SDK לא תהיה הרשאה להשתמש בממשק API באמצעות השתקפות או הפעלה של ממשקי API בערכת SDK אחרת שתואמת לזמן ריצה. במקום זאת, עבור תקשורת SDK ל-SDK בזמן הריצה של ה-SDK, אנחנו מעצבים ממשקי API נפרדים לגילוי SDK, שיהיו מפורטים בעדכון עתידי.
אנחנו ממשיכים לבחון דרכים להפחתת הסיכון לפגיעה על ידי ערכות SDK אחרות. לכן אנחנו עדיין מציעים למנוע את השימוש בקוד JNI בתוך זמן הריצה של ה-SDK, ואנחנו שוקלים באופן פעיל ממשקי API אחרים. נשתף הצעה מלאה של ממשקי API אסורים בעדכון עתידי.
Attribution Reporting API
- על סמך המשוב שקיבלנו, הוספנו דוגמה שמראה איך אירועי צפייה, קליקים והמרות יכולים להירשם על ידי כמה גורמים מעורבים. הוספנו שאלות פתוחות ושיקולים לעתיד חדשים, ואנחנו מבקשים מכם לשלוח לנו משוב עליהם.
Topics API
- Topics API מחזיר רשימה של עד 3 נושאים, אחד לכל אחד מ-3 הזמנים הקודמים (לדוגמה, במהלך 3 השבועות האחרונים). עדכנו את הצעה הטכנית של Topics API כדי להבהיר שהנושאים שמוחזרים מייצגים את תחומי העניין של המשתמש, ואפשר להשתמש בכל אחד מהנושאים שמוחזרים או בכלם כדי להתאים אישית מודעות.
סיכום של השאלות הנוספות והמשוב שהתקבלו
בקטע הזה מוצגות כמה מהשאלות והמשוב שקיבלנו, יחד עם התשובות שלנו.
שאלות כלליות
- האם ארגז החול לפרטיות ב-Android יחול על מכשירי טלוויזיה מחוברים?
- הצעות העיצוב הנוכחיות שלנו מתמקדות בתמיכה בתרחישי שימוש במכשירים ניידים ובאפליקציות. אנחנו מתכננים לשתף מידע נוסף על גורמי צורה אחרים של Android בעתיד.
- איך ארגז החול לפרטיות ב-Android יושק במכשירים לתוכנית הבטא?
- כדי לשחרר עדכונים למשתמשים בצורה גמישה לאורך זמן, הרכיבים העיקריים יופצו כמודולים של Mainline למכשירים ניידים נתמכים עם Android. כך נוכל לספק שיפורים למכשירים נתמכים בצורה חלקה, מחוץ למחזור הגרסאות הרגיל של פלטפורמת Android.
- מה התוכניות שלך לתמיכה של Kotlin?
- אנחנו עובדים על שיפור העיצוב של Privacy Sandbox API, ואנחנו מתכוונים לאפשר למפתחים לכתוב קוד Kotlin שתואם לשפה. משאבים קשורים למפתחים, כמו אפליקציות לדוגמה בתצוגה המקדימה למפתחים, זמינים ב-Kotlin (בנוסף ל-Java).
- מהם אמצעי הבקרה ברמת המשתמש של ארגז החול לפרטיות, ומהן לוחות הזמנים הצפויים להשקה של אמצעי הבקרה האלה?
העיצובים הסופיים עדיין נמצאים בפיתוח, אבל במהלך תקופת הבטא אנחנו מתכוונים לספק למשתמשים אמצעי בקרה בהגדרות המכשיר כדי:
- עזיבת הפתרונות של ארגז החול לפרטיות או הצטרפות מחדש
- הסרת נושאים ספציפיים שהמערכת הסיקה מ-Topics API
- האם מערכות אקולוגיות של חנויות אפליקציות שאינן Google Play יכולות להשתמש בפתרונות של ארגז החול לפרטיות?
כל הפתרונות של ארגז החול לפרטיות הם חלק מפרויקט Android Open Source Project (AOSP), כך שחנויות אפליקציות אחרות יכולות לאמץ אותם אם ירצו. מומלץ לפנות לחנויות האפליקציות שאיתן אתם עובדים כדי להבין טוב יותר את התוכניות שלהן.
זמן ריצה ל-SDK
- איך יתבצע ניהול הגרסאות של ערכות ה-SDK בהתאם להצעות האלה? האם אפליקציות יוכלו לשלוט ביחסי התלות של גרסאות ה-SDK אם ספקים יוכלו לעדכן את ערכות ה-SDK שלהם באופן עצמאי?
אנחנו עובדים על כך כרגע. אחת מהגישות שנבחנות היא שמפתחי SDK יצטרכו לציין את גרסת
major.minor.patchשל כל SDK שהם יבחרו להפיץ דרך חנות אפליקציות שתומכת בסביבת זמן הריצה של ה-SDK.לאחר מכן, מפתחי האפליקציות יכולים לבחור את גרסת
major.minorשהם רוצים להסתמך עליה, על ידי הצהרה עליה במניפסט של האפליקציה. עדכון התיקון האחרון לגרסה הזו שלmajor.minorיותקן עד לפרסום התיקון הבא (שגם הוא יותקן באופן אוטומטי), או עד שמפתח האפליקציה יבנה מחדש את האפליקציה ויצוין בה תלות בגרסה אחרת שלmajor.minor.- לאילו סוגים של ערכות SDK מיועד זמן הריצה של ה-SDK?
הגרסה הראשונית של זמן הריצה ל-SDK תוכננה לתמוך בתרחישי שימוש של ערכות SDK שקשורות לפרסום, כולל ערכות SDK שמאפשרות הצגת מודעות, מדידת מודעות, זיהוי הונאות בפרסום וזיהוי ניצול לרעה.
ההתמקדות הראשונית היא ב-SDKs שקשורים לפרסום, אבל מפתחים של SDKs שאינם קשורים לפרסום שרוצים לתמוך בפרטיות וסבורים שהם יכולים לפעול בתנאים שמפורטים למעלה יכולים לשתף משוב על ה-SDKs שלהם שפועלים בסביבת זמן הריצה של ה-SDK.
- אנחנו משתמשים כרגע בהרשאות שאינן מצוינות בהצעה בתרחישי השימוש שלנו. האם נוכל לבקש הרשאות נוספות?
אנחנו רוצים להבין תרחישי שימוש שקשורים לפרסום, שבהם נדרשות הרשאות גישה ספציפיות מעבר לאלה שציינו בהצעת העיצוב הראשונית שלנו.
- האם העברת ערכות SDK לתהליך SDK Runtime תביא לחיסכון בגודל ההורדה או במקום האחסון?
אם כמה אפליקציות משולבות עם ערכות SDK נפרדות שפועלות בסביבת זמן ריצה באותה גרסה, אפשר לחסוך בגודל ההורדה ובמקום בדיסק.
- האם הרשאת ה-SDK לגשת ל-AAID (AD_ID) תלויה בהרשאות של האפליקציה?
היכולת של RE SDK לגשת ל-AAID תלויה בהצהרה של האפליקציה ושל ה-SDK על ההרשאה במניפסט של האפליקציה. בעדכון עתידי של ההצעה, נספק פרטים על ה-API שערכות ה-SDK יוכלו להשתמש בו כדי לקבל את AAID, אם יש להן את ההרשאה.
- כתובות IP, גרסאות של מערכות הפעלה ונתונים חלופיים: האם הם יהיו זמינים לערכות SDK שקשורות לפרסום?
אנחנו עובדים כרגע דרך מאפייני המערכת שאליהם תהיה גישה לערכות SDK שקשורות לפרסום, ונשתף את המידע הזה בעדכון עתידי של הצעה לעיצוב. לא פרסמנו מדיניות כלשהי לגבי השימוש בנכסים האלה.
- האם מזהה קבוצת האפליקציות שמערכת ה-SDK שלנו אוספת באפליקציות רבות זהה, גם כשהאפליקציות האלה שייכות לחשבונות פיתוח שונים ב-Google Play? איך אפשר לחסום משתמשים שמבצעים תרמיות בכמה אפליקציות בלי AAID?
לאפליקציה או לכל אחת מערכות ה-SDK שלה יכולה להיות גישה רק לערך של מזהה קבוצת האפליקציות שמשויך לחשבון המפתח של האפליקציה המארחת ב-Google Play. בארגז החול לפרטיות ב-Android לא יוצע מזהה בין בעלי תוכן דיגיטלי למטרות הונאה. בינתיים, מפתחים יכולים להשתמש ב-IP כחלופה פחות עקבית.
נושאים
- האם אפשר לראות רשימה של כל הנושאים האפשריים שיכולים להוחזר על ידי ה-API?
- למטרות בדיקה, בגרסת Developer Preview 1 נעשה שימוש בנושאים מהטקסונומיה הזו, שעשויה להשתנות. אנחנו מצפים להתפתח עם הזמן על סמך משוב מהסביבה העסקית.
- אם קטגוריית Topics עשויה להשתנות, איך נוכל להביא בחשבון את השינויים האלה במודלים של צד הקנייה במורד הזרם?
- התגובה של Topics API תכלול מספר גרסה של הסיווג והטקסונומיה.
Protected Audience ב-Android
- האם תהיה תמיכה בטירגוט באמצעות החרגות ב-Protected Audience?
הצעת העיצוב הנוכחית לא תומכת בטירגוט שלילי שמבוסס על קהל מותאם אישית ב-Protected Audience.
בקמפיינים להתקנת אפליקציות, נציע פונקציונליות של סינון מודעות כדי שספקי טכנולוגיות הפרסום יוכלו לסנן אפליקציות שכבר מותקנות. אנחנו גם בודקים איך ניתן לתמוך בצרכים של סינון שלילי בקמפיינים על בסיס מכסת תדירות. פרטים נוספים יפורסמו בעדכונים הבאים של הצעת העיצוב.
- האם רשתות המודעות של בתי עסק יכולות ליצור קהלים בהתאמה אישית? או שהן מוגבלות לרשתות המודעות של הקונה?
ההצעה הנוכחית שלנו לגבי קהלים בהתאמה אישית מתמקדת בתרחיש לדוגמה של צד הקנייה, מכיוון שהם נועדו לתמוך ביצירת הצעות מחיר מצד הקנייה בתרחיש לדוגמה של רימרקטינג, תוך שמירה על הפרטיות.
דוחות שיוך (Attribution)
- האם ממשקי ה-API של ארגז החול לפרטיות יפעלו יחד כדי לתמוך בתרחישים לדוגמה מאתר לאפליקציה ומאפליקציה לאתר?
- אנחנו בודקים תרחישי שימוש שבהם אפליקציית דפדפן בנייד קוראת ל-Attribution Reporting API ל-Android כדי לאפשר שיוך בין האפליקציה לאינטרנט באותו מכשיר. אם תבחרו להפעיל את התכונה 'מעבר מאפליקציה לאינטרנט', ארגז החול לפרטיות לממשקי API של Android ישמש לאחסון ולשיוך, ויתבצע בו הסרת כפילויות של שיוך בין האפליקציה לאינטרנט (עם זאת, יכול להיות שתקבלו מה-API דוחות נפרדים לאפליקציה ולאינטרנט, ותצטרכו לשלב אותם).
- האם ה-API תומך במודלים אחרים של שיוך מלבד הקליק האחרון?
- ה-API תומך במודל שיוך (Attribution) של מגע אחרון לתעדוף המקור. בנוסף, ההצעה תומכת בלוגיקה אופציונלית של שיוך (Attribution) כדי שההמרות לאחר ההתקנה ישויכו לקליק או לצפייה שהובילו להתקנה.
- האם ארגז החול לפרטיות ישפיע על נתוני הפניות להתקנה מ-Play?
על סמך התכנון והתוכניות הנוכחיים, ממשקי ה-API של ארגז החול לפרטיות לא ישפיעו על הפונקציונליות ש-Play Install Referrer מספק.
מפתחים מסוימים זיהו פורמטים של מודעות שבהם אפשר "לתגמל" משתמשים על השלמת אירועים ספציפיים לאחר הקליק. ללא שיוך ברמת המשתמש, זה יהיה אתגר לפי ההצעות הנוכחיות.
אנחנו בודקים את הנושא כדי למצוא פתרונות אפשריים. אנחנו מעודדים משוב נוסף על התרחיש לדוגמה הזה ועל תרחישים אחרים לדוגמה.
- למה השיוך מתבצע בנפרד לכל פלטפורמת טכנולוגיית פרסום?
כיום, מפרסמים רבים סבורים שחשוב לקבל תצוגה ללא כפילויות של אירועי ההמרה שלהם ברשתות השונות, ויש שימוש נפוץ בשותף למדידת ביצועים בנייד (MMP). זה עדיין יהיה קל לשימוש בממשקי ה-API החדשים, אבל גם פלטפורמות טכנולוגיות שונות או מפרסמים יוכלו לבצע מדידה ישירות אם יש רצון לעשות זאת.
השימוש בהפניות אוטומטיות מאפשר לכם להימנע מהצורך להטמיע פיזית את ה-SDK בכל אפליקציה, אבל כן נדרש לכם קשר עם ערכות ה-SDK של טכנולוגיות הפרסום כדי להשתתף בתהליך ההפניה האוטומטית.
אחד היתרונות העיקריים של הגישה הזו הוא שלכל משתמש יכולים להיות מפתחות מטא-נתונים ומפתחות צבירת נתונים משלו, בהתאם ללוגיקה העסקית שלו, וגם להגדיר את העדיפות שלו.
- האם יש אימות או אימות התקנות מחנות Play?
המערכת משתמשת בהתקנות מאומתות רק לצורך לוגיקה אופציונלית של שיוך המרות לאחר ההתקנה. ה-API לא ישלח את ההתקנות המאומתות האלה. ה-API ישלח דוחות רק על סמך ההמרות שרשמות, ולא יחזיר אות לגבי ההתקנה הקודמת של האפליקציה על ידי המשתמש.
- האם אתם מבצעים אימות של קליקים או צפיות? האם נדרש משך זמן מינימלי לאימות תצוגה מפורטת?
הצעת ה-API הנוכחית תומכת באימות בסיסי של קליקים באמצעות קלטEvent. אנחנו בודקים דרכים מתקדמות יותר לאימות קליקים ולאימות צפיות. אנחנו מעודדים אתכם לשלוח משוב נוסף לגבי תרחישי השימוש האלה, במיוחד לגבי סוגי הגדרות התצוגה שיכולות להועיל לסביבה העסקית.