Hvorfor mobilspil har brug for en samtykke-SDK

Hvis dit spil viser annoncer fra AdMob, Ad Manager eller et medieret waterfall til spillere i Det Europæiske Økonomiske Samarbejdsområde eller Storbritannien, er du juridisk forpligtet til at indhente gyldigt samtykke, før nogen personaliseret annoncering eller sporings-identifikator anvendes. Et cookie-banner på nettet løser ikke dette — native mobilapps har ingen cookies, og samtykket skal nå ud til de annonce-SDK'er, der kører inde i dit build.

Googles svar er User Messaging Platform (UMP) SDK, samtykkelaget der følger med Google Mobile Ads SDK. Den viser en IAB TCF-kompatibel samtykkeformular, gemmer spillerens valg og eksponerer et samtykkesignal, som AdMob og medieringspartnere læser automatisk. For et Unity-studie er det at få dette flow rigtigt forskellen mellem en sund eCPM og en bølge af politik-overtrædelser.

Samtykkeflowet fra start til slut

Den korrekte rækkefølge af operationer betyder mere end noget enkelt API-kald. Ved hver app-start bør du:

• Anmode om en opdatering af samtykkeinformationen. Dette beder UMP om at tjekke spillerens region, og om en formular er påkrævet.
• Indlæse og vise formularen, hvis det kræves. UMP afgør, om den skal vises, baseret på geografi og tidligere valg — du hardkoder aldrig "er denne bruger i EU".
• Vente på at formularen lukkes, før Mobile Ads SDK initialiseres.
• Først initialisere annoncer, efter samtykket er indhentet, så den første annonceanmodning allerede bærer det korrekte signal.

At initialisere annonce-SDK'en, før samtykkeformularen vender tilbage, er den mest almindelige fejl, vi ser. Den producerer en ikke-personaliseret eller ikke-overholdende første visning og kan udløse automatiserede politik-gennemgange.

En minimal Unity-implementering

I C# ser skelettet sådan ud:

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

Tjekket CanRequestAds() er din port. Så længe det returnerer true — enten fordi spilleren gav samtykke, eller fordi vedkommende er uden for en reguleret region — må du initialisere og anmode om annoncer. Cache intet om region selv; lad UMP være den eneste kilde til sandhed.

Test uden at udgive i butikken

Du kan ikke verificere et samtykkeflow fra dit kontor i, lad os sige, Istanbul, medmindre du simulerer en EØS-enhed. UMP understøtter en debug-geografiindstilling og en liste over hashed test-enheds-ID'er:

• Registrer din testenheds hashed ID i anmodningsparametrene.
• Tving debug-geografien til EEA for at få formularen til at dukke op.
• Brug SDK'ens reset-metode mellem kørsler, så du ser førstegangsoplevelsen hver gang.

Fjern altid debug-indstillinger før et produktions-build. At udsende et tvunget EØS-debug-flag til hver spiller er en reel og pinlig hændelse.

Samtykke, mediering og din omsætning

Når samtykke propageres korrekt, modtager hvert netværk i din medieringsstak — AdMob, Meta Audience Network, Unity Ads, AppLovin — TCF-strengen og kan byde på personaliseret inventory, hvor det er tilladt. Når det går galt, falder disse netværk tilbage til ikke-personaliserede annoncer til en brøkdel af eCPM'en, og dit waterfall bløder stille omsætning. Behandl samtykkelaget som en del af din indtjeningsstak, ikke en eftertanke om overholdelse.

Hvor FlexyConsent passer ind

Native apps har brug for en CMP i appen, for eksempel Googles UMP. FlexyConsent dækker websites på desktop og mobil (CMP ID 317 er en web-CMP). Den sender signaler for IAB TCF 2.4 og Google Consent Mode v2. Dens rapporter viser beslutninger efter kilde og region.

Vigtigste pointer

• Indhent samtykke gennem UMP SDK før Mobile Ads SDK initialiseres.
• Hardkod aldrig regionslogik — lad UMP afgøre, hvornår en formular er påkrævet.
• Test med debug-geografi og hashed test-ID'er, og fjern dem så før udgivelse.
• Korrekt samtykke-propagering beskytter din personaliserede-annonce eCPM på tværs af hele medieringsstakken.