Privacy Statnive Live · Parhum Khoshbakht

راهنمای عملی آنالیتیکس بدون رضایت در اتحادیه اروپا — 2026

راهنمای عملی برای اجرای آنالیتیکس بدون بنر کوکی در سراسر اتحادیه اروپا در 2026 — اینکه هر نهاد ناظر واقعاً چه چیزی را الزامی می‌کند و چطور باید برای آن پیکربندی کنید.

این پژوهشی در حوزه‌ی حریم خصوصی است، نه مشاوره‌ی حقوقی. برای متن کامل سلب مسئولیت، پاورقی را ببینید.

خلاصه

  • اجرای آنالیتیکس بدون بنر در 2026 شدنی است — ذیل Sheet 16 نهاد CNIL فرانسه، دستورالعمل‌های 2021 نهاد Garante ایتالیا، راهنمای AEPD اسپانیا و موضع AP هلند، و همچنین سخت‌گیرانه‌ترین مبنای فعلی (مادهٔ § 25 TDDDG آلمان).
  • برای آلمان پیکربندی کنید؛ بقیه‌ی اتحادیه اروپا روی همان سوار می‌شود. معماری بدون‌کوکی و سمت‌سرور که مادهٔ § 25 TDDDG را برآورده می‌کند، استثنای اندازه‌گیری مخاطبِ هر کشور عضو دیگر را هم به‌طور خودکار برآورده می‌کند.
  • GA4 در هر کشور عضوی که چنین استثنایی دارد، از آن بازمی‌ماند. انتقال برون‌مرزی، تجمیعِ داده میانِ مشتریانِ مختلف، شناسهٔ ماندگار و ناشرِ غیرواحد، همگی آن را رد صلاحیت می‌کنند.
  • مادهٔ 88a(3)(c) از Digital Omnibus این استثنا را در کل اتحادیه اروپا یکدست می‌کند — اما فعلاً فقط پیشنهاد کمیسیون است، نه قانون؛ و نظر مشترک EDPB-EDPS شماره‌ی 2/2026 (مورخ 11 فوریه 2026) درباره‌ی بسته‌ی گسترده‌تر نگرانی‌های جدی مطرح کرد.
  • برای هر دو سناریو معماری بچینید. یک استقرارِ اول‌شخصِ بدون‌کوکی هم وضعیتِ چهل‌تکه‌ی امروز را پاسخ می‌دهد و هم اگر مادهٔ 88a دست‌نخورده تصویب شود، از روز نخست واجد شرایط است.

چرا یک راهنمای عملی، و چرا حالا

سهمِ رو به رشدی از گردانندگانِ اروپایی هم‌زمان به یک نتیجه می‌رسند: بنر کوکی مالیاتی است بر اندازه‌گیری، و همان اندازه‌گیری‌ای هم که از این مالیات عبور می‌کند روزبه‌روز نامطمئن‌تر می‌شود. مطالعهٔ بنر کوکیِ Plausible این مالیاتِ از‌دست‌رفتنِ دید را حدود 55.6% برآورد می‌کند — بازدیدکنندگانی که وارد سایت شدند، بنر را رد کردند و از آنالیتیکس بیرون افتادند. دو جریمهٔ همتای CNIL در 1 سپتامبر 2025 — 325 میلیون یورو علیه Google و 150 میلیون یورو علیه Shein، هر دو بابتِ تجربهٔ کاربریِ رضایتِ کوکی و نه زنجیرهٔ تبلیغاتِ پایین‌دست — خودِ بنر را به مسئولیتِ قانونی بدل کردند، نه فقط کوکی‌های پشتِ آن را.

یک مسیرِ قانونی برای اجرای آنالیتیکس بدون بنر در بیشترِ اتحادیه اروپا وجود دارد. این مسیر از زمانِ اصلاحِ دستورالعملِ ePrivacy در 2009 برقرار بوده است. CNIL فرانسه یک دهه صرفِ پالایشِ آن کرده؛ Garante ایتالیا و AEPD اسپانیا نسخه‌های خودشان را ساخته‌اند؛ و پیشنهادِ Digital Omnibus کمیسیون در 19 نوامبر 2025 در صورتِ تصویب، آن را در هر 27 کشور عضو یکدست می‌کند. آلمان همچنان استثنای سخت‌گیر است و سقفِ آنچه را شدنی است تعیین می‌کند.

این یک راهنمای عملی است. اینکه «بدون رضایت» در 2026 واقعاً یعنی چه، هر نهاد ناظر کجا می‌ایستد، چه چیزی تقریباً هر پیکربندیِ Google Analytics 4 را رد صلاحیت می‌کند، چه چیزی گرداننده را معاف نگه می‌دارد، چرا اندازه‌گیریِ «ناشناس» آن چیزی نیست که به نظر می‌رسد، و آن پیکربندی‌ای که Statnive Live را بر اساسش ساختیم تا بیشترِ کار، خودش در همان نرم‌افزار انجام شده باشد.

«بدون رضایت» واقعاً یعنی چه

دو لایه از قانونِ اتحادیه اروپا بر آنالیتیکس حاکم‌اند و هر دو هم‌زمان اعمال می‌شوند. نقضِ هرکدام به‌تنهایی کافی است تا رضایت لازم شود.

لایهٔ 1 — مادهٔ 5(3) دستورالعملِ ePrivacy یعنی 2002/58/EC. رضایت پیش از ذخیره‌سازی روی تجهیزاتِ پایانهٔ کاربر یا دسترسی به اطلاعاتِ از‌پیش‌ذخیره‌شده روی آن لازم است — مگر جایی که برای انتقالِ یک ارتباط کاملاً ضروری باشد، یا برای ارائهٔ خدمتی که کاربر صراحتاً درخواست کرده. راهنماهای 2/2023 نسخهٔ 2.0 نهاد EDPB، مصوبِ 7 اکتبر 2024، این را صراحتاً فراتر از کوکی‌ها بسط داد — ردیابیِ پیکسلی، ردیابی از طریقِ URL، اثرِ انگشتِ روی دستگاه، دادهٔ تولیدشده روی دستگاه که از طریقِ API خوانده می‌شود، شناسه‌های هش‌شده روی سمتِ کاربر، گزارش‌دهیِ IoT و ردیابیِ صرفاً مبتنی بر IP در جایی که گرداننده به دستگاه دستور می‌دهد اطلاعات بفرستد، همگی در دامنهٔ آن قرار می‌گیرند. هر چیزی که از دستگاهِ بازدیدکننده می‌خوانَد یا روی آن می‌نویسد مادهٔ 5(3) را فعال می‌کند.

