دليل تكامل موافقة ملفات تعريف الارتباط لتجربة FullStory الرقمية وإعادة تشغيل الجلسات: دليل 2026
FullStory هي المنصة المهيمنة في فئة تحليلات التجربة الرقمية لسبب وحيد: فهي تلتقط كل شيء بشكل افتراضي. في حين تسجّل أدوات التحليلات التقليدية أحداثاً منفصلة قام المطوّر بقياسها، وتسجّل منصات تحليلات المنتجات التفاعلات بالإضافة إلى مكمّل التقاط تلقائي، يلتقط FullStory DOM المُعروض بالكامل، ومسار المؤشر، وتوقيت ضغطات المفاتيح، وسلوك التمرير، والنقرات الغاضبة، والنقرات الميتة، وطلبات الشبكة، وأخطاء JavaScript — ويجمعها في تسجيلات جلسات يمكن للمحلل تصفّحها إطاراً إطاراً. هذا التغطية هو المنتج. وهذا أيضاً سبب وجود FullStory عند تقاطع أشد قواعد الموافقة صرامةً في كل نظام خصوصية حديث. توجيهات EDPB لإعادة تشغيل الجلسات لعام 2023 وأولويات فرقة العمل 2026 تعامل إعادة تشغيل الجلسات باعتبارها فئة موافقة منفصلة وأكثر صرامة. كانت CNIL المنظِّم الأكثر علنيةً في هذا الموضوع لكنها لست وحدها — فقد أصدرت كلٌّ من Garante وICO والإسبانية AEPD والهولندية AP مواقف متوافقة. نشر FullStory الذي تمت تهيئته للالتقاط المقيّد بالموافقة أولاً، مع إخفاء صحيح، وتقييد صحيح، ومسار تدقيق صحيح، هو أحد أقوى الأدوات التي يمكن للناشر تشغيلها؛ أما الذي لم تتم تهيئته كذلك، فهو أسهل الأهداف التي سيجدها المنظِّم.
لماذا يقع FullStory في فئة الموافقة الأكثر صرامة
تهيئة FullStory الافتراضية تفعل ما تفعله كل أداة إعادة تشغيل جلسات بل وأكثر. فهي تضع ملفات تعريف ارتباط من طرف أول تحت مساحة الأسماء fs_uid وfs_lua تحتوي على معرّف الزائر الدائم والطابع الزمني لآخر نشاط، وتولّد معرّف جلسة تحت fs_session، وتبدأ في بث DOM المُعروض إلى rs.fullstory.com في غضون ميلي ثانية من تحميل الصفحة. يشمل البث كل حدث إدخال، وكل حركة ماوس، وكل موضع تمرير، وكل انتقال بين الصفحات، و— عند تفعيل وحدة التقاط الشبكة — كل استجابة XHR وfetch تصدرها الصفحة، بما في ذلك محتويات الاستجابة ما لم يكن المشغّل قد هيّأ الكبح.
كل عملية التقاط من هذه تُشغّل بوابة موافقة منفصلة. استمرار معرّف الزائر هو عملية تخزين واستخدام وفق المادة 5(3) من توجيه ePrivacy تتطلب موافقة مسبقة وطوعية وخاصة ومستنيرة وواضحة لا لبس فيها عبر منطقة EEA والمملكة المتحدة وأي ولاية قضائية استوردت المعيار ذاته. تسجيل DOM المُعروض هو معالجة بيانات شخصية وفق GDPR لأن السجل البصري كافٍ لتعريف المستخدم والكشف عن محتوى جوهري بشأنه. التقاط تدفق ضغطات المفاتيح حساسية خاصة: كل ما يكتبه المستخدم في حقل نموذج يُلتقط إطاراً إطاراً، وإذا كان الحقل غير مخفيّ يتضمن التسجيل المحتوى المكتوب. كانت EDPB صريحة في أن التقاط إعادة تشغيل الجلسات يستلزم موافقة صريحة وتفصيلية منفصلة عن موافقة التحليلات العامة — وأن الإخفاء مكمّل للموافقة لا بديل عنها.
ما يكتبه FullStory قبل الموافقة — وما يجب كبته
يثبّت الإعداد السريع القياسي لـ FullStory مقتطف التتبع مباشرة في <head> الصفحة. يعمل هذا كما هو موثّق وهو مصدر أكثر إخفاقات الامتثال شيوعاً: يعمل المقتطف قبل عرض لافتة ملفات تعريف الارتباط، وتُكتب ملفات تعريف الارتباط fs_uid وfs_session في غضون ميلي ثانية، ويبدأ تدفق إعادة تشغيل الجلسات إلى rs.fullstory.com بصرف النظر عما يقرره المستخدم لاحقاً. كل منظِّم أوروبي بتّ في هذا النمط توصّل إلى الحكم ذاته: ملفات تعريف الارتباط المُعيَّنة قبل الموافقة غير مشروعة، والتسجيل الذي يتم الالتقاطه قبل الموافقة هو معالجة غير مشروعة، والناشر يتحمل المسؤولية.
لذا يجب على التكامل المتوافق منع مقتطف FullStory من التهيئة حتى يتم منح فئة الموافقة ذات الصلة. النمط الذي يعمل في الإنتاج هو واجهة برمجة التطبيقات FS.consent() مقترنة بالتسجيل المؤجَّل: يُحمَّل المقتطف مع FullStory({ orgId: 'XXX', recordOnlyThisIFrame: false }) ويُستدعى FS.shutdown() فوراً، ثم يُستدعى FS.restart() وFS.consent(true) فقط بعد أن تُشير CMP إلى أن فئة إعادة تشغيل الجلسات قد مُنحت. النمط البديل هو حقن السكريبت المشروط — يُضاف مقتطف FullStory إلى DOM فقط بعد منح الموافقة — وهو أنظف لكنه يتطلب من المشغّل التخلي عن أي ربط هوية قبل الموافقة قد يوفّره FullStory.
ملفات تعريف الارتباط والتخزين التي يكتبها FullStory
يكتب مقتطف FullStory المعرّفات التالية عند التهيئة، وكلها غير أساسية وتستلزم الموافقة: fs_uid بانتهاء صلاحية متعددة السنوات يحتوي على معرّف الزائر الدائم، fs_lua بالطابع الزمني لآخر نشاط مستخدم، fs_session بمعرّف الجلسة، ومعلّمات حالة التسجيل التي يستخدمها FullStory داخلياً. لذا يجب أن يؤدي سحب الموافقة إلى انتهاء صلاحية هذه الملفات واستدعاء FS.consent(false) يتبعه FS.shutdown() لإيقاف الالتقاط الإضافي، كما يجب على الناشر إرسال طلب حذف عبر نقطة نهاية الخصوصية في FullStory لتسجيلات المستخدم السابقة.
تعيين FullStory على أطر الموافقة
لا ينفّذ FullStory بشكل أصيل IAB TCF أو منصة IAB للخصوصية العالمية — فهو منصة تجربة رقمية من الطرف الأول وليس بائع تقنيات إعلانية. يكشف واجهة برمجة تطبيقات موافقة أصيلة ويدعم نموذج إخفاء خاصاً افتراضياً يعمل بصرف النظر عن حالة الموافقة. النمط الذي يصمد أمام مراجعة المنظِّم يعامل كل وحدة من وحدات FullStory كبوابة منفصلة مرتبطة بإشارة CMP محددة.
- إعادة تشغيل الجلسات وتدفق DOM الكامل مرتبطان بفئة إعادة تشغيل جلسات أو أبحاث مخصصة مستقلة عن التحليلات العامة. توجيهات EDPB صريحة في هذه النقطة — يجب أن تكون موافقة إعادة التشغيل منفصلة وتفصيلية وغير مجمّعة مع التحليلات أو التسويق.
- التقاط الشبكة يقع خلف بوابة فرعية أكثر صرامة ضمن الفئة ذاتها لأنه يلتقط محتويات استجابة HTTP التي قد تحتوي على بيانات شخصية غير مرتبطة بالواجهة المرئية. يجب أن يكون التقاط الشبكة معطّلاً افتراضياً ولا يُفعَّل إلا لمسارات تطبيق محددة تأكّد فيها المشغّل من أن محتويات الاستجابة لا تتضمن بيانات حساسة.
- ربط الهوية عبر FS.identify() يمكن أن يعمل بمعرّف جلسة مؤقت وفق أساس المصلحة المشروعة عندما يكون المستخدم مجهولاً، لكن ربط تعريف الهوية بمعرّف دائم من الطرف الأول عبر الجلسات يتطلب الموافقة ذاتها كإعادة تشغيل الجلسات.
- الخرائط الحرارية وتحليلات التحويل المشتقة من تدفق إعادة تشغيل الجلسات ترث البوابة من التدفق المصدر — فهي ليست واجهات موافقة منفصلة بل منتجات لاحقة للبيانات الملتقطة ذاتها.
نمط التكامل الفعّال
يتكوّن النشر المرجعي من أربعة أجزاء: CMP تكشف حدث تغيير الموافقة في الوقت الفعلي، وتهيئة مؤجّلة تُشغّل FullStory مع كبح الالتقاط عبر FS.shutdown()، ومستمع موافقة يستدعي FS.consent(true) وFS.restart() عند فتح بوابة إعادة تشغيل الجلسات، وإعداد إخفاء خاص افتراضي يكبت بشكل صارم كل حقل إدخال ما لم يُسمح به صراحةً.
الإخفاء الخاص افتراضياً
تعمل طبقة إخفاء FullStory باستقلالية عن الموافقة ويجب تهيئتها بقوة حتى عند منح الموافقة. فئة CSS fs-mask على أي عنصر تكبت محتوى ذلك العنصر من التسجيل؛ فئة CSS fs-exclude تستبعد العنصر كلياً من تدفق DOM؛ وفئة fs-block تحجب المحتوى والهيكل معاً. وفق قواعد الفئات الخاصة في GDPR وتعريف المعلومات الشخصية الحساسة في CCPA، يجب على أي حقل قد يلتقط معلومات صحية، أو تفاصيل مالية، أو معرّفات حكومية، أو بيانات بيومترية، أو موقعاً جغرافياً دقيقاً، أو محتويات اتصالات خاصة، استخدام سمات الإخفاء بصرف النظر عن حالة موافقة المستخدم. الوضعية الموصى بها هي تطبيق fs-mask على مستوى النموذج لا مستوى الحقل — فالمطوّر الذي يضيف حقلاً جديداً إلى نموذج قائم أقل احتمالاً بكثير لتذكّر إخفائه بشكل فردي مقارنةً بما لو كان يعمل داخل غلاف إخفاء على مستوى النموذج يلتقطه تلقائياً.
اختيار المنطقة وإقامة البيانات
يشغّل FullStory نقطتي استيعاب أمريكية وأوروبية منفصلتين. لحركة مرور EEA والمملكة المتحدة، نقطة الاستيعاب الأوروبية هي الافتراضية الصحيحة — فهي تبقي الاستيعاب والمعالجة والتخزين داخل منطقة EEA وتقلل من التعرض لـ Schrems II الذي سيحمله أي نشر لإعادة تشغيل جلسات في المنطقة الأمريكية. تُهيَّأ نقطة الاستيعاب لكل منظمة FullStory ولا يمكن تغييرها بأثر رجعي، لذا يجب اتخاذ قرار المنطقة قبل التوسع وتوثيقه في إشعار الخصوصية حتى تكون سلسلة الأساس القانوني نظيفة من الجمع إلى التخزين.
التحقق من التكامل ومسار التدقيق
خطوة التحقق هي ما يفحصه المنظِّمون وما يتخطاه الناشرون في أغلب الأحيان مع أدوات إعادة تشغيل الجلسات. يجب أن يجتاز نشر FullStory المتكامل بشكل صحيح أربعة اختبارات بالتسلسل. أولاً، يجب أن تنتج جلسة متصفح نظيفة مع عرض اللافتة دون اتخاذ أي اختيار صفراً من الطلبات إلى rs.fullstory.com ما عدا جلب ملف SDK وصفراً من ملفات تعريف الارتباط fs_ في document.cookie. ثانياً، يجب أن يحافظ رفض موافقة إعادة التشغيل على تلك الحالة — لا التقاط، ولا معرّف، ولا تسجيل. ثالثاً، يجب أن تنتج قبول موافقة إعادة التشغيل ملف تعريف الارتباط المتوقع fs_uid، وحدث FS.consent(true) واحداً، وتدفق DOM إلى نقطة نهاية المنطقة المهيّأة، مع تأكيد التقاط الحقول المخفية للعناصر النائبة للإخفاء فقط. رابعاً، يجب أن يوقف سحب الموافقة الالتقاط فوراً، وينهي ملفات تعريف الارتباط fs_، ويُشغّل طلب حذف عبر نقطة نهاية الخصوصية في FullStory لتسجيلات المستخدم السابقة.
توقع مسار التدقيق هو حيث تواجه أدوات إعادة تشغيل الجلسات التدقيق الأشد. إرشادات EDPB للافتة ملفات تعريف الارتباط 2023 وأولويات فرقة العمل المجددة لعام 2026 صريحة في أن على الناشر إثبات، لأي تسجيل جلسة محدد في مشروع FullStory، أن المستخدم الذي أنشأه قد أعطى موافقة صالحة لإعادة تشغيل الجلسات في لحظة الالتقاط. النمط القياسي هو تعيين نسخة الموافقة والطابع الزمني كمتغيرات مستخدم على معرّف FullStory عبر FS.setUserVars({ consent_version: 'v3', consent_ts: ts }) حتى يكون أي تسجيل فردي قابلاً للتتبع إلى إدخال سجل موافقة محدد. النشر المُقيَّد بشكل صحيح، المقترن بسمات إخفاء تكون خاصة افتراضياً ومسار حذف يُفعَّل عند السحب، هو ما يحوّل تغطية FullStory من تركّز مخاطر تنظيمية إلى جزء قابل للدفاع من مكدس التجربة الرقمية للناشر.