ما يجمعه Mixpanel

يقوم SDK الخاص بـ Mixpanel (المحمّل من cdn.mxpnl.com أو المستضاف ذاتيًا) بتهيئة كائن mixpanel عام ويحدد المستخدمين بملف تعريف ارتباط مملوك لـ Mixpanel يحتوي على معرّف مميز تم إنشاؤه. من تلك اللحظة، كل استدعاء لـ mixpanel.track() يبلّغ عن حمولة حدث — اسم الحدث، والخصائص، والمعرّف المميز، ومجموعة من الخصائص المجمّعة تلقائيًا (وكيل المستخدم، ونظام التشغيل، والمُحيل، ومعاملات UTM، ودقة الشاشة، والمنطقة الزمنية) — إلى نقطة نهاية استيعاب Mixpanel. يدعم SDK أيضًا وضع Autocapture الذي يراقب DOM ويصدر أحداث النقر، وعرض الصفحة، وإرسال النماذج دون أدوات صريحة، مما يوسع بشكل كبير سطح ما يتم جمعه.

بمجرد مصادقة المستخدم واستدعاء التطبيق لـ mixpanel.identify(user_id)، يتم ربط جميع الأحداث اللاحقة — واعتمادًا على التكوين، جميع الأحداث المجهولة السابقة — بالهوية المصادق عليها. الربط بأثر رجعي هو واحدة من أكثر ميزات Mixpanel إفادة وواحدة من أكثرها كشفًا من منظور الخصوصية: يتم ربط سلوك التصفح المجهول الذي تم جمعه قبل الموافقة بأثر رجعي بملف تعريف محدد في اللحظة التي يسجل فيها هذا المستخدم الدخول.

لماذا إطار "تحليلات المنتج" لا يخرجك من الموافقة

الحجة الشائعة من فرق المنتجات والهندسة هي أن بيانات Mixpanel مخصصة لقرارات المنتج الداخلية، وليس للتسويق أو الإعلان، وأن هذا الإطار للاستخدام الداخلي يجب أن يكون مبررًا كافيًا بموجب أساس المصلحة المشروعة لـ GDPR. الحجة غير صحيحة إلى حد كبير لثلاثة أسباب كان المنظمون صريحين بشأنها.

المعالجة لا تزال معالجة بيانات شخصية

بغض النظر عن سبب جمع البيانات، فإن ملفات تعريف الارتباط غير ضرورية بموجب ePrivacy Article 5(3) والأحداث تحمل معرّفات دائمة بموجب تعريف GDPR للبيانات الشخصية. تحليل الأساس القانوني هو نفسه بالنسبة لأي نص برمجي تتبع آخر.

المصلحة المشروعة تتطلب اختبار موازنة

كتبت CNIL وICO وEDPB جميعها إرشادات توضح أن المصلحة المشروعة للتحليلات السلوكية تتطلب تقييمًا موثقًا يوضح أن المعالجة ضرورية ومتناسبة ولا تتجاوز التوقعات المعقولة للمستخدم. بالنسبة لبائع SaaS طرف ثالث يتلقى بيانات الأحداث على مستوى المستخدم، نادرًا ما ينجح اختبار الموازنة هذا دون موافقة صريحة.

النقل عبر الحدود مستقل

حتى لو تمكنت من تأسيس مصلحة مشروعة للجمع نفسه، فإن النقل الدولي إلى البنية التحتية الأمريكية لـ Mixpanel يحمل متطلبات أساسه القانوني الخاص الذي عادةً ما تلبيه الموافقة أو الضمان التعاقدي بشكل أنظف من المصلحة المشروعة وحدها.

عناصر التحكم الأصلية في خصوصية Mixpanel

يعرض Mixpanel مجموعة ذات مغزى من أوليات الخصوصية المصممة لدعم عمليات النشر المحمية بالموافقة. كما هو الحال مع معظم المنصات، فإنها تفترض أن قرار الموافقة موجود في المنبع؛ فهي لا تجمعه بنفسها.

opt_out_tracking

يوقف استدعاء mixpanel.opt_out_tracking() SDK من إرسال الأحداث ويحافظ على تفضيل عدم الاشتراك عبر الجلسات. قم بإقرانه مع mixpanel.opt_in_tracking() عندما يقبل المستخدم فئة التحليلات في CMP الخاص بك. يحترم SDK هذا الإعداد عبر جميع الاستدعاءات اللاحقة دون الحاجة إلى إعادة التهيئة.

has_opted_out_tracking

دالة استعلام تُرجع حالة عدم الاشتراك الحالية، مفيدة لمزامنة حالة SDK مع حالة CMP الخاصة بك عند تحميل الصفحة أو تغيير المسار.

خيار الإقامة في EU

يقدم Mixpanel نوع مشروع إقامة بيانات EU يحافظ على بيانات الأحداث ضمن البنية التحتية الموجودة في Frankfurt. وهذا يعالج جزءًا كبيرًا من قلق النقل عبر الحدود وهو التكوين الصحيح لأي مشروع حيث تكون إقامة EU متطلبًا صارمًا. لا يلغي متطلب الموافقة.

set_config({ ip: false })

