מדוע Amplitude דורשת הסכמה

ה-SDK ברירת המחדל של דפדפן Amplitude וה-SDK הניידים של Amplitude עושים הרבה יותר מסתם תיעוד צפיות בדף. בעת האתחול הם מגדירים מזהה מכשיר באחסון מצד ראשון, מייצרים מזהה פגישה, לוכדים את המפנה, מנתחים מזהי UTM ולחיצה מה-URL, ומתחילים לתור אירועים שנלכדו אוטומטית: צפיות בדפים, לחיצות על אלמנטים, אינטראקציות עם טפסים, הורדות קבצים ו — במהדורות האחרונות — הקלטות חוזרות של פגישות. הם גם מעשירים את האירועים הללו עם גיאולוקציה מבוססת IP, נתוני מכשיר מבוססי user-agent, ואם מוגדר, העשרת צד שלישי מחלקות נתונים.

כל אחד מהצעדים הללו מעורב בבסיס משפטי נפרד של הסכמה. אחסון מזהה מכשיר הוא פעולת אחסון-וגישה לפי סעיף 5(3) של הנחיית ePrivacy, הדורשת הסכמה מוקדמת, ניתנת בחופשיות, ספציפית, מושכלת וחד-משמעית באזור הכלכלי האירופי, בבריטניה, ובכל תחום שיפוט שאימץ את אותו סטנדרט. לכידת אירועים התנהגותיים הקשורים למזהה זה היא עיבוד נתונים אישיים לפי ה-GDPR. העשרה בנתוני צד שלישי מציגה קשר בקר שני. ה-CCPA וה-CPRA מסווגים את אותו עיבוד כמכירה או שיתוף אלא אם כן למפרסם יש חוזה ספק שירות מתוחם כראוי עם Amplitude — הזמין, אך רק אם האינטגרציה מוגדרת לנטרל תכונות פרסום.

מה Amplitude אוספת לפני ההסכמה — ומה עליך לדכא

שגיאת היישום הנפוצה ביותר היא לטפל ב-Amplitude ככלי ניתוח קל שיכול לפעול לצד כרזת העוגיות. הוא אינו יכול. בקריאה ברירת מחדל של amplitude.init(), ה-SDK, בציור הראשון של הדף, יכתוב לפחות עוגייה אחת או ערך אחסון מקומי, ישלח קריאת identify, ויתחיל לאגור אירועים. אף אחד מאלה אינו מותר לפני שמשתמש אישר בצורה חיובית את קטגוריית ההסכמה הרלוונטית.

לכן אינטגרציה תואמת חייבת לדחות את amplitude.init() עד שה-CMP איתת שקטגוריית הסכמת הניתוח הוענקה. ה-SDK לא אמור להיטען כלל מתגית <script> מוגנת הסכמה התלויה באות מטרה 8 (ניתוח) או מטרה 1 (אחסון וגישה) של ה-CMP, בהתאם לאיזה מסגרת ה-CMP חושפת. אם ה-SDK חייב להיטען מוקדם יותר — לדוגמה מכיוון שהוא מוצמד לקוד האפליקציה ואינו יכול להיטען באיחור — קריאת האתחול צריכה להעביר defaultTracking: false ו-optOut: true כדי שלא יישלחו אירועים עד רישום ההסכמה, ואז אירוע opt-in דחוי צריך להפוך את הדגלים הללו.

העוגיות והאחסון שכותבת Amplitude

ה-SDK של הדפדפן 2.x כותב כברירת מחדל עוגייה יחידה מצד ראשון בשם AMP_{apiKey} עם תפוגה של שנה אחת, המכילה את מזהה המכשיר ומטא-נתוני הפגישה. גרסאות ישנות יותר כתבו גם amplitude_id_{apiKey}. ה-SDK הניידים שומרים את אותו מזהה בתוך האחסון בארגז החול של האפליקציה. הקלטה חוזרת של פגישה מוסיפה עוגייה שנייה, AMP_MKTG_{apiKey}, ושותפי העשרת Amplitude עשויים להגדיר עוגיות צד שלישי נוספות אם מודולי מיקוד הניסויים או הקהלים מופעלים. כל אלה אינם חיוניים ודורשים הסכמה.

מיפוי Amplitude למסגרות הסכמה

Amplitude אינה מיישמת באופן מקורי את Google Consent Mode v2, IAB TCF, או IAB Global Privacy Platform. זה לא פגם — Amplitude היא פלטפורמת ניתוח מצד ראשון, לא ספקית טכנולוגיית פרסום — אך פירוש הדבר שאחריות האינטגרציה נמצאת אצל המפרסם. הדפוס שעובד בפועל הוא לטפל בכל מודול של Amplitude כשער הסכמה נפרד ולקשור אותו לאות ספציפי שה-CMP כבר חושף.

