דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

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

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

ב-Android 10 (רמת API 29) נוספו הגבלות על מזהים שלא ניתן לאפס, כולל מספר ה-IMEI והמספר הסידורי. כדי לגשת למזהים האלה, האפליקציה צריכה להיות אפליקציה שבבעלות המכשיר או הפרופיל, לקבל הרשאות מיוחדות מהספק או לקבל את ההרשאה READ_PRIVILEGED_PHONE_STATE.
אפשר להשתמש במזהה פרסום רק לצורך יצירת פרופילים של משתמשים או בתרחישי שימוש של מודעות. כשמשתמשים במזהה פרסום, תמיד צריך לכבד את הבחירות של המשתמשים בנוגע למעקב אחר מודעות. אם אתם צריכים לקשר את מזהה הפרסום למידע אישי מזהה, עליכם לעשות זאת רק עם הסכמה מפורשת של המשתמש.
אין לחבר בין איפוסים של מזהה הפרסום.
בכל תרחישי השימוש האחרים, כדאי להשתמש במזהה התקנה של Firebase (FID) או במזהה GUID שמאוחסן באופן פרטי, במידת האפשר, מלבד למניעת הונאות בתשלומים ולטלפוניה. ברוב המכריע של תרחישי השימוש שאינם קשורים למודעות, FID או GUID אמורים להספיק.
כדי לצמצם את הסיכון לפגיעה בפרטיות, כדאי להשתמש בממשקי 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 וכו')."

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

TABLE-01
`timestamp`	`ad_id`	`account_id`	`clickid`
TABLE-02
`account_id`	`name`	`dob`	`country`

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

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

TABLE-01
`timestamp`	`ad_id`	`clickid`	`dev_model`
TABLE-02
`timestamp`	`demo`	`account_id`	`dev_model`	`name`

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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() או שקעי 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, מומלץ להשתמש במזהה קבוצת האפליקציות.
מזהה Firebase‏ (FID): היקף ה-FID מוגבל לאפליקציה שיוצרת אותו, וכך לא ניתן להשתמש במזהה כדי לעקוב אחרי משתמשים באפליקציות שונות. אפשר גם לאפס אותו בקלות, כי המשתמש יכול לנקות את נתוני האפליקציה או להתקין מחדש את האפליקציה. תהליך היצירה של FID הוא פשוט. אפשר לעיין במדריך להתקנות של Firebase.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המזהה המומלץ לשימוש: 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

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

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