لماذا يتطلب PostHog الموافقة — ولماذا الإجابة ليست واحدة لكل وحدة

SDK الويب الخاص بـ PostHog ليس علامة صفحة سلبية. عند التهيئة الافتراضية، يُعيّن SDK إدخالاً ثابتاً للاستمرارية أو أكثر — بشكل افتراضي مخطط مشترك من ملفات تعريف الارتباط وlocalStorage مُفهرس تحت ph_{projectKey}_posthog — ويُولّد معرفاً مستقلاً ثابتاً، ويلتقط عرض الصفحة الأولي مع المرجع ومعلمات UTM ومعرّفات النقر، ويفتح قناة أحداث طويلة الأمد إلى مضيف الاستيعاب المُهيَّأ. إذا كانت إعادة تشغيل الجلسة مُفعَّلة على مستوى المشروع، فإن SDK يبدأ أيضاً في بث سجل متواصل للـ DOM المُصيَّر وإحداثيات الماوس وأحداث الإدخال. إذا كانت علامات الميزات مُهيَّأة، فإن SDK يُقيّمها مقابل المعرّف المستقل، ويحفظ القرارات للجلسة، ويُصدر حدث $feature_flag_called لكل تقييم.

كل نشاط من هذه الأنشطة يُعيَّن إلى بوابة موافقة مختلفة. حفظ معرّف مستقل هو عملية تخزين وصول بموجب Article 5(3) من توجيه ePrivacy ويستلزم موافقة مسبقة وحرة وخاصة ومستنيرة وغير غامضة عبر EEA والمملكة المتحدة وأي ولاية قضائية استوردت المعيار نفسه. التقاط الأحداث السلوكية هو معالجة بيانات شخصية بموجب GDPR لأن مجموعة المعرّف وعنوان IP والأثر السلوكي كافية لتحديد فرد. إعادة تشغيل الجلسة تقع في فئة منفصلة وأكثر صرامة بموجب إرشادات EDPB لإعادة تشغيل الجلسة — تلتقط إعادة التشغيل DOM المُصيَّر وأي حقل إدخال غير مُقنَّع وتستلزم موافقة صريحة ودقيقة تختلف عن موافقة التحليلات العامة. تقييم علامة الميزة هو النقطة الدقيقة: الفحص الذي يُعيد قيمة منطقية لا يتطلب موافقة بحد ذاته، لكن حفظ تعيين العلامة للمستخدم في معرّف ثابت عبر الجلسات يتطلب ذلك، لأن هذه هي الطريقة التي تنشئ بها تجارب العلامات بيانات على مستوى المستخدم قابلة للتتبع.

ما يكتبه PostHog قبل الموافقة — وما يجب قمعه

يكتب Browser SDK الافتراضي لـ PostHog ما يلي عند التهيئة: ملف تعريف ارتباط مشترك واحد وإدخال localStorage تحت ph_{projectKey}_posthog يحتوي على المعرّف المستقل ومعرّف الجلسة وقرارات علامات الميزات، بالإضافة إلى، عند تفعيل إعادة تشغيل الجلسة، مخزن تسجيل مؤقت إضافي في الذاكرة يُفرَّغ إلى نقطة نهاية الاستيعاب كل بضع ثوانٍ. يُرسل SDK أيضاً حدث $pageview فورياً، وإذا كان الالتقاط التلقائي مُفعَّلاً، كل نقرة لاحقة وتفاعل نموذج ونقرة غاضبة على الصفحة.

النمط الموصى به هو تهيئة PostHog بـ opt_out_capturing_by_default: true وdisable_session_recording: true، ثم تبديل كلا العلمين بمجرد أن يُعيد بانر الموافقة إشارة إيجابية. هذا هو موقف التكامل الذي توصي به وثائق PostHog الآن، وهو الموقف الذي ينجو من مراجعة المنظّم لأنه يعكس الافتراضي: لا يُلتقط شيء حتى تُسجَّل الموافقة، ويوفر SDK انتقالاً نظيفاً بدلاً من إعادة تهيئة ذات حالة.

ملفات تعريف الارتباط وإدخالات localStorage والمعرّفات التي يحفظها PostHog

