שיטות מומלצות לשימוש במזהים ייחודיים

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

במאמר הרשאות יש הסבר כללי על ההרשאות ב-Android" סקירה כללית. למידע נוסף על שיטות מומלצות ספציפיות לעבודה עם הרשאות ב-Android, ראו שיטות מומלצות לעבודה עם הרשאות באפליקציות.

שיטות מומלצות לעבודה עם מזהי Android

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

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

2. אין להשתמש במזהי חומרה. ברוב התרחישים לדוגמה, אפשר להימנע משימוש במזהי חומרה, כמו מזהה בינלאומי של מכשיר נייד (IMEI), בלי להגביל את הפונקציונליות הנדרשת.

   ב-Android 10 (רמת API 29) נוספו הגבלות למזהים שלא ניתנים לאיפוס, שכוללות גם IMEI וגם מספר סידורי. כדי לגשת למזהים האלה, האפליקציה צריכה להיות אפליקציה שבבעלות המכשיר או הפרופיל, לקבל הרשאות מיוחדות מהספק או לקבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.

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

4. אין לחבר בין איפוסים של מזהי פרסום.

5. להשתמש במזהה התקנה (FID) של Firebase או ב-GUID שמאוחסן באופן פרטי בכל פעם אפשרית בכל שאר מקרי השימוש, מלבד מניעת הונאת תשלומים טלפוניה. ברוב המקרים שבהם המודעות לא קשורות ל-Google Ads, יש להשתמש ב-FID או ב-GUID אמור להיות מספיק.

6. כדי לצמצם את הסיכון לפגיעה בפרטיות, כדאי להשתמש בממשקי API שמתאימים לתרחיש לדוגמה שלכם. כדאי להשתמש ב-DRM API כדי להגן על תוכן בעל ערך גבוה, וב-Play Integrity APIs כדי להגן מפני ניצול לרעה. ממשקי Play Integrity API הם הדרך הקלה ביותר לקבוע אם מכשיר הוא מקורי, בלי לגרום לסיכון לפרטיות.

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

עבודה עם מזהי פרסום

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

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

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

תמיד יש לפעול בהתאם לסימון של מודעות בהתאמה אישית. מזהי הפרסום הם שניתן להגדיר כך שהמשתמשים יכולים להגביל את כמות המעקב שמשויכת ID. תמיד צריך להשתמש בשיטה AdvertisingIdClient.Info.isLimitAdTrackingEnabled() כדי לוודא שאתם לא עוקפים את רצון המשתמשים. מדיניות התוכן למפתחים של Google Play קובעת את הפרטים הבאים:

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

חשוב לבדוק את כללי המדיניות בנושא פרטיות או אבטחה שמשויכים לערכות ה-SDK שבהן אתם משתמשים, וקשורים לשימוש במזהה הפרסום. לדוגמה, אם מעבירים את הערך true ל-method‏ enableAdvertisingIdCollection() מ-Google Analytics SDK, חשוב לקרוא את כל המדיניות הרלוונטית של Analytics SDK ולפעול בהתאם לה.

חשוב לזכור גם שבמדיניות התוכן למפתחים של Google Play מצוין שאסור לקשר את מזהה הפרסום "לפרטים אישיים מזהים או לשייך אותו למזהה מכשיר קבוע (למשל: SSAID, כתובת MAC, IMEI וכו')."

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

בדוגמה הזו, אפשר לצרף את העמודה ad_id ל-PII דרך העמודה account_id בשתי הטבלאות, וזו תהיה הפרה של מדיניות התוכן למפתחים של Google Play, אם לא קיבלתם הרשאה מפורשת מהמשתמשים.

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

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

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

פתרונות נוספים כוללים:

• לא לתכנן טבלאות שמקשרות באופן מפורש פרטים אישיים מזהים למזהי פרסום. בדוגמה הראשונה שלמעלה, המשמעות היא שלא כוללים את העמודה account_id בטבלה TABLE-01.

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

  1. שמירת רשימות של בקרת גישה (ACL) לנתונים שמקודדים מזהה מפרסם ולפרטים אישיים מזהים (PII) נפרדים כדי לצמצם את מספר האנשים או התפקידים שנמצאים בשני הסוגים רשימות ACL.
  2. כדאי להטמיע רישום ביומן וביקורת של הגישה כדי לזהות ולנהל חריגים לכלל הזה.

למידע נוסף על עבודה אחראית עם מזהי פרסום, ראו במסמכי העזרה של ה-API של AdvertisingIdClient.

עבודה עם מזהי FID ומזהי GUID

הפתרון הפשוט ביותר לזיהוי מופע של אפליקציה שפועל במכשיר הוא שימוש במזהה ההתקנה של Firebase‏ (FID). זהו הפתרון המומלץ ברוב התרחישים לדוגמה שלא קשורים למודעות. רק למכונה של האפליקציה שהוקצה לה המזהה הזה יש גישה אליו, וקל (יחסית) לאפס אותו כי הוא נשמר רק כל עוד האפליקציה מותקנת.

