מה AppsFlyer אוסף

ה-SDK של AppsFlyer מאתחל סשן ברגע שאפליקציית המארח מתחילה ו, כברירת מחדל, אוסף חבילה של מזהים ואותות הקשריים: מזהה הפרסום ברמת המכשיר (IDFA ב-iOS, GAID ב-Android), ה-IDFV בטווח הספק ב-iOS, מזהה התקנה AppsFlyer שנוצר ומתמיד לאורך סשנים, כתובת IP (משמשת לגאו-IP ולהתאמה הסתברותית בסגנון טביעת אצבע), סוכן משתמש, דגם מכשיר, גרסת מערכת הפעלה, ספק ואזור זמן. לאחר ההתקנה, ה-SDK מדווח על אירוע ההתקנה לשרתי AppsFlyer, שם הוא מוצלב עם נתוני הקלקה שהועברו על ידי רשתות פרסום. אירועים מאוחרים יותר בתוך האפליקציה — Purchase, RegistrationComplete, Tutorial Complete, Custom — נורים דרך אותו SDK ויורשים את אותה קבוצת מזהים.

הרגולטורים היו מפורשים שזה עיבוד של נתונים אישיים לפי ה-GDPR. IDFA ו-GAID הם נתונים אישיים כי הם מזהים מתמידים ברמת המכשיר. ההתאמה ההסתברותית של טביעות אצבע שפועלת לצידם קשה אפילו יותר להגנה ללא הסכמה כי היא, בהגדרתה, ניסיון לזהות משתמש ללא שיתוף פעולה מפורש שלו. CNIL, ה-Garante האיטלקי וה-AEPD הספרדי פתחו חקירות נגד מפרסמים שערימות הייחוס שלהם הופעלו לפני ההסכמה.

בקרות פרטיות מקוריות של AppsFlyer

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

ה-Start SDK API

ה-SDK תומך במצב אתחול שבו הוא מוגדר אך אינו מעביר נתונים כלשהם עד ש-start() נקרא במפורש. זהו הוו החשוב ביותר לשיתוף הסכמה — כברירת מחדל ה-SDK מתחיל אוטומטית בהפעלת האפליקציה, שזו התנהגות שגויה עבור כל סמכות שיפוט עם דרישת הסכמה מוקדמת. הגדר isStopped ל-true באתחול, או השתמש ב-API של הפעלה דחויה, וקרא ל-start() רק כאשר אות ההסכמה נרשם.

Stop API

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

setSharingFilter

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

אינטגרציה עם Apple App Tracking Transparency

ב-iOS, AppsFlyer קורא את מצב ההרשאה של ATT ומתאים את התנהגותו אוטומטית — אם המשתמש דחה ATT, IDFA לא מועבר. ATT עצמאי מהסכמת GDPR, ומפרסמים רבים מערבבים ביניהם. ATT שולט באות אחד ברמת iOS; הסכמת GDPR שולטת בכל השאר.

אינטגרציה ב-iOS

הדפוס האמין ב-iOS הוא להתקין את ה-SDK של AppsFlyer אך לדחות את האתחול עד שגם ATT וגם זרם ההסכמה בתוך האפליקציה הושלמו. הרצף המינימלי הוא: האפליקציה מופעלת, ה-SDK מוגדר עם isStopped = true, באנר ההסכמה בתוך האפליקציה מוצג, המשתמש מקבל את הקטגוריות הרלוונטיות, דגל isStopped של ה-SDK נמחק ו-start() נקרא. אם האפליקציה זקוקה גם ל-ATT (וכך היא לכל משתמש שה-IDFA שלו משמעותי), הנחיית ATT מוצגת לצד הבאנר בתוך האפליקציה או אחריו. לרוב ה-CMPs התומכים בנייד יש API מבוסס-קריאה חוזרת שמוסר את החלטת ההסכמה; קריאה חוזרת זו היא המקום הנכון לקרוא ל-start().

אינטגרציה ב-Android

יישום Android מקביל ל-iOS עם שתי הבדלים. ראשית, אין מקביל ל-ATT — GAID זמין אלא אם המשתמש הפעיל את הגדרת רמת המכשיר "מחק מזהה פרסום", שרוב המשתמשים אינם עושים. שנית, מחזור החיים של Android אגרסיבי יותר לגבי ריצה ברקע, לכן אתחול ה-SDK צריך להיות קשור למצב ההסכמה המאוחסן באופן מתמיד. קרא את מצב ההסכמה מהאחסון המקומי בהפעלת האפליקציה, הגדר את ה-SDK בהתאם, ובדוק שוב בחזרה למצב פעיל למקרה שהמשתמש עדכן את בחירתו בזמן שהאפליקציה הייתה ברקע.

