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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הערה: במסגרת העדכון של Google Play Services בסוף שנת 2021, המערכת מסירה את מזהה הפרסום כשמשתמש מבטל בהגדרות של Android את ההסכמה להתאמה אישית של מודעות באמצעות מזהה הפרסום. כל ניסיון גישה למזהה יחזיר תחתיו רצף של אפסים. למידע נוסף, אפשר לעיין במרכז העזרה של Play Console.

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

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

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

טבלה-01
timestamp	ad_id	account_id	clickid
TABLE-02
account_id	name	dob	country

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

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

TABLE-01
timestamp	ad_id	clickid	dev_model
טבלה-02
timestamp	demo	account_id	dev_model	name

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

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

פתרונות אחרים כוללים:

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

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

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

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

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

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

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

במקרים שבהם 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)
• תחום
• פרטי כניסה, על סמך פרטי הכניסה שמשמשים בפרופיל Passpoint:
  • פרטי כניסה של משתמש: שם משתמש
  • פרטי כניסה לתעודה: אישור וסוג אישור
  • פרטי כניסה של 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-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 שונים את אותו המזהה במכשירים שונים.

הערה: גישה למזהה הזה מחייבת READ_PHONE_STATE הרשאה.

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

יכול להיות שאפליקציות מסוימות משתמשות כרגע ב-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

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

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