מדוע PostHog דורש הסכמה — ומדוע התשובה אינה זהה לכל מודול

SDK האינטרנט של PostHog אינו תג עמוד פסיבי. באתחול ברירת מחדל, ה-SDK מגדיר ערך מתמיד אחד או יותר של צד ראשון — כברירת מחדל שילוב של עוגיה ועיצוב localStorage עם מפתח תחת ph_{projectKey}_posthog — מייצר מזהה נפרד יציב, לוכד את צפיית הדף הראשונית עם הפניה, פרמטרי UTM ומזהי לחיצה, ופותח ערוץ אירועים ממושך למארח ההזנה המוגדר. אם הקלטת סשן מופעלת ברמת הפרויקט, ה-SDK גם מתחיל לשדר רשומה רציפה של ה-DOM המרונדר, קואורדינטות העכבר ואירועי קלט. אם דגלי תכונות מוגדרים, ה-SDK מעריך אותם מול המזהה הנפרד, שומר את ההחלטות לסשן ושולח אירוע $feature_flag_called לכל הערכה.

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

מה PostHog כותב לפני ההסכמה — ומה חייב להיות מדוכא

SDK הדפדפן של PostHog כברירת מחדל כותב את הדברים הבאים באתחול: ערך עוגיה ו-localStorage משולב תחת ph_{projectKey}_posthog המכיל את המזהה הנפרד, מזהה הסשן והחלטות דגל התכונות, ובנוסף, כאשר הקלטת סשן מופעלת, מאגר הקלטה נוסף בזיכרון שמתרוקן לנקודת הקצה של ההזנה כל מספר שניות. ה-SDK גם שולח אירוע $pageview מיידי, ואם לכידה אוטומטית פעילה, כל לחיצה, אינטראקציה עם טופס ו-rage-click עוקבים בדף.

הדפוס המומלץ הוא לאתחל את PostHog עם opt_out_capturing_by_default: true ו-disable_session_recording: true, ואז לאפס שני הדגלים ברגע שבאנר ההסכמה מחזיר אות חיובי. זוהי עמדת האינטגרציה שתיעוד PostHog ממליץ עליה כעת, וזוהי העמדה שעומדת בבדיקת הרגולטור מכיוון שהיא הופכת את ברירת המחדל: לא נלכד דבר עד שההסכמה נרשמת, וה-SDK מספק מעבר נקי ולא עדכון רטרואקטיבי עם מצב.

העוגיות, ערכי localStorage והמזהים שPostHog שומר

SDK הדפדפן 1.x כותב ערך מתמיד אחד לפרויקט, עם מפתח תחת ph_{projectKey}_posthog, עם תפוגה של 365 יום כברירת מחדל. אפשרות האתחול persistence שולטת במנגנון הבסיסי: cookie בלבד, localStorage בלבד, localStorage+cookie (ברירת המחדל), sessionStorage, או memory. לפריסת הסכמה-ראשונה, המתמיד memory הוא ברירת המחדל הנכונה כאשר טרם ניתנה הסכמה — זה מבטיח שאף מזהה לא יחיה מעבר לסשן הדף — עם מעבר ל-localStorage+cookie ברגע שההסכמה מתהפכת. ה-SDK גם כותב סמן opt-in או opt-out תחת __ph_opt_in_out_{projectKey} לזכור את בחירת המשתמש בין ביקורים; אותו סמן הוא עצמו עוגיה הכרחית בהחלט מכיוון שהוא שומר החלטת הסכמה.

מיפוי מודולי PostHog למסגרות הסכמה

PostHog אינו מיישם באופן מקורי את IAB TCF או את פלטפורמת הפרטיות הגלובלית של IAB, ולא נבנה כספק טכנולוגיית פרסום. עם זאת, הוא משתלב עם Google Consent Mode v2 באמצעות גישור בצד המו"ל, חושף API מקורי של opt-in ו-opt-out, ומכבד את כותרת Do Not Track דרך אפשרות האתחול respect_dnt. הדפוס שעובד בייצור מתייחס לכל מודול PostHog כשער נפרד הכרוך באות CMP ספציפי.

• אירועי אנליטיקת מוצר קשורים למטרת האנליטיקה. במונחי TCF זוהי לרוב מטרה 8 (מדידת ביצועי תוכן) בשילוב עם מטרה 1 (אחסון ו/או גישה למידע). ל-Consent Mode זה ממופה ל-analytics_storage.
• הקלטת סשן נמצאת מאחורי שער מחמיר יותר. הקלטת הסשן של PostHog לוכדת את ה-DOM המרונדר וכל שדה קלט בלתי מכוסה, לכן opt-in ברמת העדפות או מחקר הנפרדת מאנליטיקה היא עמדה הניתנת להגנה לפי הנחיות EDPB.
• דגלי תכונות וניסויים יכולים לפעול עם הערכה זמנית בזיכרון על בסיס אינטרס לגיטימי כאשר המטרה היא רק לשנות את הדף המרונדר. הקצאת דגל מתמדת הכרוכה במזהה יציב על פני סשנים דורשת את אותה הסכמה כמו אנליטיקה, מכיוון שאז הדגל הופך לנקודת נתוני משתמש ניתנת לעקיבה.
• סקרים ומשוב קשורים לאותו שער כמו הקלטת הסשן כאשר הם אוספים קלט טקסט חופשי, או לשער האנליטיקה כאשר הם אוספים רק דירוגים או תשובות בחירה בודדות.

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