لایهٔ 2 — GDPR. هر پردازشِ بعدیِ دادهٔ شخصی به یک مبنای قانونیِ مادهٔ 6 نیاز دارد. برای آنالیتیکس یعنی رضایتِ مادهٔ 6(1)(a)، قراردادِ مادهٔ 6(1)(b)، یا منافعِ مشروعِ مادهٔ 6(1)(f). گزینهٔ (f) به یک ارزیابیِ مستندِ منافعِ مشروع ذیلِ راهنماهای 1/2024 نهاد EDPB مورخِ 8 اکتبر 2024 نیاز دارد — شناساییِ منفعت ← ضرورت ← آزمونِ توازن در برابرِ حقوق و انتظاراتِ معقولِ صاحبِ داده.

این دو لایه روی هم سوار می‌شوند، جایگزینِ هم نمی‌شوند. طبقِ نظرِ 5/2019 نهاد EDPB و آن‌گونه که راهنمای نهاییِ آوریلِ 2026 نهاد ICO بریتانیا دربارهٔ فناوری‌های ذخیره و دسترسی دوباره تأیید کرده، مادهٔ 5(3) ePrivacy نسبت به GDPR برای هر ذخیره یا دسترسیِ روی تجهیزاتِ پایانه، قانونِ خاص (lex specialis) است. منافعِ مشروعِ مادهٔ 6(1)(f) GDPR نمی‌تواند جایگزینِ رضایتِ مادهٔ 5(3) ePrivacy شود. Garante ایتالیا حتی فراتر می‌رود و منافعِ مشروع را به‌عنوان مبنایی برای کوکی‌ها و سازوکارهای ردیابی صراحتاً ممنوع می‌کند.

دقیقاً دو مسیر برای آنالیتیکسِ بدون رضایت وجود دارد که هر دو لایه را برآورده می‌کند:

  • مسیرِ 1: اصلاً مادهٔ 5(3) را فعال نکنید. بدون کوکی، بدون localStorage، بدون کاوشِ اثرِ انگشت، بدون خواندنِ شناسه از سمتِ کاربر. مرورگر فقط همان چیزی را می‌فرستد که به‌طور پیش‌فرض می‌فرستد (IP، User-Agent، Referer)؛ سرور آن‌ها را هنگامِ دریافت می‌خواند، آنالیتیکسِ خود را محاسبه می‌کند و چیزی روی دستگاه بازنمی‌نویسد. این تنها مسیرِ بدون رضایتی است که در آلمان ذیلِ مادهٔ § 25 TDDDG در دسترس است، و همان مبنای سخت‌گیرانه‌ای است که این راهنما فرض می‌کند.
  • مسیرِ 2: ذیلِ یک استثنای ملیِ اندازه‌گیری مخاطب قرار بگیرید. Sheet 16 نهاد CNIL فرانسه، دستورالعمل‌های کوکیِ 10 ژوئن 2021 نهاد Garante ایتالیا، راهنمای AEPD اسپانیا دربارهٔ کوکی‌های اندازه‌گیری مخاطب، و موضعِ AP هلند دربارهٔ کوکی‌های تحلیلی، همگی کوکی‌های اول‌شخصِ به‌دقت‌پیکربندی‌شده را برای اندازه‌گیری مخاطب بدون رضایت ذیلِ مقرراتِ ملیِ ePrivacy خود مجاز می‌دانند. هر استثنا شرایطِ خودش را دارد. هیچ‌کدام در آلمان به رسمیت شناخته نمی‌شوند.

طراحیِ پایدار، مسیرِ 1 به‌صورتِ پیش‌فرض و مسیرِ 2 فقط زمانی است که گرداننده مستند کرده باشد یک استثنای ملیِ مشخص را برآورده می‌کند. Statnive Live مسیرِ 1 را در حالتِ consent-free خود عرضه می‌کند و یک فهرستِ حوزه‌های قضایی (enum) در اختیار می‌گذارد تا گردانندگانِ کشورهای دارای Sheet 16 بتوانند مسیرِ 2 را روی آن سوار کنند.

نقشهٔ 2026، در یک نگاه

اینکه هر نهاد ناظرِ بزرگِ اتحادیه اروپا و منطقه اقتصادی اروپا دربارهٔ آنالیتیکسِ بدون رضایت کجا می‌ایستد، تا مه 2026.

حوزهٔ قضاییاستثنای اندازه‌گیری مخاطبیادداشت‌ها
فرانسه (CNIL)بله — Sheet n°16 + خودارزیابیِ 4 ژوئیه 2025سهل‌گیرترین در اتحادیه اروپا. مهلتِ انطباق 1 ژانویه 2026. شرایطِ سخت‌گیرانه: تک‌سایت، حداکثر 3 نوع رویداد، حذفِ آخرین اوکتتِ IP، عمرِ 13 ماههٔ ردیاب، نگهداریِ 25 ماههٔ داده. بررسیِ عمیقِ CNIL را ببینید.
آلمان (DSK)خیرمادهٔ § 25 TDDDG منافعِ مشروع را به‌عنوان مبنایی برای ذخیره/دسترسی می‌بندد. معماریِ بدون رضایت باید پردازشِ کاملاً سمت‌سرور باشد. بررسیِ عمیقِ TDDDG را ببینید.
ایتالیا (Garante)بله — دستورالعمل‌های کوکیِ 10 ژوئن 2021 (لازم‌الاجرا از 10 ژانویه 2022)شرایط: عدمِ شناساییِ مستقیم، کوکی‌های با IP پوشانده‌شده، آمارِ تک‌سایت، بدون انتقال به شخصِ ثالث. منافعِ مشروع برای کوکی‌ها صراحتاً ممنوع است.
اسپانیا (AEPD)بله — راهنمای اندازه‌گیری مخاطب (2024)شرایط با CNIL هم‌راستاست. مادهٔ 22.2 LSSI + LOPD-GDD.
هلند (AP)بله — "Analytical cookies … do not require consent if they are used solely for counting visitors"مادهٔ 11.7a قانونِ Telecommunicatiewet. AP سالانه 500 سایت را برای انطباق پایش می‌کند.
بلژیک (APD)خیر"Audience measuring cookies are not exempt from the consent requirement under the current legal framework."
ایرلند (DPC)استثنای منتشرشده‌ای نداردبا راهنماهای 5/2020 نهاد EDPB هم‌راستاست.
بریتانیا (ICO)خیر — اما اولویتِ اجراییِ پایینراهنمای فناوری‌های ذخیره و دسترسیِ ICO در آوریل 2026: "Analytics cookies do not fall within the 'strictly necessary' exemption." اولویتِ پایین برای آنالیتیکسِ اول‌شخص و کم‌تهاجم پذیرفته شده، اما در قانون تثبیت نشده است.
اتریش (DSB)استثنای مستقلی نداردتصمیمِ NetDoktor در 22 دسامبر 2021 انتقالِ GA از اتحادیه اروپا به آمریکا را بر مبنای Schrems-II غیرقانونی دانست.

