App Tracking Transparency (ATT) در iOS و رضایت کوکی برای برنامههای هیبریدی در سال ۲۰۲۶
برنامههای موبایل هیبریدی — معماریای که در آن یک پوسته نیتیو نازک یک نمای وب را در بر میگیرد که بیشتر رابط کاربری را رندر میکند — همواره به طور همزمان در دو دنیای حریم خصوصی زندگی کردهاند. پوسته نیتیو تحت چارچوب App Tracking Transparency (ATT) اپل در iOS و نقشه راه Privacy Sandbox گوگل در Android اداره میشود. نمای وب داخلی تحت همان قوانین GDPR، ePrivacy، CCPA و CPRA است که برای هر مرورگری اعمال میشود. پنج سال است که ناشران تلاش کردهاند با وصلههای موقت این شکاف را پر کنند، و پنج سال است که بررسان App Store و قانونگذاران اتحادیه اروپا این وصلهکاریها را به تقریباً یک اندازه رد کردهاند. تا سال ۲۰۲۶، سوال اینکه ATT و رضایت کوکی چگونه در یک برنامه هیبریدی کنار هم قرار میگیرند دیگر یک جزئیات فنی اختیاری نیست — این تفاوت است بین برنامهای که منتشر میشود، درآمد کسب میکند و از حسابرسی حریم خصوصی جان سالم به در میبرد، و برنامهای که از فروشگاه حذف میشود یا جریمهای میخورد که بازسازی را اجباری میکند. این راهنما توضیح میدهد که ATT واقعاً چه چیزی را کنترل میکند، چه چیزی را عمداً به رضایت وب واگذار میکند، چگونه جریان مجوز و رضایت را طراحی کنیم تا دو سیستم منسجم باشند نه متضاد، و کدام الگوهای مهندسی هم از فرآیند بررسی اپل و هم از حسابرسی قانونگذار جان سالم به در میبرند.
App Tracking Transparency واقعاً چه چیزی را اداره میکند
ATT یک دروازه مجوز است که اپل آن را در iOS و iPadOS اعمال میکند. وقتی یک برنامه میخواهد به Identifier for Advertisers (IDFA) دستگاه دسترسی داشته باشد یا ردیابیای انجام دهد که کاربر را در برنامهها و وبسایتهای متعلق به سایر اپراتورها به هم مرتبط میکند، باید requestTrackingAuthorization را فراخوانی کند و یک درخواست سیستمی نمایش دهد که از کاربر میخواهد ردیابی را مجاز یا رد کند. پاسخ کاربر دودویی است، تا زمانی که کاربر آن را در تنظیمات تغییر دهد پایدار است، و از طریق API trackingAuthorizationStatus برای برنامه قابل مشاهده است.
تعریف اپل از ردیابی
راهنمای توسعهدهندگان اپل ردیابی را به طور خاص و محدود تعریف میکند: پیوند دادن دادههای کاربر یا دستگاه جمعآوری شده از برنامه شما با دادههای کاربر یا دستگاه جمعآوری شده از برنامهها، وبسایتها یا ویژگیهای آفلاین سایر شرکتها برای تبلیغات هدفمند یا اندازهگیری، یا اشتراکگذاری دادههای کاربر یا دستگاه با کارگزاران داده. این تعریف عمداً استفاده از اطلاعات شخص اول در داخل برنامه، تحلیلهای کلی ناشناس و پردازش برای پیشگیری از تقلب یا رعایت قانونی را مستثنی میکند — این فعالیتها صرف نظر از اینکه کاربر مجوز ATT داده باشد یا نه، نیازی به درخواست ATT ندارند.
ATT چه کاری نمیکند
ATT یک سیستم مدیریت رضایت به معنای GDPR نیست. ترجیحات دقیق هدف را جمعآوری نمیکند، رسید رضایت با نسخهبندی سیاست ثبت نمیکند، سیگنالها را به فروشندگان وب داخل WKWebView منتشر نمیکند، و الزام پایه قانونی برای ذخیره یا خواندن کوکیها بر روی دستگاه کاربر را برآورده نمیکند. ناشری که درخواست ATT را به عنوان کل موضع انطباق خود برای یک برنامه هیبریدی میداند، فقط یک نامه قانونگذار تا جریمه فاصله دارد، زیرا بارگذاری کوکی در داخل نمای وب یک رویداد جداگانه در ePrivacy است و به لایه رضایت خود نیاز دارد.
چگونگی اعمال GDPR و ePrivacy در داخل WKWebView
نمای وب داخل یک برنامه هیبریدی به طور جادویی از قوانینی که برای مرورگر دسکتاپ اعمال میشوند معاف نیست. لحظهای که WKWebView یک کوکی که کاملاً ضروری نیست را میخواند یا مینویسد، ePrivacy فعال میشود. لحظهای که WKWebView یک درخواست تحلیل یا تبلیغات حاوی دادههای شخصی ارسال میکند، GDPR فعال میشود. ظرف اپل تحلیل را تغییر نمیدهد — آنچه تغییر میکند سطح پیادهسازی است، زیرا بنر رضایت باید در داخل نمای وب رندر شود و وضعیت رضایت باید برای کد نیتیو که ممکن است دادههای یکسانی را نیز بخواند قابل مشاهده باشد.
بنر داخل نمای وب
الگوی استاندارد این است که یک بنر CMP داخل WKWebView به همان شکلی که روی یک وبسایت میکنید رندر کنید. بنر کوکیها را بر روی فروشگاه کوکی نمای وب تنظیم میکند، یک رویداد بهروزرسانی رضایت را در زمینه JavaScript صفحه فعال میکند، و یک ماشین حالت Google Consent Mode v2 را بهروز میکند که برچسبهای تحلیل و تبلیغات صفحه میخوانند. پیادهسازی با یک CMP وب معمولی فرقی ندارد — آنچه متفاوت است این است که فروشگاه کوکی محدود به WKWebView است و برای سایر برنامهها یا Safari قابل مشاهده نیست، که برای جداسازی مفید است اما اگر ناشر وبسایتی نیز دارد که کاربر قبلاً در آن رضایت داده مفید نیست.
به اشتراک گذاشتن رضایت بین نمای وب و پوسته نیتیو
مشکل دشوارتر پل بین WKWebView و پوسته نیتیو است. پوسته نیتیو ممکن است SDK تحلیل خود را داشته باشد که پس از اینکه کاربر ATT اعطا کرده IDFA را میخواند، در حالی که نمای وب بنر رضایت خود را دارد که کاربر ممکن است قبول کرده باشد یا نکرده باشد. اگر کاربر ATT را اعطا کند اما رضایت تبلیغاتی را در نمای وب رد کند، SDK نیتیو هنوز میتواند IDFA را بخواند اما برچسبهای نمای وب نباید. اگر کاربر ATT را رد کند اما رضایت تبلیغاتی نمای وب را بپذیرد، SDK نیتیو مسدود است اما برچسبهای نمای وب همچنان باید فعال شوند — هرچند شناسه مبتنی بر IDFA SDK نیتیو بدیهی است که نمیتواند از پل عبور کند. تمیزترین الگو یک منبع حقیقت واحد است — CMP — که از طریق یک پل JavaScript در معرض دید قرار میگیرد که پوسته نیتیو در شروع برنامه و در هر تغییر رضایت آن را میخواند، با یک درخواست موازی ATT که به تصمیم تبلیغاتی CMP متکی است نه اینکه دوباره بپرسد.
لایه CPRA و ایالتهای آمریکا
برای ناشران آمریکایی تصویر یک لایه سوم دارد. CPRA، به علاوه خوشهای از قوانین ایالتی که ویرجینیا، کلرادو، کانتیکت و یوتا را دنبال کردند، IDFA را همانطور رفتار میکند که با کوکیهای وب رفتار میکند — هر دو اطلاعات شخصی هستند که فروش یا اشتراکگذاری آنها یک حق انصراف ایجاد میکند. هدر Global Privacy Control که مرورگرهای وب ارسال میکنند سیگنال رو به مصرفکننده است، و Multi-State Privacy Agreement (MSPA) IAB با رشته US Privacy مرتبط آن سیگنال رو به ناشر است. یک برنامه هیبریدی که در آمریکا عرضه میشود باید یک پیوند "اطلاعات شخصی من را نفروشید یا به اشتراک نگذارید" را داخل خود برنامه در معرض دید قرار دهد، انصراف حاصل را هم به CMP نمای وب و هم به SDK اندازهگیری پوسته نیتیو هدایت کند، و هر هدر GPC ورودی که از طریق یک پیوند عمیق به نمای وب میرسد را رعایت کند.
کودکان و COPPA در برنامههای هیبریدی
اگر برنامه برای کودکان رتبهبندی شده یا انتظار معقولی از کاربران کودک وجود داشته باشد، COPPA در آمریکا و مقررات GDPR-K در اتحادیه اروپا محدودیتهای اضافی بر روی ATT و رضایت استاندارد اضافه میکنند. IDFA نباید برای حسابهای کودک درخواست شود، رضایت تبلیغاتی نمای وب باید به طور پیشفرض رد شود، و هر SDK شخص ثالث در پوسته نیتیو باید قبل از ارسال تأیید شود که با COPPA سازگار است. بررسی App Store برنامههای رتبهبندی شده برای کودکان را که درخواست ATT استاندارد را نشان میدهند رد میکند، که یک اشتباه رایج پیادهسازی است وقتی تیمها یک باینری واحد برای همه مخاطبان میسازند.
الگوی مهندسی که تأیید میشود
معماری برنامه هیبریدی که هم از بررسی App Store و هم از حسابرسی حریم خصوصی اتحادیه اروپا جان سالم به در میبرد تعداد کمی از عناصر تکرارپذیر دارد. بنر CMP داخل WKWebView منبع حقیقت برای رضایت تبلیغاتی است. درخواست ATT فقط بعد از اینکه CMP حل شد نشان داده میشود، فقط اگر کاربر رضایت تبلیغاتی را پذیرفته باشد، و فقط با یک پیش-درخواست سفارشی که توضیح میدهد ردیابی چه چیزی را ممکن میکند. یک پل JavaScript وضعیت رضایت CMP را در شروع برنامه برای پوسته نیتیو نمایش میدهد و در هر تغییر رضایت یک رویداد ارسال میکند. SDKهای پوسته نیتیو هم به رضایت تبلیغاتی CMP و هم به وضعیت مجوز ATT وابسته هستند؛ رد شدن هر یک برای مسدود کردن SDK کافی است.
پیش-درخواستها و دستورالعمل اپل
اپل اجازه میدهد — و در عمل انتظار دارد — یک پیش-درخواست قبل از درخواست سیستم ATT که با صدای ناشر توضیح میدهد چرا برنامه ردیابی میخواهد و کاربر در ازای آن چه چیزی دریافت میکند. یک پیش-درخواست خوب نوشته شده میتواند نرخهای opt-in را به طور قابل توجهی افزایش دهد. آنچه اپل اجازه نمیدهد یک پیش-درخواست است که سعی میکند از درخواست سیستم عبور کند، عواقب رد شدن را نادرست نشان میدهد، یا عملکرد برنامه را مشروط به مجوز ردیابی میکند. بررسان برنامهها را برای هر سه الگو رد میکنند و به طور فزایندهای برای استفاده از پیش-درخواست برای هدایت به سمت opt-in با متن دستکاریکننده.
سمت سرور و SKAdNetwork به عنوان بازگشتها
وقتی ATT رد میشود یا رضایت تبلیغاتی در نمای وب پذیرفته نمیشود، ناشر هنوز میتواند برای انتساب به SKAdNetwork تکیه کند — شبکه حفظ حریم خصوصی اپل که دادههای تبدیل را بدون نمایش شناسههای کاربری فردی تحویل میدهد. SKAdNetwork مشمول ATT نیست و صرف نظر از تصمیم رضایت کاربر کار میکند، که آن را انتخاب پیشفرض درست برای اندازهگیری زمانی که مسیر شخصیسازی بسته است میکند. پستبکهای سرور به سرور از پوسته نیتیو به یک سرویس هویت متعلق به ناشر نیز میتوانند شکاف اندازهگیری را پر کنند، مشروط بر اینکه دادهها واقعاً شخص اول باشند و با دادههای سایر اپراتورها به گونهای که آنها را به تعریف ردیابی اپل باز گرداند ترکیب نشوند.
اشتباهات رایجی که رد شدن یا حسابرسی را ایجاد میکنند
برنامههای هیبریدی که حذف یا جریمه میشوند تمایل دارند به یک مشت روش یکسان شکست بخورند. بنر CMP داخل WKWebView قبل از اینکه درخواست ATT حل شده باشد فعال میشود و در حالی که مجوز اپل هنوز در انتظار است کوکیها روی دستگاه قرار میدهد — یافتهای که میتواند منجر به رد App Store شود. درخواست ATT بدون پیش-درخواست و در راهاندازی سرد نشان داده میشود و نرخهای opt-in پایین و تجربه کاربری گیجکنندهای ایجاد میکند که ریزش را افزایش میدهد. SDK تحلیل پوسته نیتیو IDFA را قبل از اینکه CMP اولین رویداد رضایت خود را فعال کرده باشد میخواند و دادههای شخصی را بدون پایه قانونی واضحی روی سیم میفرستد. وضعیت رضایت نمای وب و وضعیت مجوز پوسته نیتیو در فروشگاههای جداگانه بدون همگامسازی نگه داشته میشوند و کاربری ایجاد میکنند که تبلیغات را در نمای وب رد کرده اما SDK تبلیغاتی نیتیو او هنوز فعال میشود. هر یک از اینها یک تا دو روز کار مهندسی و یک پاس تست رگرسیون است — اما هر کدام دقیقاً الگویی است که یک حسابرس یا بررسان با آن شروع میکند.
نتیجهگیری
ATT و رضایت کوکی لایههای اضافی زائد نیستند. ATT یک دروازه مجوز محدود به یک API خاص iOS است، و رضایت کوکی یک پایه قانونی برای پردازش داده در هر محیط کلاس مرورگر است، از جمله WKWebView. یک برنامه هیبریدی به هر دو نیاز دارد، سیمکشی شده به هم تا کاربر یک تصمیم منسجم ببیند نه دو درخواست متضاد، و تا پوسته نیتیو و نمای وب به یک پاسخ احترام بگذارند. ناشرانی که این کار را درست انجام میدهند برنامههایی ارسال میکنند که از بررسی عبور میکنند، به طور مطمئن درآمد کسب میکنند و هرگز در خلاصه اجرایی قانونگذار ظاهر نمیشوند. ناشرانی که ATT را کل پاسخ میدانند یا اجازه میدهند رضایت نمای وب و پوسته نیتیو از هم دور شوند، سال ۲۰۲۶ را در حال تناوب بین جلسات بررسی App Store و نامههای پاسخ حسابرسی میگذرانند. پل را یک بار بسازید، CMP را منبع حقیقت بدانید، و بگذارید ATT قفل خاص iOS بر روی یک موضع حریم خصوصی که از قبل در لایه وب منسجم است باشد.