אינטגרציה באינטרנט הנייד

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

מלכודות נפוצות

ארבע טעויות אינטגרציה מופיעות שוב ושוב בביקורות של פריסות AppsFlyer.

טיפול ב-ATT כהסכמת GDPR

ATT והסכמת GDPR הם אותות שונים עם היקפים שונים. משתמש שמקבל ATT אישר שימוש ב-IDFA למעקב בין-אפליקציות; הם לא אישרו כל שאר מה שה-SDK עושה. לתעבורת EU ו-UK שני האותות נדרשים, כאשר הבאנר בתוך האפליקציה הוא המחייב ו-ATT הוא שכבה ספציפית ל-iOS מעליו.

לאפשר ל-SDK להתאתחל בהפעלה

זהו הפגם הבודד הנפוץ ביותר. האינטגרציה ברירת המחדל קוראת ל-start() מיידית, אשר מפעילה את אירוע ההתקנה עם מטען מזהים מלא לפני שהמשתמש ראה את באנר ההסכמה. הסעד הוא ישיר: הגדר isStopped = true בזמן האינטגרציה וקרא ל-start() רק מהקריאה החוזרת של ההסכמה.

שכחה לטפל בנסיגה

אם משתמש מקבל ואחר כך מבטל, ה-SDK צריך להיאמר להפסיק לשדר. השתמש ב-API stop() ועדכן את מצב ההסכמה המתמיד כדי שהפעלת האפליקציה הבאה תכבד את ההחלטה החדשה.

התעלמות מפוסטבקים שרת-לשרת

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

רשימת בדיקה לביקורת

שש שאלות קונקרטיות לענות עליהן עבור כל פריסת AppsFlyer הנוגעת בתעבורת EU, UK או קליפורניה.

• האם ה-SDK ממתין להסכמה? בהתקנה טרייה במכשיר בדיקה הממוקם ב-EU, אשר שאין נקודת קצה של AppsFlyer מקבלת בקשה כלשהי לפני שהמשתמש קיבל את הבאנר.
• האם ATT מופרד מהסכמה בתוך האפליקציה? אשר שהבאנר בתוך האפליקציה הוא אות ההסכמה השולט ו-ATT מטופל כשכבה ספציפית ל-iOS נוספת.
• האם העברת השותפים מוגבלת להסכמה? אשר ש-setSharingFilter מוגדר לאסלות שותפים שהמשתמש לא אישר.
• האם הנסיגה עוצרת את ה-SDK? אשר שקריאה ל-stop() עובדת על ביטול הסכמה ושהמצב החדש מתמיד לאורך הפעלות.
• האם הפוסטבקים של השרת עברו ביקורת? אשר שרשימת "האינטגרציות המוגדרות" של לוח המחוונים של AppsFlyer מתאימה בבירור לשותפי השיווק שנחשפו בבאנר.
• האם מחיקת הנתונים אוטומטית? אשר שבקשות DSAR מפעילות את ה-API של מחיקת AppsFlyer, ולא כרטיס ידני.

איפה AppsFlyer מתאים למחסנית הסכמה-ראשונה

ייחוס נייד הוא אחד ממשטחי המזהים הכבדים ביותר במחסנית השיווק, וה-SDK של AppsFlyer הוא אחד מהאינטגרציות הבודדות המשמעותיות ביותר שלו. הבשורה הטובה היא שהפלטפורמה חושפת את הפרימיטיבים — Start SDK, Stop, מסנני שיתוף, API מחיקה — הדרושים להפוך את אכיפת ההסכמה לנקייה ובת-אימות. העבודה עבור המפרסמים היא לחבר אותם פרימיטיבים ל-CMP שמחזיק בהחלטת ההסכמה המחייבת, לטפל ב-ATT כאות משלים ולא כתחליף, ולוודא שהעברת שותפים בצד השרת לא יכולה להימלט ממעטפת ההסכמה שרשם הבאנר. כשנעשה נכון, התוצאה היא מחסנית ייחוס שמספקת רגולטורים תוך שמירת נתוני ההתקנה והאירועים שעליהם מסתמכים צוותי רכישת המשתמשים.