מה ה-Intercom Messenger אוסף

סקריפט ה-Intercom Messenger (שנטען מ-widget.intercom.io או js.intercomcdn.com) מאתחל אובייקט Intercom גלובלי ומזהה מבקרים באמצעות העוגיות intercom-id-* ו-intercom-session-*. מאותו רגע הוא לוכד צפיות בדפים, זמן בדף, עומק גלילה ומטא-נתונים ברמת המבקר: user agent, מערכת הפעלה, דפדפן, מיקום מבוסס-IP, מפנה, וכל מאפיינים מותאמים אישית שהאפליקציה מעבירה דרך Intercom('boot', {...}) או Intercom('update', {...}). תכונת הנוכחות בזמן אמת של ה-Messenger גם מדווחת על פעילות המבקר בחזרה לשרתי Intercom באופן רציף כל עוד הדף פתוח, ויוצרת את אחד מטביעות הרגל הכבדות יותר של נתוני סטרימינג בין כלי מסרים ללקוחות.

ברגע שמשתמש מזוהה — בדרך כלל על ידי קריאה ל-Intercom('boot', { user_id: ..., email: ... }) לאחר אימות — הסקריפט מקשר את זהות המבקר לאיש קשר ידוע ב-Intercom. היסטוריית שיחות, מאפיינים וחברות בפילוחים כולם נובעים מזיהוי זה, ו-Intercom משתמשת בקישור להנעת קמפיינים אוטומטיים של הודעות, דואר אלקטרוני של מחזור חיים וסיורי מוצר בתוך האפליקציה.

מדוע "זה רק ווידג'ט צ'אט" לא פוטר אתכם מהסכמה

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

מעקב לפני שיחה אינו ביצוע חוזה

ברגע שלקוח יוזם שיחת צ'אט, עיבוד הקשור לאותה שיחה ספציפית יכול להיות מאופיין באופן סביר כביצוע חוזה או קדם-חוזה תחת GDPR Article 6(1)(b). כל מה שלפני נקודה זו — מעקב צפיות בדפים, דיווח נוכחות, זיהוי מבקרים, ההודעה האוטומטית מונעת הפילוח — אינו כזה. זהו עיבוד לצורכי אנליטיקה ושיווק הדורש בסיס חוקי משלו.

ה-Messenger מופעל לפני כל שיחה

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

הודעות יוצאות אוטומטיות הן שיווק

קמפיינים אוטומטיים של הודעות, דואר אלקטרוני של מחזור חיים וטריגרים התנהגותיים של Intercom הם תקשורת שיווקית. הם דורשים בסיס חוקי משלהם הן תחת ה-GDPR והן, בארה"ב, CAN-SPAM ו-TCPA היכן שרלוונטי.

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

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

shutdown

הקריאה Intercom('shutdown') מסיימת את הסשן הפעיל, מנקה את העוגיות המקומיות ומפסיקה מעקב נוסף. צמדו אותה עם Intercom('boot') כאשר המשתמש מקבל את קטגוריית השיווק ב-CMP שלכם.

האפשרות hide_default_launcher

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

בקרות שמירת נתונים

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

אפשרות אירוח נתונים ב-EU

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

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

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

1. הסירו את קטע ה-Messenger המוגדר כברירת מחדל מה-head

Intercom מספקת קטע התקנה שמאתחל את ה-Messenger בטעינת הדף. הסירו את קריאת ה-boot מ-head המסמך. תגית הסקריפט יכולה להישאר (עם type="text/plain" ו-data-category="marketing" אם ה-CMP שלכם משתמש בתבנית זו), אבל הפעלת Intercom('boot') חייבת להידחות.

2. הפעילו את ה-Messenger מקולבק ההסכמה

כאשר ה-CMP מפעיל את אירוע קבלת-השיווק שלו, שכתבו את סוג הסקריפט בחזרה ל-text/javascript, תנו לו להיטען, ואז קראו ל-Intercom('boot', { app_id: ... }). אם המשתמש מאומת, כללו את הפרמטרים המזהים בקריאת ה-boot.

3. ספקו טריגר צ'אט ידני למשתמשים ללא הסכמה

ללקוח שדחה מעקב שיווקי עדיין יש זכות ליצור קשר עם התמיכה. הציעו נתיב צ'אט חלופי — טופס יצירת קשר, קישור דוא"ל, או כפתור "התחל צ'אט" מפורש שטוען את ה-Messenger רק כאשר לוחצים עליו. האחרון הוא התבנית הנקייה ביותר: הלחיצה המפורשת של המשתמש מהווה הסכמה למטרה הספציפית של שיחת הצ'אט.

4. טפלו בביטול

כאשר המשתמש מבטל הסכמת שיווק, קראו ל-Intercom('shutdown'). זה מנקה את העוגיות המקומיות ומפסיק מעקב. שמרו את מצב ההסכמה המעודכן כך שטעינות דף הבאות יכבדו אותו.

5. השתמשו באירוח נתונים EU עבור חשבונות EU

עבור חשבונות שמקום מגורי נתונים ב-EU חשוב להם, הגדירו את סביבת העבודה של Intercom לאירוח EU. נתבו תעבורת EU בהתאם; אם אתם מפעילים סביבות עבודה נפרדות ללקוחות EU ולא-EU, האינטגרציה חייבת לבחור את ה-app ID הנכון בזמן ה-boot.

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

ארבע טעויות אינטגרציה מופיעות שוב ושוב בביקורות של פריסות Intercom.

הפעלה לפני הסכמה

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

התייחסות ל-shutdown כאופציונלי

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

איגוד תמיכה ושיווק

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

התעלמות מעומסי מאפיינים מותאמים אישית

הנתונים המועברים בקריאות Intercom('update') — מאפייני משתמש מותאמים אישית, רמת מנוי, גיל חשבון, מזהי משתמש פנימיים — הם נתונים אישיים המועברים ל-Intercom. סקרו עומסים אלה לשיתוף-יתר; אינטגרציות רבות מעבירות יותר נתונים מזהים ממה שה-Messenger צריך מבחינה פונקציונלית.

רשימת ביקורת

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

• האם ה-Messenger מחכה להסכמה? פתחו את הדף בחלון פרטי עם הגנת מעקב קפדנית וודאו שאין בקשות intercom.io או intercomcdn.com מופעלות לפני קבלת הבאנר.
• האם יש נתיב תמיכה ללא Messenger? עבור משתמשים שדוחים שיווק, האם הם עדיין יכולים ליצור קשר עם התמיכה דרך טופס, דוא"ל, או טריגר צ'אט בלחיצה מפורשת?
• האם ביטול מכבה את ה-Messenger? וודאו שביטול הסכמה קורא ל-Intercom('shutdown') ומנקה עוגיות מקומיות.
• האם מאפיינים מותאמים אישית מצומצמים למינימום? סקרו את העומסים בקריאות Intercom('update') והסירו כל נתון שאינו נדרש מבחינה פונקציונלית על ידי ה-Messenger.
• האם אירוח נתונים EU מוגדר היכן שנדרש? וודאו שתעבורת EU מנותבת לסביבת עבודה מאורחת ב-EU, עם תיעוד של החלטת הניתוב.
• האם קמפיינים יוצאים משוערים על הסכמה? וודאו שקמפיינים אוטומטיים של הודעות מכבדים את מצב הסכמת-השיווק של איש הקשר ומפסיקים לשלוח בעת ביטול.

היכן Intercom משתלב במחסנית הסכמה-ראשונה

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