يكتب Browser SDK 1.x إدخال استمرارية واحداً لكل مشروع، مُفهرساً تحت ph_{projectKey}_posthog، بانتهاء صلاحية افتراضي 365 يوماً. يتحكم خيار التهيئة persistence في الآلية الأساسية: cookie فقط، أو localStorage فقط، أو localStorage+cookie (الافتراضي)، أو sessionStorage، أو memory. لنشر يُقدّم الموافقة أولاً، تُعدّ استمرارية memory الإعداد الافتراضي الصحيح عندما لم تُمنح الموافقة بعد — تضمن ألا يتجاوز أي معرّف جلسة الصفحة — مع الانتقال إلى localStorage+cookie بمجرد تبديل الموافقة. يكتب SDK أيضاً علامة قبول أو رفض تحت __ph_opt_in_out_{projectKey} لتذكر اختيار المستخدم عبر الزيارات؛ تلك العلامة نفسها هي ملف تعريف ارتباط ضروري بالكامل لأنها تحفظ قرار الموافقة.

تعيين وحدات PostHog إلى أطر الموافقة

لا يُطبّق PostHog IAB TCF أو منصة الخصوصية العالمية IAB بصورة أصلية، وليس مبنياً كبائع تقنية إعلانية. إلا أنه يتكامل مع Google Consent Mode v2 من خلال جسر من جانب الناشر، ويُعرض واجهة برمجة قبول وإلغاء قبول أصلية، ويحترم رأس Do Not Track عبر خيار التهيئة respect_dnt. النمط الذي يعمل في الإنتاج يُعامل كل وحدة من وحدات PostHog كبوابة منفصلة مرتبطة بإشارة CMP محددة.

• أحداث تحليلات المنتج مرتبطة بغرض التحليل. بمصطلحات TCF، هذا في الغالب الغرض 8 (قياس أداء المحتوى) مجتمعاً مع الغرض 1 (تخزين المعلومات و/أو الوصول إليها). بالنسبة لـ Consent Mode، هذا يُعيَّن إلى analytics_storage.
• إعادة تشغيل الجلسة تقع خلف بوابة أكثر صرامة. تلتقط إعادة تشغيل جلسة PostHog DOM المُصيَّر وأي حقل إدخال غير مُقنَّع، لذا فإن قبول تفضيلات أو قبول بحث مستقل عن التحليلات هو الموقف القابل للدفاع بموجب إرشادات EDPB.
• علامات الميزات والتجريب يمكنها العمل بتقييم مؤقت في الذاكرة بموجب أساس المصلحة المشروعة عندما يكون الهدف فقط تنويع الصفحة المُصيَّرة. تعيين العلامة الثابت المرتبط بمعرّف ثابت عبر الجلسات يتطلب نفس الموافقة كالتحليلات، لأن هذا هو الوقت الذي تصبح فيه العلامة نقطة بيانات على مستوى المستخدم قابلة للتتبع.
• الاستطلاعات والملاحظات مرتبطة بنفس بوابة إعادة تشغيل الجلسة عند جمع إدخال نص حر، أو بوابة التحليلات عند جمع تقييمات أو ردود أحادية الاختيار فقط.

نمط التكامل الذي يعمل

يتكون النشر المرجعي من أربعة أجزاء: CMP يُعرض حدث تغيير الموافقة في الوقت الفعلي، وتمهيد مؤجل يُهيّئ PostHog مع تعطيل الالتقاط وإعادة التشغيل، ومستمع موافقة يُبدّل opt_in_capturing ومفتاح التسجيل عند فتح البوابات ذات الصلة، ومسار سحب يستدعي opt_out_capturing ويوقف مخزن إعادة التشغيل المؤقت ويمسح المعرّفات الثابتة عبر واجهة إعادة التعيين للـ SDK.

تطبيق الويب

أنظف نمط هو تحميل PostHog SDK على كل صفحة لكن استدعاء posthog.init(apiKey, { api_host: 'https://eu.posthog.com', opt_out_capturing_by_default: true, disable_session_recording: true, persistence: 'memory', respect_dnt: true }) كبوتسترب أولي. اشترك في حدث تغيير الموافقة للـ CMP. عندما تنتقل فئة التحليلات إلى صحيح، استدعِ posthog.set_config({ persistence: 'localStorage+cookie' }) يليه posthog.opt_in_capturing()؛ هذا يُعيد تمكين التقاط الأحداث وانتقال الاستمرارية يبدأ في كتابة المعرّف المستقل. عندما تنتقل فئة إعادة تشغيل الجلسة إلى صحيح، استدعِ posthog.startSessionRecording(). عند سحب أي بوابة، استدعِ posthog.opt_out_capturing() لبوابة التحليلات أو posthog.stopSessionRecording() لبوابة إعادة التشغيل، وأنهِ إدخالات الاستمرارية الدائمة عبر posthog.reset()، وأرسل طلب حذف عبر GDPR API الخاص بـ PostHog إذا استخدم المستخدم حق المسح.