• אירועי ניתוח מרכזיים קשורים למטרת הניתוח. במונחי TCF זה לרוב מטרה 8 (מדידת ביצועי תוכן) בשילוב מטרה 1 (אחסון ו/או גישה למידע). עבור Google Consent Mode זה ממפה ל-analytics_storage.
• הקלטה חוזרת של פגישה צריכה לשבת מאחורי אות קפדני יותר. ההקלטה החוזרת לוכדת את ה-DOM שניתן, כולל ערכי טפסים אלא אם כן נמסכו במפורש, לכן opt-in נפרד של העדפות או פונקציונלי מתאים, וההקלטה החוזרת צריכה להיות מכובה כברירת מחדל אפילו כשניתוח הוענק.
• קהלים, קבוצות ועשרת צד שלישי קשורות למטרת השיווק. במונחי TCF זה מטרה 7 (מדידת ביצועי מודעות) או מטרה 9 (יישום מחקר שוק). עבור Google Consent Mode זה ממפה ל-ad_storage ו-ad_user_data.
• ניסויים — Amplitude Experiment יכול לפעול עם הקצאה אנונימית וארעית תחת בסיס עניין לגיטימי, אך הקצאה קבועה הקשורה למזהה משתמש דורשת את אותה הסכמה כמו ניתוח מרכזי.

דפוס האינטגרציה שעובד

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

יישום ב-Web

ב-Web, הדפוס הנקי ביותר הוא לחשוף את מצב ההסכמה של ה-CMP דרך אובייקט window.__cmp_consent או ה-callback הסטנדרטי __tcfapi, ולאחר מכן להחזיק סקריפט bootstrap קטן שמנוי לשינויי הסכמה. כשהסכמת ניתוח עוברת מ-false ל-true, ה-bootstrap מביא את Amplitude SDK מה-CDN המנוהל על ידי ה-CMP, קורא ל-amplitude.init(apiKey, undefined, { defaultTracking: true }), ומשמיע מחדש כל אירוע שעמד בתור בזיכרון בזמן שההסכמה הייתה בהמתנה. כשההסכמה עוברת חזרה ל-false, ה-bootstrap קורא ל-amplitude.setOptOut(true), מנקה את עוגיית AMP_ דרך פקיעת תוקף document.cookie, ומסיר כל מצב שבזיכרון. באופן קריטי, ה-bootstrap לעולם אסור שיאתחל את Amplitude באיחור באותו זרם בקשה כמו עיבוד הכרזה — ה-SDK חייב לחכות להענקה מפורשת.

יישום נייד

ב-iOS המקביל הוא להשאיר את מסגרת Amplitude מיובאת אך לדחות את Amplitude.instance().initialize(apiKey: apiKey) עד שתהליך ההסכמה בתוך האפליקציה החזיר אות ניתוח חיובי. הנחיית ATT היא דאגה נפרדת: ATT מסדירה את ה-IDFA, בעוד שמזהה Amplitude הוא ה-UUID של ה-SDK עצמו המאוחסן בארגז החול של האפליקציה. שניהם דורשים הסכמה ב-EEA, אך הבסיסים המשפטיים וההנחיות הם נפרדים. באנדרואיד אותה לוגיקה חלה עם Amplitude.getInstance().initializeApolloClient() או המקביל בהתאם לגרסת ה-SDK.

מצב בצד שרת

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

אימות האינטגרציה

שלב האימות הוא זה שמפרסמים לרוב מדלגים עליו ורגולטורים לרוב בודקים. פריסת Amplitude משולבת כראוי צריכה לעבור ארבע בדיקות. ראשית, דפדפן עם כרזת ההסכמה מוצגת אך ללא בחירה שנעשתה צריך לייצר אפס בקשות ל-api.amplitude.com או ל-api.eu.amplitude.com ואפס עוגיות AMP_ ב-document.cookie. שנית, דחיית קטגוריית הניתוח צריכה לשמור על המצב הזה — אין אירועים, אין עוגיות, אין ערכי אחסון מקומי עם קידומת AMP_. שלישית, קבלת הניתוח צריכה לייצר identify בודד ואחריו תנועת אירועים, ועוגיית AMP_ צריכה להופיע עם מאפיין SameSite עקבי עם מדיניות ה-CMP של המפרסם. רביעית, משיכת ההסכמה לאחר מעשה צריכה לעצור מיד אירועים נוספים ולנקות מזהים מאוחסנים — ניקוי מושהה הוא ממצא.

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

בחירת האזור הנכון ומקום שמירת הנתונים

Amplitude מפעילה שני אזורי ייצור: ארה"ב (api.amplitude.com) ו-EU (api.eu.amplitude.com). עבור תנועת EEA ובריטניה אזור ה-EU הוא ברירת המחדל הנכונה — הוא שומר את הנתונים בתוך ה-EEA ומפחית את משטח סיכון ההעברה שפסיקת Schrems II ומסגרת פרטיות הנתונים EU-US הפכו למרכזי בכל סקירת ניתוח. מעבר אזורים אינו רטרואקטיבי: נתונים קיימים נשארים היכן שנגלעו לראשונה. עבור מפרסמים המתכננים פריסת CMP כדאי לכן לאשר את האזור לפני הסקילה, וכדאי לתעד את הבחירה בהודעת הפרטיות כדי שרשת הבסיס המשפטי תהיה נקייה מאיסוף ועד אחסון. אזור שנבחר נכון, מזווג עם SDK מוגן נכון ויומן הסכמה שניתן לשאילתה, הוא מה שהופך את פריסת Amplitude מסיכון רגולטורי לחלק שניתן להגנה ממחסנית הניתוח.