ATT iOS: ما هو، آلية طلب التتبع و IDFA

ما هو ATT (App Tracking Transparency)؟

App Tracking Transparency هو إطار عمل من Apple لحماية خصوصية المستخدمين، تم تقديمه في iOS 14.5. يتطلب من التطبيقات الحصول على إذن صريح للوصول إلى معرّف الإعلانات للجهاز (IDFA) قبل استخدامه للتتبع.

قبل ظهور ATT، كان بإمكان المطورين قراءة IDFA دون طلب الإذن، مما سمح لشبكات الإعلانات ببناء ملفات تعريف للمستخدمين وتتبع نشاطهم بين التطبيقات والمواقع. اعتبرت Apple هذا انتهاكاً للخصوصية وأدخلت حوار موافقة إلزامي.

الإطار متاح منذ iOS 14.0، لكنه أصبح إلزامياً لجميع التطبيقات التي تستخدم IDFA مع إصدار iOS 14.5 في أبريل 2021. وفقاً لـ Flurry Analytics، بعد تطبيق ATT، أقل من 25% من المستخدمين في الولايات المتحدة وافقوا على التتبع، مما غيّر سوق الإعلانات المحمولة جذرياً.

يتحقق ATT من الإذن عبر حوار نظامي خاص لا يمكن للتطبيق تعديله أو تجاوزه. يرى المستخدم نافذة منبثقة قياسية مع النص الذي يقدمه المطور ويختار إما “السماح” أو “طلب عدم التتبع من التطبيق”.

كيف يرتبط ATT بالخصوصية في iOS

تضع Apple ATT كجزء من استراتيجيتها الشاملة للخصوصية، والتي تشمل أيضاً ملصقات الخصوصية الغذائية في App Store وبيان الخصوصية. تعمل الآليات الثلاث معاً: تظهر الملصقات البيانات التي يجمعها التطبيق، ويعلن البيان أسباب استخدام واجهات برمجة التطبيقات، ويمنح ATT المستخدم التحكم في التتبع.

رفض التتبع لا يمنع عمل التطبيق نفسه — يمكن للمستخدمين الاستمرار في استخدام جميع الميزات، لكن شبكات الإعلانات لن تحصل على IDFA للتخصيص والإسناد. بدائل Apple لـ IDFA تشمل SKAdNetwork والإسناد الاحتمالي.

وفقاً لـ Branch Metrics، بعد تطبيق ATT، انخفضت نسبة التطبيقات التي تتلقى IDFA من 70% إلى 20% على المستوى العالمي. أدى هذا إلى إعادة النظر في أساليب إسناد التثبيت وتحقيق الدخل من الإعلانات.

التغييرات في iOS 15 و 16

في iOS 15، لم تشدد Apple متطلبات ATT لكنها أضافت تقرير خصوصية التطبيق — تقرير يظهر للمستخدم عدد مرات وصول التطبيقات إلى أجهزة الاستشعار والبيانات. وسّع iOS 16 نطاق التحكم: يمكن للمستخدم تغيير إعدادات التتبع في أي وقت عبر الإعدادات → الخصوصية → التتبع.

الأهم: إذا اختار المستخدم “طلب عدم التتبع من التطبيق” في حوار ATT، لا يتلقى التطبيق قيمة IDFA، بل يعيد بدلاً من ذلك سلسلة من الأصفار: 00000000-0000-0000-0000-000000000000. محاولة قراءة IDFA بطريقة أخرى أو بأساليب التفافية تؤدي إلى رفض التطبيق في App Store.

ابتداءً من iOS 17، شددت Apple عمليات التحقق: إذا طلب التطبيق IDFA دون عرض حوار ATT النظامي، يتلقى رفضاً على مستوى نظام التشغيل، وليس مجرد معرّف فارغ. هذا يستبعد إمكانية جمع IDFA في الخلفية دون علم المستخدم.

كيف يعمل طلب التتبع في iOS

تتكون عملية طلب ATT من ثلاث مراحل: التحقق من الحالة، عرض الحوار النظامي، ومعالجة الرد. لا يمكن للمطور تخطي أي خطوة — نظام التشغيل يتحكم في كل مرحلة.

التحقق من حالة التفويض

قبل استدعاء الحوار، يجب على التطبيق التحقق من الحالة الحالية عبر ATTrackingManager. الحالات الممكنة: notDetermined (لم يُطلب بعد)، restricted (محظور بسياسات الجهاز)، denied (رفض المستخدم)، authorized (مسموح).

إذا كانت الحالة محددة بالفعل (authorized أو denied)، لا يمكن استدعاء الحوار مرة أخرى — اتخذ المستخدم قراراً دائماً. الطريقة الوحيدة لتغيير القرار هي من خلال إعدادات نظام iOS.

للتحقق من الحالة، يتم استخدام الخاصية ATTrackingManager.trackingAuthorizationStatus. يجب أن يتم الاستدعاء في الخيط الرئيسي لأن الحوار النظامي هو مكون واجهة مستخدم.

import AppTrackingTransparency
import AdSupport

