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

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

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

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

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

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

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

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

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

4. לא לגשר על איפוסים של מזהה הפרסום.

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

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

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

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

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

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

"…אם מזהה הפרסום יאומת, אסור לקשר מזהה פרסום חדש למזהה הפרסום הקודם או לנתונים שנגזרו ממזהה הפרסום הקודם ללא הסכמה מפורשת של המשתמש"

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

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

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

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

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

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

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

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

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

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

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

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

  1. חשוב להפריד בין רשימות בקרת הגישה (ACL) של נתונים עם מפתחות מזהה המפרסם לבין רשימות בקרת הגישה של פרטים אישיים מזהים (PII), כדי למזער את מספר האנשים או התפקידים שנכללים בשתי רשימות בקרת הגישה.
  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)
• Realm
• פרטי כניסה, על סמך פרטי הכניסה שמשמשים בפרופיל Passpoint:
  • פרטי הכניסה של המשתמש: שם המשתמש
  • פרטי הכניסה של האישור: cert ו-cert type
  • פרטי כניסה של SIM: סוג EAP ו-IMSI

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

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

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

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

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

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

היקף

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

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

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

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

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

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

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

ייחודיות

הייחודיות קובעת את הסבירות להתנגשות, כלומר, קיומם של מזהים זהים בתוך ההיקף המשויך. ברמה הגבוהה ביותר, למזהה ייחודי גלובלי אף פעם לא מתרחשת התנגשות, גם במכשירים או באפליקציות אחרים. אחרת, רמת הייחודיות תלויה באנטרופי של המזהה ובמקור האקראיות ששימש ליצירתו. לדוגמה, הסיכוי להתנגשות גבוה הרבה יותר במזהים אקראיים שנוצרו באמצעות תאריך ההתקנה בלוח השנה (כמו 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, הגישה ל-ICCID הוגבלה עוד יותר ב-Android דרך ה-API של getIccId(), ללא קשר לרמת ה-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

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

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