לכן, מזהי FID מספקים מאפייני פרטיות טובים יותר בהשוואה מזהי חומרה ברמת המכשיר שלא ניתנים לאיפוס ואי אפשר לאפס. למידע נוסף, ראו הפניית ה-API של firebase.installations.

במקרים שבהם FID אינו מעשי, אפשר גם להשתמש בהתאמה אישית מזהים ייחודיים גלובליים (GUID) לזיהוי ייחודי של מופע אפליקציה. האפשרות הפשוטה ביותר כדי לעשות זאת היא ליצור GUID משלכם באמצעות הקוד הבא:

var uniqueID = UUID.randomUUID().toString()

String uniqueID = UUID.randomUUID().toString();

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

לא עובדות עם כתובות MAC

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

שינויים בזמינות של כתובת MAC ב-Android 11

באפליקציות שמטרגטות ל-Android מגרסה 11 ואילך, רנדומיזציה של MAC דרך Passpoint הרשתות מתבצעות לכל פרופיל Passpoint, וכך נוצרת כתובת MAC ייחודית על סמך השדות הבאים:

• שם דומיין שמוגדר במלואו (FQDN)
• תחום
• פרטי כניסה, על סמך פרטי הכניסה שמשמשים בפרופיל Passpoint:
  • פרטי כניסה של משתמש: שם משתמש
  • פרטי הכניסה של האישור: cert ו-cert type
  • פרטי כניסה לכרטיס SIM: סוג EAP ו-IMSI

בנוסף, אפליקציות ללא הרשאות לא יכולות לגשת לכתובת ה-MAC של המכשיר. בלבד ממשקי רשת עם כתובת IP גלויים. זה משפיע על getifaddrs() וגם NetworkInterface.getHardwareAddress() שיטות, וכן לשליחת RTM_GETLINK הודעות Netlink.

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

• הפונקציה NetworkInterface.getHardwareAddress() מחזירה ערך null בכל ממשק.
• אפליקציות לא יכולות להשתמש בפונקציה bind() בשקעים של NETLINK_ROUTE.
• הפקודה ip לא מחזירה מידע על ממשקים.
• לאפליקציות אין אפשרות לשלוח הודעות RTM_GETLINK.

חשוב לזכור שרוב המפתחים צריכים להשתמש בממשקי ה-API ברמה גבוהה יותר של ConnectivityManager, ולא בממשקי API ברמה נמוכה יותר כמו NetworkInterface,‏ getifaddrs() או שקעי Netlink. לדוגמה, לאפליקציה שזקוקה למידע עדכני מסלולים קיימים יכולים לקבל את המידע הזה על ידי האזנה לשינויים ברשת באמצעות ConnectivityManager.registerNetworkCallback() וקוראים לרשתות LinkProperties.getRoutes()

מאפייני המזהה

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

היקף

היקף המזהה מסביר אילו מערכות יכולות לגשת למזהה. במכשירי Android בדרך כלל יש שלושה טעמים:

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

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

יכולת איפוס ועקביות

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

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

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

ייחודיות

הייחודיות קובעת את הסבירות להתנגשות, כלומר, קיומם של מזהים זהים בתוך ההיקף המשויך. ברמה הגבוהה ביותר, למזהה ייחודי גלובלי אף פעם לא מתרחשת התנגשות, גם במכשירים או באפליקציות אחרים. אחרת, רמת הייחודיות תלויה באנטרופי של המזהה ובמקור האקראיות ששימש ליצירתו. לדוגמה, הסיכוי קיימת סבירות גבוהה הרבה יותר עבור מזהים אקראיים שהתאריך שלהם הוא (למשל 2019-03-01) מאשר עבור מזהים שהמקור שלהם ב-Unix חותמת הזמן של ההתקנה (למשל, 1551414181).

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

הגנה על שלמות האפליקציה ואי-התכחשות

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

תרחישים נפוצים לדוגמה והמזהה המתאים שבו צריך להשתמש

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

חשבונות

סטטוס ספק

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

המזהה המומלץ לשימוש: IMEI,‏ IMSI ו-Line1

למה דווקא ההמלצה הזו?

מותר להשתמש במזהי חומרה, אם הוא נדרש פונקציונליות שקשורה לספק. לדוגמה, אפשר להשתמש במזהים האלה כדי לעבור בין ספקי סלולר או בין חריצי SIM, או כדי לשלוח הודעות SMS דרך IP (עבור Line1) – חשבונות משתמשים שמבוססים על SIM. עם זאת, לאפליקציות ללא הרשאות מומלץ להשתמש בכניסה לחשבון כדי לאחזר את פרטי המכשיר של המשתמש בצד השרת. אחת מהסיבות לכך היא שב-Android 6.0 (רמת API‏ 23) ואילך, אפשר להשתמש במזהים האלה רק באמצעות הרשאה בסביבת זמן הריצה. יכול להיות שמשתמשים ישביתו את ההרשאה הזו, לכן האפליקציה צריכה לטפל בחריגות האלה בצורה חלקה.

סטטוס המינוי בנייד

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

המזהה המומלץ לשימוש: Subscription ID API כדי לזהות כרטיסי SIM שמשמשים במכשיר.

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

למה דווקא ההמלצה הזו?

