چرا بازی‌های موبایل به یک SDK رضایت نیاز دارند

اگر بازی شما تبلیغاتی از AdMob، Ad Manager یا یک waterfall واسطه‌گری شده را به بازیکنان در منطقه اقتصادی اروپا یا بریتانیا نمایش می‌دهد، طبق قانون موظف هستید پیش از استفاده از هرگونه تبلیغات شخصی‌سازی‌شده یا شناسه ردیابی، رضایت معتبر دریافت کنید. یک بنر کوکی وب این مشکل را حل نمی‌کند — اپلیکیشن‌های بومی موبایل کوکی ندارند و رضایت باید به ad SDKهایی که داخل build شما اجرا می‌شوند برسد.

پاسخ گوگل User Messaging Platform (UMP) SDK است، لایه رضایتی که همراه با Google Mobile Ads SDK ارائه می‌شود. این SDK یک فرم رضایت سازگار با IAB TCF نمایش می‌دهد، انتخاب‌های بازیکن را ذخیره می‌کند و سیگنال رضایتی را در معرض دید قرار می‌دهد که AdMob و شرکای واسطه‌گری به‌طور خودکار آن را می‌خوانند. برای یک استودیوی Unity، درست انجام دادن این جریان تفاوت بین یک eCPM سالم و موجی از جریمه‌های نقض سیاست است.

جریان رضایت، از ابتدا تا انتها

ترتیب صحیح عملیات مهم‌تر از هر فراخوانی API منفرد است. در هر اجرای اپلیکیشن باید:

• درخواست به‌روزرسانی اطلاعات رضایت بدهید. این به UMP می‌گوید که منطقه بازیکن و اینکه آیا فرم لازم است را بررسی کند.
• در صورت نیاز، فرم را بارگذاری و نمایش دهید. UMP بر اساس موقعیت جغرافیایی و انتخاب‌های قبلی تصمیم می‌گیرد که آیا آن را نمایش دهد — شما هرگز "آیا این کاربر در EU است" را به‌صورت ثابت کدنویسی نمی‌کنید.
• پیش از مقداردهی اولیه Mobile Ads SDK، منتظر بسته شدن فرم بمانید.
• تبلیغات را فقط پس از جمع‌آوری رضایت مقداردهی اولیه کنید، تا اولین درخواست تبلیغ از پیش حامل سیگنال صحیح باشد.

مقداردهی اولیه ad SDK پیش از بازگشت فرم رضایت رایج‌ترین اشتباهی است که می‌بینیم. این کار یک نمایش اول غیرشخصی یا غیرمنطبق تولید می‌کند و می‌تواند بررسی‌های خودکار سیاست را فعال کند.

یک پیاده‌سازی حداقلی در Unity

در C#، اسکلت به این شکل است:

var request = new ConsentRequestParameters();
ConsentInformation.Update(request, (FormError error) => {
  ConsentForm.LoadAndShowConsentFormIfRequired((FormError err) => {
    if (ConsentInformation.CanRequestAds()) InitializeAds();
  });
});

بررسی CanRequestAds() دروازه شماست. تا زمانی که true برمی‌گرداند — چه به این دلیل که بازیکن رضایت داده و چه به این دلیل که خارج از یک منطقه تحت مقررات است — می‌توانید تبلیغات را مقداردهی اولیه و درخواست کنید. خودتان چیزی درباره منطقه cache نکنید؛ بگذارید UMP تنها منبع حقیقت باشد.

تست بدون ارسال به فروشگاه

شما نمی‌توانید یک جریان رضایت را از دفتر خود، مثلاً در استانبول، تأیید کنید مگر اینکه یک دستگاه EEA را شبیه‌سازی کنید. UMP از یک تنظیم جغرافیای اشکال‌زدایی و فهرستی از شناسه‌های hash شده دستگاه تست پشتیبانی می‌کند:

• شناسه hash شده دستگاه تست خود را در پارامترهای درخواست ثبت کنید.
• جغرافیای اشکال‌زدایی را به EEA مجبور کنید تا فرم ظاهر شود.
• بین اجراها از متد reset SDK استفاده کنید تا هر بار تجربه اولین اجرا را ببینید.

همیشه تنظیمات اشکال‌زدایی را پیش از build تولیدی حذف کنید. ارسال یک پرچم اشکال‌زدایی اجباری EEA به هر بازیکن یک حادثه واقعی و شرم‌آور است.

رضایت، واسطه‌گری و درآمد شما

وقتی رضایت به‌درستی منتشر می‌شود، هر شبکه در stack واسطه‌گری شما — AdMob، Meta Audience Network، Unity Ads، AppLovin — رشته TCF را دریافت می‌کند و می‌تواند در جایی که مجاز است روی موجودی شخصی‌سازی‌شده پیشنهاد دهد. وقتی خراب می‌شود، آن شبکه‌ها به تبلیغات غیرشخصی با کسری از eCPM بازمی‌گردند و waterfall شما بی‌سروصدا درآمد از دست می‌دهد. لایه رضایت را به‌عنوان بخشی از stack درآمدزایی خود تلقی کنید، نه یک موضوع جانبی انطباق.

جایگاه FlexyConsent

اپلیکیشن‌های بومی به یک CMP درون‌اپلیکیشنی مانند UMP گوگل نیاز دارند. FlexyConsent وب‌سایت‌ها را در دسکتاپ و موبایل پوشش می‌دهد (CMP ID 317 یک CMP وب است). این ابزار سیگنال‌های IAB TCF 2.4 و Google Consent Mode v2 را ارسال می‌کند. گزارش‌های آن تصمیم‌ها را بر اساس منبع و منطقه نشان می‌دهند.

نکات کلیدی

• رضایت را از طریق UMP SDK پیش از مقداردهی اولیه Mobile Ads SDK جمع‌آوری کنید.
• هرگز منطق منطقه را به‌صورت ثابت کدنویسی نکنید — بگذارید UMP تصمیم بگیرد چه زمانی فرم لازم است.
• با جغرافیای اشکال‌زدایی و شناسه‌های تست hash شده تست کنید، سپس آن‌ها را پیش از انتشار حذف کنید.
• انتشار صحیح رضایت از eCPM تبلیغات شخصی‌سازی‌شده شما در سراسر کل stack واسطه‌گری محافظت می‌کند.