Google تتراجع عن حظرها لبصمات الأجهزة: ما يحتاج المطورون لمعرفته

في فبراير 2025، حدَّثت Google بهدوء سياسات إعلاناتها للسماح ببصمات الأجهزة — التقنية نفسها التي أدانتها علناً بأنها "خاطئة" في 2019. دخل التغيير حيز التنفيذ في 16 فبراير 2025، وله تبعات مهمة لكل من يبني تحليلات، أو يُشغِّل موقعاً، أو يعتمد على بنية إعلانات Google التحتية.

ما هي البصمة فعلياً

بصمة الجهاز هي ممارسة الجمع بين عدة إشارات سلبية من متصفح أو جهاز لبناء مُعرِّف دائم. لا يُضبط كوكي. لا تُكتب مدخلة localStorage. لا يُطلب من المستخدم شيء. الإشارات المستخدمة تشمل:

• عنوان IP والبيانات الوصفية للشبكة
• نظام التشغيل وإصدار المتصفح
• دقة الشاشة وعمق الألوان
• الخطوط المُثبَّتة والترميزات المتاحة
• اللغة والمنطقة الزمنية وحالة البطارية

بشكل فردي، لا شيء من هذه مُعرِّف فريد. مجتمعة، تُنتج بصمة دقيقة بما يكفي لإعادة تحديد الجهاز نفسه عبر الجلسات، حتى بعد مسح الكوكيز وحتى في وضع التصفح الخاص. على عكس الكوكيز، لا توجد آلية للمستخدم لحذف بصمة.

ما قالته سياسة Google — وما تغيَّر

كان موقف Google في 2019 صريحاً: البصمات "تُقوِّض اختيار المستخدم وهي خاطئة" لأنها تعمل خارج عناصر التحكم القياسية بخصوصية المتصفح. حظرت السياسة على المعلنين استخدام البصمات في منتجات إعلانات Google.

أزال تحديث فبراير 2026 ذلك الحظر. صياغة Google كانت إجرائية — وُصِف التحديث على أنه مراجعة سياسة روتينية — لكن الجوهر كان تراجعاً. يمكن للمعلنين الآن استخدام مُعرِّفات على مستوى الجهاز بما في ذلك عنوان IP، وحجم الشاشة، والمنطقة الزمنية، وحالة البطارية، وسلاسل User-Agent، لأغراض الاستهداف والقياس دون أي اشتراط للحصول على موافقة المستخدم أو الإفصاح عن الممارسة.

الرد التنظيمي

ردَّ مكتب مفوض المعلومات في المملكة المتحدة (ICO) فوراً. وصف ستيفن ألموند، المدير التنفيذي للمخاطر التنظيمية في ICO، الخطوة بأنها "غير مسؤولة" وأوضح الموقف التنظيمي: تخضع البصمات لاشتراطات الموافقة نفسها التي تخضع لها الكوكيز بموجب PECR (لوائح الخصوصية والاتصالات الإلكترونية).

تعليل ICO دقيق تقنياً. تُعرِّف PECR مُحفِّز الموافقة بأنه "تخزين معلومات، أو الوصول إلى معلومات مُخزَّنة، على جهاز". تصل البصمات إلى معلومات من الجهاز — تقرأ قيماً من بيئة المتصفح — مما يعني أن اشتراط الموافقة ينطبق بصرف النظر عما إذا كُتب ملف كوكي. آلية الوصول هي ما يهم، لا تنسيق الديمومة.

بموجب GDPR، أصحاب البيانات أنفسهم الذين يمكنهم طلب محو ملف تعريف معتمد على كوكي ليس لديهم آلية مماثلة لملف تعريف مُشتق من بصمة. لا يمكنك حذف بصمة من خادم لا تتحكم فيه. يُنشئ ذلك عدم تناظر تفحصه الجهات التنظيمية بنشاط في الاتحاد الأوروبي والمملكة المتحدة.

لماذا يهم ذلك لمجموعة أدوات تحليلاتك

