משטח המעקב של SFMC

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

Web Analytics Connector וקוד מעקב Collect

קוד המעקב Collect (שנקרא לעיתים קרובות collect.js או מופנה דרך cdn.evgnet.com) הוא עוקב ההתנהגות של SFMC. הוא מגדיר את קובצי העוגיות _etmc והקשורים אליהם, מזהה מבקרים בין סשנים, ומעביר אירועי צפייה בדף, לחיצה והמרה ל-SFMC לשימוש בטריגרים של Journey Builder ובמיקוד מחדש בדואר אלקטרוני. מנקודת מבט רגולטורית, מדובר בבירור בעוקב שיווקי — אף על פי שהאירועים נראים כמו ניתוח, הנתונים מזינים אוטומציה שיווקית ישירה.

הסקריפט של Marketing Cloud Personalization

סקריפט Personalization (Interaction Studio הישן) כבד יותר מ-Collect. הוא טוען SDK שצופה ב-DOM כולו, לוכד נתוני זרם קליקים ואינטראקציה עם טפסים, ומעביר אותם למנוע החלטות התאמה אישית שיכול לשכתב תוכן עמוד בזמן אמת. קובצי עוגיות שנוגדרו כוללים מזהי _ev_* ואסימון סשן. מדובר ללא ספק בעיבוד למטרות שיווקיות ודורש הסכמת opt-in בכל שיפוט EU או UK.

טפסי CloudPages וקישורים עם מעקב

דפי נחיתה המתארחים ב-CloudPages וקישורי הדואר האלקטרוני עם מעקב שעוברים דרך SFMC נושאים פרמטרים מזהים משלהם (פרמטרים של subscriberkey, jb, mid בכתובות URL). כאשר מבקר מגיע דרך קישור עם מעקב, SFMC יכול לקשר את הסשן לרשומת המנוי שלו אפילו לפני שמתפעל כל מעקב בתוך הדף. זהו עמדה משפטית שונה משמעותית ממעקב אנונימי — זהות המנוי ידועה בקשר ראשון — והסכמה לתקשורת שיווקית חייבת כבר להתקיים.

מחברי Data Cloud

אינטגרציית Data Cloud של SFMC (שכבת פלטפורמת נתוני הלקוחות) מושכת מזהים ממעקב אינטרנט, SDK לנייד, רשומות CRM ונתונים לא מקוונים לפרופיל מאוחד. מצב ההסכמה צריך להתפשט ל-Data Cloud, לא רק לפיקסל המעקב ברמת השטח, כדי שהפעלות דאון-סטרים לרשתות פרסום יכבדו את ההעדפות המתועדות של המבקר.

בקרות פרטיות מקוריות של SFMC

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

ביטול מעקב עבור Web Analytics Connector

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

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

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

הסכמת Marketing Cloud Personalization

ה-SDK של Personalization מקבל דגל הסכמה במהלך האתחול. הגדר אותו ל-false עד שהמשתמש קיבל את קטגוריית השיווק בבאנר CMP, ואז אתחל מחדש את ה-SDK כאשר ניתנת הסכמה.

אינטגרציית CMP שלב אחר שלב

הארכיטקטורה האמינה היא לשמור על כל ארבעת משטחי המעקב מאחורי ה-CMP ולהשתמש בדגלים המקוריים של SFMC לשכלול התנהגות דאון-סטרים לאחר מתן ההסכמה.

1. עצור את סקריפט Collect מטעינה כברירת מחדל

הסר את סקריפט Collect מכותרת המסמך והחלף אותו במציין מיקום שה-CMP יכול להפעיל. כאשר המבקר מקבל את קטגוריית השיווק, ה-CMP משכתב את מציין המיקום לטעינת collect.js. כל אירועים בתור נשטפים בטעינה.

2. דחה את אתחול Marketing Cloud Personalization

סקריפט Personalization אסור שיתאחל לפני ההסכמה. רוב ה-CMPs מטפלים בכך עם דפוס טעינה מדחה: אלמנט הסקריפט נמצא ב-DOM אך מאפיין ה-type שלו הוא text/plain, וה-CMP משכתב אותו ל-text/javascript עם קבלת ההסכמה.

3. שמור על פרמטרי מעקב של CloudPages

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

4. הפץ את מצב ההסכמה ל-Data Cloud

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

5. מפה לשדות הסכמת מנוי של SFMC

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

מלכודות נפוצות

שלוש טעויות אינטגרציה מהוות את רוב ממצאי הביקורת הארגוניים ב-SFMC.

טיפול ב-Collect כניתוח

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

לאפשר ל-Personalization לפעול לפני ההסכמה

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

אי סנכרון ההסכמה על פני הערימה

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

רשימת תיוג לביקורת

חמש שאלות קונקרטיות לענות עבור כל פריסת SFMC הנוגעת לתנועה מה-EU, מה-UK או מקליפורניה.

• האם Collect ממתין להסכמה? אשר שאין בקשת collect.js או evgnet.com שמופעלת לפני קבלת הבאנר.
• האם Personalization נדחה? אשר ש-SDK של Personalization לא מתאחל עד שקטגוריית השיווק ניתנת.
• האם פרמטרי קישורים נכנסים עם מעקב נשמרים עד ההסכמה? אשר שהתאמה אישית מונעת על ידי subscriberkey ממתינה לאות הסכמה מפורש.
• האם Data Cloud רואה את מצב ההסכמה? אשר שתוסף ההסכמה מוגדר וה-CMP כותב החלטות ל-Data Cloud בזמן אמת.
• האם שדות הסכמת המנוי מסונכרנים? אשר ששינויים במרכז ההעדפות מתפשטים לבאנר שבדף ולהיפך.

היכן SFMC משתלב בערימת הסכמה ראשונה

SFMC היא אחת מפלטפורמות השיווק החזקות ביותר — ואחת המסוכנות ביותר — שארגון יכול לפרוס. דפוס ההתקנה כברירת מחדל פשוט אינו עומד בציפיות האירופיות או הקליפורניות הנוכחיות, ובקרות המקוריות של הפלטפורמה הן פרימיטיבים שימושיים אך אינם תחליף לשכבת ניהול הסכמה בסטרים עליון. הארכיטקטורה הנכונה מתייחסת ל-CMP כמקור האמת היחיד, שומרת כל מודול מעקב מאחוריו, ומשתמשת בתוספי ההסכמה של SFMC כדי שה-Data Cloud ורשומות המנויים יפיצו את האמת הזו על פני שאר הערימה. כשנעשה נכון, SFMC ממשיך לעשות את מה שהמשווקים קנו אותו לשם — טריגרים של Journey Builder, קבלת החלטות Personalization, הפעלת Data Cloud — בעוד עמדת הציות הבסיסית תואמת את מה שהרגולטורים מצפים כעת מכל משווק ארגוני.