نقشهٔ مرجعِ کشور‌به‌کشور، بقیهٔ حوزه‌های قضاییِ اتحادیه اروپا و منطقه اقتصادی اروپا و نیز پرسش‌های مربوط به سطل‌های OTHER-EU و OTHER-NON-EU گرداننده را پوشش می‌دهد.

اثرِ عملیِ این نقشه: گرداننده‌ای که برای آلمان — سخت‌گیرانه‌ترین خانه — پیکربندی می‌کند، برای همه‌جای دیگرِ اتحادیه اروپا هم پیکربندی شده است. گرداننده‌ای که برای Sheet 16 فرانسه پیکربندی می‌کند، فرانسه، ایتالیا، اسپانیا و هلند را به‌تمیزی پوشش می‌دهد، اما اگر هر بخشی از ترافیک آلمانی باشد، باز هم به معماریِ هم‌ترازِ آلمان نیاز دارد. برای آلمان پیکربندی کنید؛ بقیه روی همان سوار می‌شود.

هفت کارِ نکن که تقریباً هر پیکربندیِ GA4 را رد صلاحیت می‌کنند

این فهرستِ منفیِ گرداننده است. هر کدام از این‌ها، در هر حوزهٔ قضاییِ نقشهٔ بالا، یک استقرارِ آنالیتیکس را از قلمروِ بدون رضایت بیرون می‌اندازد و به «نیازمندِ بنری با دکمهٔ رد که به‌اندازهٔ دکمهٔ پذیرش آسان باشد» برمی‌گرداند.

1. بدون رضایت کوکیِ ردیابی نگذارید و روی localStorage ننویسید. کوکی‌های اندازه‌گیری مخاطب ذیلِ Sheet 16 فرانسه، راهنمای AEPD اسپانیا و دستورالعمل‌های 2021 نهاد Garante مجازند — اما فقط ذیلِ شرایطِ سخت‌گیرانهٔ استثنای ملی، نه به‌صورتِ پیش‌فرض. localStorage و sessionStorage همان فعال‌سازِ مادهٔ 5(3) را مثلِ کوکی‌ها دارند و هیچ‌جا استثنای اندازه‌گیری مخاطب ندارند.

2. از نمکِ ثابت یا تک‌نمک استفاده نکنید. هشِ یک IPv4 با نمکِ ثابت، مستعارسازی است نه ناشناس‌سازی — Garante ایتالیا دقیقاً همین را در تصمیمِ 9 ژوئن 2022 علیه Caffeina Media دربارهٔ قابلیتِ ناشناس‌سازیِ IP در Google گفت. فضای IPv4 تقریباً 4.3 میلیارد نشانی است؛ ساختنِ یک جدولِ رنگین‌کمانی از SHA-256(static_salt + IPv4) روی یک GPU بی‌زحمت است. نمکی که نمی‌چرخد، نمکی است که محافظت نمی‌کند.

3. IP خام یا رشتهٔ User-Agent خام را ذخیره نکنید. هر دو در عمل دادهٔ شخصی‌اند — رأیِ Breyer دیوانِ CJEU (C-582/14، 19 اکتبر 2016) این را برای IP پویا حل کرد. طبقِ خودارزیابیِ ژوئیهٔ 2025 نهاد CNIL، IPv4 تا /24 (و IPv6 تا /48 یا /64) کوتاه می‌شود و User-Agent پیش از هر ذخیره‌ای فقط به نسخه‌های اصلی کاهش می‌یابد («Chrome 126»، نه «Chrome/126.0.6478.127 Mobile Safari/537.36»).

4. از کتابخانه‌های اثرِ انگشتِ شخصِ ثالث استفاده نکنید. بومِ گرافیکی، بافتِ صوتی، پارامترهای WebGL، شمارشِ فونت‌ها، هم‌روندیِ سخت‌افزار — همهٔ این‌ها طبقِ راهنماهای 2/2023 نهاد EDPB در دامنهٔ مادهٔ 5(3) قرار دارند. FingerprintJS، ClientJS و SDKهای تجاریِ مختلفِ اثرِ انگشت، در هر حوزهٔ قضاییِ اتحادیه اروپا رضایت را لازم می‌کنند. مهارتِ بازبینیِ کدِ GDPR در Statnive آن‌ها را در ردیاب ممنوع می‌کند.

5. با CRMهای مشتری یا داده‌های دیگرِ سایت تطبیق ندهید. شرطِ Sheet 16 نهاد CNIL صریح است: "aucune mise en commun par le prestataire de données brutes de mesure d'audience provenant de plusieurs de ses clients n'est mise en œuvre." یعنی هیچ تجمیعِ داده میانِ مشتریانِ ارائه‌دهنده انجام نمی‌شود؛ هیچ پیوندی با مجموعه‌داده‌های داخلیِ دیگر که نیم‌رخ‌های میان‌زمینه‌ای بسازد، صورت نمی‌گیرد.

6. شناسه‌ها را میانِ سایت‌های مشتریان دوباره به کار نبرید. همان بازدیدکننده روی دو سایتِ متفاوت باید دو امضای بی‌ارتباط تولید کند. Sheet 16 نهاد CNIL: "Aucun identifiant permettant un suivi à travers plusieurs domaines n'est utilisé." به همین دلیل است که Fathom و Statnive هر دو از یک جزءِ نمکِ مختص‌سایت استفاده می‌کنند — همان فرد که از دو سایتِ متفاوت بازدید می‌کند، بنا به ساختار دو هشِ غیرقابلِ‌پیوند تولید می‌کند.

7. بدون پوششِ تأییدشدهٔ فصلِ پنجم، دادهٔ شخصی را به آمریکا یا دیگر کشورهای ثالث منتقل نکنید. تصمیم‌های 2022ِ DSB اتریش در پروندهٔ NetDoktor، CNIL فرانسه، Garante ایتالیا و نهاد ناظرِ دانمارک که Google Analytics را بر مبنای Schrems-II ممنوع کردند، با هیچ رأیِ 2024 تا 2026 وارونه نشده‌اند. چارچوبِ کنونیِ حریمِ خصوصیِ دادهٔ اتحادیه اروپا و آمریکا (DPF، لازم‌الاجرا از ژوئیهٔ 2023) پوششی موقت می‌دهد اما موضوعِ چالش‌های در جریانِ Latombe و چالش‌های موازیِ NOYB است. پاسخِ معماریاً پایدار، فقط‌-اتحادیه‌اروپا است.

GA4 دستِ‌کم در نقاطِ 1 (شناسهٔ ماندگار)، 5 (اکوسیستمِ میان‌مشتریِ Google)، 6 (شناسهٔ میان‌سایتی) و 7 (انتقالِ داده به آمریکا) رد می‌شود. نتیجه‌گیریِ CNIL در Sheet 16: «بیشترِ سرویس‌های بزرگِ اندازه‌گیری مخاطب، صرف‌نظر از پیکربندی‌شان، در دامنهٔ این استثنا قرار نمی‌گیرند.»

