מה זה ITP ועל מה הוא חל?
ITP הוא לא תוסף ולא הגדרה שהמשתמש מדליק. לפי עמוד המדיניות של WebKit, רוב ההגנות נגד מעקב פעילות כברירת מחדל. העמוד מתאר את מדיניות העוגיות של WebKit במערכות ההפעלה של Apple, בהן iOS, iPadOS ו-macOS. כלומר מדובר בכל גולש Safari רגיל, לא בקבוצה קטנה של משתמשים שמודעים לפרטיות.
המנגנון נבנה בשכבות לאורך כמה שנים. ההגבלה על עוגיות שנוצרו ב-JavaScript הוצגה ב-ITP 2.1, בגרסאות הבטא של iOS 12.2 ושל Safari 12.1. החסימה המלאה של עוגיות צד שלישי הגיעה ב-iOS ו-iPadOS 13.4 וב-Safari 13.1 ב-macOS. מה שמעניין היום הוא לא ההיסטוריה אלא המצב הנוכחי, כפי שהוא מתועד בעמוד Tracking Prevention in WebKit.
מה קורה לעוגיות צד שלישי ב-Safari?
הן נחסמות. לפי התיעוד, ITP חוסם כברירת מחדל את כל עוגיות הצד השלישי, בלי חריגים. הדרך היחידה לקבל גישה היא Storage Access API, לצד תיקון תאימות זמני לחלונות קופצים. גם אחסון אחר של צד שלישי מוגבל: LocalStorage ו-IndexedDB של צד שלישי מחולקים לפי האתר שבו המשתמש נמצא ומוגדרים כזמניים.
בנוסף, ה-referrer של צד שלישי מקוצר כברירת מחדל לרמת ה-origin. ההגבלה חלה גם על כותרת ה-referrer בבקשת HTTP וגם על document.referrer. הדוגמה בתיעוד: כתובת מלאה של פיד ברשת חברתית, כולל פרמטר clickID, מגיעה לאתר שלכם ככתובת הבסיס בלבד.
לכן כל מדידה שנשענת על עוגיית צד שלישי פשוט לא קיימת ב-Safari. השאלה המעשית היא מה קורה לעוגיות צד ראשון, אלה שהתגים שלכם כותבים על הדומיין שלכם.
לכמה זמן נשמרת עוגיית צד ראשון שנוצרה ב-JavaScript?
שבעה ימים. לפי עמוד המדיניות, ITP מוחק את כל העוגיות שנוצרו ב-JavaScript ואת כל שאר האחסון שסקריפט יכול לכתוב אחרי 7 ימים בלי אינטראקציה של המשתמש עם האתר. הרשימה כוללת את IndexedDB, LocalStorage, Media keys, SessionStorage ואת הרישומים והמטמון של Service Worker. מי שחשב לעקוף את ההגבלה על עוגיות דרך LocalStorage מגלה שההגבלה זהה.
שני פרטים שקל לפספס. הראשון: אינטראקציה מוגדרת בתיעוד כקליק, הקשה או הקלדה באתר, בעוד שגלילה לא נחשבת אינטראקציה. השני: בפוסט של WebKit על החסימה המלאה הספירה מתוארת כשבעה ימים של שימוש ב-Safari בלי אינטראקציה עם האתר, כלומר הימים נספרים לפי ימי שימוש בדפדפן. חריג אחד: אפליקציית ווב שנוספה למסך הבית פטורה מההגבלה הזאת על הדומיין שלה.
| סוג האחסון | מה ITP עושה | משך |
|---|---|---|
| עוגיות צד שלישי | נחסמות כברירת מחדל, בלי חריגים | לא נשמרות |
| עוגיות שנוצרו ב-JavaScript | נמחקות בלי אינטראקציה של המשתמש עם האתר | 7 ימים |
| LocalStorage, IndexedDB, SessionStorage, Service Worker | נמחקים באותו כלל כמו עוגיות JavaScript | 7 ימים |
| עוגיות JavaScript בדף נחיתה עם link decoration | התוקף מקוצר | 24 שעות |
| עוגיות בתגובת HTTP של צד ראשון | לא כפופות להגבלת 7 הימים | לפי התוקף שהשרת קבע |
| עוגיות בתגובת HTTP בבקשה שזוהתה כ-cloaking של צד שלישי | התוקף מקוצר | 7 ימים |
מתי התוקף יורד ל-24 שעות?
כשמעורב link decoration, כלומר מזהה קליק שמוצמד לכתובת הקישור. התיעוד מתאר את השיטה כך: גורם מעקב מוסיף מזהה לכתובת, סקריפט בדף היעד קורא אותו ושומר אותו כדי לקשר את המשתמש בין אתרים. ITP מזהה את הדפוס הזה ומגביל ל-24 שעות את התוקף של עוגיות שנוצרו ב-JavaScript בדף הנחיתה.
בפוסט על ITP 2.2 מפורטים שני התנאים, ששניהם צריכים להתקיים. הראשון: הדומיין שהעביר את המשתמש לדף סווג כבעל יכולת מעקב חוצה אתרים. השני: בכתובת הסופית של הניווט יש query string או fragment. לפי התיעוד, הסיווג מבוסס על דפוסים כמו הופעה כמשאב צד שלישי תחת אתרים רבים ועל הפניות בין אתרים.
המשמעות לקמפיינים ברורה: תנועה ממודעה מגיעה כמעט תמיד עם פרמטרים בכתובת, ממקור שעשוי להיות מסווג. דווקא התנועה שהכי חשוב לכם לייחס היא זאת שחשופה לחלון הקצר ביותר.
עוגיית צד ראשון ב-Safari
מה קורה למזהה של משתמש שהגיע ממודעה
האם עוגייה שהשרת קובע פטורה מההגבלה?
ברוב המקרים כן, עם סייג אחד. בפוסט על ITP 2.1 נכתב שרק עוגיות שנוצרו דרך document.cookie מושפעות מהשינוי, כך שעוגייה שמגיעה בתגובת HTTP מהשרת של האתר לא נכללת בהגבלת שבעת הימים.
הסייג הוא ההגנה מפני cloaking. לפי עמוד המדיניות, ITP מזהה בקשות של CNAME cloaking ושל IP address cloaking מצד שלישי. במקרים האלה הוא מגביל ל-7 ימים את התוקף של כל עוגייה שנקבעה בתגובת ה-HTTP. CNAME cloaking מוגדר שם כמשאב של צד ראשון שנפתר דרך CNAME ששונה מהדומיין של האתר וגם מה-CNAME של הדומיין הראשי עצמו, אם יש לו כזה. לדוגמה, תת-דומיין שלכם שמפנה ב-DNS לשרתים של ספק מדידה חיצוני. את המקרה של כתובת IP התיעוד מזכיר בשמו בלי לפרט את כלל הזיהוי.
לכן "עוגיית שרת" היא לא מילת קסם. ההבדל הוא בין שרת שהוא באמת חלק מהתשתית של האתר לבין תת-דומיין שרק נראה כמו צד ראשון. את השיקולים של תשתית כזאת פירטנו במתי צריך מדידה בצד שרת. את שלבי ההקמה עצמם תמצאו בהקמת Server-Side GTM.
מה זה עושה למדידה ב-GA4 ובפלטפורמות הפרסום?
לפי מרכז העזרה של Google Analytics, תגי ה-JavaScript של GA4 משתמשים בעוגיות צד ראשון כדי להבחין בין משתמשים ובין סשנים. העוגייה _ga מזהה את המשתמש ותוקף ברירת המחדל שלה הוא שנתיים. ב-Safari המספר הזה תיאורטי, כי עוגייה שתג בדפדפן יוצר כפופה לכלל שבעת הימים. אותו עמוד של Google מציין זאת בעצמו: דפדפנים מגבילים את משך החיים של עוגיות צד ראשון כשהמשתמש לא חוזר לאתר, עד 400 יום ב-Chrome ועד 7 ימים ב-Safari. מכאן נובעות שלוש השפעות על הדוחות.
הראשונה היא ספירת משתמשים. גולש Safari שחוזר אחרי שהעוגייה נמחקה מקבל מזהה חדש ונספר כמשתמש חדש. השנייה היא ייחוס. המרה שמתרחשת אחרי שהעוגייה נמחקה כבר לא מחוברת לביקור שהתחיל את המסע, כך שהמקור המקורי אובד. השלישית היא פלטפורמות הפרסום, ששומרות את מזהה הקליק בעוגיית צד ראשון. כשהעוגייה נעלמת, ההמרה לא נקשרת לקליק.
ההשפעה לא אחידה בין עסקים: באתר שבו רוב ההמרות קורות באותו ביקור היא קטנה, בעוד שבעסק עם מחזור החלטה של שבועות היא משמעותית. חלק מהפער הזה Google משלים בהערכה סטטיסטית, כפי שהסברנו במידול המרות ב-Google Ads וב-GA4.
מה משתנה בגלישה פרטית?
בגלישה פרטית ההגנות מחמירות: לפי התיעוד, הסשן שם זמני ועוגיות לא נשמרות אחרי סגירת הלשונית. מאז Safari 17.0 נוספה לגלישה הפרטית הגנה בשם Link Tracking Protection: Safari מסיר מהכתובת חלק מהפרמטרים שזוהו כמשמשים למעקב חוצה אתרים. לפי הפוסט של WebKit, פרמטר שמשמש רק לייחוס קמפיין ולא מזהה משתמש בודד ממשיך לעבור. המשתמש יכול להרחיב את ההגנות האלה גם לגלישה רגילה דרך ההגדרה Advanced Tracking and Fingerprinting Protection.
איך מצמצמים את הנזק למדידה?
- מודדים את היקף הבעיה. משווים ב-GA4 את Safari לשאר הדפדפנים: שיעור המשתמשים החדשים, שיעור המשתמשים החוזרים ומשך הזמן עד ההמרה. בלי המספר הזה אי אפשר לדעת אם שווה להשקיע בתשתית.
- מעבירים את הזיהוי לעוגייה שהשרת של האתר קובע. לפי התיעוד של Google ל-Server-Side GTM, שרת תיוג שרץ על הדומיין של האתר יכול להגדיר עוגיות מהשרת, עם מה ש-Google מכנה יתרונות אבטחה ועמידות. שרת שנשאר על דומיין ברירת המחדל של ספק הענן יכול להגדיר רק עוגיות JavaScript. לפי WebKit, עוגייה בתגובת HTTP של צד ראשון לא כפופה להגבלת שבעת הימים.
- בודקים שהתשתית לא נראית כמו cloaking. לפי הטבלה של WebKit, תת-דומיין שמפנה ב-CNAME לצד שלישי, כשהדומיין הראשי עצמו לא מפנה לאותו יעד, מקבל שוב את ההגבלה של 7 ימים. את זה בודקים מול מי שמנהל את ה-DNS לפני שבונים, לא אחרי.
- מזהים משתמשים מחוברים במזהה משלכם. באתר עם התחברות, מזהה משתמש שנשלח מהמערכת שלכם לא תלוי בעוגיית הדפדפן. פירטנו בUser-ID וזהות הדיווח ב-GA4.
- מחזקים את ההמרות בנתוני צד ראשון. התאמה לפי נתונים שהלקוח מסר, כמו בEnhanced Conversions ל-Google Ads, לא נשענת רק על עוגיית הקליק.
מה לא כדאי לנסות: העברת המזהה ל-LocalStorage או לכל אחסון אחר בדפדפן. לפי התיעוד, כל אחסון שסקריפט כותב נמחק באותו כלל.
שאלות נפוצות
מה זה ITP ב-Safari?
ITP, ראשי תיבות של Intelligent Tracking Prevention, הוא מנגנון מניעת המעקב של WebKit, מנוע הדפדפן של Safari. לפי התיעוד של WebKit הוא חוסם כברירת מחדל את כל עוגיות הצד השלישי ומגביל את משך החיים של עוגיות ואחסון שנוצרו ב-JavaScript. רוב ההגנות פעילות כברירת מחדל, בלי שהמשתמש צריך להפעיל משהו.
לכמה זמן Safari שומר עוגיית צד ראשון?
לפי התיעוד של WebKit, עוגייה שנוצרה ב-JavaScript נמחקת אחרי 7 ימים בלי אינטראקציה של המשתמש עם האתר. אותו כלל חל על LocalStorage, IndexedDB, SessionStorage ו-Service Worker. עוגייה שהשרת של האתר קובע בתגובת HTTP לא כפופה להגבלה הזאת, אלא אם הבקשה זוהתה כ-cloaking של צד שלישי.
מתי Safari מקצר עוגייה ל-24 שעות?
כשמזוהה link decoration. לפי הפוסט של WebKit על ITP 2.2 צריכים להתקיים שני תנאים. הראשון: הדומיין שהעביר את המשתמש לדף סווג כבעל יכולת מעקב חוצה אתרים. השני: בכתובת הסופית יש query string או fragment. במצב כזה התוקף של עוגיות שנוצרו ב-JavaScript בדף הנחיתה מוגבל ל-24 שעות.
האם ITP משפיע על עוגיית GA4 _ga?
כן. לפי מרכז העזרה של Google Analytics, תגי ה-JavaScript של GA4 משתמשים בעוגיות צד ראשון. תוקף ברירת המחדל של עוגיית GA4 _ga הוא שנתיים, אבל אותו עמוד מציין שדפדפנים מגבילים עוגיות צד ראשון כשהמשתמש לא חוזר, עד 7 ימים ב-Safari. זה כלל שבעת הימים של ITP על עוגיות שתג בדפדפן יוצר. משתמש שחוזר אחרי שהעוגייה נמחקה מקבל מזהה חדש ונספר כמשתמש חדש.
האם מדידה בצד שרת פותרת את ההגבלה של ITP?
רק אם העוגייה באמת נקבעת על ידי צד ראשון. לפי WebKit, עוגיות בתגובת HTTP של צד ראשון לא מוגבלות ל-7 ימים. אבל ITP מזהה CNAME cloaking ו-IP address cloaking של צד שלישי. במקרים האלה התוקף של עוגיות בתגובת ה-HTTP מוגבל ל-7 ימים. תת-דומיין שמפנה לספק חיצוני לא מספיק.
מה נחשב אינטראקציה של המשתמש מבחינת ITP?
לפי התיעוד של WebKit, אינטראקציה היא קליק, הקשה או הקלדה באתר. גלילה לא נחשבת אינטראקציה. ההגבלה של 7 ימים על עוגיות ואחסון שנוצרו ב-JavaScript חלה כשאין אינטראקציה כזאת עם האתר. משתמש שרק נכנס וגולל בלי ללחוץ על דבר לא מאריך את חיי המזהה שלו.
מה השורה התחתונה?
ITP לא שובר את המדידה, הוא מקצר את הזיכרון שלה. ב-Safari עוגייה שתג בדפדפן יוצר חיה שבעה ימים בלי אינטראקציה, לפעמים רק 24 שעות. כל ביקור חוזר מעבר לחלון הזה נראה כמו משתמש חדש בלי מקור. הצעד הראשון הוא למדוד כמה מההמרות שלכם קורות מעבר לחלון הזה ב-Safari. רק אז מחליטים אם להעביר את הזיהוי לעוגייה שהשרת של האתר קובע, בלי תת-דומיין שנראה כמו cloaking. את הבדיקה ואת ההקמה אנחנו עושים כחלק משירות מדידה מתקדמת. אם הנתונים של Safari אצלכם נראים שונה משאר הדפדפנים בלי הסבר, כתבו לנו.
מקורות
WebKit: Tracking Prevention in WebKit, WebKit: Intelligent Tracking Prevention 2.1, WebKit: Intelligent Tracking Prevention 2.2, WebKit: Full Third-Party Cookie Blocking and More, WebKit: Private Browsing 2.0, Analytics Help: [GA4] Cookie usage on websites
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי