انتساب موبایل AppsFlyer و رضایت کوکی: راهنمای یکپارچهسازی ۲۰۲۶ برای ناشران اپلیکیشن
برای توسعهدهندگان اپلیکیشن، سنجش موبایل مشکلی بنیادی متفاوت از سنجش وب است. کوکیهایی که ناشران وب نگران آنها هستند در اپلیکیشنهای بومی وجود ندارند، اما شناسههایی که جایگزین آنها میشوند — IDFA، GAID، IDFV، شناسههای نصب، ایمیلهای هششده، اثرانگشتهای دستگاه مشتق از IP — همان سؤالات حقوقی را مطرح میکنند و به همان نهادهای نظارتی پاسخ میدهند. AppsFlyer، پرکاربردترین شریک سنجش موبایل در بازیهای موبایل، فینتک و اپلیکیشنهای مصرفکننده، در مرکز این خط لوله قرار دارد. SDK آن شناسههای با کیفیت انتساب را جمعآوری میکند، سرورهایش آنها را با پستبکهای شبکههای تبلیغاتی مرتبط میکنند، و انتساب حاصل بودجههای جذب کاربر را در همه کانالهای اصلی تأمین میکند. هیچکدام از این پردازشها بدون مبنای قانونی انجام نمیشود، و مبنای قانونی که GDPR و دستورالعمل ePrivacy واقعاً نیاز دارند رضایت است — که قبل از راهاندازی SDK جمعآوری شده، به عنوان شواهد ثبت شده، و به هر یکپارچهسازی پاییندستی منتشر شده باشد. این راهنما توضیح میدهد که AppsFlyer چه چیزی جمعآوری میکند، چگونه آن را با چارچوب مدیریت رضایت در iOS، Android و وب موبایل یکپارچه کنید، و چگونه اولیههای حریم خصوصی بومی پلتفرم (Start SDK API، سیگنالهای ATT و Data Privacy Framework) با این تصویر هماهنگ میشوند.
چه چیزی AppsFlyer جمعآوری میکند
SDK AppsFlyer به محض راهاندازی اپلیکیشن میزبان یک جلسه را آغاز میکند و به طور پیشفرض مجموعهای از شناسهها و سیگنالهای متنی جمعآوری میکند: شناسه تبلیغاتی سطح دستگاه (IDFA در iOS، GAID در Android)، IDFV محدوده فروشنده در iOS، شناسه نصب AppsFlyer تولیدشده که در طول جلسات پایدار است، آدرس IP (برای geo-IP و تطبیق احتمالی به سبک اثرانگشت استفاده میشود)، عامل کاربر، مدل دستگاه، نسخه OS، اپراتور و منطقه زمانی. پس از نصب، SDK رویداد نصب را به سرورهای AppsFlyer گزارش میدهد، جایی که با دادههای کلیک ارسالشده توسط شبکههای تبلیغاتی مطابقت داده میشود. رویدادهای دروناپلیکیشنی بعدی — Purchase، RegistrationComplete، Tutorial Complete، Custom — از طریق همان SDK فعال میشوند و همان مجموعه شناسه را به ارث میبرند.
نهادهای نظارتی صراحتاً بیان کردهاند که این پردازش دادههای شخصی تحت GDPR است. IDFA و GAID دادههای شخصی هستند زیرا شناسههای سطح دستگاه دائمی هستند. تطبیق احتمالی اثرانگشت که در کنار آنها اجرا میشود بدون رضایت حتی سختتر است که از آن دفاع کنید، زیرا طبق تعریف تلاشی برای شناسایی کاربر بدون همکاری صریح آنهاست. CNIL، Garante ایتالیا و AEPD اسپانیا همه تحقیقاتی علیه ناشرانی که پشتههای انتسابشان قبل از رضایت فعال شدند باز کردهاند.
کنترلهای حریم خصوصی بومی AppsFlyer
AppsFlyer مجموعهای معنادار از اولیههای حریم خصوصی بومی را در اختیار میگذارد. آنها جایگزینی برای یک چارچوب رضایت واقعی نیستند، اما درک آنها ضروری است زیرا اهرمهایی هستند که یک CMP برای کنترل رفتار SDK از آنها استفاده میکند.
Start SDK API
SDK از یک حالت راهاندازی پشتیبانی میکند که در آن پیکربندی شده اما تا زمانی که start() صراحتاً فراخوانی نشده هیچ دادهای منتقل نمیکند. این مهمترین قلاب برای دروازهبندی رضایت است — به طور پیشفرض SDK به طور خودکار هنگام راهاندازی اپلیکیشن شروع میکند که رفتار اشتباهی برای هر حوزهای با نیاز رضایت قبلی است. isStopped را در راهاندازی روی true تنظیم کنید یا از API شروع تأخیری استفاده کنید، و start() را فقط زمانی فراخوانی کنید که سیگنال رضایت ثبت شده است.
Stop API
اگر رضایت در میان جلسه پس گرفته شود، فراخوانی stop() همه انتقالات بعدی را متوقف میکند. دادههایی که قبلاً ارسال شدهاند را به صورت گذشتهنگر حذف نمیکند. برای حذف کامل باید یک درخواست حذف موضوع داده از طریق پورتال حریم خصوصی AppsFlyer ارائه دهید — یک تیم یکپارچهسازی باید این را از طریق API AppsFlyer به جای یک گردش کار دستی خودکار کند.
setSharingFilter
این فیلتر میکند که کدام شبکههای تبلیغاتی پاییندستی دادههای پستبک دریافت میکنند. این اولیه مناسب برای رضایت دقیق به ازای هر شریک است — به عنوان مثال، اجازه دادن به انتساب به طور کلی اما مسدود کردن ارسالها به یک شبکه خاص که کاربر رد کرده است.
یکپارچهسازی Apple App Tracking Transparency
در iOS، AppsFlyer وضعیت مجوز ATT را میخواند و رفتار خود را به طور خودکار تنظیم میکند — اگر کاربر ATT را رد کرده باشد، IDFA منتقل نمیشود. ATT مستقل از رضایت GDPR است، و بسیاری از ناشران آنها را با هم قاطی میکنند. ATT یک سیگنال سطح iOS را کنترل میکند؛ رضایت GDPR همه چیز دیگر را کنترل میکند.
یکپارچهسازی در iOS
الگوی قابل اعتماد در iOS نصب SDK AppsFlyer اما به تأخیر انداختن راهاندازی تا زمانی است که هم ATT و هم جریان رضایت دروناپلیکیشنی کامل شده باشند. حداقل توالی این است: اپلیکیشن راهاندازی میشود، SDK با isStopped = true پیکربندی میشود، بنر رضایت دروناپلیکیشنی نمایش داده میشود، کاربر دستهبندیهای مربوطه را قبول میکند، پرچم isStopped SDK پاک میشود و start() فراخوانی میشود. اگر اپلیکیشن به ATT هم نیاز داشته باشد (که برای هر کاربری که IDFA برایش معنادار است نیاز دارد)، درخواست ATT در کنار یا بعد از بنر دروناپلیکیشنی نمایش داده میشود. بیشتر CMPهایی که موبایل را پشتیبانی میکنند یک 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 گفته شود که انتقال را متوقف کند. از API stop() استفاده کنید و وضعیت رضایت ماندگار را بهروز کنید تا راهاندازی بعدی اپلیکیشن تصمیم جدید را رعایت کند.
نادیده گرفتن پستبکهای سرور به سرور
AppsFlyer رویدادهای تبدیل را از طریق پستبکهای سمت سرور به دنباله بلندی از شبکههای تبلیغاتی یکپارچهشده ارسال میکند. هر ارسال دادههای شخصی حمل میکند و حوزه رضایت رویداد اصلی را به ارث میبرد. از setSharingFilter استفاده کنید تا اطمینان حاصل شود که ارسالها فقط به شرکایی میروند که رضایت کاربر آنها را پوشش میدهد، نه به هر شریکی در داشبورد AppsFlyer شما.
چکلیست ممیزی
شش سؤال مشخص برای پاسخ دادن به هر استقرار AppsFlyer که ترافیک EU، UK یا کالیفرنیا را لمس میکند.
- آیا SDK منتظر رضایت میماند؟ در نصب تازه روی یک دستگاه آزمایشی در مکان EU، تأیید کنید که هیچ اندپوینت AppsFlyer قبل از قبول کردن بنر توسط کاربر هیچ درخواستی دریافت نمیکند.
- آیا ATT از رضایت دروناپلیکیشنی جدا شده است؟ تأیید کنید که بنر دروناپلیکیشنی سیگنال رضایت کنترلکننده است و ATT به عنوان یک لایه اضافی خاص iOS در نظر گرفته میشود.
- آیا ارسال شریک محدود به رضایت است؟ تأیید کنید که setSharingFilter برای حذف شرکایی که کاربر مجاز نکرده پیکربندی شده است.
- آیا پسگیری SDK را متوقف میکند؟ تأیید کنید که فراخوانی stop() در لغو رضایت کار میکند و وضعیت جدید در راهاندازیها پایدار میماند.
- آیا پستبکهای سرور ممیزی شدهاند؟ تأیید کنید که فهرست "یکپارچهسازیهای پیکربندیشده" داشبورد AppsFlyer به طور واضح با شرکای بازاریابی افشاشده در بنر مطابقت دارد.
- آیا حذف داده خودکار است؟ تأیید کنید که درخواستهای DSAR API حذف AppsFlyer را فعال میکنند، نه یک تیکت دستی.
AppsFlyer در یک پشته رضایت-محور کجا جای میگیرد
انتساب موبایل یکی از سطوح پر از شناسه در پشته بازاریابی است، و SDK AppsFlyer یکی از مؤثرترین یکپارچهسازیهای منفرد آن است. خبر خوب این است که پلتفرم اولیهها — Start SDK، Stop، فیلترهای اشتراکگذاری، APIهای حذف — مورد نیاز برای تمیز و قابل تأیید کردن اجرای رضایت را در اختیار میگذارد. کار ناشران این است که آن اولیهها را به CMP که تصمیم رضایت الزامی را دارد متصل کنند، ATT را به عنوان یک سیگنال تکمیلی نه جایگزین در نظر بگیرند، و اطمینان حاصل کنند که ارسال شریک سمت سرور نمیتواند از پاکت رضایتی که بنر ثبت کرده فرار کند. اگر درست انجام شود، نتیجه یک پشته انتساب است که نهادهای نظارتی را راضی میکند در حالی که دادههای نصب و رویداد را که تیمهای جذب کاربر به آنها متکی هستند حفظ میکند.