پنج کارِ بکن که شما را معاف نگه می‌دارد

این‌ها شرایطی هستند که — وقتی با هم اعمال شوند — به یک پشتهٔ آنالیتیکسِ اول‌شخص اجازه می‌دهند هم‌زمان واجدِ شرایطِ سخت‌گیرانه‌ترین رژیمِ فعلی (مادهٔ § 25 TDDDG) و سهل‌گیرترین استثنای ملی (Sheet 16 نهاد CNIL) شود. این‌ها همان معماری‌ای هستند که پیشنهادِ مادهٔ 88a(3)(c) از Digital Omnibus در صورتِ تصویبِ دست‌نخورده، در سراسرِ اتحادیه اروپا استانداردسازی می‌کند.

1. نمکِ مختص‌سایت با چرخشِ روزانه و نابودی. امضای بازدیدکنندگان این‌گونه ساخته می‌شود: BLAKE3-HMAC(master_secret, site_id || YYYY-MM-DD). نمک درون‌پردازشی محاسبه می‌شود، هرگز ذخیره نمی‌شود و نمکِ روزِ قبل هنگامِ چرخش نابود می‌شود. همان بازدیدکننده در دوشنبه و سه‌شنبه ← دو امضای متفاوت؛ بازشناسیِ میان‌روزی بنا به ساختار ناممکن است. همان بازدیدکننده روی دو سایتِ متفاوت ← دو امضای غیرقابلِ‌پیوند؛ بازشناسیِ میان‌سایتی بنا به ساختار ناممکن است. این همان ساختارِ Plausible است (hash(daily_salt + website_domain + ip_address + user_agent)) به‌علاوهٔ تضمینِ حذفِ نمک.

2. کوتاه‌سازیِ IP پیش از هر ذخیره. دست‌کم آخرین اوکتتِ IPv4 را حذف کنید (203.0.113.42 ← 203.0.113.0/24). برای IPv6 فقط پیشوندِ شبکه را نگه دارید — معمولاً /48 یا /64. IP خام مجاز است کوتاه‌مدتی در مسیرِ درخواست برای جست‌وجوی GeoIP وجود داشته باشد؛ اما باید پیش از آنکه نویسندهٔ دسته‌ای سطر را ببیند، دور ریخته شود. مکان‌یابی به سطحِ شهر/منطقه تنزل می‌یابد — همان سقفِ CNIL.

3. کمینه‌سازیِ User-Agent و ارجاع‌دهندهٔ فقط-میزبان. User-Agentها به دستگاه + نسخهٔ اصلیِ مرورگر + نسخهٔ اصلیِ سیستم‌عامل کاهش می‌یابند، در سمتِ سرور تجزیه می‌شوند و رشتهٔ خام دور ریخته می‌شود. ارجاع‌دهنده پیش از ذخیره فقط به میزبان کاهش می‌یابد (example.com، نه example.com/search?q=secret) — این کار PII تصادفی در رشته‌های پرس‌وجو را حذف می‌کند. هر دو شرطِ Sheet 16 نهاد CNIL‌اند و هر دو هنگامِ دریافت در سرورِ Statnive Live رخ می‌دهند.

4. بدون کوکی، بدون localStorage، بدون اثرِ انگشت. مادهٔ 5(3) ePrivacy فعال نمی‌شود چون هیچ ذخیره یا دسترسیِ روی تجهیزاتِ پایانه رخ نمی‌دهد. در DevTools مرورگرِ خود بررسی کنید (مسیرِ Application → Storage)؛ سهمیه‌ها صفر می‌مانند. هیچ کاوشِ بومِ گرافیکی، WebGL، شمارشِ فونت، بافتِ صوتی یا navigator.plugins هم در کار نیست — این‌ها همگی خواندن‌های سمتِ کاربرند که راهنماهای 2/2023 نهاد EDPB در دامنهٔ مادهٔ 5(3) قرار می‌دهد.

5. نگهداریِ محدود همراه با یک LIA مستند. سقف‌های 13 ماههٔ عمرِ ردیاب و 25 ماههٔ نگهداریِ دادهٔ CNIL، سخت‌گیرانه‌ترین میله‌های اروپاییِ فعلی‌اند. خروجی‌های تجمیعیِ داشبورد را به نزدیک‌ترین مضربِ 10 گرد کنید (یا یک تحلیلِ ناشناس‌بودن با استناد به نظرِ ناشناس‌سازیِ WP29/EDPB مستند کنید). یک ارزیابیِ منافعِ مشروع طبقِ راهنماهای 1/2024 نهاد EDPB نگه دارید — با مشارکتِ DPO، آزمونِ سه‌مرحله‌ای، که سالانه یا هنگامِ تغییرِ بنیادی به‌روز شود. برای استقرارهای پرحجم، در عمودِ حساس یا پرامکانات، یک DPIA طبقِ مادهٔ 35 GDPR.

این پنج نکته، خودِ معماری‌اند. به تصویبِ Digital Omnibus وابسته نیستند. سخت‌گیرانه‌ترین رژیمِ فعلیِ کشورهای عضو را تاب می‌آورند. و در یک پیکربندیِ واحد ترکیب می‌شوند که گرداننده مجبور نیست با تغییرِ رویهٔ قضایی، آن را عوض کند.

چرا «ناشناس» کافی نیست — تمایزِ مستعارسازی

گردانندگانی که زمانی صرفِ خواندنِ صفحه‌های بازاریابیِ فروشندگانِ آنالیتیکسِ خود کرده باشند، واژهٔ «ناشناس» را دیده‌اند که به هشِ IP و ردیابیِ بدون‌کوکی نسبت داده شده. این واژه باری حقوقی را به دوش می‌کشد که GDPR اجازه‌اش را نمی‌دهد.

پیش‌نویسِ راهنماهای 01/2025 نهاد EDPB دربارهٔ مستعارسازی — که در نشستِ صد‌ویکمِ عمومی در 16 ژانویه 2025 به‌عنوانِ پیش‌نویس تصویب شد، تا 28 فوریه 2025 برای مشاورهٔ عمومی باز بود و تا مه 2026 هنوز در دستِ تدوین است — روشن می‌کنند که دادهٔ مستعارشده، از جمله هشِ IP، شناسه‌های کوکی، امضاهای بازدیدکنندهٔ BLAKE3/HMAC و رشته‌های TC، تا وقتی بازشناسی از طریقِ ابزارهای در دسترسِ کنترل‌کننده یا هر شخصِ ثالثی به‌طورِ معقول محتمل باشد، همچنان دادهٔ شخصی باقی می‌ماند. رأیِ IAB Europe دیوانِ CJEU (C-604/22، 7 مارس 2024) این را فراتر از رشته‌های TC به هر شناسه‌ای که با یک IP جفت شود بسط داد.