יכול להיות שאפליקציות מסוימות משתמשות כרגע ב-ICC ID למטרה הזו. מאחר שמזהה ה-ICC הוא ייחודי גלובלי ולא ניתן לאיפוס, הגישה הוגבל לאפליקציות עם READ_PRIVILEGED_PHONE_STATE מ-Android 10. החל מ-Android 11 ועד Android להגביל את הגישה ל-ICCID דרך getIccId() API, בלי קשר לרמת ה-API המטורגטת של האפליקציה. האפליקציות המושפעות צריכות לעבור אל במקום זאת, צריך להשתמש במזהה המינוי.

כניסה יחידה (SSO)

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

המזהה המומלץ לשימוש: חשבונות שתואמים לחשבון הניהול, כמו קישור לחשבון Google

למה דווקא ההמלצה הזו?

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

מודעות

מיקוד

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

מזהה מומלץ לשימוש: אם באפליקציה שלכם נעשה שימוש במזהה עבור מודעות והעלאות או מפרסם ב-Google Play, המזהה הזה חייב להיות מזהה הפרסום.

למה דווקא ההמלצה הזו?

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

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

מדידה

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

המזהה המומלץ לשימוש: מזהה פרסום או ממשקי API של גורמים מפנים להתקנות ב-Play

למה דווקא ההמלצה הזו?

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

המרות

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

מזהה מומלץ לשימוש: מזהה הפרסום או ממשקי API של הפניה להתקנה ב-Play

למה דווקא ההמלצה הזו?

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

רימרקטינג

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

המזהה המומלץ לשימוש: מזהה פרסום

למה דווקא ההמלצה הזו?

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

ניתוח נתונים של אפליקציות

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

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

פתרונות אפשריים:

• מזהה קבוצת אפליקציות: מזהה קבוצת אפליקציות מאפשר לנתח התנהגות משתמש בכל כמה אפליקציות שבבעלות הארגון שלך, כל עוד לא משתמשים בנתוני משתמשים למטרות פרסום. אם אתם מטרגטים מכשירים שמבוססים על שירותי Google Play, מומלץ להשתמש במזהה קבוצת האפליקציות.
• מזהה Firebase (FID): מזהה FID נמדד באפליקציה שיוצרת אותו, מונע שימוש במזהה כדי לעקוב אחרי משתמשים באפליקציות שונות. אפשר גם לאפס אותו בקלות, כי המשתמש יכול לנקות את נתוני האפליקציה או להתקין מחדש את האפליקציה. תהליך היצירה של FID הוא פשוט. אפשר לעיין במדריך להתקנות של Firebase.

פיתוח אפליקציות

דיווחים על קריסה

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

מזהה מומלץ לשימוש: FID או מזהה קבוצת אפליקציות

למה דווקא ההמלצה הזו?

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

דיווח על ביצועים

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

מזהה מומלץ לשימוש: מעקב אחרי ביצועים ב-Firebase

למה דווקא ההמלצה הזו?

ניטור הביצועים ב-Firebase עוזר לכם להתמקד במדדים שהכי חשובים לכם ולבדוק את ההשפעה של שינוי שהתבצע לאחרונה באפליקציה.

בדיקת אפליקציות

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

מזהה מומלץ לשימוש: FID או מזהה קבוצת אפליקציות

למה דווקא ההמלצה הזו?

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

התקנה במכשירים שונים

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

המזהה המומלץ לשימוש: FID או GUID

למה דווקא ההמלצה הזו?

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

אבטחה

זיהוי ניצול לרעה

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

המזהה המומלץ לשימוש: טוקן השלמות של Google Play Integrity API

למה דווקא ההמלצה הזו?

כדי לוודא שבקשה מגיעה ממכשיר Android אמיתי, ולא ממכשיר מזויף (אמולטור או קוד אחר) שמתחזה למכשיר אחר, צריך להשתמש ב-Google Play Integrity API.

מודעת תרמית

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

המזהה המומלץ לשימוש: מזהה פרסום

למה דווקא ההמלצה הזו?

השימוש במזהה הפרסום הוא חובה בתרחישי שימוש לפרסום, בהתאם למדיניות התוכן למפתחים ב-Google Play, כי המשתמש יכול לאפס אותו.

ניהול זכויות דיגיטלי (DRM)

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

המזהה המומלץ לשימוש: שימוש ב-FID או ב-GUID מאלץ את המשתמש להתקין מחדש את האפליקציה כדי לעקוף את מגבלות התוכן, וזו נטל מספיק גדול כדי להרתיע את רוב האנשים. אם ההגנה הזו לא מספיקה, ב-Android יש DRM API שאפשר להשתמש בו כדי להגביל את הגישה לתוכן. ה-API הזה כולל מזהה לכל קובץ APK, מזהה Widevine.

העדפות משתמש

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

מזהה מומלץ לשימוש: FID או GUID

למה דווקא ההמלצה הזו?

לא מומלץ לעקוב אחר מידע על ידי התקנות מחדש, מפני שמשתמשים עלולים שרוצים לאפס את ההעדפות שלהם על ידי התקנה מחדש של האפליקציה.