إذا كان موقعك يُحمِّل وسوم إعلانات Google — بما في ذلك gtag.js الخاص بـ GA4 حين يكون متصلاً بـ Google Ads — فإن زوارك يخضعون الآن لبصمات بموجب سياسة لا تتطلب موافقتهم. وسم GA4 نفسه نحو 45 كيلوبايت ويُجري طلبات صادرة متعددة؛ ومع تغيير البصمات، يمكن أن تحمل تلك الطلبات الآن مُعرِّفات دائمة مُشتقة من الجهاز إلى بنية Google التحتية.

للمطورين العاملين تحت GDPR، النتيجة العملية هي أن نشر وسوم Google دون آلية موافقة يصعب الدفاع عنه بشكل متزايد. ذكر ICO أن البصمات "تُمثِّل عتبة عالية للوصول إليها" بموجب الأطر القائمة — إشارة إلى أن إجراءات التنفيذ ضد الناشرين الذين يُمكِّنون التتبع المعتمد على البصمات خطر واقعي قصير المدى.

ثمة نتيجة ثانية أدق: جودة البيانات. تحقن البصمات مُعرِّفات غير مُتفق عليها في خطوط أنابيب التحليلات. إن كنت تستخدم مجموعة أدوات قياس Google، فإن بعض إسناداتك مُشتقة الآن من إشارات أجهزة سلبية بدلاً من أحداث مُتفق عليها. الفئتان — المُتفقة والمبصومة — ليستا متكافئتين، وخلطهما دون تمييزهما يُضعف موثوقية مقاييسك.

التباين مع التجميع الخالي من البصمات

نهج تحليلات لا يضع بصمات أصلاً يتجنب هذه المشاكل هيكلياً. يُرسل مُتتبِّع Monoid طلب POST واحداً إلى /collect بلا إشارات على مستوى الجهاز سوى عائلة متصفح عامة ونوع جهاز يُستنبطان من جهة الخادم من User-Agent العادي للطلب. لا يُخزَّن IP. لا حصر للخطوط. لا دقة شاشة. لا مُعرِّف عبر الجلسات.

تجزئة الزائر اليومية — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — تستخدم IP وUser-Agent في الذاكرة فقط، وتُتلفهما فوراً، وتُنتج قيمة تُعاد تهيئتها كل 24 ساعة. هذا نقيض البصمة: لا يمكن أن تبقى عبر الجلسات، ولا يمكن ربطها عبر الأيام، ولا يمكن استخدامها لإعادة تحديد جهاز معين.

بموجب تحليل ICO، لا يُفعِّل هذا النهج اشتراطات موافقة PECR، لأنه لا يصل إلى معلومات مُخزَّنة على الجهاز ولا يُنتج مُعرِّفاً دائماً. لم تُزَدْ الحجة القانونية والتقنية لهذا النهج إلا قوةً منذ فبراير 2025.

ما ينبغي تدقيقه الآن

إذا كنت تُشغِّل وسوم تحليلات أو إعلانات على موقعك، فهناك ثلاثة أسئلة تستحق الإجابة فوراً:

1. Does this tag access device-level signals (fonts, battery, screen resolution)?
2. Does it send those signals to a third-party server?
3. Do you have a legal basis — consent or legitimate interest — documented for that transfer?

تغيير سياسة Google لا يُغيِّر التزاماتك القانونية؛ بل يُغيِّر ما تسمح به Google لمعلنيها. لا تزال GDPR وPECR تتطلبان أساساً قانونياً للمعالجة، وشفافية في إشعار الخصوصية، و — حين يكون الأساس هو الموافقة — آلية للمستخدمين لمنعها وسحبها.

أبسط طريق من خلال ذلك هو ألا تجمع بيانات مُشتقة من البصمات في المقام الأول. أداة لا تمس إشارات على مستوى الجهاز أبداً لا تتعرض للغموض التنظيمي المحيط بالبصمات، بصرف النظر عن كيفية تطور سياسات Google.