ما يجمعه Messenger من Intercom

يقوم نص Messenger من Intercom (المحمل من 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 بشكل نظيف.

1. إزالة مقتطف Messenger الافتراضي من الرأس

يوفر Intercom مقتطف تثبيت يهيئ Messenger عند تحميل الصفحة. قم بإزالة استدعاء boot من رأس المستند. يمكن أن يبقى علامة النص (مع 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، قم بتكوين مساحة عمل Intercom للاستضافة في EU. وجه حركة المرور في EU وفقاً لذلك؛ إذا كنت تدير مساحات عمل منفصلة لعملاء EU وغير EU، فيجب أن يختار التكامل app ID الصحيح في وقت التشغيل.

الأخطاء الشائعة

تظهر أربعة أخطاء تكامل بشكل متكرر في عمليات تدقيق نشر Intercom.

التشغيل قبل الموافقة

العيب الأكثر شيوعاً. التثبيت الافتراضي يشغّل Messenger عند تحميل الصفحة، مما يطلق تحديد هوية الزائر وتتبع مشاهدة الصفحة قبل أي قرار موافقة. الإصلاح بسيط — تأجيل استدعاء boot إلى رد اتصال الموافقة — لكن وثائق التكامل الافتراضية لا تشير إلى هذا بوضوح كافٍ.

معاملة shutdown كخيار

إذا ألغى المستخدم الموافقة ولم يتم إيقاف Messenger صراحةً، يستمر النص في العمل مع ملفات تعريف ارتباط الجلسة الخاصة به في مكانها. سجل CMP الإلغاء لكن التتبع الأساسي يستمر. اربط دائماً shutdown بإلغاء الموافقة.

جمع الدعم والتسويق معاً

تبرر بعض الفرق تحميل Messenger قبل الموافقة بالقول إنه "دعم، وليس تسويقاً". إذا كان نفس Messenger يدير أيضاً حملات صادرة آلية أو جولات منتج داخل التطبيق، فلا يمكن رسم الخط. النهج المحافظ هو حجب Messenger بالكامل تحت التسويق وتوفير مسار اتصال دعم منفصل غير مجمع للمستخدمين الذين يرفضون التسويق.

تجاهل حمولات السمات المخصصة

البيانات التي تُمرر في استدعاءات Intercom('update') — سمات المستخدم المخصصة، ومستوى الاشتراك، وعمر الحساب، ومعرّفات المستخدم الداخلية — هي بيانات شخصية تُعاد توجيهها إلى Intercom. راجع هذه الحمولات للإفراط في المشاركة؛ تمرر العديد من عمليات التكامل بيانات تعريفية أكثر مما يحتاجه Messenger وظيفياً.

قائمة التدقيق

ستة أسئلة ملموسة للإجابة عليها لأي نشر Intercom يلامس حركة المرور من EU أو UK أو California.

• هل ينتظر Messenger الموافقة؟ افتح الصفحة في نافذة خاصة مع حماية تتبع صارمة وتأكد من عدم إطلاق أي طلبات intercom.io أو intercomcdn.com قبل قبول اللافتة.
• هل يوجد مسار دعم بخلاف Messenger؟ بالنسبة للمستخدمين الذين يرفضون التسويق، هل يمكنهم الاتصال بالدعم عبر نموذج أو بريد إلكتروني أو محفز دردشة بنقرة صريحة؟
• هل يوقف الإلغاء Messenger؟ تأكد من أن إلغاء الموافقة يستدعي Intercom('shutdown') ويمسح ملفات تعريف الارتباط المحلية.
• هل تم تقليل السمات المخصصة؟ راجع الحمولات في استدعاءات Intercom('update') وأزل أي بيانات غير مطلوبة وظيفياً من Messenger.
• هل تم تكوين استضافة البيانات في EU حيث يتطلب ذلك؟ تأكد من أن حركة مرور EU توجه إلى مساحة عمل مستضافة في EU، مع توثيق قرار التوجيه.
• هل حملات الإرسال الصادرة محجوبة بالموافقة؟ تأكد من أن حملات الرسائل الآلية تحترم حالة موافقة التسويق لجهة الاتصال وتتوقف عن الإرسال عند الإلغاء.

أين يتناسب Intercom في مجموعة الموافقة أولاً

تحتل منصات الدردشة المباشرة ومراسلة العملاء منطقة تنظيمية رمادية لم يكن البائعون حريصين على تسليط الضوء عليها. يبدو تدفق البيانات مثل تتبع التحليلات والتسويق؛ يركز الإطار على خدمة العملاء. أوضح المنظمون أن تدفق البيانات يتحكم في التحليل، وليس الإطار. تتعامل البنية الصحيحة مع Messenger من Intercom مثل أي نص تابع لجهة خارجية يحدد الهوية: احجبه خلف الموافقة، وقدم مساراً بديلاً للاتصال بالدعم للمستخدمين الذين يرفضون، واستخدم وحدة shutdown الأصلية للمنصة لتكريم الإلغاءات، وقم بتكوين استضافة البيانات في EU حيث تهم الإقامة. تم بشكل صحيح، تحتفظ فرق الدعم بالدردشة المباشرة والأتمتة لدورة الحياة التي تجعل Intercom قيّماً، بينما يتوقف وضع الامتثال الأساسي عن كونه تعرضاً هادئاً في انتظار التدقيق لإبرازه.