סורק קוקיז לא מוצא חצי מהטראקרים: היכן זה נשבר
סורק קוקיז עובר על הדף כמו רובוט: טוען את הסימון, ממתין לרינדור, אוסף בקשות לדומיינים חיצוניים. הבעיה היא שמשתמש אמיתי עובר על הדף אחרת — פותח חלונות מודאליים, מאשר באנר, גולל בפיד, ורק אז נטענים סקריפטים של אנליטיקה, ריטרגטינג וצ'אטים. סריקת קוקיז כברירת מחדל רואה חתך סטטי ומפספסת כל מה שנטען בעקבות פעולה.
הסיבה הנפוצה ביותר היא טעינה דינמית. הסקריפט מוכנס ל-DOM לאחר לחיצה, גלילה או טיימאאוט, וברגע הסריקה הוא עדיין לא נמצא בסימון. השנייה — סקריפטים חיצוניים שמופעלים לא ישירות, אלא דרך מנהל תגים: הסורק רואה קונטיינר אחד, ובתוכו עשרה תגים, כל אחד עם הקוקיז שלו.
השלישית — פיקסלים וטראקרים נסתרים בתוך iframe: הם לא מוסרים את עצמם למסמך הראשי, והסריקה לא מתעדת אותם.
בנפרד, מטמון ו-CDN שוברים את התמונה. הסורק מקבל גרסה שמורה במטמון של הדף, שבה חלק מהתגים כבר נחתכו או, להפך, נשארו מבנייה קודמת.
אם באנר ההסכמה נטען באופן אסינכרוני, סריקת הקוקיז עלולה בכלל לא לראות אותו ברגע הבדיקה — ובדוח תופיע עמוד "נקי", אף שבפרודקשן הטראקרים פעילים.
שורה תחתונה: הסורק מציג לא את סט הטראקרים האמיתי, אלא את מה שהספיק להתבצע בזמן שהוקצה לו. לכן הגדרה נכונה מתחילה לא בכפתור "Scan", אלא בשחזור תרחישי משתמש — נבחן כיצד זה נסגר ברמת הגדרות הסריקה ומנהל התגים.
מה נותנת הגדרה נכונה של סורק ה-cookie
הגדרת סורק ה-cookie אינה "להציב באנר ולשכוח". הסורק עובר על האתר לפי מפת עמודים, מיירט בקשות לפני ואחרי אינטראקציה עם הממשק ואוסף את כל מה שנשלח לדפדפן: סקריפטים עצמיים, פיקסלים של צד שלישי, ווידג'טים מוטמעים, תגי אנליטיקה ופרסום.
בפלט נוצר מרשם של טראקרים, שבו לכל פריט יש מקור, ייעוד, תוחלת חיים וקטגוריית cookie. אם מפת המעבר אינה מלאה, חלק מהטראקרים נשארים מחוץ למרשם — ואותם בדיוק הופכים למקור לתלונות בעת בדיקת תאימות.
הניסיון מלמד: באתר טיפוסי עם טפסים, צ'אט ואנליטיקה מוטמעת, מעבר ראשוני מוצא noticeably פחות טראקרים מכפי שיש בפועל. הסיבה היא שחלק מהסקריפטים נטענים רק לאחר פעולת משתמש — שליחת טופס, פתיחת מפה, לחיצה על וידאו.
לכן מגדירים את הסורק במצב תרחישים: הוא עובר על נתיבי משתמש מרכזיים, מתעד שינויים ומוסיף את מה שנמצא למרשם. לאחר מכן קטגוריות ה-cookie מפסיקות להיות פורמליות — טראקרים שיווקיים, אנליטיים והכרחיים לחלוטין מופרדים לקבוצות שלהם, ולא נערמים לאחת.
עבודה נפרדת היא החיבור בין הסורק למנגנון ההסכמה. כל עוד הבאנר לא קיבל פעולה מפורשת של המשתמש, אף טראקר שאינו הכרחי לא אמור להתחיל; לאחר סירוב — לא אמור לפעול כלל.
זה נבדק לא בעין אלא בהרצה: הסורק מתעד אילו בקשות נשלחות לפני ההסכמה, אילו אחריה, והאם ההתנהגות בפועל תואמת את המוצהר במדיניות. פער כאן הוא הסיבה הנפוצה ביותר לכך שבדיקת תאימות מסתיימת בהוראה מחייבת.
האפקט המדיד מהסדר שהושרר מורכב מכמה דברים. שלמות מרשם הטראקרים מגיעה לרמה שבה סקריפטים חדשים נתפסים בשלב ההוספה, ולא כעבור חצי שנה. שיעור ההסכמות התקינות עולה, משום שהבאנר מפסיק לחסום את הממשק ובמקביל אינו מניח לטראקרים לעבור לפני הזמן.
מהירות המעבר של בדיקות וביקורת cookie תופסת שעות במקום שבועות — המרשם, הקטגוריות ויומני ההסכמות מיוצאים בדוח אחד. סיווג התלונות יורד: במקום מחלוקת על עצם דליפת הנתונים, נדונה פרוצדורה שכבר פועלת.
דרכים לפרוס סורק קוקיז: השוואת אפשרויות
ניתן לפרוס את הסורק בשלוש דרכים, והבחירה קובעת לא את "האופנתיות" של הכלי, אלא מי אחראי על עדכניות מאגר הטראקרים וכיצד מהר תיקון מגיע לפרודקשן. להלן השוואה לפי קריטריונים אמיתיים: מהירות ההתחברות, שליטה בנתונים, עומס התמיכה והמחלקה של המגבלות שמקבלים יחד עם כל אפשרות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סורק בענן | נדרש התחלה מהירה וסריקה חוזרת שוטפת ללא תשתית משלכם | נתוני הסריקה עוברים לצד של הספק; עומק הסריקה מוגבל לפי התוכנית ומגבלת העמודים; ווידג'טים וסקריפטים מותאמים אישית שנטענים לפי פעולה לא תמיד מזוהים |
| אוסף עצמאי בצד האתר | דרישות מחמירות לגבי היכן מאוחסנים הנתונים, או סטאק לא סטנדרטי | יש לתחזק בעצמכם את הסורק, לעדכן חתימות של טראקרים ולעקוב אחר עדכוני מדיניות הדפדפנים; סף הכניסה גבוה יותר |
| תוכנית היברידית | נדרשת שליטה בנתונים יחד עם מאגר טראקרים מוכן | מורכבת יותר לאיתור באגים: פער בין מה שהענן רואה לבין מה שהאוסף המקומי רואה יש לנתח ידנית |
המגבלה המרכזית של כל סורק — הוא רואה רק את מה שהספיק להיטען בזמן הסריקה. סקריפטים שמתחברים לאחר הסכמה, בגלילה או בחלונות מודאליים, לא נכנסים לדוח הבסיסי, ולכן חיבור סקריפט כמעט תמיד משלימים בבדיקה ידנית של תרחישי המפתח.
את התוכנית ההיברידית בוחרים כאשר המאגר בענן מכסה 80% מהטראקרים הטיפוסיים, ואת 20% הנותרים — האינטגרציות שלכם, שיש לשלוט בהן באופן מקומי. אז הענן אחראי על רוחב הכיסוי, והאוסף העצמאי — על העומק בתרחישים שלכם.
איך אנחנו מטמיעים סורק קוקיז: שלבי העבודה
אנחנו מתחילים את ההטמעה לא מהבאנר, אלא מהמלאי: הסורק עובר על האתר לפי מפת המדורים ומתעד אילו סקריפטים מציבים קוקיז, לאיזה דומיין הם פונים, והאם הם נטענים לפני מסירת ההסכמה או אחריה.
בשלב הזה עולים מונים "נשכחים", ווידג'טים מוטמעים ופיקסלים שקבלני צד שלישי מציבים — דווקא הם לרוב פוגעים בתקינות הבאנר.
בהמשך אנחנו ממיינים את מה שנמצא לקטגוריות (הכרחיים לחלוטין, אנליטיים, שיווקיים, פונקציונליים) ומגדירים את התנהגות הפלטפורמה: חסימה עד למתן הסכמה, בקשה חוזרת בעת עדכון המדיניות, תקופת שמירת הבחירה, כללי גיאו לאזורים שונים.
את הקטגוריות אנחנו מצליבים עם נוסח מדיניות הקוקיז והרשימה שבה — אי-התאמה בין הבאנר למסמך היא הדבר הראשון שבודקים מוצאים.
- ביקורת עמודים ומלאי סקריפטים: מעבר על המדורים, תיעוד מקורות הקוקיז וייעודם.
- הצלבה עם מדיניות הפרטיות: הבאת רשימת הקוקיז והקטגוריות לצורה אחידה.
- הגדרת קטגוריות וטריגרים: מה נחסם עד למתן הסכמה, מה נטען מיד, איך עובד הסירוב.
- חיבור פלטפורמת ניהול ההסכמה וקישורה לתגים ולמערכות אנליטיקה.
- בדיקה על תעבורה חיה: סשנים לבדיקה, סירוב והסכמה חוזרת, דפדפני מובייל, רענון עמוד.
- תיקון אי-התאמות: סקריפטים שמציבים קוקיז בעקיפין לבאנר מועברים לניהול ההסכמה.
- מסירת תיעוד ותקנון ליווי: איך מוסיפים סקריפטים חדשים ומתי בוחנים מחדש את הקטגוריות.
לאחר ההשקה אנחנו משאירים תקנון: כל מונה או ווידג'ט חדש עובר את אותה בקרה, ורשימת הקוקיז מתעדכנת עם שינוי המדיניות. כך הסורק לא הופך להגדרה חד-פעמית — הוא נשאר כלי עבודה שמחזיק את ההסכמות במצב מעודכן.
מדיניות הסכמה וכללי חסימת טראקרים
מדיניות הסכמה היא לא טקסט בעמוד, אלא קונפיגורציה מבוצעת: קטגוריות קוקיז, תנאי הפעלת הבאנר והכללים שלפיהם סקריפטים נטענים מיד או ממתינים לפעולה מפורשת של המשתמש. להלן מה שהלקוח מקבל לידיו ובאילו סעיפים אנו עוברים יחד בעת הקבלה.
- מפת טראקרים. רשימה מלאה של סקריפטים, פיקסלים ותגים בכל התבניות: שם, ייעוד, קטגוריה, רגע הטעינה. אנו משווים לתעבורה בפועל, ולא לתיעוד של קבלנים — אי-התאמות צפות כמעט תמיד.
- קטגוריות קוקיז. הכרחיות strictly, אנליטיות, פונקציונליות, שיווקיות. הגבולות מוגדרים כך שלא ניתן לייחס תג שנוי במחלוקת ל"הכרחי" כברירת מחדל.
- כללי הפעלת הבאנר. גיאוגרפיה, שפה, ביקור חוזר, משיכת הסכמה. הבאנר אינו מכסה תוכן ואינו חוסם את הממשק לפני הסכמה במקומות שבהם הדבר שובר את התרחיש.
- רשימת חריגים. תגים שנטענים לפני הסכמה: הגנה מפני בוטים, אנטי-פראוד, איזון עומסים. כל חריג מנומק ומתועד בכתב.
- יומן הסכמות. מה ומתי בחר המשתמש, עם איזו גרסה של המדיניות, עם אפשרות ייצוא. זהו הוכחה בעת בדיקה ובסיס לבקשה חוזרת בעת שינוי מדיניות.
- נוהל עדכון. מי וכיצד מוסיף טראקר חדש, כיצד הוא נכנס למפה ולקטגוריה לפני העלאה לפרודקשן.
בנפרד אנו מתעדים את ההתנהגות בעת סירוב: אילו סקריפטים לא מתחילים, מה נמחק מאחסון הדפדפן, כיצד משיכת הסכמה מבטלת תגים שכבר נטענו. בלי זה המדיניות נשארת הצהרה, וחסימת הטראקרים — חלקית.
מקרה בוחן: סורק קוקיז באתר עם עשרות סקריפטים של צד שלישי
מה היה לפני
הלקוח הגיע עם תמונה טיפוסית: באתר יותר מעשרה סקריפטים של צד שלישי — אנליטיקה, פיקסלים פרסומיים, צ'אט תמיכה, מפות, ווידג'טים של ביקורות — ובאנר ההסכמות הציג למשתמש שלוש קטגוריות ואסף סימונים "בעין". סורק אוטומטי, שהופעל במצב בסיסי, מצא 6-7 טראקרים: הוא ראה רק את אלה שנטענים מיד עם פתיחת העמוד.
השאר התחברו מאוחר יותר — לאחר גלילה, לחיצה על כפתור או דרך שרשרת: סקריפט אחד משך שני, זה משך שלישי. טראקרים כאלה הסורק לא תיעד, וברשומה הם פשוט לא היו. בנוסף, חלק מהם הציבו קוקיז לפני שהמשתמש בכלל לחץ על משהו בבאנר — כלומר ההסכמה רשמית לא נאספה, אבל הנתונים כבר יצאו.
מה שינו
העברנו את הסורק למצב של מעבר על תרחישים: הוא עבר על העמודים כמו משתמש אמיתי — פתח תפריטים, גלל עד הסוף, שלח טפסים — ובכל שלב תיעד בקשות חדשות ומאגרי אחסון.
הגדרנו הפעלה מחדש תקופתית כדי לתפוס סקריפטים שלא מתחברים בכל פעם, וריכזנו את הממצאים לרשומת טראקרים אחודה עם ציון קטגוריה, ייעוד ורגע ההפעלה.
לאחר מכן בנינו מחדש את הלוגיקה של הבאנר: קטגוריות ההסכמות קושרו לקבוצות טראקרים אמיתיות מהרשומה, וטעינת כל סקריפט הותנתה בהסכמה שהתקבלה. מבחינה טכנית זהו חסימה עד לאישור מפורש — אף טראקר לא מתחיל לפני שהמשתמש אישר את הקטגוריה המתאימה. הכלי — CookieBot, אך הגישה ניתנת להעברה לכל סורק עם תמיכה בחסימה עד להסכמה.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| טראקרים ברשומה | 6-7 | 19 |
| טראקרים לפני הסכמה | 4 | 0 |
| שיעור סשנים עם הסכמה תקפה | ~60% | 94% |
| עריכות ידניות ברשומה בחודש | קבועות | לפי סקריפטים חדשים |
הרשומה הפסיקה להיות חלקית: סקריפטים חדשים שמשווקים מוסיפים נכנסים אליה כעת במעבר הבא, ולא אחרי תלונה. בדיקת התאימות הצטמצמה להשוואת הרשומה עם הבקשות בפועל — אין אי-התאמות.
במה שונה סורק קוקיז ממנהל הסכמה?
סורק קוקיז הוא כלי גילוי. הוא עובר על דפי האתר כמו מבקר רגיל, מתעד אילו טראקרים מצליחים לפעול לפני ואחרי אינטראקציה עם הבאנר, וממיין אותם לקטגוריות: הכרחיים בהחלט, אנליטיים, שיווקיים. בתוצאה מתקבל מלאי — רשימת סקריפטים עם ציון המקור, הדומיין, משך החיים והייעוד.
לאחר מכן יש לתחזק את הרשימה הזו: די להוסיף טופס חדש, להטמיע צ'אט או לחבר פיקסל פרסומי — והמלאי מתיישן עד שהסריקה תתבצע מחדש.
מנהל הסכמה פותר משימה אחרת — הוא מנהל את הבאנר ואת שמירת הבחירות. הוא זה שמציג למבקר חלון עם קטגוריות, חוסם טראקרים עד לקבלת הסכמה, מתעד מה ומתי האדם אישר או ביטל, ומעביר את הנתונים האלה הלאה — לאנליטיקה וליומן הראיות.
הסורק עצמו לא מצייר באנר ולא שומר הסכמה; מנהל בלי סורק לא יודע את הרשימה המלאה של מה שעליו לחסום. זהו ההבדל בין הכלים: האחד עונה על השאלה "מה מותקן אצלנו באתר", השני — "מה המבקר אישר ואיך נוכיח זאת".
בפועל הם עובדים יחד, והסדר חשוב. תחילה הסריקה נותנת מפה מלאה של הטראקרים, לאחר מכן הנתונים האלה מועברים להגדרות מנהל ההסכמה — קטגוריות, כללי חסימה, טקסטים של הבאנר.
אחרי זה הסריקה מופעלת מחדש, כבר עם באנר פעיל: כך בודקים שלפני ההסכמה לא דולף שום דבר מיותר, ואחרי — מתחבר בדיוק מה שמותר. הרצה סדירה לפי לוח זמנים תופסת טראקרים שהוספו בעקיפין לתהליך.
עבור הלקוח משמעות הדבר היא חלוקת אחריות פשוטה: הסורק מכסה את השלמות והעדכניות של המלאי, המנהל — את תקינות ניהול הבאנר ואת שמירת הבחירות. כאשר שניהם מוגדרים ומקושרים, הבדיקה מראה שאף טראקר לא מתחיל לפני ההסכמה, ויומן הבחירות מוכן לשאילתה בכל רגע.
ספקות טכניים נפוצים בנוגע להגדרת הסורק
סורק ה-cookie מתנהג באופן צפוי רק בעמודים סטטיים עם רינדור בצד השרת. ברגע שמופיעים אפליקציות עמוד יחיד, טעינה מדורגת של סקריפטים ו-cache אגרסיבי ב-CDN, התמונה משתנה: חלק מהסקריפטים מותקנים כבר אחרי המעבר הראשון, והסורק לא רואה אותם. להלן — ניתוח של המצבים שאנו נתקלים בהם בתדירות הגבוהה ביותר.
כבר פרוס סורק אחר — לשכתב הכול מחדש?
לא. תחילה מסירים את התצורה הנוכחית: אילו קטגוריות הוגדרו, לפי אילו סלקטורים מסומנים הסקריפטים, כיצד בנוי באנר ההסכמה ולאן הולך היומן. אם הסימון תקין, מעבירים אותו לפלטפורמה החדשה ומשנים רק את מה שלא מכסה את הדרישות. החלפה מלאה נדרשת כאשר הקטגוריות אינן מופרדות או שההסכמה אינה חוסמת את הסקריפטים עד לקבלתה.
אפליקציית עמוד יחיד — הסורק רואה לא את כל הסקריפטים. מה לעשות?
הבעיה היא שהסורק סורק את ה-URL, והאפליקציה טוענת מודולים בהתאם לניווט. מגדירים סריקה לפי המסלולים האמיתיים, ולא לפי נקודת כניסה אחת, ומוסיפים סימון ידני לסקריפטים שמותקנים לפי פעולת המשתמש.
לאחר מכן מריצים תרחישים: מעבר בין מדורים, פתיחת טפסים, אימות — ובודקים שכל סקריפט שנמצא נכנס לקטגוריה הנכונה.
CDN וה-cache מחזירים גרסה ישנה של הבאנר. כיצד לסנכרן?
הסורק והבאנר צריכים להתעדכן בגל אחד. מאפסים את ה-cache ב-CDN לאחר פרסום התצורה, מוסיפים גרסאות לסקריפט הבאנר עצמו ובודקים שבכל הצמתים מוחזרת הבנייה העדכנית. אחרת נוצר פער: הסורק כבר יודע על הסקריפט החדש, ולמבקר מגיע הסימון הישן ללא הקטגוריה הנדרשת.
באיזו תדירות להריץ סריקה חוזרת?
באופן קבוע, ולא חד-פעמי. קובעים סריקה תקופתית לפי לוח זמנים ובנוסף — לאחר כל שחרור, מכיוון שקוד חדש כמעט תמיד גורר אחריו סקריפט חדש. את תוצאת כל מעבר משווים לקודמת: הופיעו cookie לא מסומנים — מיד לעבודה, ולא כעבור חודש כשזה יצוף בבדיקה.
נדון במשימה שלך עם סורק ה-cookie
את השיחה אנחנו מתחילים לא במצגת, אלא באתר שלך: כמה דומיינים ותת-דומיינים, במה בנוי ה-frontend, איך בנויה קבלת ההסכמות ומה כבר מוגדר בסורק הנוכחי. זה מספיק כדי להבין את ההיקף ולא לנחש לפי צילומי מסך.
מכאן העבודה מתנהלת בשלבים, ובכל שלב אתה רואה תוצאה, ולא דוח על עומס:
- ניתוח המצב הנוכחי — אילו סקריפטים וטרэкеры באמת נטענים, מה מהם לפני הסכמת המשתמש, היכן הסורק מפספס הטמעות צד-שלישי.
- השוואה לדרישות — אילו קטגוריות הסכמה נדרשות לפי תחום השיפוט שלך ומודל העבודה עם הנתונים, מה כבר מכוסה ומה לא.
- הערכת עבודה — היקף התיקונים ב-markup ובתגים, נקודות האינטגרציה עם הסורק, מאמץ העבודה לכל בלוק.
- תוכנית הטמעה — רצף הצעדים, מה עושים בסביבת בדיקה, מה מעלים לפרודקשן ובאיזה סדר.
- הגדרה וחיבור — באנר, קטגוריות, כללי חסימה לפני הסכמה, סנכרון עם מערכות אנליטיקה ופרסום.
- בדיקה — הרצה עם הסורק, בדיקה ידנית של תרחישי המפתח, השוואת יומן ההסכמות להתנהגות בפועל של הסקריפטים.
- מסירה ותמיכה — הרשאות, תיעוד ההגדרות, נוהל עדכון בעת הוספת שירותים חדשים.
תמיכה בסורק — חלק נפרד של העבודה: כללים וקטגוריות מתיישנים כשמוסיפים שירות חדש לאתר או כשהמרקאפ משתנה. אנחנו מתעדים מי ואיך מבצע שינויים, כדי שהבאנר לא יהיה מנותק ממכלול הסקריפטים בפועל.
תאר את המשימה: כתובת האתר, הסורק הנוכחי ומה מטריד — סקריפטים שהוחמצו, באנר מיושן, היעדר יומן הסכמות. נחזור עם הערכה ותוכנית עבודה.