לפריסת הייחוס יש ארבעה חלקים: CMP שחושפת אירוע שינוי הסכמה בזמן אמת, bootstrap דחוי שמאתחל את PostHog עם לכידה והשמעה חוזרת מושבתות, מאזין הסכמה שמאפס את opt_in_capturing ומתג ההקלטה כאשר השערים הרלוונטיים נפתחים, ונתיב נסיגה שקורא ל-opt_out_capturing, עוצר את מאגר ההשמעה החוזרת ומנקה מזהים מתמידים דרך API האיפוס של ה-SDK.

מימוש ווב

הדפוס הנקי ביותר הוא לטעון את PostHog SDK בכל עמוד אך לקרוא ל-posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) כ-bootstrap הראשוני. הירשם לאירוע שינוי ההסכמה של ה-CMP. כאשר קטגוריית האנליטיקה עוברת ל-true, קרא ל-posthog.set_config({ persistence: 'localStorage+cookie' }) ולאחריו ל-posthog.opt_in_capturing(); זה מפעיל מחדש את לכידת האירועים ומעבר המתמיד מתחיל לכתוב את המזהה הנפרד. כאשר קטגוריית הקלטת הסשן עוברת ל-true, קרא ל-posthog.startSessionRecording(). כאשר שער כלשהו נסוג, קרא ל-posthog.opt_out_capturing() עבור שער האנליטיקה או ל-posthog.stopSessionRecording() עבור שער ההשמעה החוזרת, פג את ערכי המתמיד הרלוונטיים דרך posthog.reset(), ושלח בקשת מחיקה דרך ה-API של GDPR של PostHog אם המשתמש הפעיל את זכות המחיקה שלו.

בחירת אזור: PostHog Cloud ארה"ב לעומת האיחוד האירופי לעומת עצמאי

PostHog מפעיל שני אזורי ענן — ארה"ב (us.posthog.com) ואיחוד אירופי (eu.posthog.com) — ותומך בהתקנות עצמאיות על תשתית הלקוח עצמו. עבור תנועת EEA וה-UK, ענן האיחוד האירופי הוא ברירת המחדל הנכונה; הוא שומר על ההזנה, העיבוד והאחסון בתוך ה-EEA ומפחית את החשיפה ל-Schrems II שכל פריסת אנליטיקה באזור ארה"ב נושאת. אפשרות האתחול api_host מקבעת את האזור. PostHog עצמאי מעביר את כל הסטק לתשתית המו"ל עצמו, שהיא עמדת מגורי הנתונים החזקה ביותר אך אינה מסירה התחייבויות הסכמה — הבסיס המשפטי עוקב אחרי הנתונים, לא אחרי המפעיל. כל אפשרות שנבחרה חייבת להתבטא בהודעת הפרטיות וברשומת העיבוד של הבקר.

לכידה בצד שרת

PostHog תומך בהזנת אירועים בצד שרת דרך ה-SDK של Python, Node, Go, Ruby ו-PHP. אירועי צד שרת אינם פטורים מהסכמה — הבסיס המשפטי עוקב אחרי הנתונים — אך הזנה בצד שרת נותנת למו"ל שליטה מלאה על אילו שדות נפלטים ומתי. דפוס נפוץ הוא ללכוד סט אירועים חיוניים מינימלי בצד שרת תחת אינטרס לגיטימי, ואז להעשיר את האירועים הללו בפרטים התנהגותיים מהלקוח רק לאחר שהמשתמש העניק הסכמת אנליטיקה. האירועים בצד שרת ובצד הלקוח מצטרפים על אותו מזהה נפרד כאשר ההסכמה התהפכה; לפני ההסכמה, אירועי צד שרת נפלטים עם מזהה אנונימי וזמני המאופס בכל סשן.

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

שלב האימות הוא מה שהרגולטורים בודקים ומה שמו"לים מדלגים עליו לרוב. פריסת PostHog משולבת כראוי חייבת לעבור ארבעה מבחנים ברצף. ראשית, סשן דפדפן נקי עם הבאנר המוצג אך ללא בחירה שנעשתה חייב לייצר אפס בקשות ל-api_host המוגדר מעבר להורדת קובץ ה-SDK, אפס עוגיות ph_ ב-document.cookie ואפס ערכי ph_ ב-localStorage. שנית, דחיית אנליטיקה חייבת לשמור על המצב הזה — ללא לכידה, ללא הקלטה, ללא מזהה מתמיד. שלישית, קבלת אנליטיקה חייבת לייצר אירוע $opt_in מיידי, ערך המתמיד ph_{projectKey}_posthog הצפוי עם מאפייני SameSite נכונים ותנועת אירועים לזרום למארח המוגדר. רביעית, נסיגת ההסכמה לאחר מכן חייבת מיד לעצור לכידה והשמעה חוזרת נוספת, לפוג מזהים מתמידים ולהפעיל בקשת מחיקה דרך ה-API של GDPR של PostHog אם המשתמש הפעיל מחיקה.

ציפיית נתיב הביקורת תחת הנחיות באנר עוגיות 2023 של EDPB ועדיפויות כוח המשימה המחודשות של 2026 היא שהמו"ל יכול להוכיח, לכל אירוע נתון בפרויקט PostHog, שהמשתמש שיצר אותו נתן הסכמה תקפה ברגע הלכידה. הדפוס הסטנדרטי הוא להגדיר את גרסת ההסכמה וחותמת הזמן כמאפייני אדם על מזהה ייחודי דרך posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) כך שכל אירוע בודד ניתן לעקיבה חזרה לערך יומן הסכמה ספציפי. פריסה מגודרת כראוי, בצירוף בחירת אזור התואמת את הקהל, מתמיד שמוגדר כברירת מחדל לזיכרון ונתיב מחיקה שמופעל בנסיגה, הוא מה שהופך את PostHog מסיכון ריכוזיות רגולטורית למרכז ניתן להגנה של סטק אנליטיקת המוצר.