انتهاء الموافقة وإعادة الطلب: قائمة تحقق لمعرفة متى تسأل الزوار مرة أخرى
الموافقة ليست أبدية
بمجرد أن يختار الزائر، ينبغي أن تتذكر اختياره كي لا تزعجه في كل صفحة. لكن الاختيار المخزَّن لا يدوم إلى أجل غير مسمى. فالظروف تتغير، وتُضاف الأدوات، وقد لا يعكس قرار اتُّخذ منذ زمن طويل ما كان الزائر سيختاره اليوم. تساعدك قائمة التحقق هذه على وضع قواعد معقولة للانتهاء وإعادة الطلب.
ما الذي تقوله القواعد (وما الذي لا تقوله)
لا يحدد GDPR تاريخ انتهاء ثابتًا للموافقة. وتملأ إرشادات الجهات التنظيمية هذا الفراغ عمليًا. فمثلًا توصي الهيئة الفرنسية CNIL بالاحتفاظ باختيار الزائر نحو ستة أشهر قبل السؤال مجددًا، وتقول إن عمر ملفات ارتباط التتبع نفسها يجب ألا يتجاوز 13 شهرًا. أما الجهات الأخرى فلم تحدد أرقامًا دقيقة. راجع الجهة المعنية بجمهورك ووثّق المدة التي تختارها.
قائمة التحقق 1: حدّد المدة الافتراضية
- اختر مدة للموافقة ودوّنها. تتراوح المدة الشائعة بين ستة واثني عشر شهرًا؛ واختر الطرف الأقصر حيث توصي به جهتك التنظيمية.
- خزّن تاريخ اتخاذ الاختيار، لا الاختيار وحده.
- طبّق منطق المدة نفسه على ملف الارتباط أو عنصر التخزين الذي يحمل سجل الموافقة.
- تأكد من أن الاختيار المخزَّن ينتهي على جانب الخادم أو في منطقك البرمجي، لا في المتصفح فقط.
قائمة التحقق 2: عرّف محفّزات إعادة الطلب
اسأل الزائر مجددًا، بغض النظر عن عمر الاختيار المخزَّن، عندما:
- تضيف غرضًا جديدًا. فاستخدام جديد للبيانات لم يغطّه الاختيار السابق قط.
- تضيف مزوّدًا أو شريكًا جديدًا يعالج البيانات بطريقة لم يُفصح عنها سابقًا.
- تتغير سياسة الخصوصية أو ملفات الارتباط لديك تغيرًا جوهريًا.
- يتغير إصدار البانر بشكل يغيّر الخيارات المعروضة.
- يكون الاختيار المخزَّن مفقودًا أو تالفًا أو غير مقروء.
اربط ذلك بـرقم إصدار للموافقة تزيده كلما حدث أي مما سبق. فالاختيار المخزَّن بإصدار أقدم يُظهر البانر.
قائمة التحقق 3: احمِ تجربة الزائر
- لا تعِد الطلب بمؤقّت داخل الجلسة الواحدة.
- لا تسأل زائرًا رفض مجددًا لمجرد إنهاكه؛ احترم الرفض طوال المدة كاملة ما لم يقع محفّز حقيقي.
- أبقِ رابطًا دائمًا في التذييل ليتمكن الزوار من تغيير رأيهم في أي وقت دون انتظار الانتهاء.
- اجعل سحب الموافقة سهلًا بقدر منحها.
قائمة التحقق 4: تعامل مع الحالات الحدّية
- ملفات الارتباط التي مُسحت. سيظهر البانر من جديد. هذا متوقع؛ لا تحاول الالتفاف عليه ببصمة الجهاز.
- نطاقات أو نطاقات فرعية متعددة. قرر ما إذا كان الاختيار مشتركًا بينها واجعل السلوك متسقًا.
- التطبيقات. خزّن الاختيار وتاريخه في تخزين التطبيق، واسأل مجددًا بعد تحديثات SDK التي تضيف استخدامات جديدة للبيانات.
- تغيّر المنطقة. إذا انتقل الزائر إلى ولاية قضائية مختلفة، فتحقق مما إذا كان ينبغي أن تُطبَّق قواعدك بشكل مختلف.
قائمة التحقق 5: احتفظ بالأدلة
- سجّل الطابع الزمني وإصدار البانر والاختيار لكل موافقة.
- احتفظ بسجل تغييرات يوضح متى غيّرت المدة أو رقم الإصدار ولماذا.
- راجع الإعدادات كل ربع سنة إلى جانب جرد ملفات الارتباط.
أين يندرج FlexyConsent
FlexyConsent معتمد من IAB Europe وIAB Canada، ويدعم IAB TCF 2.4 وGoogle Consent Mode v2، ويغطي مناطق منها الاتحاد الأوروبي والمنطقة الاقتصادية الأوروبية والمملكة المتحدة وولايات أمريكية وكندا وكيبك. أيًّا كانت المنصة التي تستخدمها، تحقق من كيفية تخزينها للاختيار وما الذي يطلق مطالبة جديدة، وقارن ذلك بالقواعد التي دوّنتها أعلاه.
أهم النقاط
- ينبغي أن تنتهي صلاحية الموافقة؛ لا يوجد رقم قانوني واحد، فاختر مدة ودوّنها وراجع إرشادات جهتك التنظيمية.
- أعد الطلب عند تغيّر الأغراض أو المزوّدين أو السياسات أو خيارات البانر، باستخدام رقم إصدار للموافقة.
- لا تُلحّ على الزوار الذين رفضوا دون محفّز حقيقي.
- أبقِ وسيلة متاحة دائمًا لتغيير الموافقة أو سحبها.
- سجّل الطابع الزمني والإصدار والاختيار، وراجع القواعد كل ربع سنة.