ما يجمعه AppsFlyer

يبدأ AppsFlyer SDK جلسة بمجرد تشغيل التطبيق المضيف، وبشكل افتراضي، يجمع حزمة من المعرّفات والإشارات السياقية: معرّف الإعلان على مستوى الجهاز (IDFA على iOS، وGAID على Android)، وIDFV المحدد النطاق للموردين على iOS، ومعرّف تثبيت AppsFlyer الذي يستمر عبر الجلسات، وعنوان IP (يُستخدم لـ geo-IP وللمطابقة الاحتمالية بنمط البصمة)، ووكيل المستخدم، وطراز الجهاز، وإصدار نظام التشغيل، والناقل، والمنطقة الزمنية. بعد التثبيت، يُبلغ SDK عن حدث التثبيت إلى خوادم AppsFlyer، حيث تتم مطابقته مع بيانات النقر التي تُرسلها شبكات الإعلانات. الأحداث اللاحقة داخل التطبيق — الشراء، إكمال التسجيل، إكمال البرنامج التعليمي، مخصص — تُطلق عبر نفس SDK وترث نفس مجموعة المعرّفات.

كانت الجهات التنظيمية صريحة في أن هذه معالجة للبيانات الشخصية بموجب GDPR. IDFA وGAID هما بيانات شخصية لأنهما معرّفات دائمة على مستوى الجهاز. المطابقة الاحتمالية للبصمة التي تعمل جنبًا إلى جنب أصعب في الدفاع عنها بدون موافقة لأنها، بحكم التعريف، محاولة لتحديد هوية المستخدم دون تعاونه الصريح. فتحت CNIL وGarante الإيطالية وAEPD الإسبانية تحقيقات ضد ناشرين أطلقت أنظمة الإسناد لديهم قبل الموافقة.

عناصر التحكم الأصلية في خصوصية AppsFlyer

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

Start SDK API

يدعم SDK وضع تهيئة حيث يتم تكوينه ولكن لا ينقل أي بيانات حتى يتم استدعاء start() صراحةً. هذا هو الخطاف الأكثر أهمية لبوابة الموافقة — بشكل افتراضي، يبدأ SDK تلقائيًا عند إطلاق التطبيق، وهو السلوك الخاطئ لأي ولاية قضائية لديها متطلب موافقة مسبقة. قم بتعيين isStopped على true عند التهيئة، أو استخدم واجهة البدء المؤجل، واستدع start() فقط عند تسجيل إشارة الموافقة.

Stop API

إذا تم سحب الموافقة في منتصف الجلسة، فإن استدعاء stop() يوقف جميع عمليات الإرسال اللاحقة. لا يحذف البيانات التي تم إرسالها بالفعل بأثر رجعي. للحذف الكامل، تحتاج إلى تقديم طلب حذف موضوع البيانات عبر بوابة خصوصية AppsFlyer — تكامل يجب على الفرق أتمتته عبر AppsFlyer API بدلاً من سير عمل يدوي.

setSharingFilter

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

تكامل Apple App Tracking Transparency

على iOS، يقرأ AppsFlyer حالة تفويض ATT ويضبط سلوكه تلقائيًا — إذا رفض المستخدم ATT، فلن يتم إرسال IDFA. ATT مستقل عن موافقة GDPR، ويخلط العديد من الناشرين بينهما. يتحكم ATT في إشارة واحدة على مستوى iOS؛ تتحكم موافقة GDPR في كل شيء آخر.

التكامل على iOS

النمط الموثوق على iOS هو تثبيت AppsFlyer SDK ولكن تأجيل التهيئة حتى يكتمل كل من ATT وتدفق الموافقة داخل التطبيق. التسلسل الأدنى هو: يتم إطلاق التطبيق، ويتم تكوين SDK مع isStopped = true، ويظهر شعار الموافقة داخل التطبيق، ويقبل المستخدم الفئات ذات الصلة، ويتم مسح علامة isStopped الخاصة بـ SDK ويتم استدعاء start(). إذا كان التطبيق يحتاج أيضًا إلى ATT (وهو ما يحتاجه لأي مستخدم حيث يكون IDFA ذا معنى)، يتم عرض مطالبة ATT جنبًا إلى جنب مع أو بعد الشعار داخل التطبيق. معظم CMPs التي تدعم الهاتف المحمول لديها API قائم على رد الاتصال يقدم قرار الموافقة؛ رد الاتصال هذا هو المكان المناسب لاستدعاء start().

التكامل على Android

يوازي تطبيق Android نظام iOS مع اختلافين. أولاً، لا يوجد ما يعادل ATT — يتوفر GAID ما لم يستدعِ المستخدم إعداد "حذف معرّف الإعلان" على مستوى الجهاز، وهو ما لا يفعله معظم المستخدمين. ثانيًا، دورة حياة Android أكثر قوة في الانتقال إلى الخلفية، لذلك يجب ربط تهيئة SDK بحالة الموافقة المخزنة بشكل دائم. اقرأ حالة الموافقة من التخزين المحلي عند إطلاق التطبيق، وقم بتكوين SDK وفقًا لذلك، وأعد الفحص عند الاستئناف في حالة قيام المستخدم بتحديث اختياره أثناء تشغيل التطبيق في الخلفية.

التكامل على ويب الهاتف المحمول