در عمل:

  • یک سامانهٔ ردیابیِ بدون‌کوکی با نمکِ روزانه‌چرخان در طولِ روز مستعار است و فقط در گذرِ روزها ناشناس می‌شود — و آن هم فقط به این دلیل که نمکِ روزِ قبل نابود شده است.
  • یک هشِ IP با نمکِ ثابت به‌طورِ نامحدود مستعار است و برای هر کسی که یک GPU و فهرستی از IPهای نامزد داشته باشد، برگشت‌پذیر است.
  • یک مکان‌یابیِ «سطحِ شهر» که از کوتاه‌سازیِ /24 یک IP به دست آمده، طبقِ Breyer مستعار است — اما کوتاه‌سازی، بازشناس‌پذیرترین شناسه را از لایهٔ ذخیره‌سازی حذف می‌کند، که همان چیزی است که هم اصلِ کمینه‌سازیِ دادهٔ مادهٔ 5(1)(c) GDPR و هم شرطِ Sheet 16 نهاد CNIL لازم می‌دانند.

موضعِ پایدار: شناسه‌های هش‌شدهٔ بازدیدکننده را دادهٔ شخصیِ کم‌خطر تلقی کنید. مبنای منافعِ مشروعِ مادهٔ 6(1)(f) را بر پردازشِ آن‌ها اعمال کنید. LIA را مستند کنید. درخواست‌های دسترسیِ مادهٔ 15 و حذفِ مادهٔ 17 را از طریقِ یک نقطهٔ پایانیِ DSAR در برابرِ آن‌ها پاسخ دهید. آن‌ها را «ناشناس» بازاریابی نکنید. آن واژه برای داده‌ای است که بازشناسیِ آن برای هیچ‌کس و هرگز به‌طورِ معقول محتمل نباشد — و یک هشِ IP که با اختیاراتِ دسترسیِ قانونیِ یک دولت پاک می‌شود، این میله را برآورده نمی‌کند.

به همین دلیل هم هست که Garante ایتالیا قابلیتِ ناشناس‌سازیِ IP در Google را در تصمیمِ Caffeina Media ناکافی دانست: «این قابلیت، مستعارسازیِ نشانیِ IP است نه ناشناس‌سازی. … این قابلیت مانعِ آن نمی‌شود که Google LLC کاربر را دوباره شناسایی کند، با توجه به توانایی‌های Google در غنی‌سازیِ این داده از طریقِ اطلاعاتِ دیگری که در اختیار دارد.» این قابلیت دقیقاً همان کاری را می‌کرد که بازاریابی‌اش می‌گفت. فقط به معنای GDPR، ناشناس‌سازی نبود.

Statnive Live چگونه برای این کار ساخته شده است

Statnive Live در برابرِ همان کارِ بکن‌ها و کارِ نکن‌های بالا طراحی شده است. این معماری همان چیزی است که سرورِ مستقر در نورنبرگ روی Hetzner به‌طورِ پیش‌فرض اجرا می‌کند؛ همان نرم‌افزار روی زیرساختِ خودِ مشتری نیز قابلِ خودمیزبانی است، که در آن صورت اصلاً چیزی در Statnive پردازش نمی‌شود.

بدون‌کوکی بنا به ساختار. بدون کوکی، بدون localStorage، بدون sessionStorage. مادهٔ 5(3) ePrivacy فعال نمی‌شود چون هیچ ذخیره یا دسترسیِ روی تجهیزاتِ پایانه رخ نمی‌دهد. ردیاب یک اسکریپتِ اول‌شخصِ ~2.0 KB minified / ~0.9 KB gzipped است که از همان دامنهٔ سایتِ گرداننده سرو می‌شود — بدون CDN شخصِ ثالث، بدون مدیرِ تگِ شخصِ ثالث.

امضاهای بازدیدکنندهٔ BLAKE3-HMAC با چرخشِ روزانه. هش‌ها این‌گونه ساخته می‌شوند: HMAC(master_secret, site_id || YYYY-MM-DD). نمک درون‌پردازشی است؛ نمکِ روزِ قبل هنگامِ چرخش نابود می‌شود. این ساختار با رویکردِ Plausible / Fathom همخوان است و یک جزءِ سطحِ‌سایت اضافه می‌کند تا بازدیدکننده‌ای روی دو سایتِ ردیابی‌شده با Statnive، دو امضای غیرقابلِ‌پیوند تولید کند.

شناسهٔ کوکیِ هش‌شده هنگامِ ذخیره. وقتی گرداننده Statnive Live را در حالتِ consent-required یا hybrid و با رضایتِ داده‌شده اجرا می‌کند، شناسهٔ کوکیِ ارسالی به مرورگر یک UUID خام است؛ مقداری که در سمتِ سرور ذخیره می‌شود SHA-256(master_secret || site_id || cookieID) با پیشوندِ h: است. مرورگر UUID خام را می‌بیند؛ پایگاه‌داده هرگز آن را نمی‌بیند. پیوستگیِ میان‌روزیِ بازدیدکننده بدونِ ذخیرهٔ شناسهٔ خام حفظ می‌شود.

ارجاع‌دهندهٔ فقط-میزبان در سمتِ سرور. ردیاب کلِ document.referrer را نگه می‌دارد؛ هنگامِ دریافت، سرور آن را پیش از نوشتن به بخشِ میزبان کاهش می‌دهد. رشته‌های پرس‌وجو (که ممکن است عباراتِ جست‌وجو یا PII را حمل کنند) هرگز واردِ ذخیره‌سازیِ ماندگار نمی‌شوند.

IP خام پیش از ذخیره دور ریخته می‌شود. IP در مسیرِ درخواست برای جست‌وجوی GeoIP و اشتقاقِ هش وجود دارد؛ اما پیش از آنکه نویسندهٔ دسته‌ای سطر را ببیند، دور ریخته می‌شود. این موضوع با یک آزمونِ یکپارچگی در internal/enrich/geoip.go از مخزنِ Statnive Live راستی‌آزمایی شده است.

نگهداریِ 25 ماههٔ تجمیع‌ها. یک TTL برابرِ 750 روز روی تجمیع‌های AggregatingMergeTree نسخهٔ یک (hourly_visitors، daily_pages، daily_sources) اعمال می‌شود — 24.6 ماه، که با حاشیه‌ای امن با سقفِ CNIL همخوان است. پس از آن، تجمیع‌ها بدونِ دخالتِ گرداننده به‌طورِ خودکار منقضی می‌شوند.

