מה Snap Pixel שולח ומדוע ההסכמה חשובה

Snap Pixel הוא קטע JavaScript המתארח ב-sc-static.net/scevent.min.js. בטעינת הדף הוא מאותחל עם ה-pixel_id שלכם ואופציונלית עם מזהי משתמש מוצפנים — כתובת דוא"ל, טלפון, כתובת IP, סוכן משתמש. לאחר האתחול הוא מדווח על אירועים: צפיות בדף, הוספה לסל, רכישה, הרשמה, אירועים מותאמים אישית. כל אירוע מתפרסם לנקודת הקצה של איסוף Snap ומותאם בצד השרת מול מזהי משתמש Snap לייחוס קליקים וצפיות מקמפיינים של Snap Ads.

מנקודת מבט של פרטיות, הפיקסל מעבד שלוש קטגוריות של נתונים הדורשות בסיס משפטי תחת GDPR: מזהי מכשיר ודפדפן (עוגיות, עוגיית צד ראשון שהוגדרה על ידי Snap), מזהים ישירים מוצפנים (דוא"ל, טלפון) כאשר התאמה מתקדמת מופעלת, ומטה-נתוני אירועי התנהגות. CCPA ו-CPRA מתייחסים לאותו זרימה כמכירה או שיתוף אלא אם המשתמש הסיר את הסכמתו. אות IAB GPP — כיום תקן לציות רב-מדינתי בארה"ב — חייב להיות מכובד ללא קשר לאיזה מדינה המשתמש נמצא.

ארכיטקטורת שני פיקסלים: דפדפן בתוספת Conversions API

יישומי Snap Pixel מודרניים משתמשים הן בפיקסל הדפדפן והן ב-Conversions API בצד השרת (לעיתים קרובות נקרא Snap CAPI). פיקסל הדפדפן יורה ממכשיר המשתמש; CAPI יורה מה-backend שלכם לאחר אותה פעולת משתמש. Snap מבטל כפילויות של אירועים המגיעים בשני הערוצים באמצעות client_dedup_id משותף. למה להפעיל את שניהם? פיקסל הדפדפן נחסם יותר ויותר על ידי ITP, ETP ובאנרים של עוגיות שדוחים. CAPI ממלא את הפער כי הוא פועל מהשרת שלכם ואינו כפוף להגבלות מעקב של דפדפן — אך הוא עדיין דורש הסכמה תקפה של המשתמש ברגע שבו נוצר האירוע.

ההסכמה חלה על שני הערוצים

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

חיבור Snap Pixel ל-CMP שלכם

שלב 1: חסמו עד שההסכמה ידועה

אל תכללו את תגית הסקריפט של Snap Pixel ישירות ב-HTML שלכם. במקום זאת, רשמו אותה כ-תגית חסומה במנהל התגיות שלכם — Google Tag Manager, Tealium, Commanders Act, או כל טוען תואם-CMP שבו אתם משתמשים. הגדירו את התגית לירות רק כאשר דגלי ההסכמה הרלוונטיים הם נכונים.

עבור תעבורת TCF v2.2 השילוב מבוסס על מטרה. Snapchat רשום כספק TCF וכלול ברשימת הספקים הגלובלית של IAB. כלל מנהל התגיות שלכם צריך לדרוש שהמשתמש יהיה הסכים למטרות 1 (אחסון וגישה), 3 (פרופיל מודעות מותאם אישית), 4 (מודעות מותאמות אישית), 7 (מדידה) ולהסכמת ספק Snap. עבור תעבורה מארה"ב השילוב הוא הקטע של מחרוזת GPP המתאים למדינת המשתמש — קטע 7 לקליפורניה (CPRA), קטע 8 לוירג'יניה וכדומה — בשילוב עם אות USP המדור הקודם כגיבוי.

שלב 2: העבירו את מצב ההסכמה ל-CAPI

בעת יריית אירועי CAPI מה-backend שלכם עליכם לכלול את השדה data_processing_options. עבור תעבורה מהאיחוד האירופי שהסכימה, השמיטו את השדה לחלוטין. עבור תעבורה מארה"ב שהסכימה, השמיטו אותו. עבור משתמש שביטל הסכמתו במסגרת CCPA / CPRA שלחו data_processing_options: ["LDU"] (שימוש מוגבל בנתונים) יחד עם קודי מדינה ומדינה. Snap מעבד אז את האירוע במצב מוגבל פרטיות שאינו מזין קהלי שיווק מחדש או שיתוף נתונים עם צדדים שלישיים.

שלב 3: השתמשו באותות מצב הסכמה של Google אם אתם מסתמכים על GTM

אם אתם טוענים את הפיקסל דרך Google Tag Manager עם Consent Mode v2 מופעל, שלטו בתגית Snap על ad_storage ו-ad_user_data. כאשר אחד מהם נדחה, GTM חוסם את יריית התגית. שיגור CAPI מהשרת שלכם צריך להשתמש באותו מצב הסכמה שנלכד ברגע פעולת המשתמש.

התאמה מתקדמת: מזהים מוצפנים והסכמה

התאמה מתקדמת שולחת דוא"ל, טלפון, IP וסוכן משתמש מוצפנים ל-Snap כדי לשפר שיעורי התאמה בין מבקרי אתרים ומשתמשי Snap. למרות שהערכים מוצפנים SHA-256, הרגולטורים מתייחסים אליהם כנתונים אישיים — ההצפנה הפיכה בקנה מידה כי מרחב הקלט ניתן לספירה, ו-Snap יכול להתאים אותה למשתמש ידוע.

התייחסו להתאמה מתקדמת כהחלטת הסכמה נפרדת כאשר אפשרי. אם המשתמש מעניק רק מטרה 7 (מדידה) אך לא מטרה 4 (מודעות מותאמות אישית), אתם עדיין יכולים להפעיל את הפיקסל למדידה אך לא אמורים להפעיל התאמה מתקדמת, כיוון שההתאמה עצמה היא פעולת מודעות מותאמות אישית. מרבית מנהלי התגיות התואמי-TCF חושפים זאת כמתג-משנה בתגית Snap.

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

ירייה לפני טעינת ה-CMP

אם קטע Snap Pixel שלכם נמצא ב-head של הדף וה-CMP שלכם נטען בצורה אסינכרונית, הפיקסל יכול לירות לפני שההסכמה ידועה. זו הפרת GDPR הנפוצה ביותר שנמצאת בביקורות עוגיות. העבירו את קטע הפיקסל מאחורי מאזין אירועים cmpReady, או השתמשו במנהל תגיות המשולב בצורה טבעית עם IAB CMP API.

שכחת מחרוזת GPP בתעבורה מארה"ב

Snap נמצא בתהליך של חיוב מחרוזת GPP לאכיפת ביטול הסכמה בארה"ב. אם ה-CMP שלכם פולט רק את ה-USP הישן ותגית Snap לא מקבלת אות GPP, גרסאות אחרונות של הפיקסל יתייחסו לאירוע כביטול הסכמה כברירת מחדל. בצעו ביקורת על דגימה של תגובות הצעות מארה"ב ושיגורי CAPI; GPP חסר הוא לעיתים קרובות אובדן אטריביוציה שקט.

מזהי dedup שאינם תואמים

פיקסל הדפדפן ו-CAPI חייבים לשתף את אותו client_dedup_id לאותו אירוע, אחרת Snap סופר את האירוע פעמיים. צרו UUID בזמן האירוע בצד הלקוח, העבירו אותו לפיקסל הדפדפן, והעבירו אותו לשרת שלכם לשיגור CAPI התואם. שרשרת dedup שבורה בודדת מנפחת ספירות המרות ושוברת אופטימיזציה מורידה.

הסכמה ישנה בסשנים ארוכים

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

בדיקות ואימות

Snap מפרסם הרחבת Chrome הנקראת Snap Pixel Helper שמציגה כל קריאת פיקסל ומפענחת את המטען שלה. הפעילו שלושה תרחישי בדיקה מקצה לקצה: משתמש שהסכים לגמרי (פיקסל ו-CAPI יורים, התאמה מתקדמת קיימת, ללא דגל LDU), משתמש דחה-הכל (ללא פיקסל, ללא CAPI) ומשתמש פרטני שהסכים למדידה אך לא למודעות מותאמות אישית (פיקסל יורה, CAPI יורה, אך שדות התאמה מתקדמת נעדרים ודגל LDU מוגדר לתעבורה מארה"ב). אמתו כל תרחיש ביומן האירועים של Snap Ads Manager ובמסוף הניפוי של מנהל התגיות שלכם לפני הפריסה לייצור.

סיכום

ערימת Snap Pixel שהוגדרה כראוי עושה שלושה דברים: היא שולטת הן בפיקסל הדפדפן והן ב-CAPI באותה החלטת הסכמה, מכבדת אותות TCF ו-GPP פרטניים כדי שמשתמשים שמסרבים למודעות מותאמות אישית לא יעקבו בשקט בכל זאת, ושומרת על ביטול הכפילויות שלם כדי שהאטריביוציה תישאר מדויקת. בצעו ביקורת על ההגדרות שלכם מדי רבעון — אכיפת Snap על אותות GPP מתהדקת לאורך 2026, ושילוב עובד היום אינו בהכרח שילוב עובד בעוד שישה חודשים.