يعمل AppsFlyer أيضًا على ويب الهاتف المحمول من خلال منتجات الشعار الذكي وOneLink. هذه في الأساس أدوات تحليلات الويب والروابط العميقة التي تضع ملفات تعريف الارتباط وتستدعي خوادم AppsFlyer من المتصفح. تتبع نفس القواعد مثل أي سطح تتبع ويب آخر: ضعها خلف فئة التسويق الخاصة بـ CMP، ولا تدع نص الشعار الذكي يعمل قبل منح الموافقة، وتأكد من أن أي أحداث يتم تشغيلها بواسطة OneLink من حملات البريد الإلكتروني أو الدفع تحترم حالة موافقة المستخدم.

الأخطاء الشائعة

تظهر أربعة أخطاء تكامل بشكل متكرر في عمليات تدقيق نشر AppsFlyer.

معاملة ATT كموافقة GDPR

ATT وموافقة GDPR إشارتان مختلفتان بنطاقات مختلفة. المستخدم الذي يقبل ATT قد أذن باستخدام IDFA للتتبع عبر التطبيقات؛ لم يُفوّض كل شيء آخر يفعله SDK. لحركة المرور من EU وUK، يلزم وجود الإشارتين، حيث يكون الشعار داخل التطبيق هو الملزم وATT طبقة إضافية خاصة بـ iOS في الأعلى.

السماح لـ SDK بالتهيئة عند الإطلاق

هذا هو العيب الفردي الأكثر شيوعًا. يستدعي التكامل الافتراضي start() فورًا، مما يطلق حدث التثبيت مع حمولة المعرّف الكاملة قبل أن يرى المستخدم شعار الموافقة. المعالجة واضحة: قم بتكوين isStopped = true في وقت التكامل واستدع start() فقط من رد اتصال الموافقة.

نسيان التعامل مع السحب

إذا قبل المستخدم ثم ألغى لاحقًا، فيجب إخبار SDK بالتوقف عن الإرسال. استخدم stop() API وقم بتحديث حالة الموافقة المستمرة بحيث يحترم إطلاق التطبيق التالي القرار الجديد.

تجاهل ردود الاتصال من الخادم إلى الخادم

يعيد AppsFlyer توجيه أحداث التحويل إلى قائمة طويلة من شبكات الإعلانات المتكاملة عبر ردود الاتصال من جانب الخادم. تحمل كل إعادة توجيه بيانات شخصية وترث نطاق الموافقة للحدث الأصلي. استخدم setSharingFilter لضمان أن إعادة التوجيه تذهب فقط إلى الشركاء المشمولين بخيارات موافقة المستخدم، وليس إلى كل شريك في لوحة تحكم AppsFlyer الخاصة بك.

قائمة مراجعة التدقيق

ستة أسئلة ملموسة للإجابة عليها لأي نشر AppsFlyer يلمس حركة مرور EU أو UK أو كاليفورنيا.

• هل ينتظر SDK الموافقة؟ على تثبيت جديد في جهاز اختبار موجود في EU، تأكد من عدم تلقي أي نقطة نهاية AppsFlyer أي طلب قبل أن يقبل المستخدم الشعار.
• هل يتم فصل ATT عن الموافقة داخل التطبيق؟ تأكد من أن الشعار داخل التطبيق هو إشارة الموافقة المتحكمة وأن ATT يُعامل كطبقة إضافية خاصة بـ iOS.
• هل تقتصر إعادة توجيه الشريك على الموافقة؟ تأكد من تكوين setSharingFilter لاستبعاد الشركاء الذين لم يفوضهم المستخدم.
• هل يوقف السحب SDK؟ تأكد من أن استدعاء stop() يعمل عند إلغاء الموافقة وأن الحالة الجديدة تستمر عبر عمليات الإطلاق.
• هل يتم تدقيق ردود الاتصال من الخادم؟ تأكد من أن قائمة "التكاملات المكونة" في لوحة تحكم AppsFlyer تتطابق بوضوح مع شركاء التسويق المكشوف عنهم في الشعار.
• هل يتم حذف البيانات بشكل تلقائي؟ تأكد من أن طلبات DSAR تؤدي إلى تشغيل AppsFlyer deletion API، وليس تذكرة يدوية.

أين يتناسب AppsFlyer في مكدس يعطي الأولوية للموافقة

يُعد إسناد الهاتف المحمول أحد الأسطح الأكثر كثافة في المعرّفات في مكدس التسويق، وSDK الخاص بـ AppsFlyer هو أحد أهم تكاملاته الفردية. الأخبار الجيدة هي أن المنصة تعرض الأوليات — Start SDK وStop وفلاتر المشاركة وAPIs الحذف — اللازمة لجعل فرض الموافقة نظيفًا وقابلاً للتحقق. العمل المطلوب من الناشرين هو ربط هذه الأوليات بـ CMP يملك قرار الموافقة الملزم، ومعاملة ATT كإشارة تكميلية بدلاً من بديل، والتأكد من أن إعادة توجيه الشريك من جانب الخادم لا يمكن أن تهرب من مظروف الموافقة الذي سجله الشعار. عند إجرائها بشكل صحيح، تكون النتيجة هي مكدس إسناد يرضي الجهات التنظيمية مع الحفاظ على بيانات التثبيت والحدث التي تعتمد عليها فرق اكتساب المستخدمين.