Safari קוצצת ל-7 ימים עוגיות שרת בתת-דומיין למעקב: מה זה עושה ל-sGTM
ניתוח חדש מסביר למה הטמעות של תיוג בצד השרת על תת-דומיין, כמו sst.yourdomain.com, עדיין מאבדות את עוגיות הזיהוי אחרי שבוע ב-Safari, ומה המשמעות לייחוס ולבידינג. הפתרון המוצע: נתיב באתר הראשי.
TL;DR בקצרה
- Safari מגבילה ל-7 ימים עוגיות שמוגדרות בתגובת HTTP כשהיא מזהה הסוואה דרך CNAME או כתובת IP של צד שלישי.
- ההתנהגות קיימת מאז Safari 16.4 (מרץ 2023), אבל ניתוח מספטמבר 2026 מראה שהיא עדיין פוגעת בהטמעות sGTM על תת-דומיין.
- התרחיש הנפוץ: האתר הראשי מאחורי Cloudflare ושרת המעקב אצל ספק אחר, כך שכתובות ה-IP לא דומות.
- הפתרון המוצע: להגיש את המעקב מנתיב באותו מקור, למשל yourdomain.com/metrics, ולהעביר את כותרות Set-Cookie במלואן.
הרבה עסקים עברו בשנים האחרונות לתיוג בצד השרת (server-side tagging). למשל, עם Google Tag Manager בגרסת השרת (sGTM). בין השאר, הם רצו להאריך את חיי עוגיות הזיהוי. ניתוח חדש מראה ש-Safari עלולה לקצר ל-7 ימים בלבד עוגיות שהשרת מגדיר מתת-דומיין למעקב. זה קורה אם תת-הדומיין, כמו sst.yourdomain.com, יושב ברשת אחרת מזו של האתר הראשי.
את הניתוח כתב Mariusz Brucki, מהנדס אנליטיקה ומייסד Measurelake. הוא פרסם אותו בבלוג של חברת התיוג TAGGRS ב-30 בספטמבר. באוקטובר הרחיב עליו PPC Land.
Safari: לא שינוי חדש, אבל בעיה שעדיין לא נפתרה
חשוב לדייק: Safari לא שינתה משהו החודש. WebKit הוא המנוע של Safari, ובעמוד מניעת המעקב שלו מופיע כלל לגבי הסוואה (cloaking). ההסוואה יכולה להיות דרך CNAME או דרך כתובת IP של צד שלישי. במקרים כאלה, הדפדפן מגביל ל-7 ימים את התוקף של כל עוגייה שמוגדרת בתגובת HTTP.
לפי הניתוח, הכלל חל על עוגיות שרת מאז 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. Google השיקה אותו במאי 2025 עם Cloudflare כשותפה ראשונה. מיוני 2026 הוא זמין גם בשילוב עם Google Cloud. Google טענה לשיפור של 11% באותות, אבל אלה נתונים של Google, לא מדידה עצמאית.
גם TAGGRS, שפרסמה את הניתוח, מוכרת פתרון כזה, ואין בניתוח נתונים על היקף התופעה. Louder הציעה בזמנו חלופה. לפי ההצעה, שרת התיוג רץ על אותה תשתית כמו האתר, או על טווח כתובות דומה.
מה זה אומר עבורכם
- בדקו אם הבעיה פוגעת בכם: פתחו את האתר ב-Safari במק. בכלי המפתחים בדקו את תאריך התפוגה של FPID או של עוגיות אחרות שהשרת מגדיר. תפוגה של שבוע במקום חודשים היא הסימן.
- השוו כתובות. בדקו לאן מפנה תת-הדומיין של המעקב (רשומת A, AAAA או CNAME) לעומת האתר הראשי. אם אחד מאחורי Cloudflare והשני אצל ספק אחר, סביר שאתם בתרחיש שתואר.
- שקלו מעבר לנתיב באותו מקור: דרך Google tag gateway, Cloudflare Worker או reverse proxy. ודאו שכותרות Set-Cookie עוברות במלואן. העדיפו נתיב לא צפוי, כי חוסמי פרסומות עלולים לחסום נתיבים כמו /analytics או /collect.
- אל תתלו הכל בעוגייה. שלחו User ID עבור המשתמשים המחוברים, כדי שהזיהוי לא יהיה תלוי רק בדפדפן.
- מדדו לפני ואחרי: השוו את שיעור המשתמשים החוזרים מ-Safari לפני השינוי ואחריו. וזכרו: ההסכמה לעוגיות היא עדיין חובה בכל מקרה.
מקורות והרחבה
- Safari cuts server-set cookies to 7 days on cloaked tracking subdomainsPPC Land
- Tracking Prevention in WebKitWebKit
- Apple ITP targets HTTP cookies with 7-day capLouder
- WebKit Features in Safari 16.4WebKit
הכתבה נכתבה במקור בעברית על ידי מערכת GEEKLIK, על בסיס המקורות שלמעלה ובדיקת העובדות מולם.
מצאתם טעות? דווחו לנו
