Safari קוצצת ל-7 ימים עוגיות שרת בתת-דומיין למעקב: מה זה עושה ל-sGTM

הרבה עסקים עברו בשנים האחרונות לתיוג בצד השרת (server-side tagging), למשל עם Google Tag Manager בגרסת השרת (sGTM), בין השאר כדי להאריך את חיי עוגיות הזיהוי. ניתוח חדש מראה שב-Safari, עוגיות שהשרת מגדיר מתת-דומיין למעקב, כמו sst.yourdomain.com, עלולות להיות מוגבלות ל-7 ימים בלבד אם תת-הדומיין יושב ברשת אחרת מזו של האתר הראשי. את הניתוח כתב Mariusz Brucki, מהנדס אנליטיקה ומייסד Measurelake, בבלוג של חברת התיוג TAGGRS ב-30 בספטמבר, ו-PPC Land הרחיב עליו באוקטובר.

לא שינוי חדש, אבל בעיה שעדיין לא נפתרה

חשוב לדייק: Safari לא שינתה משהו החודש. בעמוד מניעת המעקב של WebKit, המנוע של Safari, כתוב שבמקרים של הסוואה (cloaking) דרך CNAME או דרך כתובת IP של צד שלישי, הדפדפן מגביל את התוקף של כל עוגייה שמוגדרת בתגובת HTTP ל-7 ימים. לפי הניתוח, הכלל חל על עוגיות שרת מאז Safari 16.4, שיצאה ב-27 במרץ 2023. עוד ביולי 2023 דיווחה חברת האנליטיקה Louder על הטמעות sGTM שבהן עוגיית הזיהוי FPID, שהוגדרה לתוקף של עד שנתיים, פגה אחרי שבוע אצל משתמשי Safari. החידוש בניתוח הנוכחי הוא ההסבר המפורט למה גם הטמעה ״נכונה״ לכאורה, על תת-דומיין של האתר עצמו, עדיין נופלת.

איך Safari מחליטה שתת-הדומיין חשוד

מבחינת הדפדפן, תת-דומיין הוא ״אותו אתר״ (same-site), כי הוא חולק את הדומיין הראשי, אבל לא ״אותו מקור״ (same-origin), כי שם המארח שונה. לפי הניתוח, WebKit משווה בין כתובת הרשת של השרת שמחזיר את תגובת המעקב לבין זו של האתר הראשי. היא מסמנת הסוואה כשכתובת אחת היא IPv4 והשנייה IPv6, כששתי כתובות IPv4 חולקות פחות מ-16 ביטים ראשונים, או כששתי כתובות IPv6 חולקות פחות מ-64. לפי Brucki, WebKit מגדירה את המנגנון כהיוריסטיקה, כך שההתנהגות עשויה להשתנות בגרסאות הבאות.

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

מה זה עושה למדידה ולקמפיינים

כשהמזהה פג אחרי שבוע, משתמש שחוזר לאתר אחרי עשרה ימים נספר כמשתמש חדש. המסע שלו מתפצל לשתי זהויות ב-GA4 ובפלטפורמות אחרות, והקשר בין קליק על מודעה לבין רכישה מאוחרת יותר עלול ללכת לאיבוד. לפי הניתוח, זה גם מצמצם את האותות ש-Smart Bidding מקבל ופוגע באיכות קהלי הרימרקטינג. User ID של משתמשים מחוברים ונתונים ממודלים יכולים לחבר חלק מהביקורים, אבל לא את כולם.

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

הפתרון: נתיב באתר הראשי

הפתרון שמוצע בניתוח הוא לעבור ל״אותו מקור״: להגיש את המעקב מנתיב באתר הראשי, כמו yourdomain.com/metrics, דרך reverse proxy או Cloudflare Worker שמעביר את הבקשות לקונטיינר בשרת. התנאי הקריטי הוא שכל כותרת Set-Cookie תועבר כמו שהיא, עם המאפיינים הנכונים. ל-Google יש פתרון דומה משלה, Google tag gateway, שהושק במאי 2025 עם Cloudflare כשותפה ראשונה, ומיוני 2026 זמין גם בשילוב עם Google Cloud. Google טענה לשיפור של 11% באותות, אבל אלה נתונים של Google, לא מדידה עצמאית. גם TAGGRS, שפרסמה את הניתוח, מוכרת פתרון כזה, ואין בניתוח נתונים על היקף התופעה. Louder הציעה בזמנו חלופה: להריץ את שרת התיוג על אותה תשתית או על טווח כתובות דומה לזה של האתר.