اختيار المنطقة: PostHog Cloud US مقابل EU مقابل المستضاف ذاتياً

يُشغّل PostHog منطقتين سحابيتين — US (us.posthog.com) وEU (eu.posthog.com) — ويدعم التثبيتات المستضافة ذاتياً على بنية تحتية خاصة بالعميل. بالنسبة لحركة EEA والمملكة المتحدة، السحابة الأوروبية هي الإعداد الافتراضي الصحيح؛ تُبقي الاستيعاب والمعالجة والتخزين داخل EEA وتُقلل تعرض Schrems II الذي يحمله أي نشر تحليلات في المنطقة الأمريكية. خيار التهيئة api_host يُثبّت المنطقة. يُنقل PostHog المستضاف ذاتياً المنظومة بأكملها إلى بنية تحتية خاصة بالناشر، وهو أقوى موقف لإقامة البيانات لكنه لا يُزيل التزامات الموافقة — الأساس القانوني يتبع البيانات وليس المشغّل. أي خيار يتم اختياره يجب أن ينعكس في إشعار الخصوصية وسجل معالجة البيانات الخاص بالمتحكم.

الالتقاط من جانب الخادم

يدعم PostHog استيعاب الأحداث من جانب الخادم عبر Python وNode وGo وRuby وPHP SDKs. أحداث جانب الخادم ليست معفاة من الموافقة — الأساس القانوني يتبع البيانات — لكن الاستيعاب من جانب الخادم يمنح الناشر تحكماً كاملاً في الحقول المُصدَرة ووقت إصدارها. نمط شائع هو التقاط مجموعة أحداث أساسية محدودة من جانب الخادم بموجب المصلحة المشروعة، ثم إثراء تلك الأحداث بتفاصيل سلوكية من العميل فقط بعد منح المستخدم موافقة التحليلات. تنضم أحداث جانب الخادم وجانب العميل على نفس المعرّف المستقل عند تبديل الموافقة؛ قبل الموافقة، تُصدَر أحداث جانب الخادم بمعرّف مجهول وزائل يُعاد تعيينه في كل جلسة.

التحقق من التكامل ومسار التدقيق

خطوة التحقق هي ما يفحصه المنظّمون وما يتخطاه الناشرون في أغلب الأحيان. يجب أن يجتاز نشر PostHog المتكامل بشكل صحيح أربعة اختبارات بالتسلسل. أولاً، يجب أن تُنتج جلسة متصفح نظيفة مع عرض البانر دون اختيار صفر طلبات إلى api_host المُهيَّأ ما عدا جلب ملف SDK، وصفر ملفات تعريف ارتباط ph_ في document.cookie، وصفر إدخالات ph_ في localStorage. ثانياً، رفض التحليلات يجب أن يُبقي تلك الحالة — لا التقاط، لا تسجيل، لا معرّف ثابت. ثالثاً، قبول التحليلات يجب أن يُنتج حدث $opt_in فورياً وإدخال الاستمرارية المتوقع ph_{projectKey}_posthog بسمات SameSite صحيحة وتدفق أحداث إلى المضيف المُهيَّأ. رابعاً، سحب الموافقة بعد ذلك يجب أن يوقف الالتقاط وإعادة التشغيل فوراً وينهي المعرّفات الثابتة ويُشغّل طلب حذف عبر GDPR API الخاص بـ PostHog إذا استخدم المستخدم حق المسح.

التوقع المتعلق بمسار التدقيق بموجب إرشادات بانر ملفات تعريف الارتباط لعام 2023 الصادرة عن EDPB وأولويات فريق العمل المتجددة لعام 2026 هو أن يستطيع الناشر إثبات، لأي حدث معين في مشروع PostHog، أن المستخدم الذي ولّده كان قد أعطى موافقة صالحة في لحظة الالتقاط. النمط القياسي هو تعيين إصدار الموافقة وطابعه الزمني كخصائص شخص على المعرّف المستقل عبر posthog.setPersonProperties({ consent_version: 'v3', consent_ts: ts }) بحيث يكون أي حدث فردي قابلاً للتتبع إلى إدخال سجل موافقة محدد. النشر المُبوَّب بشكل صحيح، مقترناً باختيار المنطقة الذي يتطابق مع الجمهور، والاستمرارية التي تُعيّن ذاكرة كإعداد افتراضي، ومسار الحذف الذي يُفعَّل عند السحب، هو ما يحوّل PostHog من خطر تركيز تنظيمي إلى مركز قابل للدفاع لمنظومة تحليلات المنتج.