چهار حالتِ رضایت، یازده حوزهٔ قضایی، اعتبارسنجیِ قاعدهٔ سخت. سیاستِ سایت یک enum برای حالتِ رضایت (permissive / consent-free / consent-required / hybrid) و یک enum برای حوزهٔ قضایی (DE / FR / IT / ES / NL / BE / IE / UK / OTHER-EU / IR / OTHER-NON-EU) دارد. یک اعتبارسنجِ قاعدهٔ سخت مانعِ آن می‌شود که گردانندگانِ آلمانی permissive را انتخاب کنند (مادهٔ § 25 TDDDG آن را ممنوع می‌کند) و نیز مانعِ انتخابِ consent-required بدونِ یک یکپارچه‌سازیِ فعالِ رضایت می‌شود. اعتبارسنج هنگامِ ذخیره در پنلِ مدیریت و دوباره هنگامِ بارگذاریِ سیاست در هر درخواستِ دریافت اجرا می‌شود. بررسیِ عمیقِ TDDDG، خانهٔ آلمان را به‌تفصیل پوشش می‌دهد.

GPC و DNT پیش از هش مدار را قطع می‌کنند. وقتی Sec-GPC: 1 یا DNT: 1 تنظیم شده باشد و سیاستِ سایت به این سیگنال‌ها احترام بگذارد، درخواست پیش از محاسبهٔ شناسهٔ بازدیدکننده رها می‌شود. برای بازدیدکننده‌ای که انصراف داده، هیچ شناسهٔ مستعاری ساخته نمی‌شود — چیزی برای حذف وجود ندارد چون چیزی ساخته نشده. پستِ GPC و حالتِ ترکیبی، طرحِ آزمونِ سرتاسری را گام‌به‌گام شرح می‌دهد.

نقاطِ پایانیِ DSAR از همان ابتدا. POST /api/privacy/opt-out، GET /api/privacy/access، POST /api/privacy/erase — محافظت‌شده در برابرِ CSRF، با محدودیتِ نرخ و با ثبتِ ممیزی. هشت رویدادِ ممیزیِ حریم خصوصی (privacy.opt_out_received، privacy.dsar_access_requested، privacy.dsar_erase_requested، privacy.consent_given، privacy.consent_withdrawn، legal.lia_viewed، legal.dpa_viewed، legal.privacy_policy_viewed) لاگ‌های ساخت‌یافته‌ای منتشر می‌کنند که برای یک ممیزیِ پاسخ‌گوییِ مادهٔ 28(3)(h) آماده‌اند. پستِ DSAR سطحِ یکپارچه‌سازی را پوشش می‌دهد.

مسیرهای افشای حقوقیِ عمومی، تعبیه‌شده در نرم‌افزار. /privacy، /legal/privacy-policy/en، /legal/privacy-policy/de، /legal/lia و /legal/dpa با همان نرم‌افزارِ Go سرو می‌شوند که ردیاب را سرو می‌کند — بدون وابستگی به CDN، امن در برابرِ قطعِ کاملِ شبکه (air-gap)، و در دسترسِ گردانندگانی که Statnive Live را در محیط‌های با خروجیِ محدود اجرا می‌کنند.

نتیجه، پیکربندی‌ای است که هم امروز میلهٔ سخت‌گیرانهٔ آلمان را برآورده می‌کند، هم با یک خودارزیابیِ مستند ذیلِ Sheet 16 فرانسه واجدِ شرایط می‌شود، و هم اگر Digital Omnibus دست‌نخورده تصویب شود، از روزِ نخست برای مادهٔ 88a(3)(c) پیشنهادی آماده است. گردانندگان مجبور به انتخاب نیستند؛ همان سیاستِ سایت ادامه می‌یابد.

آنچه در راه است — مادهٔ 88a(3)(c)

پیشنهادِ Digital Omnibus کمیسیون اروپا در 19 نوامبر 2025 — یعنی COM(2025) 837 final — یک مادهٔ 88a جدید در GDPR معرفی می‌کند با فهرستی بسته از مقاصدِ بدون‌رضایت. بندِ مرتبط برای آنالیتیکس، 88a(3)(c) است: «ساختنِ اطلاعاتِ تجمیعی دربارهٔ استفاده از یک خدمتِ آنلاین برای اندازه‌گیری مخاطبِ آن خدمت، در جایی که این کار با کنترل‌کنندهٔ همان خدمت و صرفاً برای استفادهٔ خودش انجام شود.»

وضعیت تا اواسطِ مه 2026: این پرونده گزارشگرِ ITRE به نامِ Aura Salla (از گروهِ EPP/فنلاند — انتصابش از سوی هفت سازمانِ مدنی به‌دلیلِ تعارضِ منافعِ لابیِ Meta مورد اعتراض است) و گزارشگرِ LIBE به نامِ Marina Kaljurand (از گروهِ S&D/استونی) را دارد؛ EESC نظرِ خود را در 18 مارس 2026 تصویب کرد؛ گروهِ کاریِ شورا در بحثِ فعال است (پروندهٔ WK 3736/2026 INIT). هنوز هیچ رأیِ صحنِ علنیِ پارلمانِ اروپا روی COM(2025) 837 وجود ندارد — رأیِ 26 مارس 2026 در صحنِ علنی روی پروندهٔ جداگانهٔ Digital Omnibus دربارهٔ هوش مصنوعی، پیشنهادی دیگر است. نظرِ مشترکِ EDPB-EDPS شماره‌ی 2/2026 مورخِ 11 فوریه 2026 نگرانی‌های جدی دربارهٔ اثرِ بسته‌ی گسترده‌تر بر حفاظت از افراد و قطعیتِ حقوقی مطرح کرد. تصویبِ واقع‌بینانه اواخرِ 2026 تا 2027 است؛ لازم‌الاجرا شدن احتمالاً 2027 تا 2028؛ و اعمالِ مادهٔ 88a شش ماه پس از لازم‌الاجرا شدن.