func checkTrackingStatus() {
    let status = ATTrackingManager.trackingAuthorizationStatus
    switch status {
    case .notDetermined:
        requestTrackingPermission()
    case .authorized:
        readIDFA()
    case .denied, .restricted:
        useAlternativeTracking()
    @unknown default:
        break
    }
}

عرض الحوار النظامي

لعرض الحوار، يتم استدعاء الطريقة requestTrackingAuthorization مع إغلاق يستقبل نتيجة اختيار المستخدم. مهم: الحوار يظهر مرة واحدة فقط. إذا حاول المطور استدعاءه مرة أخرى، يتجاهل النظام الطلب.

يتكون نص الحوار من جزأين: عنوان نظامي (لا يمكن تغييره) ورسالة مخصصة يحددها المطور في Info.plist عبر المفتاح NSUserTrackingUsageDescription.

يجب أن يظهر الحوار في سياق طبيعي — ليس فور تشغيل التطبيق، بل عند أول محاولة لاستخدام وظيفة مرتبطة بالتتبع. توصي Apple بعرض الحوار بعد أن يفهم المستخدم قيمة الوظيفة.

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        DispatchQueue.main.async {
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier
                print("IDFA: \(idfa)")
            case .denied:
                print("رفض المستخدم التتبع")
            default:
                break
            }
        }
    }
}

IDFA وتقييد الوصول

IDFA (Identifier for Advertisers) هو معرّف إعلانات فريد لأجهزة iOS، يُستخدم للإعلانات المستهدفة وإسناد التثبيتات. قبل ATT، كان المطورون يحصلون عليه عبر ASIdentifierManager دون قيود. بعد ATT، الوصول إلى IDFA محظور حتى يمنح المستخدم موافقته الصريحة.

ما هو IDFA ولماذا هو مطلوب

IDFA هو سلسلة UUID فريدة لكل جهاز iOS. تستخدم شبكات الإعلانات IDFA من أجل: تتبع تثبيتات التطبيقات (الإسناد)، عرض إعلانات ذات صلة بناءً على اهتمامات المستخدم، قياس فعالية الحملات الإعلانية، و إعادة الاستهداف — إعادة المستخدمين الذين لم يكملوا الإجراء المطلوب.

بعد رفض المستخدم للتتبع، يعيد ASIdentifierManager القيمة 00000000-0000-0000-0000-000000000000. لا يزال بإمكان التطبيق قراءة IDFA للأغراض التقنية (مثل مكافحة الاحتيال)، لكن لا يمكنه إرساله لشبكات الإعلانات.

وفقاً لـ Singular (2024)، يبلغ معدل الموافقة العالمي على ATT 25–35%، بينما تكون النسبة في أوروبا (GDPR) أعلى (40–50%) منها في الولايات المتحدة (15–25%). دفع هذا منصات الإعلانات إلى تطوير طرق إسناد بديلة.

بدائل IDFA: SKAdNetwork والإسناد الاحتمالي

SKAdNetwork هو إطار عمل من Apple لإسناد التثبيتات دون الكشف عن IDFA. يعمل على مستوى نظام التشغيل: ترسل شبكة الإعلانات رد اتصال موقعاً، يتحقق منه Apple وينقله إلى المطور. يحدث الإسناد دون تحديد مستخدم معين، فقط على مستوى الحملة.

يستخدم الإسناد الاحتمالي إشارات متعددة من الجهاز — الطراز، إصدار iOS، المنطقة الزمنية، سطوع الشاشة — لمطابقة التثبيتات مع مرات عرض الإعلانات بشكل احتمالي. لكن Apple تحظر هذه الطريقة في قواعدها وقد يؤدي استخدامها إلى رفض التطبيق.

طورت Google وAdjust وAppsFlyer حلولاً هجينة خاصة بها تجمع بين SKAdNetwork والبيانات المجمعة الخاصة. على سبيل المثال، يستخدم تتبع تحويلات Google Ads ردود اتصال SKAdNetwork ونماذج التعلم الآلي الخاصة به للإسناد دون IDFA.

تنفيذ ATT في كود التطبيق

لدمج ATT، تحتاج إلى إضافة المفتاح NSUserTrackingUsageDescription إلى Info.plist واستيراد إطار عمل AppTrackingTransparency. فيما يلي خطوات Swift وObjective-C.

إعداد Info.plist

الخطوة الأولى هي إضافة المفتاح NSUserTrackingUsageDescription إلى Info.plist مع نص يشرح لماذا يحتاج التطبيق إلى التتبع. سيظهر هذا النص في الحوار النظامي. مثال: “يتم استخدام IDFA الخاص بك لعرض إعلانات مخصصة وتتبع فعالية الحملات.”

بدون هذا المفتاح، سيؤدي استدعاء requestTrackingAuthorization إلى تعطل التطبيق — تتحقق Apple صراحة من وجود NSUserTrackingUsageDescription قبل عرض الحوار. يجب أن يكون النص موجزاً ومحدداً ويعكس الاستخدام الفعلي للبيانات.

مهم: تتم إضافة المفتاح يدوياً عبر علامة تبويب المعلومات في Xcode أو بتحرير ملف XML المصدر لـ Info.plist. بعد الإضافة، أعد بناء المشروع وتحقق من ظهور المفتاح في الملف الثنائي النهائي.

