התאמת אפליקציית מובייל ל-COPPA: הגנת נתוני ילדים

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

פיתוח ותמיכה בכל סוגי היישומים הניידים:

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

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 1734 השירותים
התאמת אפליקציית מובייל ל-COPPA: הגנת נתוני ילדים
מורכב
~2-3 ימים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית מובייל עבור FEEDME
    פיתוח אפליקציית מובייל עבור FEEDME
    971
  • פיתוח אפליקציית מובייל עבור XOOMER
    פיתוח אפליקציית מובייל עבור XOOMER
    869
  • פיתוח אפליקציית מובייל עבור RHL
    פיתוח אפליקציית מובייל עבור RHL
    1289
  • פיתוח אפליקציית מובייל עבור ZIPPY
    פיתוח אפליקציית מובייל עבור ZIPPY
    1143
  • פיתוח אפליקציית מובייל עבור Affhome
    פיתוח אפליקציית מובייל עבור Affhome
    1076
  • פיתוח אפליקציית מובייל עבור חברת FLAVORS
    פיתוח אפליקציית מובייל עבור חברת FLAVORS
    677

מדוע תאימות COPPA מכשילה את שחרור האפליקציה למובייל

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

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

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

הלאה — הסכמת הורה ניתנת לאימות. תיבת סימון «אני הורה» אינה הסכמה: יש צורך במנגנון מאומת לאימות בגיר, ואחריו — הגבלת האיסוף למינימום הדרוש לתפקוד של פונקציה מסוימת.

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

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

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

מה משתנה לאחר ההטמעה: אפקט מדיד

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

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

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

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

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

אפשרויות לארגון הסכמת הורים: השוואת גישות

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

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

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

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

שלבי הטמעת קו COPPA במחזור השחרור של המוצר

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

  1. ביקורת איסוף נתונים. עורכים מלאי של כל הנקודות שבהן האפליקציה או מודולים מחוברים מקבלים נתונים: הרשמה, פרופיל, אנליטיקה, פרסום, פניות לתמיכה. לכל נקודה מקצים סיווג — נתוני ילדים, גיל בספק, ניטרלי.
  2. מפת זרמי נתונים. לכל נקודה מתעדים את היעד: השרת שלנו, שירות חיצוני, אחסון מקומי. מסמנים מה בדיוק יוצא ובאיזה בסיס נשאר.
  3. מזעור ותפקידי גישה. מסירים שדות שבלעדיהם המוצר עובד, משביתים מזהי פרסום עבור פרופילי ילדים. מפרידים תפקידים כך שהתמיכה והאנליטיקאי רואים חתך נתונים שונה.
  4. תרחישי הסכמה. מתכננים מסך הסכמת הורה, מנגנון אישור, ביטול ומחיקה. בנפרד מתארים את התנהגות האפליקציה כל עוד אין הסכמה.
  5. בדיקת תרחישי הסכמה. מריצים סירוב, ביטול, כניסה חוזרת, החלפת מכשיר. הבילד לא ממשיך הלאה אם לפחות תרחיש אחד אוסף נתונים בלי אישור.
  6. נהלי תמיכה. מתארים טיפול בבקשת הורה למחיקה או להעתקת נתונים, מי מאשר את הפעולה ובאיזה מועד.
  7. מסירת תיעוד. מוסרים מפת זרמים, תיאור תפקידים, רשימת בדיקות ונוהל עדכון בעת הוספת מודולים חדשים.

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

מה אנו מוסרים לידיים: קונפיגורציות, סכמות ונהלים

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

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

מקרה בוחן: אפליקציית ילדים עברה בדיקה בלי חסימה

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

מה נמצא בביקורת

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

מה שינו

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

מדדים לאחר מכן

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

מה לעשות אם נתוני ילדים כבר נאספים?

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

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

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

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

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

ספקות טכניים: מה מבררים לפני ההתחלה

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

הילד יזין כל שנת לידה — האם בדיקת הגיל בכלל עובדת?

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

מה נחשב להוכחת הסכמה והיכן היא נשמרת?

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

האם אפשר להשאיר פרסום ומודולים חיצוניים?

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

כמה זמן נשמרים נתוני ילדים?

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

נדון במשימה: מה נדרש מכם בהתחלה

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

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

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