دليل تكامل موافقة الكوكيز لتحليلات المنتج مع الالتقاط التلقائي من Heap: دليل عمل 2026 للناشرين
يُعدّ Heap استثناءً في نظام بيئة تحليلات المنتج بسبب ما يفعله بشكل افتراضي. في حين يطلب Mixpanel وAmplitude وPostHog من الناشر تجهيز الأحداث المهمة، يلتقط Heap كل شيء تلقائيًا ويتيح للمحلل تعريف الأحداث بأثر رجعي من التدفق الملتقط. هذا النموذج للالتقاط التلقائي هو الميزة المحددة للمنتج والسبب الذي يدفع الفرق إلى اختياره؛ وهو أيضًا السبب في أن نشر Heap الافتراضي يحمل أحد أوسع الأسطح للبيانات السلوكية من بين أي أداة يرجح أن يثبّتها الناشر. يتم التقاط كل نقرة ولمسة وتمرير وتفاعل مع النماذج وانتقال صفحة ونقرة غاضبة مقابل معرّف ثابت في غضون ميلي ثوانٍ من تحميل الصفحة — مما يعني أن كل هذه العمليات تستلزم التزامًا بالموافقة. الخبر السار هو أن Heap، منذ استحواذ Contentsquare عليه، يأتي مزوّدًا بواحدة من أكثر واجهات برمجة تطبيقات الموافقة تفصيلاً في مجال تحليلات المنتج؛ والعمل يكمن في توصيلها بشكل صحيح فعليًا عبر سطح الالتقاط التلقائي وطبقة الهوية وحدة إعادة تشغيل الجلسة التي يضيفها تكامل Contentsquare.
لماذا يتطلب Heap الموافقة — ولماذا الإجابة أوسع من التحليلات النموذجية
يؤدي التهيئة الافتراضية لـ Heap عدة أشياء في أول رسم للصفحة. يضع ملف تعريف ارتباط طرف أول تحت _hp2_id.{envId} يحتوي على معرّف المستخدم الدائم، وملف تعريف ارتباط للجلسة تحت _hp2_ses_id.{envId} بمعرّف الجلسة، وملف تعريف ارتباط لمعدل العينة تحت _hp2_props.{envId}، وعلامة _hp2_loaded التي تشير إلى أن SDK قد اكتمل تهيئته. يولّد المعرّف المميز إذا لم يكن موجودًا بالفعل، ويلتقط عرض الصفحة الأولي مع المُحيل ومعاملات UTM ومعرّفات النقر، ويبدأ فورًا في تسجيل كل تفاعل لاحق مقابل هذا المعرّف — نقرات ولمسات وتغييرات في النماذج وتغييرات في المسار وأحداث مخصصة، وعند تمكين تكامل Contentsquare، فرق DOM المُقدَّم الكاملة لإعادة تشغيل الجلسة.
كل واحد من هذه الأنشطة يستلزم بوابة موافقة منفصلة. يُعدّ استمرار معرّف المستخدم عملية تخزين ووصول بموجب Article 5(3) من توجيه ePrivacy ويستلزم موافقة مسبقة حرة ومحددة ومستنيرة وصريحة عبر EEA والمملكة المتحدة وأي ولاية قضائية استوردت المعيار ذاته. يُعدّ التقاط تدفق حدث الالتقاط التلقائي معالجةً للبيانات الشخصية بموجب GDPR لأن الجمع بين المعرّف وعنوان IP والأثر السلوكي كافٍ للتمييز بين الأفراد. تقع إعادة تشغيل الجلسة في فئة منفصلة أكثر صرامة بموجب إرشادات EDPB لإعادة تشغيل الجلسة — تلتقط إعادة التشغيل DOM المُقدَّم وأي حقل إدخال غير مقنَّع وتستلزم موافقة صريحة ودقيقة مستقلة عن موافقة التحليلات العامة. يعامل CCPA وCPRA المعالجة ذاتها باعتبارها بيعًا أو مشاركة ما لم يكن لدى الناشر عقد مزوّد الخدمة ذي الصلة مع Heap — وهو ما يعرضه Heap، لكن العقد لا يسري إلا عند تكوين التكامل لوضع مزوّد الخدمة.
ما يكتبه Heap قبل الموافقة — وما يجب قمعه
يثبّت البدء السريع القياسي المرفق مع لوحة تحكم Heap مقتطف التتبع مباشرةً في <head> الصفحة. يعمل ذلك كما هو موثّق وهو مصدر أكثر إخفاقات الامتثال شيوعًا في عمليات نشر Heap: يعمل المقتطف قبل تقديم لافتة الكوكيز، وتُكتب ملفات تعريف ارتباط _hp2_ في غضون ميلي ثوانٍ، ويبدأ تدفق الالتقاط التلقائي إلى heapanalytics.com بغض النظر عما يقرره المستخدم لاحقًا. كل جهة تنظيمية أوروبية أصدرت حكمًا بشأن هذا النمط قضت بالطريقة ذاتها: ملفات تعريف الارتباط المُعيَّنة قبل الموافقة غير قانونية، والناشر يتحمل المسؤولية.
لذلك يجب أن يمنع التكامل المتوافق مقتطف Heap من التحميل حتى تُمنح فئة الموافقة ذات الصلة. النمطان اللذان يعملان في الإنتاج هما حقن النص البرمجي المشروط — يُضاف المقتطف إلى DOM فقط بعد أن يُشير CMP إلى الموافقة — والتحميل المسبق للمقتطف مع heap.load(appId, { disableTextCapture: true, secureCookie: true, autocapture: false }) كـ bootstrap مؤجل ثم استدعاء heap.startAutoCapture() بمجرد تسجيل الموافقة. نمط الحقن المشروط أكثر نظافةً وهو الذي توصي به وثائق Heap الآن. نمط الـ bootstrap المؤجل هو الخيار الصحيح عندما يحتاج الناشر إلى مرجع عالمي مستقر لتخييط الهوية ولكن لا يمكنه السماح بتشغيل الالتقاط التلقائي قبل الموافقة.
ملفات تعريف الارتباط والتخزين التي يكتبها Heap
يكتب مقتطف Heap المعرّفات التالية عند التهيئة، وكلها غير أساسية وتستلزم موافقة: _hp2_id.{envId} بانتهاء صلاحية 14 شهرًا يحتوي على معرّف المستخدم، و_hp2_ses_id.{envId} بانتهاء صلاحية جلسة لمدة 30 دقيقة، و_hp2_props.{envId} لمعدل العينة ونشر الخصائص، و_hp2_loaded كعلامة تحميل. تضيف وحدة إعادة تشغيل الجلسة المتكاملة مع Contentsquare مخزنًا مؤقتًا للتسجيل في الذاكرة يتدفق إلى نقطة نهاية Heap كل بضع ثوانٍ وقد تستمر في تخزين معرّف جلسة إعادة تشغيل صغير بشكل منفصل. لذلك يجب أن يؤدي سحب الموافقة إلى انتهاء صلاحية ملفات تعريف ارتباط _hp2_ وإرسال طلب حذف عبر GDPR API الخاص بـ Heap لتسجيلات المستخدم السابقة وتدفق الأحداث.
ربط Heap بأطر الموافقة
لا ينفّذ Heap IAB TCF أو IAB Global Privacy Platform بصورة أصلية — فهو منصة تحليلات منتج طرف أول، وليس بائعًا للتقنيات الإعلانية — لكنه يتكامل مع Google Consent Mode v2 من خلال التجسير من جانب الناشر، ويكشف عن API أصلية للاشتراك وإلغاء الاشتراك، ويدعم طبقة تنقيح للخصائص الحساسة تعمل بصرف النظر عن حالة الموافقة. النمط الذي ينجو من مراجعة جهة تنظيمية يعامل كل وحدة من وحدات Heap كبوابة منفصلة مرتبطة بإشارة CMP محددة.
- يرتبط الالتقاط التلقائي وتدفق الأحداث الأساسي بغرض التحليلات. من حيث TCF، يكون هذا في الغالب الغرض 8 (قياس أداء المحتوى) مقترنًا بالغرض 1 (تخزين المعلومات و/أو الوصول إليها). بالنسبة لـ Consent Mode، يتوافق هذا مع analytics_storage.
- تقع إعادة تشغيل الجلسة عبر تكامل Contentsquare وراء بوابة منفصلة أكثر صرامة لأن إعادة التشغيل تلتقط DOM المُقدَّم وأي حقل إدخال غير مقنَّع، وإرشادات EDPB لإعادة تشغيل الجلسة تعامله كفئة تستلزم موافقة صريحة ودقيقة مستقلة عن التحليلات العامة.
- يمكن تشغيل تحديد هوية المستخدم عبر heap.identify() بمعرّف جلسة مؤقت بموجب أساس المصلحة المشروعة عندما يكون المستخدم مجهولاً، لكن ربط التعريف بمعرّف طرف أول ثابت عبر الجلسات يستلزم موافقة مماثلة للتحليلات لأن ذلك هو الوقت الذي يصبح فيه المعرّف نقطة بيانات على مستوى المستخدم قابلة للتتبع.
- يستلزم نشر هوية عبر المواقع أو المنتجات عبر identity API بوابة التسويق لأنه يتخطى الخط الفاصل من تحليلات المنتج إلى نسب التسويق على مستوى المستخدم.
نمط التكامل الذي يعمل
يتكون النشر المرجعي من أربعة أجزاء: CMP يكشف عن حدث تغيير الموافقة في الوقت الفعلي، وbootstrap مؤجل يحمّل Heap مع تعطيل الالتقاط التلقائي، ومستمع للموافقة يقلّب الالتقاط التلقائي ويبدأ مخزن إعادة تشغيل الجلسة المؤقت عند فتح البوابات ذات الصلة، ومسار سحب يستدعي heap.resetIdentity()، ويوقف الالتقاط التلقائي، وينهي صلاحية ملفات تعريف ارتباط _hp2_، ويرسل طلب الحذف عبر نقطة نهاية GDPR الخاصة بـ Heap.
التنفيذ على الويب
على الويب، يكمن النمط الأنظف في تحميل مقتطف Heap بشكل مشروط — يُحقن تاغ <script> فقط بعد منح فئة التحليلات. اشترك في حدث تغيير موافقة CMP. عندما تنتقل فئة التحليلات إلى true، احقن مقتطف Heap مع secureCookie: true وdisableTextCapture: false للالتقاط التلقائي الكامل وأي تكوين خاص بالبيئة. عندما تنتقل موافقة إعادة تشغيل الجلسة إلى true ويكون تكامل Contentsquare ممكّنًا، يتنشّط مخزن إعادة التشغيل المؤقت تلقائيًا. عند سحب أي بوابة، استدعِ heap.resetIdentity() متبوعًا بإزالة عنصر نص Heap البرمجي، وأنهِ صلاحية ملفات تعريف ارتباط _hp2_ عبر document.cookie، واستدعِ GDPR-deletion API لمعرّف المستخدم.
تنقيح الخصائص الحساسة
يأتي Heap مزوّدًا بطبقة تنقيح تعمل بصرف النظر عن حالة الموافقة ويجب على الناشرين استخدامها حتى عند منح الموافقة. يقمع سمة data-heap-redact-text على حقل نموذج المحتوى النصي الملتقط؛ وتقمع سمة data-heap-redact-attributes سمات العنصر. بموجب قواعد الفئة الخاصة في GDPR وتعريف المعلومات الشخصية الحساسة في CCPA، يجب أن يستخدم أي حقل يمكنه التقاط المعلومات الصحية أو التفاصيل المالية أو المعرّفات الحكومية أو البيانات البيومترية أو الموقع الجغرافي الدقيق أو محتويات الاتصالات الخاصة سمات التنقيح بصرف النظر عن حالة موافقة المستخدم. تعيين السمات على مستوى النموذج هو النمط الأكثر أمانًا — فهو يقمع النموذج بأكمله حتى عندما يضيف مطوّر حقلاً جديدًا ينسى تمييزه بشكل فردي.
اختيار المنطقة: إقامة البيانات في الاتحاد الأوروبي مقابل الولايات المتحدة
يشغّل Heap نقاط نهاية استيعاب منفصلة لأوروبا والولايات المتحدة. لحركة مرور EEA والمملكة المتحدة، تُعدّ نقطة نهاية الاتحاد الأوروبي الإعداد الافتراضي الصحيح؛ إذ تبقي الاستيعاب والمعالجة والتخزين داخل EEA وتقلل من تعرّض Schrems II الذي يحمله أي نشر لتحليلات في منطقة الولايات المتحدة. يتم تعيين نقطة النهاية عبر تكوين المقتطف ولا يمكن تغييرها بأثر رجعي — تبقى البيانات الموجودة في المكان الذي تم استيعابها فيه أولاً. لذلك يستحق الناشرون الذين يخططون لنشر Heap تأكيد المنطقة قبل التوسع، وتوثيق الاختيار في إشعار الخصوصية حتى تكون سلسلة الأساس القانوني نظيفة من الجمع وحتى التخزين.
التحقق من التكامل ومسار التدقيق
خطوة التحقق هي ما تفحصه جهات التنظيم وما يتجاهله الناشرون في أغلب الأحيان. يجب أن يجتاز نشر Heap المتكامل بشكل صحيح أربعة اختبارات بالتسلسل. أولاً، يجب أن تُنتج جلسة متصفح نظيفة مع عرض اللافتة ولكن دون اتخاذ أي اختيار صفرًا من الطلبات إلى heapanalytics.com باستثناء جلب ملف SDK وصفرًا من ملفات تعريف ارتباط _hp2_ في document.cookie. ثانيًا، يجب أن يحافظ رفض التحليلات على تلك الحالة — لا التقاط تلقائي ولا معرّف ولا تسجيل. ثالثًا، يجب أن يُنتج قبول التحليلات ملف تعريف ارتباط _hp2_id المتوقع بسمات SameSite الصحيحة وحركة أحداث تتدفق إلى نقطة نهاية المنطقة المكوَّنة. رابعًا، يجب أن يوقف سحب الموافقة فورًا مزيدًا من الالتقاط التلقائي وإعادة التشغيل، وينهي صلاحية ملفات تعريف ارتباط _hp2_، ويُشغّل طلب حذف عبر GDPR API الخاص بـ Heap.
توقّع مسار التدقيق بموجب إرشادات لافتة الكوكيز الصادرة عن EDPB لعام 2023 وأولويات فريق العمل المجدَّدة لعام 2026 هو أن يتمكن الناشر من إثبات، لأي حدث معين في مشروع Heap، أن المستخدم الذي أنشأه كان قد أعطى موافقة صالحة في لحظة الالتقاط. النمط القياسي هو تعيين إصدار الموافقة والطابع الزمني كخصائص مستخدم على المعرّف المميز عبر heap.addUserProperties({ consent_version: 'v3', consent_ts: ts }) بحيث يكون بالإمكان تتبع أي حدث فردي حتى إدخال سجل موافقة محدد. إن النشر المُقيَّد بشكل صحيح، مقترنًا بسمات التنقيح التي تقمع الحقول الحساسة بشكل افتراضي ومسار حذف يُنشَّط عند السحب، هو ما يحوّل نموذج الالتقاط التلقائي من Heap من مخاطرة تنظيمية مركّزة إلى أحد أقوى أجزاء حزمة تحليلات المنتج لدى الناشر وأكثرها قابلية للدفاع.