תיקון 13 לחוק הגנת הפרטיות נכנס לתוקף ב-14 באוגוסט 2025, הרחיב את ההגדרה של מידע אישי ונתן לרשות להגנת הפרטיות סמכויות אכיפה משמעותיות, כולל עיצומים כספיים. עבור מותגים שמפרסמים בדיגיטל, המשמעות המעשית היא לסדר שלושה דברים: מה נאסף באתר ובאפליקציה, איך מתקבלת ומועברת ההסכמה של המשתמש, ואיך נתוני ההמרות מגיעים לפלטפורמות הפרסום בצורה מלאה ומבוקרת.
בקצרה
- הרגולציה התהדקה. תיקון 13 הרחיב את ההגדרות, את חובת היידוע ואת סמכויות האכיפה, וחלק מהחברות נדרשות למנות ממונה על הגנת הפרטיות.
- הסכמה צריכה להיות אמיתית. לפי גילוי הדעת של הרשות בנושא הסכמה, שתיקה אינה הסכמה, ושימוש במידע לפרופיילינג שאינו קשור לעסקה דורש הסכמה אקטיבית.
- מדידה חסרה עלולה לפגוע במדיה. מערכות הפרסום של גוגל ומטא לומדות מנתוני ההמרות שהן מקבלות, ולכן אירועים חסרים או הסכמה שלא מועברת נכון עלולים להחליש את האופטימיזציה.
- מתחילים במיפוי. קודם בודקים מה רץ באתר ומה נשלח, ורק אז מחליטים אילו רכיבים נדרשים: מנגנון הסכמה שמחובר ל-Consent Mode, מדידה בצד השרת או חיבורי המרות ישירים כמו Conversions API.
מה זה תיקון 13 לחוק הגנת הפרטיות ומה הוא משנה?
תיקון 13 לחוק הגנת הפרטיות הוא העדכון הרחב ביותר של חוק הגנת הפרטיות הישראלי מאז נחקק ב-1981, כך לפי המדריך המקצועי של הרשות להגנת הפרטיות. התיקון אושר באוגוסט 2024 ונכנס לתוקף ב-14 באוגוסט 2025.
השינוי הראשון הוא בהגדרות. מידע אישי מוגדר כעת באופן רחב, ככל נתון הנוגע לאדם מזוהה או לאדם שניתן לזהות אותו, במקום רשימה סגורה של סוגי מידע. במקביל נקבעה קטגוריה של "מידע בעל רגישות מיוחדת", שכוללת בין היתר מידע רפואי, גנטי וביומטרי ונתוני מיקום. גם המונח "עיבוד" הורחב, והוא כולל איסוף, אחסון, העתקה, מסירה והעברה של מידע.
השינוי השני הוא באכיפה. הרשות קיבלה סמכות להטיל עיצומים כספיים על הפרות של החוק ושל תקנות אבטחת המידע, ובתי המשפט יכולים לפסוק פיצויים ללא הוכחת נזק בהפרות מסוימות. בנוסף הורחבה חובת היידוע: מי שאוסף מידע מאדם צריך להבהיר לו אם מסירת המידע היא חובה או רשות, מה ההשלכות של סירוב ומהן זכויותיו לעיין במידע ולתקן אותו.
השינוי השלישי נוגע למבנה האחריות. חלק מהגופים חייבים למנות ממונה על הגנת הפרטיות, ובהם גופים ציבוריים, סוחרי מידע, גופים שעיסוקם המרכזי הוא עיבוד מידע רגיש בהיקף גדול וגופים שעיקר פעילותם כולל ניטור שוטף ושיטתי של אנשים. בגילוי הדעת שלה בנושא מינוי ממונה, הרשות מבהירה שניטור כזה יכול לכלול מעקב אחר פעילות משתמשים באתרים ובאפליקציות ובניית פרופילים לפרסום ממוקד. האם החברה שלכם נכנסת להגדרה הזו היא שאלה משפטית שתלויה בפעילות בפועל.
המאמר מתאר את התיקון ברמה כללית בלבד ואינו ייעוץ משפטי. לשאלות על החובות הספציפיות של החברה שלכם יש להתייעץ עם היועץ המשפטי שלה.
למה תיקון 13 משפיע על מדידה וקמפיינים?
תיקון 13 משפיע על מדידה כי כלי מדידה ופרסום רבים באתר אוספים מזהים ונתוני התנהגות, ואלה עשויים להיחשב מידע אישי לפי ההגדרה הרחבה.
פיקסל, תגית אנליטיקס או סקריפט של כלי צ'אט יכולים לשלוח מידע לצד שלישי בטעינת עמוד. לא תמיד קל לענות בוודאות כמה תגיות כאלה רצות באתר, מה כל אחת שולחת ולאן. זה סוג המידע שכדאי שיהיה מתועד ומבוקר לאור התיקון.
במקביל, הקמפיינים עצמם תלויים בנתונים. מערכות הקנייה האוטומטיות של גוגל ומטא מקבלות את רוב החלטות ההצעה והטרגוט, והן לומדות מאירועי ההמרה שהן מקבלות. כשאירועים חסרים, כשההסכמה לא מועברת נכון או כשתגית נשברה אחרי עדכון באתר, המערכת לומדת מתמונה חלקית ומקצה תקציב בהתאם.
כלומר, אותו סידור שמקטין חשיפה משפטית יכול גם לשפר את איכות הנתונים שהמדיה לומדת מהם. לכן הנושא צריך לשבת גם אצל השיווק, ולא רק אצל המחלקה המשפטית. הטבלה הבאה מחברת בין השינויים לבין מה שכדאי לבדוק.
| מה משתנה | מה לבדוק במדידה השיווקית |
|---|---|
| הגדרה רחבה של מידע אישי | אילו מזהים נאספים באתר ובאפליקציה: עוגיות, מזהי מכשיר, כתובות מייל וטלפונים |
| הרחבת המונח "עיבוד" | לאן כל תגית שולחת נתונים, ומי בחברה ואצל הספקים מקבל אליהם גישה |
| חובת יידוע מורחבת | האם מדיניות הפרטיות מתארת את מה שקורה באתר בפועל, כולל כלי פרסום ומדידה |
| עקרונות ההסכמה של הרשות | האם בקשת ההסכמה ברורה, והאם אפשר לסרב בלי עיצוב שמקשה או מטעה |
| מידע בעל רגישות מיוחדת | האם נאסף מיקום מדויק או מידע רפואי, והאם הוא נשלח לפלטפורמות פרסום |
| עיצומים כספיים | האם יש תיעוד מסודר של תגיות, הסכמות והסכמי עיבוד עם ספקים |
| ממונה על הגנת הפרטיות | אם מונה ממונה, האם הוא שותף להחלטות על כלי מדידה חדשים |
מה צריך לדעת על עוגיות באתר והסכמה לעוגיות?
עוגיות באתר הן קבצי טקסט קטנים שהדפדפן שומר, והן משמשות לזיהוי משתמש בין עמודים וביקורים, למדידה ולפרסום.
המדריך של הרשות לתיקון 13 אינו עוסק בעוגיות במפורש. עם זאת, ההגדרה הרחבה של מידע אישי וגילוי הדעת של הרשות בנושא הסכמה רלוונטיים לכל מנגנון שבו משתמש מתבקש לאשר איסוף מידע. לפי גילוי הדעת, הסכמה צריכה להינתן מדעת וברצון חופשי, ושתיקה או היעדר התנגדות אינם הסכמה. הרשות מציינת גם שעיצוב שמקשה להבין או לסרב, מה שמכונה "טקטיקות אפלות", פוגע בתוקף ההסכמה.
עוד נקבע בגילוי הדעת ששימוש במידע לפרופיילינג או לדיוור ישיר שאינם קשורים לעסקה עצמה דורש הסכמה אקטיבית, ושמשתמש רשאי לחזור בו מהסכמתו. מבחינת מותג, אלה שאלות שכדאי לבחון גם בתכנון של באנר העוגיות.
בפועל, הסכמה לעוגיות היא לא רק באנר. היא צריכה להתחבר לכלים: אם משתמש סירב לעוגיות פרסום, תגיות הפרסום צריכות לדעת את זה ולפעול בהתאם. CMP (Consent Management Platform) היא פלטפורמה שמציגה את בקשת ההסכמה, שומרת את הבחירה של המשתמש ומעבירה אותה לכלי המדידה והפרסום.
מה זה Consent Mode?
Consent Mode הוא מנגנון של גוגל שמתאים את התנהגות התגיות של גוגל לבחירת ההסכמה של המשתמש. הוא מעביר ארבעה סוגי הסכמה: ad_storage לאחסון לצורכי פרסום, analytics_storage לאחסון לצורכי מדידה, ad_user_data לשליחת נתוני משתמש לגוגל לצורכי פרסום, ו-ad_personalization לפרסום מותאם אישית כמו רימרקטינג.
יש שתי דרכי הטמעה. במצב הבסיסי, תגיות גוגל לא נטענות עד שהמשתמש בוחר בבאנר ההסכמה. משתמש שסירב לא שולח לגוגל דבר, גם לא את עצם הסירוב. במצב מתקדם, התגיות נטענות עם ברירת מחדל של סירוב ושולחות אותות ללא עוגיות, ומידע מלא נשלח רק אחרי הסכמה. האותות האלה מאפשרים לגוגל לבצע מידול המרות ב-Google Ads וב-GA4, בכפוף לסף נתונים מינימלי. הבחירה בין שני המצבים היא החלטה שכדאי לקבל יחד עם היועץ המשפטי, ולא רק עם המפתח.
מה זה Conversions API ו-server side tracking, ולמה הם חשובים?
Conversions API ו-server side tracking הם שתי דרכים להעביר נתוני מדידה דרך שרת שהחברה שולטת בו, במקום להסתמך רק על קוד שרץ בדפדפן של המשתמש.
Conversions API הוא ממשק של מטא שמחבר נתוני שיווק של המפרסם, כמו אירועים מהאתר, מהאפליקציה ומה-CRM, ישירות מהשרת של המפרסם למערכות של מטא. לפי התיעוד של מטא, אירועי שרת מעובדים בדומה לאירועים שנשלחים מהפיקסל, ומשמשים למדידה, לדיווח ולאופטימיזציה. מטא ממליצה להפעיל את Conversions API לצד הפיקסל ולשלוח את אותם אירועים בשני הערוצים, כדי לכסות אירועים שהפיקסל מפספס בגלל בעיות טעינה או חיבור.
שני פרטים טכניים קובעים אם זה עובד. הראשון הוא מניעת כפילויות: כל אירוע צריך לשאת אותו שם ואותו מזהה (event_id) בשני הערוצים, אחרת הוא עלול להיספר פעמיים. השני הוא איכות ההתאמה: מטא מציגה לכל אירוע ציון Event Match Quality מתוך 10, ופרטי לקוח כמו מייל או טלפון צריכים לעבור גיבוב (hashing) לפני שליחה. שליחת פרטי לקוח היא הנקודה שבה מדידה פוגשת פרטיות, ולכן צריך להגדיר מראש מה נשלח ועל בסיס איזו הסכמה.
Server side tracking הוא מדידה בצד השרת: במקום שכל תגית תשלח נתונים ישירות מהדפדפן לספק חיצוני, הנתונים עוברים קודם דרך שרת של החברה. ב-Google Tag Manager זה נקרא server-side tagging, ומיכל השרת רץ בתשתית ענן שהחברה בוחרת. גוגל מציינת שבמודל הזה המפרסם מחליט אילו שדות נשלחים ולאיזו מערכת, ושעד שהוא מעביר את הנתונים הלאה, אף ספק חיצוני לא רואה אותם. גוגל ממליצה להקים את המיכל על דומיין של החברה.
היתרון לשיווק כפול. אפשר לסנן שדות לפני שהם יוצאים לפלטפורמות, ובמקביל לשפר את שלמות הנתונים שמגיעים למערכות הפרסום. אבל מדידה בצד השרת אינה דרך לעקוף את ההסכמה. אם המשתמש סירב, גם השרת צריך לכבד את הבחירה שלו.
מה לבדוק עכשיו? צ'קליסט מדידה ופרטיות
הדרך המעשית לסדר את הנושא היא תהליך של שמונה צעדים, שמתחיל במיפוי ונגמר בבקרה שוטפת. המיפוי קובע אילו מהצעדים נדרשים באתר מסוים, ולא כל אתר צריך את כל הרכיבים.
- מיפוי תגיות. רשימה של כל תגית, פיקסל וסקריפט באתר ובאפליקציה: מה הוא אוסף, לאן הוא שולח ומי אחראי עליו.
- ניקוי. הסרת תגיות של כלים שכבר אינם בשימוש וצמצום שדות שאין בהם צורך עסקי ברור.
- מנגנון הסכמה. ניסוח בקשת הסכמה ברורה ואפשרות לסרב שאינה מסובכת יותר מהאפשרות להסכים. אם נדרש כלי ייעודי, בוחרים CMP לפי מה שעלה במיפוי.
- חיבור ההסכמה לכלים. הטמעת Consent Mode בתגיות של גוגל והגדרת תנאי הפעלה מתאימים לשאר הכלים ב-Tag Manager.
- מדידה בצד השרת. כשיש לכך הצדקה, הקמת מיכל שרת על דומיין של החברה וניתוב האירועים המרכזיים דרכו.
- חיבורי המרות ישירים. כשמטא היא ערוץ משמעותי, הפעלת Conversions API לצד הפיקסל, עם event_id למניעת כפילויות ובדיקה של Event Match Quality.
- מסמכים והסכמים. עדכון מדיניות הפרטיות כך שתשקף את המצב בפועל, והסדרת הסכמים עם ספקים וסוכנויות לגבי מי מעבד איזה מידע.
- בקרה שוטפת. בדיקה קבועה שהמדידה עובדת אחרי כל שינוי באתר, השוואה בין נתוני הפלטפורמות לנתוני המכירות והתראה כשאירוע נעלם.
הצעדים האלה דורשים עבודה משותפת של שיווק, פיתוח, אבטחת מידע, המחלקה המשפטית והממונה על הגנת הפרטיות, אם מונה כזה. הרשות מפרסמת מעת לעת גילויי דעת והנחיות שמפרשים את תיקון 13, ולכן כדאי לחזור לבדיקה הזו באופן קבוע ולא להסתפק בפרויקט חד פעמי.
איך אנחנו ניגשים לזה ב-CONNECT
ב-CONNECT מקבוצת הפרסום ברוקנר יער לוי אנחנו מתחילים כל עבודת מדידה במיפוי: מה רץ באתר, מה נשלח, לאן, ועל בסיס איזו הסכמה. משם בונים תוכנית עבודה משותפת עם צוות הפיתוח ועם היועץ המשפטי של המותג, כי ההחלטות על הסכמה ועל שליחת פרטי לקוח אינן החלטות של מדיה בלבד.
אחרי ההטמעה אנחנו מתייחסים למדידה כאל מערכת חיה. סוכני ה-AI לבקרת קמפיינים מנטרים את החשבונות ומתריעים על חריגות בביצועים ובקצב ההוצאה, וירידה פתאומית בהמרות היא לעיתים קרובות הסימן הראשון לתגית שנשברה. כך אפשר לזהות תקלות כאלה מוקדם יותר.
שאלות נפוצות
מתי נכנס לתוקף תיקון 13 לחוק הגנת הפרטיות?
תיקון 13 לחוק הגנת הפרטיות אושר באוגוסט 2024 ונכנס לתוקף ב-14 באוגוסט 2025. מאז פרסמה הרשות להגנת הפרטיות מדריך מקצועי לתיקון וגילויי דעת בנושאים כמו הסכמה ומינוי ממונה על הגנת הפרטיות. כדאי לבחון את תשתית המדידה לאור התיקון, יחד עם היועץ המשפטי של החברה.
האם חייבים באנר עוגיות באתר בישראל?
המדריך של הרשות לתיקון 13 אינו עוסק בעוגיות במפורש, ולכן התשובה תלויה במה שהאתר אוסף ובמטרות השימוש. עם זאת, אם האתר משתמש בעוגיות לפרסום ולמדידה, עקרונות ההסכמה שפרסמה הרשות רלוונטיים: הסכמה מדעת, אפשרות אמיתית לסרב והימנעות מעיצוב מטעה. את ההחלטה כדאי לקבל עם היועץ המשפטי, לפי מה שקורה באתר בפועל.
מה ההבדל בין Consent Mode בסיסי למתקדם?
במצב בסיסי, תגיות גוגל חסומות עד שהמשתמש מגיב לבאנר, ואם הוא סירב לא נשלח שום מידע, אפילו לא מצב ההסכמה. במצב מתקדם, התגיות נטענות עם ברירת מחדל של סירוב ושולחות אותות ללא עוגיות עד שמתקבלת הסכמה. המצב המתקדם מאפשר לגוגל מידול המרות מפורט יותר, אבל הבחירה ביניהם צריכה לכלול גם שיקול משפטי.
האם Conversions API מחליף את הפיקסל של מטא?
לא. מטא ממליצה להפעיל את Conversions API בנוסף לפיקסל ולשלוח את אותם אירועים בשני הערוצים. הפיקסל אוסף אירועים מהדפדפן, ו-Conversions API שולח אירועים מהשרת, כך שאירועים שהפיקסל מפספס עדיין מגיעים למטא. כדי שאירוע לא ייספר פעמיים, צריך לשלוח אותו עם אותו שם ואותו event_id בשני הערוצים.
האם server side tracking פותר את בעיית הפרטיות?
לא לבד. מדידה בצד השרת נותנת לחברה שליטה טובה יותר על הנתונים: אפשר לראות מה נשלח, לסנן שדות ולנתב לפלטפורמות רק את מה שנדרש. אבל היא לא מחליפה הסכמה ולא פוטרת מחובת היידוע. אם משתמש סירב לעוגיות פרסום, גם השרת צריך לכבד את הבחירה. המטרה היא שליטה ושקיפות בנתונים, בהתאם לבחירה של המשתמש.
ראו גם: דאטה ואנליטיקס · קמפיינים ממוקדי ביצועים · איך לקרוא דוח קמפיין · ROAS ורווח באיקומרס · הטכנולוגיה שלנו
מקורות: הרשות להגנת הפרטיות: מדריך מקצועי לתיקון 13 · הרשות להגנת הפרטיות: גילוי דעת בנושא הסכמה · הרשות להגנת הפרטיות: גילוי דעת על מינוי ממונה על הגנת הפרטיות · Google: Consent mode · Google: Server-side tagging · Meta: Conversions API · Meta: Conversions API best practices
רוצים לבחון את תשתית המדידה לאור תיקון 13? השאירו פרטים.