سه پیامد برای گردانندگان:

  • پیکربندیِ این راهنما با آینده سازگار است. اندازه‌گیریِ مخاطبِ اول‌شخص، تجمیعی و فقط‌-برای‌-استفاده‌ی‌-کنترل‌کننده، دقیقاً همان موردِ کاربری است که مادهٔ 88a(3)(c) توصیف می‌کند. گردانندگانی که کارِ بکن‌های بالا را پیاده می‌کنند، امروز ذیلِ استثناهای ملی (در جایی که وجود دارند) و فردا ذیلِ مادهٔ 88a سراسرِ اتحادیه اروپا (در صورتِ تصویبِ دست‌نخورده) واجدِ شرایط‌اند.
  • این پیشنهاد یک جابه‌جاییِ لایه است، نه افزودنی موازی. برای دسترسیِ تجهیزاتِ پایانه به دادهٔ شخصی، مادهٔ 88a GDPR حاکم می‌شود و مادهٔ 5(3) ePrivacy دیگر بر آن عملیات اعمال نمی‌شود. برای دسترسیِ تجهیزاتِ پایانه به دادهٔ غیرشخصی (یک باقیماندهٔ باریک‌تر)، مادهٔ 5(3) ePrivacy همچنان حاکم می‌ماند. این دو چارچوب به‌جای موازی، پیاپی کار می‌کنند. تمیزترین موضع همچنان «اصلاً هیچ ذخیره یا دسترسیِ روی تجهیزاتِ پایانه نباشد» است — که هر دو لایه را دور می‌زند.
  • متن یک نقشهٔ راه است، نه یک مبنای قانونیِ فعلی. گردانندگانی که فقط برای Digital Omnibus و نه برای قانونِ کنونیِ کشورهای عضو طراحی کنند، 12 تا 18 ماهِ آینده را در یک خلأ مقرراتی سپری خواهند کرد.

چطور این راهنما را مستقر کنیم

یک توالیِ عملیِ استقرار برای گرداننده‌ای که Statnive Live را برمی‌دارد (یا معماری را روی یک پشتهٔ خودمیزبان بازتولید می‌کند):

  1. سخت‌گیرانه‌ترین حوزهٔ قضاییِ خود را انتخاب کنید. اگر هر بخشی از ترافیک آلمانی است، برای DE / consent-free پیکربندی کنید. اعتبارسنجِ قاعدهٔ سخت این کار را برای شما انجام می‌دهد و پیکربندی‌های permissive را رد می‌کند.
  2. یک ارزیابیِ منافعِ مشروع منتشر کنید. قالبِ راهنماهای 1/2024 نهاد EDPB، ساختارِ مرجع است: شناساییِ منفعت ← ضرورت ← توازن. قالبِ LIA را دانلود کنید تا متنِ پیشنهادیِ Statnive Live را داشته باشید؛ و با مشورتِ حقوقی آن را با زمینهٔ پردازشِ خود تطبیق دهید.
  3. یک اطلاعیهٔ حریم خصوصی منتشر کنید. بندهای انگلیسی و آلمانی در Statnive Live در /legal/privacy-policy/en و /legal/privacy-policy/de تعبیه شده‌اند. بندِ آلمانی متنِ عینیِ § 25 Abs. 1 TDDDG را دربارهٔ نبودِ ذخیره یا دسترسیِ روی تجهیزاتِ پایانه حمل می‌کند؛ بندِ انگلیسی مبنای مادهٔ 6(1)(f) و الگوی گواهیِ Sheet 16 نهاد CNIL را پوشش می‌دهد.
  4. نقاطِ پایانیِ DSAR را وصل کنید. سه مسیر (/api/privacy/opt-out، /api/privacy/access، /api/privacy/erase) با نرم‌افزار عرضه می‌شوند. پستِ DSAR یکپارچه‌سازی را پوشش می‌دهد؛ سطحِ لاگِ ممیزی به‌طورِ پیش‌فرض وصل است.
  5. در حالتِ اتحادیه اروپا، GPC را به‌طورِ پیش‌فرض محترم بشمارید. روی هر سایتِ آلمانی، فرانسوی، ایتالیایی و هلندی consent.respect_gpc = true را تنظیم کنید. پستِ GPC لایه‌های قطعِ مدار در سمتِ کاربر و اعمال در سمتِ سرور را شرح می‌دهد.
  6. نقطهٔ پایانیِ ممیزیِ رویداد را ماهانه اجرا کنید. GET /api/admin/event-audit?site_id=N تعدادِ نام‌رویدادِ یکتای هر سایت را در برابرِ سقفِ سه‌رویدادیِ CNIL برمی‌گرداند. هدف، وضعیتِ ok است؛ هر over را فوری بررسی کنید.
  7. LIA را سالانه بازبینی کنید. EDPB بازبینیِ سالانه و در صورتِ تغییرِ بنیادی را توصیه می‌کند — مثلاً هنگامِ تصویبِ Digital Omnibus، هنگامِ یک ارجاعِ CJEU که وضعیتِ DPF را تحتِ تأثیر قرار دهد، یا هنگامِ انتشارِ راهنماییِ تازه از سوی یک نهاد ناظرِ ملی.

نقشهٔ مرجعِ کشور‌به‌کشور، جدولِ جست‌وجو برای جزئیاتِ هر حوزهٔ قضایی است. سه پستِ موجودِ حریم خصوصی — چرا آنالیتیکسِ حریم‌خصوصی‌محور در 2026 اهمیت دارد، آنالیتیکسِ وبِ منطبق با GDPR در 2026، و داده‌ی آنالیتیکسِ خود را در اختیار بگیرید: خودمیزبان در برابرِ SaaS خصوصیِ اروپایی در 2026 — چشم‌اندازِ گسترده‌تر و زاویهٔ کنترل‌کننده در برابرِ پردازنده را پوشش می‌دهند.

چه بکنید و از چه بگذرید — نقشهٔ فشرده

بخش‌های بالا فهرستِ کاملِ «هفت کارِ نکن» و «پنج کارِ بکن» را دارند. نسخهٔ فشرده، برای گردانندگانی که اول مرور می‌کنند:

بکنیدنکنید
برای سخت‌گیرانه‌ترین رژیمِ کشورهای عضو (مادهٔ § 25 TDDDG آلمان) پیکربندی کنید — بقیهٔ اتحادیه اروپا روی همان سوار می‌شود.برای هر کشور عضوی که ترافیک دارید جداگانه پیکربندی کنید — این مسیرِ رسیدن به 27 LIA متفاوت است که هرگز به‌روزشان نمی‌کنید.
از نمکِ مختص‌سایتِ روزانه‌چرخان استفاده کنید؛ نمکِ دیروز را در پایانِ روز نابود کنید.از نمکِ ثابت استفاده کنید — یک GPU و یک جدولِ رنگین‌کمانیِ IPv4 آن را برمی‌گرداند؛ Garante در پروندهٔ Caffeina Media همین را گفت.
IPv4 را تا /24 و IPv6 را تا /48 پیش از هر ذخیره کوتاه کنید؛ User-Agent را به نسخه‌های اصلی و Referer را به میزبان کاهش دهید.IP خام، User-Agent خام یا نشانیِ کاملِ ارجاع‌دهنده را ذخیره کنید — همگی دادهٔ شخصی‌اند؛ رشته‌های پرس‌وجوی خام PII را لو می‌دهند.
یک ارزیابیِ مستندِ منافعِ مشروع طبقِ راهنماهای 1/2024 نهاد EDPB و خودارزیابیِ مختصِ کشور منتشر کنید.ادعای «دارای گواهیِ CNIL» کنید یا از لوگوی CNIL استفاده کنید. CNIL برنامهٔ ارزیابیِ خود را در 1 ژانویه 2026 بازنشسته کرد — گردانندگان خودارزیابی می‌کنند.
در حالتِ اتحادیه اروپا، GPC و DNT را به‌طورِ پیش‌فرض محترم بشمارید؛ به حقِ اعتراضِ مادهٔ 21 با یک پیوندِ ماندگارِ انصراف احترام بگذارید.شناسه‌های هش‌شدهٔ بازدیدکننده را دادهٔ «ناشناس» تلقی کنید — این‌ها ذیلِ پیش‌نویسِ راهنماهای 01/2025 نهاد EDPB مستعارند و طبقِ Breyer دادهٔ شخصیِ تمام‌عیار.

