על עוגיות והקשר לאתר שלכם ולשיווק דיגיטלי

המאמר הזה נכתב במקור בדצמבר 2023. הגרסה שלפניכם עודכנה ב־7 באפריל 2026.

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

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

מה זה בכלל קוקי

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

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

קוקי חיוני לעומת לא חיוני

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

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

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

First party לעומת third party

כאן נמצא אחד הפערים הכי משמעותיים בהבנה של הנושא. יש קוקיז שהאתר שלכם מציב וקורא בעצמו, ויש קוקיז שמוצבים או נקראים על ידי שירות חיצוני שפועל מתוך האתר. הראשונים נקראים בדרך כלל first party. השניים third party.

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

ההבחנה הזאת גם מסבירה חלק גדול מהשינויים שקרו בשנים האחרונות בשוק הפרסום. כרום התחיל בסוף 2023 ניסוי של Tracking Protection, שבו לחלק קטן מהמשתמשים הוגבלה כברירת מחדל הגישה לקוקיז של צד שלישי. אחר כך, באפריל 2025, גוגל הודיעה שהיא לא תמשיך כרגע למסלול של חסימה גורפת לכל המשתמשים, אלא תשאיר את הגישה הקיימת ותמשיך לקדם את Privacy Sandbox וכלי פרטיות נוספים. כלומר, קוקיז של צד שלישי לא נעלמו, אבל אי הוודאות סביבם והמעבר לפתרונות אחרים בהחלט נשארו חלק מהמציאות.

איפה המידע באמת נאסף ונשמר

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

אפשר לראות את זה טוב באתר ישראלי טיפוסי שבנוי על וורדפרס. נניח אתר עם אלמנטור, ווקומרס, טופס לידים, GA4, פיקסל של מטא וצ'אט חיצוני. מבחוץ זה נראה כמו אתר אחד. בפועל זו כבר מערכת עם שכבת תפעול, שכבת מדידה, שכבת פרסום ושכבת שירותים חיצוניים. במקרים רבים זה יכול להגיע בקלות ל־15 עד 25 קוקיז וטכנולוגיות דומות ממקורות שונים. זה לא אומר שמשהו שם בהכרח לא בסדר. זה כן אומר שבעל האתר לא יכול להסתפק במשפט כללי על עוגיות לשיפור חוויית השימוש ולחשוב שזה סוגר את התמונה.

מה זה אומר בישראל

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

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

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

מה נכון שיהיה ברור למשתמשים

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

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

למה הנתונים נשברים, גם כשלא נגעתם בקמפיין

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

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

איפה נכנסים Consent Mode ומדידה בצד שרת

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

אותו עיקרון נכון גם למדידה בצד שרת. כלים כמו Google Tag Manager Server Side או פתרונות דומים לא מבטלים את הצורך בהסכמה, ולא פותרים לבדם את העניין החוקי. הם כן יכולים לשפר שליטה, ביצועים ואיכות מדידה, כי פחות קוד רץ בדפדפן ויותר לוגיקה עוברת לסביבה שאתם מנהלים. בעולם של מטא, עסקים רבים פוגשים את אותו כיוון דרך Conversions API, בדיוק מאותה סיבה. ניסיון להשלים חלק מהפער שנוצר כשדפדפנים ומשתמשים מגבילים מדידה בצד לקוח.

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

איך בודקים מה באמת קורה אצלכם

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

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

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

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