מאז ההכרזה הראשונית בפברואר 2022, קיבלנו משוב משותפים ברחבי הסביבה העסקית של Android. אנחנו מעריכים את כל המשוב שלכם וממשיכים להזמין אתכם להמשיך לשתף משוב ושאלות.
במסגרת עדכוני ההתקדמות האלה נשתף סיכום של ההתפתחויות והעדכונים החדשים בהצעות העיצוב, שאלות מפתח ומשוב שקיבלנו, ועדכוני גרסאות בתצוגה המקדימה למפתחים.
אלבומים חדשים
הגרסה המקדימה למפתחים 7 הושקה
הגרסה האחרונה הזו היא אבן דרך חשובה שהיא הבסיס לגרסאות הבטא הבאות של ארגז החול לפרטיות. הגרסה הזו כוללת פונקציונליות נוספת בתמיכה בתהליך בחירת הרשת (Mediation) ב-Waterfall של Protected Audience API, הפניות אוטומטיות מסוג שרשראות (daisy-chain) לדיווח על אירועי שיוך (Attribution) ושינויים אחרים ב-API.
נמשיך לעדכן את המשאבים של התצוגה המקדימה למפתחים, ובחודשים הקרובים נשיק פונקציונליות חדשה. אנחנו ממליצים לשתף משוב או שאלות ולהירשם לקבלת עדכונים ביוזמה.
גרסת הבטא של מרץ 2023 הושקה
הגרסה הזו מייצגת את הזמינות של ממשקי ה-API של ארגז החול לפרטיות במכשירים ציבוריים, והיא זהה מבחינה פונקציונלית לגרסת תצוגה מקדימה למפתחים 6. מפתחים יכולים לגשת לממשקי ה-API בגרסאות בטא דרך Extension SDK.
עדכון על לוח הזמנים של גרסאות טרום-השקה למפתחים
כל התאריכים והפרטים עשויים להשתנות
כל גרסה של תצוגה מקדימה למפתחים וגרסת בטא כוללות נתוני גרסה ומדריכים מפורטים שמתארים איזו פונקציונליות זמינה ואילו לא זמינה בכל גרסה.
זמין עכשיו:
- תצוגה מקדימה 7 למפתחים – כוללת פונקציונליות שמאפשרת לתכנן שילוב באמצעות ממשקי API רלוונטיים,כולל זמן הריצה ל-SDK , Topics, Protected Audience ו-Attribution Reporting API
- תוכנית הבטא זמינה לבדיקות ייצור מוגבלות. גרסת הבטא של מרץ 2023 מייצגת את הזמינות של ממשקי ה-API של ארגז החול לפרטיות במכשירים ציבוריים, והיא מקבילה מבחינה פונקציונלית לגרסת Preview 6 למפתחים.
תחילת 2023:
- מהדורת API יציבה ראשונה של ממשקי ה-API לשמירה על הפרטיות בקרב אחוז קטן ממכשירי Android 13.
עד 2023:
- איטרציות נוספות לגרסאות מקדימות למפתחים ולגרסאות API יציבות עם פונקציונליות נוספת. הרחבה למשתמשים ולמכשירי Android נוספים.
תזכורת: כאשר הודענו על ארגז החול לפרטיות ב-Android בפברואר, הדגשנו שבעוד שאנחנו מתכננים, מפתחים ובודקים את הפתרונות החדשים, אנחנו מתכננים לתמוך בתכונות הקיימות של פלטפורמות המודעות למשך שנתיים לפחות. אנחנו מתכננים לספק הודעה משמעותית לפני שינויים עתידיים.
עדכונים לגבי הצעה לעיצוב
חלק זה מתאר כמה עדכונים ספציפיים בהצעות העיצוב.
ממשקי API של Reflection
בהצעה המקורית שלנו לעיצוב זמן ריצה ל-SDK, ביקשנו משוב על ההצעה למנוע גישה להשתקפות ולהפעיל ממשקי API, במטרה לעזור למפתחי SDK למנוע פגיעה על ידי ערכות SDK אחרות.
קיבלנו משוב חשוב על תרחישי השימוש שהושפעו, ולאחר בדיקה נוספת של כלי השירות והסיכונים, נאפשר שימוש בשיקוף ובהפעלת ממשקי API בתוך זמן הריצה של ה-SDK. כמו כן, עדכנו את הצעות העיצוב שלנו בהתאם.
עם זאת, ב-SDK לא תהיה הרשאה להשתמש בשיקוף או להפעיל ממשקי 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 למכשירים של גרסת הבטא?
- כדי לפרסם עדכונים באופן גמיש למשתמשים לאורך זמן, הרכיבים העיקריים יופצו כמודולים ראשיים למכשירים ניידים נתמכים עם Android. כך נוכל לספק שיפורים למכשירים נתמכים בצורה חלקה ויעילה, מחוץ למחזור הגרסאות הרגיל של פלטפורמת Android.
- מה דעתך על התמיכה ב-Kotlin?
- אנחנו עובדים על חזרה על העיצוב של ה-API של ארגז החול לפרטיות, ומתכוונים לאפשר למפתחים לכתוב קוד אידיומטי ב-Kotlin. משאבים קשורים למפתחים, כמו אפליקציות לדוגמה בתצוגה המקדימה למפתחים, זמינים ב-Kotlin (בנוסף ל-Java).
- מהם אמצעי הבקרה ברמת המשתמש של ארגז החול לפרטיות ומהם לוחות הזמנים הצפויים להשקה של אמצעי הבקרה האלה?
העיצובים הסופיים עדיין בשלבי פיתוח, אבל בשלב הבטא אנחנו מתכוונים לספק אמצעי בקרה למשתמשים בהגדרות המכשיר כדי:
- עזיבת הפתרונות של ארגז החול לפרטיות או הצטרפות אליהם מחדש
- הסרת נושאים ספציפיים שהוסקו מה-Topics API
- האם סביבה עסקית של חנויות אפליקציות, שהן לא Google Play, יכולה להשתמש בפתרונות של ארגז החול לפרטיות?
כל הפתרונות של ארגז החול לפרטיות הם חלק מפרויקט הקוד הפתוח של Android (AOSP), כך שחנויות אפליקציות אחרות יכולות להשתמש בהם אם רוצים. מומלץ לפנות לחנויות האפליקציות שאיתן אתם עובדים כדי להבין טוב יותר את התוכניות שלהן.
זמן ריצה ל-SDK
- איך ינוהלו גרסאות ערכות SDK במסגרת ההצעות האלה? האם אפליקציות יוכלו לשלוט ביחסי תלות בין גרסאות ה-SDK אם ספקים יכולים לעדכן את ערכות ה-SDK שלהם באופן עצמאי?
זה כרגע בשלבי תכנון. אחת מהגישות שבשיקולים היא שמפתחי SDK מציינים את גרסת
major.minor.patchשל כל SDK שהם בוחרים להפיץ דרך חנות אפליקציות שתומכת בזמן הריצה ל-SDK.לאחר מכן, מפתחי האפליקציות יוכלו לבחור את גרסת
major.minorשהם רוצים להסתמך עליה על ידי הצהרה על כך בקובץ המניפסט של האפליקציה. גרסת התיקון האחרונה של אותה גרסתmajor.minorתותקן עד שהתיקון הבא יופץ (שעצמו יותקן באופן אוטומטי) או עד שמפתח האפליקציה יבנה מחדש את האפליקציה עם ציון תלות שונה של גרסתmajor.minor.- לאילו סוגים של ערכות SDK מיועד זמן הריצה של ה-SDK?
הגרסה הראשונית של זמן הריצה ל-SDK תוכננה לתמוך בתרחישים לדוגמה שקשורים לערכות SDK שקשורות לפרסום, כולל ערכות SDK שמאפשרות הצגת מודעות, מדידת מודעות, הונאות במודעות וזיהוי ניצול לרעה.
ההתמקדות הראשונית היא בערכות SDK שלא קשורות לפרסום, אבל מפתחים של ערכות SDK שלא קשורות לפרסום, שמעוניינים בהתנהגות שתומכת בפרטיות ומאמינים שהם יכולים לפעול בהתאם לתנאים שצוינו למעלה, יכולים לשתף משוב על ערכות ה-SDK שלהם שפועלות בסביבת זמן הריצה של ה-SDK.
- כרגע אנחנו משתמשים בהרשאות מעבר לאלה שמצוינות בהצעה בתרחישים לדוגמה שלנו. האם יש לך אפשרות לבקש הרשאות נוספות?
אנחנו רוצים להבין תרחישים לדוגמה שקשורים לפרסום שדורשים הרשאות גישה ספציפיות, מעבר לאלה שהיו בהצעת העיצוב הראשונית. מומלץ לשתף משוב על הפונקציונליות שהושפעה.
- האם העברת ערכות SDK לתהליך זמן הריצה של ה-SDK תגרום לגודל ההורדה או לחיסכון במקום?
אם כמה אפליקציות משולבות עם ערכות SDK ספציפיות שתואמות לזמן ריצה של אותה גרסה, גודל ההורדה ונפח האחסון ייחסכו.
- הרשאת הגישה ל-AAID (AD_ID) עבור ה-SDK תלויה בהרשאות של האפליקציה?
היכולת של RE SDK לגשת ל-AAID תלויה באפליקציה וב-SDK עם הצהרה על ההרשאה במניפסט של האפליקציה. בעדכון הצעה בעתיד נפרט את ה-API שבו ערכות ה-SDK יוכלו להשתמש כדי לקבל את ה-AAID, אם יש להן הרשאה.
- כתובות IP, גרסאות של מערכות הפעלה ונתונים חלופיים: האם הם יהיו זמינים לערכות SDK שקשורות לפרסום?
אנחנו עובדים כרגע דרך מאפייני המערכת שלערכות ה-SDK שקשורות לפרסום תהיה גישה אליהם. המידע הזה ישותף בעדכון עתידי עם הצעה לעיצוב. לא פרסמנו מדיניות בנוגע לשימוש בנכסים האלה.
- האם מזהה קבוצת האפליקציות שה-SDK שלנו אוסף זהה לאפליקציות רבות, גם אם האפליקציות האלה שייכות לחשבונות פיתוח שונים ב-Google Play? איך אפשר לחסום משתמשים שמנסים לבצע תרמיות בכמה אפליקציות ללא AAID?
ייתכן שלאפליקציה אחת או לכל ערכות ה-SDK שלה תהיה גישה רק לערך של מזהה קבוצת האפליקציות שמשויך לחשבון הפיתוח של האפליקציה המארחת ב-Google Play. ארגז החול לפרטיות ב-Android לא יציע מזהה של בעלי תוכן דיגיטלי למטרות הונאה. בשלב זה, מפתחים יכולים להשתמש ב-IP כחלופה קצת פחות עקבית.
נושאים
- האם אוכל לראות רשימה של כל הנושאים האפשריים שה-API יכול להחזיר?
- למטרות בדיקה, התצוגה המקדימה למפתחים 1 משתמשת בנושאים מהטקסונומיה הזו, והיא עשויה להשתנות. אנחנו צופים שנמשיך לפתח את התחום עם הזמן, בהתאם למשוב שקיבלנו מהסביבה העסקית.
- אם טקסונומיית Topics כפופה לשינויים, איך אנחנו יכולים להביא בחשבון את השינויים האלה במודלים שבהמשך של צד הקנייה?
- התגובה של Topics API תכלול את מספר הגרסה של המסווג והטקסונומיה.
Protected Audience ב-Android
- האם טירגוט להחרגה ייתמך על ידי Protected Audience?
הצעת העיצוב הנוכחית אינה תומכת בטירגוט שלילי על סמך קהל מותאם אישית ב'קהל מוגן'.
בקמפיינים להתקנת אפליקציות, נציע לספקי פרסום דיגיטלי פונקציונליות של מודעות כדי לסנן את האפליקציות שכבר מותקנות. בנוסף, אנחנו בודקים איך אפשר לספק תמיכה בסינון שלילי של קמפיינים על בסיס מכסת תדירות. עדכונים מפורטים יותר על ההצעה לעיצוב יפורסמו בקרוב.
- האם ניתן ליצור קהלים בהתאמה אישית ברשתות המודעות של בתי העסק? או האם הן מוגבלות לרשתות המודעות של הקונים?
ההצעה הנוכחית שלנו לקהלים מותאמים אישית מתמקדת בתרחיש לדוגמה של הצד הקונה, בתנאי שהם מיועדים לתמוך ביצירת הצעות מחיר לצד הרכישה עבור תרחיש לדוגמה של רימרקטינג, תוך שמירה על הפרטיות.
דוחות שיוך (Attribution)
- האם ממשקי ה-API של ארגז החול לפרטיות יפעלו יחד כדי לתמוך בתרחישים לדוגמה מהאתר לאפליקציה?
- אנחנו בוחנים תרחישים לדוגמה שבהם אפליקציות של דפדפנים לנייד משתמשות ב-Android Attribution Reporting API כדי לאפשר את השימוש בשיוך באפליקציה ובאינטרנט באותו מכשיר. אם תבחרו להפעיל את הקישור מאפליקציה לאתר, ממשקי ה-API של ארגז החול לפרטיות ב-Android ישמשו לאחסון ולשיוך, ותבטל את השיוך באפליקציות ובאינטרנט (עם זאת, יכול להיות שתקבלו מה-API דוחות נפרדים לאפליקציות ולאינטרנט, שיהיה צורך לשלב אותם).
- האם ה-API תומך במודלים אחרים של שיוך מלבד קליק אחרון?
- ה-API תומך במודל ייחוס לפי עדיפות מקור באמצעות מודל ייחוס אחרון. בנוסף, ההצעה תומכת בלוגיקת שיוך אופציונלית של המרות אחרי התקנה שייוחסו לקליק או לצפייה שגרמו להתקנה.
- האם ארגז החול לפרטיות ישפיע על הגורם המפנה להתקנת Play?
על סמך העיצוב והתוכניות הנוכחיים, ממשקי ה-API של ארגז החול לפרטיות לא ישפיעו על הפונקציונליות שסופקה על ידי הגורם המפנה להתקנת Play.
חלק מהמפתחים זיהו פורמטים של מודעות שבהם משתמשים יכולים "לתגמל" משתמשים על השלמת אירועים ספציפיים שהתרחשו בעקבות קליק. ללא ייחוס ברמת המשתמש, זה עלול להיות מאתגר בהצעות הנוכחיות.
זה תחום שנמצא בבדיקה כדי לקבוע פתרונות אפשריים. מומלץ לקבל משוב נוסף על התרחיש הזה ועל תרחישים אחרים לדוגמה.
- למה השיוך מתבצע בנפרד לכל פלטפורמה של פרסום דיגיטלי?
כיום, מפרסמים רבים חושבים שחשוב לקבל תצוגה ללא כפילויות של אירועי ההמרה שלהם ברשתות שונות. מקובל להשתמש בשותף מדידה לנייד (MMP). עדיין יהיה קל לעשות זאת בממשקי ה-API החדשים, אבל גם פלטפורמות טכנולוגיות או מפרסמים ספציפיים יוכלו לבצע מדידות ישירות אם יש רצון לעשות זאת.
כשמשתמשים בהפניות לכתובות אחרות, אין צורך בנוכחות פיזית של SDK בכל אפליקציה, אבל כן צריך קשר עם ערכות ה-SDK של הפרסום הדיגיטלי שיהיו מעורבים בתהליך ההפניה האוטומטית.
אחד היתרונות המרכזיים של הגישה הזו הוא שלכל אחד יש מפתחות צבירה ומטא-נתונים משלו ללוגיקה העסקית שלו, וגם להגדיר עדיפות משלו.
- האם יש אימות או אימות של התקנות מחנות Play?
התקנות מאומתות משמשות רק ללוגיקה אופציונלית לשיוך המרות אחרי ההתקנה. ההתקנות המאומתות האלה לא יישלחו על ידי ה-API. ה-API ישלח דוחות רק על סמך ההמרות שנרשמו, ולא יחזיר אותות לגבי השאלה אם המשתמש התקין את האפליקציה בעבר.
- האם אתם מבצעים אימות של קליקים או תצוגות מפורטות? האם יש משך זמן מינימלי לאימות תצוגה מפורטת?
הצעת ה-API הנוכחית תומכת באימות קליקים בסיסי באמצעות InsertEvent. אנחנו בודקים צורות מתקדמות יותר של אימות קליקים ואימות תצוגות. מומלץ לקבל משוב נוסף לגבי תרחישי השימוש האלו, במיוחד בנוגע לסוגים של הגדרות התצוגה שיכולות להועיל לסביבה העסקית.