راهنمای یکپارچهسازی رضایت کوکی ربات چت Intercom: چت زنده مطابق با GDPR در ۲۰۲۶
Intercom پلتفرم پیامرسان تجاری غالب برای شرکتهای SaaS و فروش مستقیم به مصرفکننده است و ویجت Messenger درونصفحهای آن — حباب چت که به گفتگوی زنده، مکالمات ربات و تورهای محصول باز میشود — یکی از رایجترین سطوح جاوااسکریپت نصبشده در وب مدرن است. از منظر حریم خصوصی، این یکی از پرپیامدترینها نیز هست. اسکریپت Messenger کوکیهای شناسایی تنظیم میکند، بازدیدهای صفحه و رویدادهای جلسه را ردیابی میکند، متادیتای دستگاه و مرورگر را ثبت میکند و همه چیز را به محض راهاندازی به زیرساخت آمریکایی Intercom ارسال میکند. برای هر شرکتی که با ترافیک EU، UK یا کالیفرنیا سروکار دارد، الگوی نصب پیشفرض همان مشکل انطباق نصب Klaviyo یا HubSpot است: یک اسکریپت غیرضروری که قبل از رضایت اجرا میشود، دادههای شخصی را تحت GDPR پردازش میکند، آنها را از مرزها عبور میدهد و در صورت بررسی تنظیمکننده، مواجهه مستندی ایجاد میکند. این راهنما توضیح میدهد که Intercom Messenger چه چیزهایی جمعآوری میکند، چگونه آن را پشت یک CMP بدون خراب کردن تجربه چتی که مشتریان واقعاً استفاده میکنند محدود کنید و ابزارهای حریم خصوصی بومی Intercom کجا قرار میگیرند.
Intercom Messenger چه چیزهایی جمعآوری میکند
اسکریپت Intercom Messenger (که از widget.intercom.io یا js.intercomcdn.com بارگذاری میشود) یک شیء سراسری Intercom راهاندازی میکند و بازدیدکنندگان را با کوکیهای intercom-id-* و intercom-session-* شناسایی میکند. از آن لحظه بازدیدهای صفحه، زمان در صفحه، عمق اسکرول و متادیتای سطح بازدیدکننده را ثبت میکند: عامل کاربر، سیستمعامل، مرورگر، موقعیت مکانی مبتنی بر 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 به طور تمیز خاموش میشود.
۱. قطعه Messenger پیشفرض را از head حذف کنید
Intercom یک قطعه نصب ارائه میدهد که Messenger را در بارگذاری صفحه راهاندازی میکند. فراخوانی بوت را از head سند حذف کنید. تگ اسکریپت میتواند بماند (با type="text/plain" و data-category="marketing" اگر CMP شما از آن الگو استفاده میکند)، اما فراخوانی Intercom('boot') باید به تعویق بیفتد.
۲. Messenger را از فراخوانی رضایت بوت کنید
هنگامی که CMP رویداد پذیرش بازاریابی خود را فعال میکند، نوع اسکریپت را به text/javascript بازنویسی کنید، اجازه بارگذاری دهید و سپس Intercom('boot', { app_id: ... }) را فراخوانی کنید. اگر کاربر احراز هویت شده است، پارامترهای شناسایی را در فراخوانی بوت بگنجانید.
۳. یک محرک چت دستی برای کاربران بدون رضایت فراهم کنید
مشتری که ردیابی بازاریابی را رد کرده است همچنان حق تماس با پشتیبانی را دارد. یک مسیر چت جایگزین ارائه دهید — یک فرم تماس، یک لینک ایمیل یا یک دکمه صریح «شروع چت» که Messenger را فقط هنگام کلیک بارگذاری میکند. الگوی دوم تمیزترین است: کلیک صریح کاربر رضایت برای هدف خاص مکالمه چت را تشکیل میدهد.
۴. لغو را مدیریت کنید
هنگامی که کاربر رضایت بازاریابی را لغو میکند، Intercom('shutdown') را فراخوانی کنید. این کوکیهای محلی را پاک میکند و ردیابی را متوقف میکند. وضعیت رضایت بهروز شده را حفظ کنید تا بارگذاریهای صفحه بعدی آن را رعایت کنند.
۵. از میزبانی داده EU برای حسابهای EU استفاده کنید
برای حسابهایی که اقامت داده EU اهمیت دارد، فضای کاری Intercom را برای میزبانی EU پیکربندی کنید. ترافیک EU را بر این اساس مسیریابی کنید؛ اگر فضاهای کاری جداگانه برای مشتریان EU و غیر EU دارید، یکپارچهسازی باید app_id صحیح را در زمان بوت انتخاب کند.
دامهای رایج
چهار اشتباه یکپارچهسازی به طور مکرر در ممیزیهای استقرار Intercom ظاهر میشوند.
بوت کردن قبل از رضایت
رایجترین نقص. نصب پیشفرض Messenger را در بارگذاری صفحه بوت میکند که شناسایی بازدیدکننده و ردیابی بازدید صفحه را قبل از هر تصمیم رضایتی فعال میکند. اصلاح ساده است — فراخوانی بوت را به فراخوانی رضایت موکول کنید — اما مستندات یکپارچهسازی پیشفرض این را به اندازه کافی واضح علامتگذاری نمیکند.
اختیاری تلقی کردن 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 را ارزشمند میکند حفظ میکنند، در حالی که وضعیت انطباق زیربنایی دیگر یک مواجهه ساکت در انتظار یک ممیزی برای آشکار کردن آن نیست.