حرفِ آخر

آنالیتیکسِ بدون رضایت در اتحادیه اروپا در 2026 شدنی است. اما نه به‌طورِ تصادفی، و نه با پیکربندیِ یک ابزارِ آنالیتیکسِ مستقر در آمریکا برای «ناشناس‌سازیِ» IPها. این کار با طراحیِ بیرون‌کشیدنِ فعال‌سازِ ذخیره/دسترسی از سامانه، اشتقاقِ امضاهایی که خودشان را نابود می‌کنند، کوتاه‌سازیِ دادهٔ شناسایی‌کننده هنگامِ دریافت، و مستندسازیِ مبنای منافعِ مشروع ذیلِ آزمونِ سه‌مرحله‌ای EDPB شدنی است. معماری، همان انطباق است؛ قرارداد، همان ردِ ممیزی.

برای آلمان پیکربندی کنید؛ برای همه‌جای دیگر هم پیکربندی شده‌اید. یک LIA اجرا کنید؛ مبنایی برای استناد دارید. به GPC احترام بگذارید؛ ذیلِ مادهٔ 88b پیشنهادی فرضِ انطباق دارید. نگهداریِ خود را به 25 ماه محدود کنید؛ بی‌زحمت درونِ سقفِ CNIL می‌نشینید. کوکی را به‌کلی کنار بگذارید؛ از همان مسئولیتِ مقرراتیِ تجربه‌ی کاربریِ بنرِ کوکی می‌گذرید که در سپتامبرِ 2025 برای CNIL، 475 میلیون یورو جریمه ساخت.

Statnive Live برای همین است. بدون‌کوکی. فقط‌-اتحادیه‌اروپا. نمک‌های روزانه‌چرخان. شناسهٔ کوکیِ هش‌شده هنگامِ ذخیره. ارجاع‌دهندهٔ فقط-میزبان. نگهداریِ 25 ماهه. چهار حالتِ رضایت، یازده حوزهٔ قضایی، اعتبارسنجیِ قاعدهٔ سخت. نقاطِ پایانیِ DSAR، قالبِ LIA، و قالب‌های سیاستِ حریم خصوصی و DPA درونِ نرم‌افزار، قابلِ دانلود بدونِ یک تماسِ فروش.

اگر این راهنما کمک کند یک تکه از پشتهٔ آنالیتیکسِ کنونیِ شما را محکم‌تر کنید، برای همین است. و اگر متقاعدتان کند که جابه‌جا شوید — statnive.com/live برای همین است. در هر حال، کارِ بکن‌ها و کارِ نکن‌های بالا همان معماریِ پایدارند؛ رویهٔ قضایی و پیشنهادها همچنان پیرامونشان جابه‌جا خواهند شد، و این راهنما طوری ساخته شده که گرداننده مجبور نباشد هر بار از نو معماری کند.

این پژوهشی در حوزه‌ی حریم خصوصی است، نه مشاوره‌ی حقوقی. پیکربندی‌های توصیف‌شده، هنگامی که طبقِ یک ارزیابیِ مستندِ منافعِ مشروع و خودارزیابیِ مختصِ هر کشور مستقر شوند، ذیلِ راهنماییِ نهادهای ناظر واجدِ شرایط‌اند. هر مشتریِ Statnive همچنان کنترل‌کنندهٔ داده باقی می‌ماند و مسئولِ پیکربندی و DPIA خودش است. پیش از انتشار، با مشاورِ حقوقیِ واجدِ صلاحیت در حوزهٔ قضاییِ خود مشورت کنید.

وضعیتِ ارجاعاتِ مقرراتی تا 13 مه 2026: Sheet 16 نهاد CNIL + به‌روزرسانیِ 4 ژوئیه 2025 (مهلتِ انطباقِ 1 ژانویه 2026 اکنون گذشته؛ برنامهٔ ارزیابیِ قدیمی بازنشسته شده؛ رژیمِ خودارزیابی عملیاتی است)؛ مادهٔ § 25 TDDDG (لازم‌الاجرا از 1 دسامبر 2021، تغییرِ نام در مه 2024)؛ دستورالعمل‌های کوکیِ Garante ایتالیا مورخِ 10 ژوئن 2021 (لازم‌الاجرا از 10 ژانویه 2022)؛ راهنمای کوکیِ AEPD (ژوئیه 2023، اجرا از 11 ژانویه 2024)؛ موضعِ AP هلند دربارهٔ کوکی‌های تحلیلی (مادهٔ 11.7a قانونِ Telecommunicatiewet)؛ راهنمای فناوری‌های ذخیره و دسترسیِ ICO بریتانیا (29 آوریل 2026)؛ راهنماهای 2/2023 نهاد EDPB نسخهٔ 2.0 (7 اکتبر 2024)؛ راهنماهای 1/2024 نهاد EDPB (8 اکتبر 2024)؛ پیش‌نویسِ راهنماهای 01/2025 نهاد EDPB دربارهٔ مستعارسازی (به‌عنوانِ پیش‌نویس در 16 ژانویه 2025 تصویب شد؛ مشاورهٔ عمومی تا 28 فوریه 2025؛ نسخهٔ نهایی تا مه 2026 هنوز منتشر نشده)؛ نظرِ مشترکِ EDPB-EDPS شماره‌ی 2/2026 مورخِ 11 فوریه 2026 دربارهٔ Digital Omnibus؛ Digital Omnibus یعنی COM(2025) 837 final (پیشنهادِ کمیسیون در 19 نوامبر 2025، بدونِ رأیِ صحنِ علنیِ پارلمانِ اروپا روی COM(2025) 837 تا 13 مه 2026)؛ رأیِ CJEU در C-582/14 Breyer (ECLI:EU:C:2016:779)؛ رأیِ CJEU در C-604/22 IAB Europe (7 مارس 2024)؛ رأیِ CJEU در C-621/22 KNLTB (ECLI:EU:C:2024:857)؛ رأیِ CJEU در C-446/21 Schrems v Meta (4 اکتبر 2024).

Get Statnive Free