Una ficha de Play solo enlaza a una app de AdMob: por qué tus anuncios rinden poco
Un segundo proyecto de AdMob se quedó con la verificación de la ficha de Play y la app que estaba en producción sirvió con fill bajo y eCPM bajo, sin errores visibles.
Un desarrollador de Android tenía su juego publicado en Play con los identificadores de una app de AdMob compilados dentro del APK, y a la vez la ficha del juego estaba enlazada a una segunda app de AdMob distinta, creada tiempo atrás y sin nada dentro. AdMob respondió limitando la entrega de anuncios en la app que sí tenía usuarios, y desde Play Console no hay forma de mover ese enlace. El arreglo no pasaba por tocar código.
Qué es la entrega limitada
AdMob entrega ID de aplicación y de unidades de anuncio sin comprobar que la app exista en una tienda. Hasta que esa app no se enlaza a su ficha, queda sin verificar, y una app sin verificar sirve con poca demanda: tasa de relleno baja, eCPM bajo, sin puja programática. Los anuncios no se apagan, simplemente valen muy poco, y eso se nota menos que una caída.
Conviene precisar de qué límite se habla, porque el término está sobrecargado. Casi todo lo que aparece al buscar el asunto es el otro: una infracción del centro de políticas, una suspensión o un límite temporal mientras alguien revisa la cuenta. Aquí era el aburrido, el administrativo, y no se levanta con una apelación.
Una ficha de Play, una sola app de AdMob
Esa frase es todo el problema. La segunda app había reclamado la ficha del juego y estaba verificada; la primera, la que iba dentro del build, ya no podía enlazarse porque la ficha estaba ocupada. La consola ni siquiera la ofrece. Cada una tenía justo lo que le faltaba a la otra: la de producción, las unidades de anuncio; la enlazada, la verificación y nada que servir.
Hay dos salidas. La barata es borrar la app vacía: no tenía unidades, así que no hay nada que perder, se libera la ficha y la app ya instalada se enlaza y se verifica. Sin cambios de código y sin publicar nada, la versión que la gente tiene en el móvil empieza a servir bien cuando pase la verificación. La otra es mudarse a la app enlazada: crear allí las unidades (banner, interstitial y rewarded), cambiar cuatro IDs, compilar, subir y esperar a que los usuarios actualicen. El autor recomienda la primera y acabó haciendo la segunda, porque las unidades ya se habían creado mientras decidían.
El ID vive en dos sitios
El app ID aparece en el bloque react-native-google-mobile-ads de app.json y otra vez en el meta-data de AndroidManifest.xml, con un tools:replace para ganar la fusión de manifiestos. Cambiar solo el primero compila sin errores y deja el valor viejo dentro del paquete. La comprobación está en el artefacto, no en el código fuente: unzip -p app-release.aab base/manifest/AndroidManifest.xml | strings | grep -o "ca-app-pub-[0-9]*~[0-9]*".
Y luego está el coste que se repite: como el arreglo viaja dentro de una versión, gasta versionCode. El cambio salió como 1.0.10 y un segundo pase la misma noche se convirtió en 1.0.11. Borrar la app vacía no habría gastado ninguno. El app-ads.txt, en cambio, no se tocó: el identificador de editor era el mismo en las dos apps.
Probar el build en un emulador no sirve para esto. AdMob trata los emuladores como dispositivos de test sin excepción, así que ver el banner etiquetado como Test Ad solo confirma que el SDK arrancó. La verificación de verdad está en la consola: el aviso para enlazar una ficha tiene que desaparecer.