يعطل التقاط عنوان IP، مما يقلل من بصمة البيانات الشخصية لكل حدث. مفيد كإجراء دفاع متعمق إلى جانب بوابة الموافقة.

تكامل CMP خطوة بخطوة

نمط التكامل الذي يعمل بشكل موثوق هو تهيئة Mixpanel في حالة عدم الاشتراك بشكل افتراضي، ثم إشراك المستخدم عندما يقبل فئة التحليلات في CMP.

1. تهيئة Mixpanel مع الإعداد الافتراضي لعدم الاشتراك

استدعِ mixpanel.init(token, { opt_out_tracking_by_default: true }) في أقرب وقت ممكن في تمهيد التطبيق الخاص بك. يؤدي هذا إلى تحميل SDK ولكنه يمنعه من إرسال أي أحداث حتى يتم استدعاء opt_in_tracking().

2. ربط رد الاتصال الموافقة

عندما يطلق CMP حدث قبول فئة التحليلات الخاص به، استدعِ mixpanel.opt_in_tracking(). عادةً ما يتم تجاهل الأحداث المصفوفة التي تم التقاطها خلال فترة عدم الاشتراك؛ إذا كنت بحاجة إلى الاحتفاظ بها، فقم بتكوين سلوك الصف في SDK بشكل صريح واقبل المخاطرة الصغيرة بأن الأحداث من فترة ما قبل الموافقة يتم إرسالها بعد الموافقة.

3. التعامل مع الإلغاء

إذا ألغى المستخدم الموافقة لاحقًا، فاستدعِ mixpanel.opt_out_tracking(). يؤدي هذا إلى إيقاف استيعاب الأحداث الإضافية. للحذف الكامل للبيانات التاريخية، يجب على التطبيق أيضًا استدعاء API الحذف الخاص بـ Mixpanel أو تشغيل طلب حذف من واجهة مستخدم مشروع Mixpanel.

4. تجنب دمج الهوية بأثر رجعي دون موافقة صريحة

عطّل سلوك الدمج بأثر رجعي لاستدعاء identify ما لم يوافق المستخدم على ربط تصفحه قبل التعريف بملفه الشخصي. تعرض خيارات SDK الخاصة بـ Mixpanel علامة لهذا؛ الافتراضي المحافظ هو "لا دمج بأثر رجعي".

5. استخدام مشروع إقامة EU لحركة المرور EU

بالنسبة للمشاريع حيث تهم إقامة EU، قم بتوجيه حركة المرور من EU إلى مشروع Mixpanel بإقامة EU وحركة المرور من US/غيرها إلى مشروع منفصل. يدعم SDK تحميل رموز مختلفة مشروطة على المنطقة المكتشفة للمستخدم.

المزالق الشائعة

أربعة أخطاء تكامل تمثل معظم نتائج التدقيق على عمليات نشر Mixpanel.

معاملة Mixpanel كمعفى لأنه استخدام داخلي

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

ترك Autocapture مفعّلًا بشكل افتراضي

يوسع Autocapture بشكل كبير سطح ما يتم إرساله — كل نقرة، كل تفاعل حقل إدخال، كل عرض صفحة. يتوسع سطح المخاطر معه. بالنسبة لمعظم عمليات نشر SaaS، تنتج الأدوات الصريحة بيانات أنظف وبصمة تدقيق أصغر من Autocapture؛ أوقف Autocapture ما لم يكن لديك سبب محدد للحفاظ عليه.

نسيان دمج الهوية بأثر رجعي

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

تشفير افتراض إقامة EU

عدد مفاجئ من الفرق يوجه كل حركة المرور إلى مشروع Mixpanel بإقامة US بافتراض أن الموافقة تغطي سؤال الإقامة. إنها لا تغطيها — الموافقة والإقامة أسئلة امتثال مستقلة. قم بالتوجيه حسب المنطقة المكتشفة، وليس حسب الافتراضي العالمي.

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

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

• هل يبدأ Mixpanel في حالة عدم الاشتراك؟ تأكد من تهيئة SDK بـ opt_out_tracking_by_default: true وعدم إطلاق أي أحداث قبل الموافقة.
• هل ينطلق الاشتراك في حدث CMP الصحيح؟ تأكد من أن رد الاتصال المقبول للتحليلات يستدعي opt_in_tracking()، وليس حدثًا أكثر تساهلاً.
• هل Autocapture ضروري؟ إذا كان مفعّلاً، فوثّق السبب. إن لم يكن، فعطّله.
• هل الدمج بأثر رجعي معطّل؟ تأكد من أن استدعاء التعريف لا يربط السلوك المجهول قبل الموافقة بملفات التعريف المحددة حديثًا.
• هل حركة المرور EU على مشروع إقامة EU؟ تأكد من أن منطق التوجيه يرسل زوار EU إلى رمز مشروع EU.
• هل طلبات الحذف مؤتمتة؟ تأكد من أن طلبات DSAR تشغل API الحذف الخاص بـ Mixpanel بدلاً من تذكرة يدوية.

أين يتناسب Mixpanel في مجموعة تقنيات تعطي الأولوية للموافقة

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