<!-- Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>This identifier is used to deliver
personalized ads and measure campaign performance.</string>

التكامل الكامل في Swift

في مشروع حقيقي، من الأفضل استدعاء طلب ATT قبل التشغيل الأول لوحدة الإعلانات أو متتبع. يُوصى بشرح قيمة الموافقة أولاً على شاشة منفصلة (شاشة الإذن المسبق) — فهذا يزيد معدلات الموافقة بنسبة 20–30%.

شاشة الإذن المسبق هي واجهة مستخدم مخصصة تظهر فائدة تفعيل التتبع (“ساعدنا في عرض إعلانات ذات صلة لك”). فقط بعد النقر على “متابعة” يظهر حوار ATT النظامي. سجلت Adjust (2024) زيادة بنسبة 40% في الموافقة عند استخدام شاشة الإذن المسبق.

final class TrackingManager {
    static let shared = TrackingManager()

    func requestTrackingIfNeeded() {
        guard ATTrackingManager.trackingAuthorizationStatus
            == .notDetermined
        else { return }

        ATTrackingManager.requestTrackingAuthorization { _ in
            NotificationCenter.default.post(
                Notification(Name("trackingStatusChanged"))
            )
        }
    }
}

أخطاء عند العمل مع ATT

غالباً ما يرتكب المطورون أخطاء نموذجية عند دمج ATT، مما يؤدي إلى انخفاض معدل الموافقة أو رفض التطبيق من قبل مراجعي App Store. دعنا نستعرض خمس مشكلات شائعة.

طلب ATT مباشرة بعد تشغيل التطبيق

الخطأ الأكثر شيوعاً هو عرض حوار ATT النظامي على الشاشة الأولى بعد تحميل التطبيق مباشرة. المستخدم لا يفهم بعد قيمة التطبيق ومن المحتمل جداً أن يضغط “رفض”. أظهرت IronSource (2023) انخفاضاً بنسبة 32% في الموافقة عند الطلب على الشاشة الأولى مقارنة بالطلب بعد الجلسة الثالثة.

توصية: اطلب التتبع بعد أن يقوم المستخدم بإجراء قيّم (عرض محتوى، بدء مرحلة الإعداد) أو بعد 3–5 جلسات استخدام. هذا يزيد الثقة وإدراك القيمة.

عدم وجود شاشة إذن مسبق

عرض حوار ATT النظامي دون شرح مسبق هو خطأ يخفض معدل الموافقة إلى 15–20%. يرى المستخدم طلباً غير متوقع ويرفضه غريزياً. شاشة الإذن المسبق مع شرح الفائدة ترفع الموافقة إلى 35–45%.

يجب أن يكون نص الإذن المسبق محدداً: “اسمح لنا بعرض إعلانات ذات صلة — هذا يساعدنا في البقاء مجاناً.” تجنب العبارات العامة — فهي تقلل الثقة. أظهرت GameAnalytics في 2023 أن شاشة الإذن المسبق التي تشرح الفائدة تحقق موافقات أكثر بنسبة 28% من الشاشة الفارغة.

تجاهل الحالة restricted و denied

إذا كان المستخدم قد رفض التتبع بالفعل أو كانت الحالة restricted (الرقابة الأبوية، السياسات المؤسسية)، يجب على التطبيق عدم استدعاء حوار ATT مرة أخرى. الاستدعاء المتكرر لا يعمل ويُنظر إليه كانتهاك للخصوصية. بدلاً من ذلك، تحول إلى SKAdNetwork و الإعلانات السياقية.

في الحالة restricted، لا يمكن للتطبيق تحديد ما إذا كان خيار “السماح بطلبات التتبع” مفعلاً في الإعدادات. في هذه الحالة، استخدم دائماً SKAdNetwork كطريقة الإسناد الوحيدة ولا تعرض شاشة الإذن المسبق.

قراءة IDFA دون استدعاء ATT

قراءة IDFA عبر ASIdentifierManager.shared().advertisingIdentifier دون إذن ATT المسبق تعيد سلسلة من الأصفار. يحاول بعض المطورين استخدام طرق قديمة للوصول إلى IDFA عبر واجهات برمجة تطبيقات خاصة — وهذا يضمن الرفض أثناء مراجعة التطبيق.

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

نص NSUserTrackingUsageDescription غير صحيح

نص طويل جداً أو غامض أو مضلل في مفتاح NSUserTrackingUsageDescription هو سبب لرفض المراجعين. تتحقق Apple من أن الوصف يتوافق مع الاستخدام الفعلي للبيانات. إذا لم يكن للتطبيق إعلانات ولكنه يذكر “لأغراض إعلانية”، سيرفض المراجع الإصدار.

التنسيق الموصى به: وصف محدد للغرض من استخدام IDFA بطول 2–3 جمل. مثال لتطبيق بدون إعلانات: “يُستخدم المعرّف للتحليلات ومنع الاحتيال. لا تتم مشاركة البيانات مع أطراف ثالثة ولا تُستخدم لإنشاء ملفات تعريف.”