يتيح لك هذا المكون من القالب إرسال بيانات حول استخدام موقعك إلى Segment.
يدعم المكون استدعاء segment.identify عند تسجيل دخول المستخدم إلى الموقع لأول مرة. بالنسبة للمواقع التي تستخدم SSO، يمكنك إما إرسال معرف Discourse الخاص بالمستخدم أو معرف external_id الخاص به إلى Segment. يسمح لك المكون بتتبع مشاهدات صفحات أحدث مواضيع Discourse، والفئات، والفئة، والوسم، والموضوع. كما يتيح لك تتبع إنشاء المواضيع والمشاركات، والإعجابات، والأعلام، والإشارات المرجعية.
التثبيت
اتبع الدليل الموجود في Installing a theme or theme component لتثبيت المكون. استخدم https://github.com/scossar/discourse-segment-theme-component لتثبيته مباشرةً من مستودع Git الخاص به. يمكنك أيضًا تنزيله من هنا.
التكوين
أضف مفتاح الكتابة (Write Key) الخاص بـ Segment إلى إعداد segment write key. ثم اختر الأحداث التي ترغب في تتبعها:
أعلم أنني متأخر جداً في هذا الأمر، لكن لدي طلب آمل أن تتمكنوا من تلبيته.
هل يمكنكم إضافة عنوان البريد الإلكتروني للمستخدم، بالإضافة إلى رقم معرف المستخدم (User ID)، عند تسجيل دخول المستخدمين إلى Discourse؟
في Segment، أحاول دمج بيانات Discourse مع بيانات المستخدمين لنفس المستخدم المحتمل على موقع شركتي، لفهم أي المستخدمين يتصفحون Discourse وأيهم يزورون الموقع، لكنني لا أستطيع مطابقة المستخدمين حالياً لأن معرف المستخدم في Discourse لا يتطابق مع معرف المستخدم في الموقع.
إذا تمكنت من مطابقتهم عندما يتطابق عنوان البريد الإلكتروني بين Discourse والموقع، فسيكون ذلك مفيداً للغاية.
إضافة رائعة، شكرًا لك @simon! لقد كنت أستخدمها لعدة أشهر، وألاحظ أنها تفوت أحداث topic_created بين الحين والآخر. لم أتمكن من تحديد أي أنماط في هذه الإخفاقات، لذا فكرت في الكتابة هنا. هل لديك أي أفكار؟ هل توجد سجلات يمكنني التحقق منها بحثًا عن أخطاء؟
هذا ممكن تقنيًا. ومع ذلك، لدي بعض المخاوف الأمنية والخصوصية بشأن إضافة عنوان البريد الإلكتروني إلى الحمولة. سأفكر في الأمر وأطلب من فريق Discourse معرفة رأيهم. إذا تم إضافة عنوان البريد الإلكتروني إلى الحمولة، فسيكون هناك إعداد للموضوع يتيح ذلك، وسيكون الافتراضي هو عدم تضمين عنوان البريد الإلكتروني.
سأبحث في هذا الأمر. إذا عثرت على أي نمط، يرجى إخباري.
سأحاول إيجاد الوقت الأسبوع المقبل لاختبار المكون وإجراء بعض التحديثات عليه. بمجرد الانتهاء من ذلك، سأقوم بنقله من مستودع GitHub الشخصي إلى مستودع GitHub الخاص بـ Discourse.
@سيمون، أنا أفهمك وأوافق على مخاوف الأمان، ومع ذلك، أنا مدير لمنصة Discourse التي أسحب منها هذه البيانات، لذا يمكنني العثور على نفس عناوين البريد الإلكتروني للمستخدمين ببساطة عن طريق أخذ المعرف المقدم والذهاب إلى سجلات المستخدمين لربط المعرف بعنوان البريد الإلكتروني بهذه الطريقة. هذه المعلومات متاحة بالفعل، وإن كانت بشكل يدوي.
بالإضافة إلى ذلك، وبعد التحدث مع آخرين في مؤسستنا، قد ننتهي بالانتظار حتى نقوم بإعداد Oauth، بحيث يضطر مستخدمونا لاستخدام نفس المعرف لتسجيل الدخول إلى نظامنا ونظام Discourse.
بغض النظر، أعتقد أنه لا يزال من الجيد أن تكون هذه ميزة متاحة - في حال لم تكن هناك حل مماثل متاح لشخص آخر في المجتمع.
يبدو هذا النهج مثاليًا. يمكن تحديث مكون سمة Segment لإضافة خيار يتضمن provider_uid الذي توفره موفّر المصادقة الخاص بك.
أنا سعيد لأنك أثارْتَ هذه النقطة. يحتوي مكون تتبع Segment حاليًا على خيار لإضافة external_id الخاص بالمستخدم للمواقع التي تستخدم DiscourseConnect. عند النظر إليه الآن، أرى أنه يستخدم اسم الإعداد القديم لـ DiscourseConnect — فهو يتحقق مما إذا كان إعداد enable_sso مفعّلًا. يجب تغيير ذلك إلى enable_discourse_connect. سأقوم بإصلاح ذلك غدًا.
شكرًا جزيلاً، سيكون حقل provider_uid رائعًا جدًا — مما يجب أن يجعل من الممكن لنا ربط إجراءات المستخدم عبر موقعنا وDiscourse كليهما بعد إرسالها إلى Segment.
تم إصلاح المشكلة المتعلقة بتتبع المستخدمين بناءً على external_id في الحالة التي يكون فيها DiscourseConnect مفعّلًا كمزوّد مصادقة لموقع Discourse.
حتى الآن، لم أتمكن من تحديد السبب الذي قد يؤدي إلى عدم تتبع إنشاء المواضيع في بعض الأحيان. يبدو أن الأمر يعمل معي دون أي مشاكل.
تم تحديث الاسم المستخدم لحدث “Topic Bookmarked”. سابقًا، كان اسم الحدث المرسل إلى Segment هو “Thread Bookmarked”. لا أتذكر السبب وراء ذلك. نأمل أن لا يؤدي تغيير اسم الحدث إلى “Topic Bookmarked” إلى التسبب في مشاكل مع تحليلات أي شخص.
عندما تفحصت شاشة التصحيح في Segment، كان كل ما تم إرساله في استدعاء التعريف هو معرف المستخدم وعنوان IP. هل يمكن أيضًا تمرير عنوان البريد الإلكتروني مع استدعاء التعريف؟
عند تفعيله، سيتم تمرير عنوان البريد الإلكتروني للمستخدم مع استدعاء identify. إذا قمت بتحديث مكون السمة في موقع Discourse إلى أحدث إصدار، فسيكون هذا الإعداد متاحًا لك.
هناك مشكلة طفيفة لاحظتها أثناء الاختبار، وهي أنه إذا تم تعطيل الإعداد، سيستمر ظهور عنوان البريد الإلكتروني للمستخدم الحالي في Segment طوال مدة جلسته. ويرتبط ذلك بكيفية تعامل Segment مع هذه الأمور من جانبهم. فعند تعطيل الإعداد، يتوقف Discourse فورًا عن تمرير عناوين البريد الإلكتروني للمستخدمين إلى Segment.
لم أنسَ الطلب الخاص بتمرير provider_uid إلى Segment، لكن بينما كنت أعمل على هذا الأمر، تساءلت عما إذا كان من المفيد تمرير معرّفات أخرى إلى Segment. وتحديداً، تساءلت عن تمرير اسم المستخدم name واسم المستخدم username إلى استدعاء identify.
بخصوص الاسم واسم المستخدم، نعم، سيكونان مفيدَيْن أيضًا. الحل طويل الأمد هو تنفيذ طريقة لدفع جميع البيانات المضمنة في الأساس، بالإضافة إلى أي حقول مستخدم إضافية تم إنشاؤها في Discourse.
السبب في ذلك هو أن بعض الوجهات تتطلب قطعة بيانات محددة لتعمل. سيكون من المفيد جدًا وجود واجهة مستخدم لبناء الحمولة (payload) داخل Discourse. حتى لو كانت محدودة بالحقول القياسية المذكورة في وثائق Segment https://segment.com/docs/connections/spec/identify/.
عذراً على الرد المتأخر. لقد بحثت في هذا الأمر أكثر. لا يمكن حالياً تعيين provider_uid من خلال مكون سمة لأن Discourse لا يرسل provider_uid إلى العميل. ربما يمكن تمكين هذا عبر إعداد موقع في المستقبل، ولكن لكي يعمل، ستحتاج بعض التغييرات إلى إجرائها على الكود الأساسي لـ Discourse.
