Sesión de preguntas y respuestas sobre las políticas de Play

Bien.

Gracias a todos por unirse a este panel sobre cómo descifrar las políticas de Google Play.

Soy Jan Kleinert, ingeniero de Relaciones con Desarrolladores del equipo de Android para vehículos.

Y seré el moderador del panel de hoy.

Les daré la palabra a nuestros panelistas, Bohdan y Paul, para que se presenten.

Bohdan, comencemos contigo.

Hola.

Soy Bohdan y trabajo en el equipo de Confianza y Seguridad de Google Play.

Trabajo aquí desde hace más de cuatro años y en el sector de confianza y seguridad tecnológica desde hace más de una década.

Me gusta ver cómo interactúan la tecnología, la industria y la cultura, y cómo los eventos fomentan el desarrollo de nuevas apps. También me gustan los eventos como este, en los que podemos hacer todo lo posible para ayudar a que desarrolladores como ustedes tengan éxito.

Hola a todos.

Me llamo Paul.

Trabajo en el mismo equipo que Bohdan y he estado en Confianza y seguridad durante aproximadamente el mismo período que Bohdan, una década, y la mayor parte de ese tiempo ha sido con el equipo de Confianza y seguridad de Google Play.

Por eso, me alegra mucho estar aquí hoy. Comencemos.

Muy bien, gracias.

Para preparar el terreno antes de comenzar el panel, le devolveré la palabra a Paul.

Comenzará con una breve descripción general de los recursos de políticas, información sobre las prácticas recomendadas y otros temas similares para ayudarte a preparar tu app para una revisión de cumplimiento de las políticas más fluida y eficiente.

Sí.

¿Qué entendemos por política de Play?

Estas son las reglas fundamentales que los desarrolladores deben cumplir cuando publican y mantienen aplicaciones para dispositivos móviles en Google Play Store.

Proporcionamos algunos vínculos cortos en la pantalla para acceder a los recursos de las políticas de Play.

El primer vínculo te lleva al Centro de políticas para desarrolladores.

Si haces clic en Actualizaciones recientes en la parte superior de la página, podrás leer los detalles sobre las políticas nuevas, así como las actualizaciones o aclaraciones de las políticas existentes.

Si prefieres aprender de forma visual o auditiva, el segundo vínculo corto te llevará a una playlist de nuestros Policy Bytes.

Son videos en los que hablamos sobre las actualizaciones de las políticas.

Por último, el tercer vínculo te llevará a una página en la que podrás obtener más información sobre la información de las políticas de Play en Android Studio, una función que tiene como objetivo proporcionar orientación útil antes de la revisión, que se entrega como verificaciones de lint en Android Studio.

Bien.

También hay una habilidad de Android para ayudar a auditar las apps para Android en función de estas políticas de Google Play y ayudarte a verificar el cumplimiento de los permisos, la eliminación de cuentas y la seguridad de los datos.

Puedes instalar esta habilidad con la CLI de Android, como cualquier otra habilidad.

android skills list
android skills add play-policy-insights

Por último, antes de comenzar con algunas de las preguntas del panel de Jan, queríamos compartir algunas prácticas recomendadas para trabajar con las políticas de Play y las revisiones de apps.

En primer lugar, proporciona credenciales de acceso para los revisores.

Parece algo sencillo, pero un motivo muy común de retraso o rechazo es el contenido inaccesible.

Si tu app requiere un acceso, tiene contenido restringido, créditos o suscripciones, debes proporcionar credenciales de prueba.

En algunas apps, esto significa proporcionar credenciales de acceso solo al principio de la app y, en otras, es posible que tengas diferentes secciones, como el contenido pagado que mencioné.

Puedes hacerlo en Play Console y, luego, proporcionar estas credenciales de acceso a nuestros revisores.

Antes se llamaba Acceso a la app, pero ahora se llama Detalles de acceso y se encuentra en la sección Contenido de la app.

Y, luego, debes asegurarte de que las credenciales omitan cualquier tipo de autenticación de dos factores, captchas, muros de pago, etcétera.

Sí, desactiva los códigos de versión anteriores.

Por lo tanto, los desarrolladores suelen experimentar lo que llamamos, de forma coloquial, bucles de rechazo, porque suben una compilación de producción limpia y que cumple con las políticas, pero suelen olvidar que una versión anterior que no cumple con las políticas sigue activa en Play Console en otro segmento, ya sea de pruebas abiertas, cerradas, etcétera. Por lo tanto, incluso si un paquete de aplicación está en un segmento de pruebas antiguo, está sujeto a la revisión de cumplimiento de las políticas de Play.

Por lo tanto, si solicita permisos restringidos o usa SDK vulnerables desactualizados, se someterá a revisión.

Por lo tanto, asegúrate de reemplazar o desactivar todos los códigos de versión obsoletos en todos los segmentos antes de presionar el botón de envío.

Tercero, deja tiempo suficiente para las revisiones y usa la publicación administrada.

Por lo tanto, las revisiones y publicaciones de apps pueden tardar siete días o, a veces, más en publicarse, especialmente si se trata de una app nueva o una que solicita un permiso sensible.

Por lo tanto, debes dar suficiente tiempo de anticipación.

Si tienes un lanzamiento importante, asegúrate de enviar la app nueva al menos un par de semanas antes de la fecha de lanzamiento real.

Luego, puedes vincularlo con la publicación administrada.

La publicación administrada es una función que permite retener las actualizaciones aprobadas hasta que estés listo para lanzarlas, lo que evita demoras inesperadas durante las campañas de marketing o en otros lanzamientos importantes.

Mientras lo haces, asegúrate de no volver a enviar la app una vez que ya se haya enviado para su revisión.

Porque si lo haces, el reloj se reinicia.

Creo que, a veces, los desarrolladores se olvidan de eso y tienen una app a medio camino, y se olvidan: "Oh, tengo que hacer este pequeño cambio".

Vuelven a enviarla y, luego, regresa al inicio del proceso de revisión.

Correcto, revisa tus declaraciones.

Por lo tanto, las declaraciones de contenido de tu app, como la sección de seguridad de los datos, la política de privacidad o los permisos de fotos y videos, por ejemplo, deben coincidir con el manifiesto de la app de los paquetes o códigos de versión activos en todos los segmentos.

Por ejemplo, si el manifiesto de tu app solicita acceso a la ubicación precisa, pero tu formulario de declaración de permisos no divulga su propósito, es muy probable que se apliquen medidas por incumplimiento en la app.

Por lo tanto, asegúrate de que los SDK de terceros no extraigan datos que no hayas declarado.

Incluso si tu app no usa un dato específico, si decides integrar un SDK que sí lo hace, podría generar una aplicación de medidas por incumplimiento.

Por lo tanto, consulta el Índice SDK de Google Play para ver estadísticas sobre más de 100 de los SDK comerciales más utilizados.

Me gustaría interrumpir con una pregunta rápida antes de continuar.

Cuando dices "aplicaciones de medidas por incumplimiento", ¿a qué te refieres específicamente?

¿Qué significa ese término?

Las aplicaciones de medidas por incumplimiento pueden ser cualquier acción adversa, por lo que pueden variar desde advertencias hasta rechazos, o incluso aplicaciones de medidas por incumplimiento más graves, como eliminaciones, suspensiones o incluso prohibiciones de cuentas.

Por lo tanto, cuando hablo de aplicaciones de medidas por incumplimiento, me refiero a estas acciones adversas.

Genial.

Gracias.

Sí.

Por último, usa las apelaciones.

No vuelvas a enviar la misma versión después de un rechazo.

Además, los rechazos repetitivos por el mismo problema en un período breve podrían activar un indicador algorítmico que genere medidas más severas, como las que mencionó Paul, como eliminaciones o suspensiones.

Por lo tanto, si se rechaza una app, no la vuelvas a enviar de inmediato sin realizar cambios, adivinar o abordar los comentarios.

Recibirás comunicaciones tanto en la bandeja de entrada de la consola como en los correos electrónicos asociados que proporcionaste para conocer el incumplimiento exacto y obtener orientación.

Y, luego, si no estás de acuerdo o tal vez no entiendes, pero supongamos que no estás de acuerdo con un rechazo, apela, ¿verdad?

Si crees que se trata de un falso positivo, puedes usar el vínculo que se proporciona en las comunicaciones para apelar.

Y ese es un mejor primer paso que simplemente apresurarse a volver a enviar la app sin realizar ningún cambio.

Y lo mismo ocurre si recibes las comunicaciones y no tienen mucho sentido para ti, tal vez sean muy extensas, tal vez tengan demasiados párrafos, sea lo que sea, está perfectamente bien volver a las apelaciones.

Cuando lo hagas, te comunicarás por correo electrónico con una persona real.

Si bien puede haber algunos límites en cuanto a lo que pueden comunicar, a menudo puedes obtener detalles adicionales sobre el motivo del rechazo.

Otras veces, el equipo de apelaciones comprende que las comunicaciones pueden ser bastante extensas.

Por lo tanto, lo que harán es destacar o poner en negrita las secciones que se aplican específicamente a ti y a tu app.

Entonces, sí.

Dicho esto, le cedo la palabra a Jan.

Bien.

Gracias.

Por lo tanto, recopilamos preguntas de desarrolladores de varios canales y fuentes diferentes.

Por lo tanto, estas preguntas que tenemos hoy representan algunos de los problemas que escuchamos con frecuencia de los desarrolladores en lo que respecta a las políticas.

Comencemos con esto.

¿Cuáles son algunos de los motivos comunes por los que se puede rechazar una app en relación con los permisos?

¿Y cómo pueden los desarrolladores evitar esos rechazos relacionados con, por ejemplo, los incumplimientos de las políticas de permisos?

Bien.

Permisos, yo me encargo de eso.

Por lo tanto, los permisos, en especial los sensibles, deben ser fundamentales para el propósito principal de tu app.

Por lo tanto, si tienes una función auxiliar o alguna función que ni siquiera está en la app y que ni siquiera se anuncia, es muy probable que se rechace la app.

Por lo tanto, asegúrate de que la declaración coincida con el caso de uso de la app.

Además, muchas veces se rechaza una app porque no se puede acceder a los vínculos de video que proporcionas en las declaraciones.

Nuestro equipo de revisión debe poder acceder a la app, los vínculos de video que proporciones y todo lo que esté dentro de la app para, ya sabes, revisarla por completo.

Por lo tanto, asegúrate de que todo sea accesible dentro de la app, el manifiesto y la declaración.

Por lo tanto, asegúrate de que se completen esos tres elementos y, muy probablemente, bueno, no quiero decir muy probablemente, pero será un proceso más fluido.

Genial.

Bien.

Por lo tanto, cada vez más desarrolladores de apps comienzan a usar plataformas de terceros para el contenido generado por IA en sus apps, ¿verdad?

Si esas plataformas producen contenido inapropiado, incorrecto o algo similar, ¿puede eso llevar al rechazo de la app del desarrollador? ¿Quién es realmente responsable en esos casos?

Sí.

Sí, eso puede provocar un rechazo.

Desde el inicio de Play Store, la postura siempre ha sido que, ya sabes, lo que un desarrollador tiene en la app o lo que un usuario puede acceder en la app es responsabilidad del desarrollador.

Y, aunque la IA generativa es un área nueva, lo mismo se aplica a ella.

Creo que un buen paralelo para la IA generativa es el contenido generado por usuarios, porque para ambas políticas se deben tener muchos de los mismos tipos de, ya sabes, se debe tener, marcar, ya sabes, si aparece algo que no es del todo apropiado.

Debe haber un mecanismo de filtrado.

Creo que hay, es decir, hay otras políticas, por supuesto, que se aplicarían, pero la forma en que me gusta verlo es que, si tienes contenido de IA generativa, tienes a Google que revisa la app, tienes a los usuarios que hacen clic en marcar si ven algo inapropiado y, luego, tienes tus mecanismos de filtrado.

Por lo tanto, Google, los desarrolladores y los usuarios trabajan en conjunto para ayudar a que la app sea lo más segura posible para todos.

Bien.

Muy bien.

Pero, en general, ¿recomendamos que, además de tener mecanismos para que los usuarios marquen contenido, los desarrolladores implementen algún tipo de… ¿A eso te refieres con el mecanismo de filtrado?

¿Para evitar que se muestren ciertos tipos de contenido a los usuarios?

Correcto.

Sí.

Por lo tanto, durante el proceso de revisión, nuestros equipos no van a intentar analizar tu código ni aplicar ingeniería inversa para descubrir cuál es tu mecanismo de filtrado exacto.

Solo van a verificar si pueden acceder a contenido inapropiado.

Y si pueden, entonces enviaríamos algunas comunicaciones de vuelta, y luego sería el trabajo de tu equipo averiguar cómo pueden hacer que ese mecanismo de filtrado sea más robusto.

Entendido.

Genial, gracias.

Por ejemplo, una de las políticas existentes se llama política de suplantación de identidad o de imitación, ¿verdad?

Entonces, si se rechaza una app en virtud de esa política de suplantación de identidad, pero el desarrollador cree que se trata de un error, por el motivo que sea, ¿qué debería hacer?

¿Y cómo pueden evitar de forma proactiva ese tipo de rechazo?

Apelar.

Sí, esa es una de las, creo que es la quinta práctica recomendada que tenemos en el pizarrón: si te rechazan por eso, debes apelar.

Y, luego, lo que deberías hacer es, bueno, las situaciones más comunes serán que la marca que estás suplantando es, tal vez, tu propia marca, ¿verdad?

O bien, estás creando una app en nombre de otra persona, y eso diría que es probablemente lo más común, donde tienes desarrolladores de marca blanca que están creando apps para, tal vez, sus instalaciones de fitness, SaaS, ya sabes, algún tipo de solución de SaaS.

Y, por lo tanto, es más fácil publicarlas en tu propia cuenta de desarrollador, ¿verdad?

Por lo tanto, puedes presentar una apelación, y lo que nuestro equipo buscará es lo que se denomina prueba de permiso.

Supongamos que tienes un cliente llamado Joe's Chicken, que tiene el mejor pollo, ya sabes, al oeste del Mississippi.

Te darán una carta de prueba de permiso con el membrete oficial de la empresa y su logotipo que diga, por ejemplo, "Nosotros, Joe's Chicken, le damos permiso al desarrollador ABC para que use nuestras imágenes y nuestra imagen en su app". Es mejor si incluyen el nombre de la app y el nombre del paquete de la app.

Por ejemplo, com.joeschicken.app, y, luego, puedes responderle al desarrollador y proporcionarle esa documentación.

Bien.

Y, luego, creo que la segunda parte era…

¿Hay algo que puedan hacer de forma proactiva para evitarlo?

Por ejemplo, ¿puedes subir, olvidé cómo se llamaba, la prueba de algo, ya sabes, en el momento en que realizas tu primer envío?

Sí.

Así es.

En Play Console, hay un formulario de aviso anticipado que puedes enviar y en el que puedes subir estos documentos que asocian tu cuenta con la otra entidad.

De esta manera, puedes proteger de forma preventiva el envío de tu app contra este tipo de acciones adversas de aplicación de políticas.

Así es.

Genial.

Bien.

Mencionaste un poco sobre el uso de SDKs de terceros en la sección de prácticas recomendadas, pero me gustaría profundizar un poco más en eso.

Entonces, cuando las apps usan SDKs de terceros, parece que es cierto que los desarrolladores de apps son responsables de cómo esos SDKs de terceros usan elementos como los datos de los usuarios.

Entonces, ¿cómo se supone que los desarrolladores sepan que los SDK cumplen con las políticas de seguridad de los datos y de datos del usuario?

¿Cómo pueden navegar por ese panorama?

Sí, es una excelente pregunta.

Trabajé mucho con SDK en Google durante mis primeros 2 años aquí, y esto se relaciona con la pregunta anterior, en la que hablábamos de la IA generativa y el contenido generado por usuarios, en el sentido de que, en última instancia, el desarrollador es responsable de todo lo que hay en su app.

Creo que Paul mencionó brevemente en la introducción que tenemos algo llamado Índice SDK de Google Play, y puedes buscarlo en Google.

Debería ser el primer o segundo resultado, Índice de SDK de Google Play, y lo que obtendrás es una página web que tiene más de cien, tal vez varios cientos de SDK divididos por ¿es un SDK para monetización, o para anuncios, o es para salud, o algo diferente?

Y esa página solo extrae datos disponibles públicamente.

Es algo que organiza Google.

Pero lo que notarás es que, a medida que revisas estos SDK, algunos de ellos tendrán una insignia que dice algo como "registrado en SDK Console".

Así como ustedes, los desarrolladores, tienen una consola para desarrolladores de Play para sus apps, los desarrolladores de SDKs tienen la opción de acceder a una consola para desarrolladores de SDKs.

Y deben pasar por un proceso de revisión similar.

Nos envían su SDK.

Google realiza algunas verificaciones diferentes, pero si todo está en orden y cumple con los requisitos, se obtiene la insignia.

Para ustedes, como desarrolladores, esto significa que pueden consultar ese índice y ver qué SDKs pasaron por ese proceso.

Esto no garantiza que la app se aprobará o que el SDK nunca dejará de cumplir con las políticas, pero diría que brinda dos puntos de confianza.

La primera es que hay una probabilidad mucho mayor de que no se rechace la app si usas ese SDK.

Solo una probabilidad.

La segunda, y esto es algo que me gusta mucho de todo el proceso, es que, si descubrimos que el SDK tiene algo que no cumple con las políticas, adoptaremos un enfoque de dos frentes.

La primera es que nos comunicaremos con el desarrollador del SDK y le diremos: "Oye, notamos que tu SDK envía datos de los usuarios de una manera que no cumple con las políticas".

Luego, trabajarán para que su app o SDK cumpla con las políticas.

Y, al mismo tiempo, o tal vez un poco después, como segundo paso, nuestros equipos enviarán notificaciones o advertencias a los desarrolladores.

Y la notificación dirá algo como "Hola, notamos que tu app envía esos datos de una manera que no cumple con las políticas y que esto sucede en el SDK ABC".

Por lo tanto, como desarrollador, puedes actualizar el SDK a cualquier versión que cumpla con las políticas que hayan proporcionado.

Si quieres tomar medidas más drásticas, puedes quitar el SDK o reemplazarlo, pero sé que eso requiere mucho esfuerzo y trabajo.

Pero eso es lo que me gusta del Índice SDK de Google Play.

Sí.

En el índice, no se indica con qué políticas exactas cumple o no, pero sí se obtiene esa insignia, que es como un voto de confianza.

Bien.

Sí.

Muy bien.

Y, según lo que dijiste, si enviamos mensajes a los desarrolladores para decirles, por ejemplo, "Estás usando este SDK y tiene un problema",

¿Les decimos qué versión deben actualizar? Si el desarrollador lo corrige, ¿les decimos algo como "Oye, hay una versión mejor, que es tal y tal"?

¿O tienen que investigar un poco por su cuenta?

Creo que, de hecho, tiene el código de versión allí.

Sí, no me tomes la palabra, pero creo que tiene el código de versión que se indica allí y que pueden actualizar.

Sí, y para ser totalmente transparente, no soy desarrollador ni ingeniero, pero, por lo que entiendo de mis conversaciones con desarrolladores, a veces es tan fácil como hacer clic en un botón o un par de botones, y luego se inicia el proceso de actualización del SDK dentro de la app.

Qué genial.

Genial.

Gracias.

Bien.

Hablaste un poco sobre las credenciales de acceso, que es un tema con el que estoy un poco familiarizado, y sobre lo importante que es tener esta información allí.

Mencionaste cosas como omitir la autenticación de dos factores y garantizar una forma de superar los muros de pago o el acceso al contenido basado en suscripciones.

¿Qué otras situaciones comunes deberían tener en cuenta los desarrolladores?

Por ejemplo, un caso que me encontré es que, a veces, las apps tienen contenido al que solo se puede acceder en ciertos países o ubicaciones geográficas, o tal vez una app de mensajería que requiere dos accesos para poder probarla.

¿Hay otras situaciones como esa en las que, además de proporcionar un acceso, los desarrolladores deban hacer algo más?

Sí.

Es decir, creo que siempre empezaría y terminaría con las credenciales de acceso que proporciones al equipo de revisión. Solo asegúrate de que les den acceso a todas las funciones de la app.

Esa sección de Play Console se llamaba Acceso a apps y, hace aproximadamente un mes, se cambió a Detalles de acceso.

Y sí, hay un lugar donde puedes ingresar el nombre de usuario, la contraseña y, debajo, creo que hay un campo de texto libre.

Por lo tanto, puedes dar instrucciones sobre cómo te gusta que sean los pasos para acceder si no es muy sencillo.

También puedes proporcionar un segundo, un tercero y un cuarto acceso si quieres que los usuarios lo hagan.

Y para darte una idea de cómo nuestros equipos revisan las apps, no es que alguien se sienta en una sala, mira un poco y luego hace clic en aprobar o rechazar.

Hay muchos equipos que analizan las diferentes políticas y flujos de trabajo, por lo que es muy probable que más de una persona acceda a tu app desde varios dispositivos y, a veces, desde diferentes regiones.

Y entiendo la dificultad, porque muchos mecanismos de seguridad dicen: "Oh, si vemos muchos accesos", entonces, por el bien de la seguridad del usuario, se detiene y se vuelve a poner.

Pero, independientemente de lo que elijas hacer, ten en cuenta que revisamos la app en muchos flujos de trabajo diferentes, por lo que es posible que veas eso.

Por lo tanto, proporcionar esos accesos múltiples puede ayudar.

Sí.

Genial.

Sí, debo destacar la importancia de utilizar ese texto de formato libre en la declaración.

Por lo tanto, si tu cuenta de demostración no es simplemente un nombre de usuario y una contraseña, y si hay más pasos involucrados, debes asegurarte de que nuestro equipo de revisión comprenda cómo acceder a tu app.

Podrías, por ejemplo, proporcionar un video para mostrar cómo hacerlo, solo para asegurarte de que nuestro equipo entienda cómo hacerlo si es más complejo que, por ejemplo, un nombre de usuario y una contraseña.

Sí.

A veces, miramos las apps y vemos algunos accesos bastante sofisticados.

He visto algunos en los que, y no estoy inventando esto, hay que presionar este botón 17 veces, luego dibujar una X en la pantalla, luego aparece el modo de desarrollador y luego hay, ya sabes, otros 11 pasos que seguir, así que no hagas eso.

Porque eso lo hace un poco difícil.

Una situación de la que he oído hablar es que, ya sabes, algunas apps solo te permitirán tener, por ejemplo, X, ya sabes, accesos sucesivos o accesos al mismo tiempo con una app antes de que te diga: "Oh, tienes que quitar uno".

Por lo tanto, si tu app admite esa función, creo que también es útil incluir información sobre cómo encontrar la página en la que se puede quitar el acceso a, por ejemplo, los accesos anteriores.

Sí.

Genial.

Por lo tanto, cuando actualizamos las políticas o publicamos políticas nuevas, a veces, es posible que los desarrolladores deban realizar cambios en sus apps que, según el caso, podrían tardar un tiempo en implementarse.

A veces, estas tienen una fecha límite, ¿verdad?

Por ejemplo, antes de esta fecha, debes haber hecho XYZ para cumplir con una nueva política.

Si se acerca esa fecha límite, pero un desarrollador sabe que necesitará más tiempo para cumplir con los requisitos, ¿qué opciones tiene?

Sí, eso suena como una advertencia.

Sí, suena como una advertencia.

Sí.

Sí, con las advertencias, la más sencilla es, por ejemplo, pedir más tiempo, ¿verdad?

Por lo general, el proceso funciona de la siguiente manera: lanzamos políticas nuevas, actualizaciones de políticas existentes o incluso solo aclaraciones.

Y, luego, creo que Google suele dar un buen plazo de entrega.

Y esa política podría anunciarse públicamente 6 meses, ya sabes, antes de que empecemos a tomar medidas.

Y luego, sí, se enviarán las advertencias y diremos: "Oye, tu app infringe esta política que se anunció", ya sabes, "hace 6 o 12 meses", o lo que sea.

Pero una cosa que, y Paul y yo a veces nos oponemos a esto, pero podrían decir que tienes 7 días para hacer este cambio.

Y es que el desarrollo lleva mucho tiempo.

Lo entendemos.

Por lo tanto, lo que haría es simplemente responder.

Deberías hacerlo a través de una apelación y decir algo como "Hola, entendemos la política y cómo nuestra app, ya sabes, no cumple con ella.

Ya estamos trabajando en ello, o estos son los pasos que vamos a seguir para, ya sabes, resolver el problema relacionado con las políticas, pero necesitamos más tiempo".

Por lo tanto, suelen darte un poco más de tiempo.

Si pasan otros 7 días y se acerca el final de ese período, puedes volver a solicitarlo.

Por supuesto, no es infinito.

Pero, como dije, Paul y yo nos oponemos, pero eso es a nivel individual y también a un nivel más alto.

Por ejemplo, cuando sabemos que se implementarán políticas nuevas y quiénes están trabajando en ellas, les decimos: "Miren, ¿podrían dar una advertencia de 28 días en lugar de 7, o al menos de 14?".

Sí.

Así es.

Si demuestras buena fe, ya sabes, estableciendo que estás haciendo cambios de buena fe para cumplir con los requisitos, Google Play trabajará contigo para, ya sabes, establecer una nueva fecha límite para establecerlo.

Una mejor línea de tiempo para ti.

Bien.

Entonces, parece que las apelaciones son como una herramienta multifacética para ayudar con muchas de estas situaciones, siempre que se usen de forma adecuada.

Por ejemplo, apelar cuando tiene sentido y comunicar suficientes detalles sobre el motivo de la apelación puede ser una buena forma de obtener esa consideración y ayuda.

Bien.

Por lo tanto, si un desarrollador tiene varias apps en una cuenta de desarrollador, lo que sé que sucede todo el tiempo,

y se suspende una app por algún tipo de incumplimiento de política, ¿qué significa eso para toda su cuenta de desarrollador?

¿Eso pone en riesgo la cuenta o las otras apps que sí cumplen con las políticas?

¿Cómo funciona?

Podría ser.

Serían como tus desarrolladores de marca blanca.

Antes, hablé de Joe's Chicken, ¿verdad?

Y tal vez, ya sabes, tienes clientes que están todos en esa industria.

Y, por lo tanto, lo veo como si estuvieras jugando béisbol y tuvieras strikes, ¿verdad?

Lamentablemente, hay agentes que intentan ingresar a Play Store con malas intenciones, y ese es uno de los motivos por los que tenemos este tipo de medidas de aplicación de políticas, que van desde las más leves hasta las más severas, como eliminaciones, suspensiones y hasta prohibiciones de cuentas.

Por lo tanto, si tienes una de esas situaciones en las que tienes muchas apps similares en Play Store y se suspende una de ellas, digamos que…

Mm-hm.

Eres un agente malicioso, ¿verdad?

Así que lo arreglas y, un mes después, intentas volver a incluirlo.

Luego, nuestros equipos lo detectan y se vuelve a suspender la cuenta, ¿verdad?

Y luego lo quitas de tu app y lo vuelves a poner un mes después, y luego, bueno, ahora tenemos un patrón de comportamiento repetitivo, y estás en el bate, tienes tres strikes y estás fuera, ¿verdad?

Pero supongamos que estás creando una app para un restaurante de pollo, que no va a ser contenido malicioso ni nada por el estilo, solo intentas que la gente conozca comida deliciosa.

Por lo tanto, supongamos que envías todas estas apps al mismo tiempo con una canalización de CI/CD o algo similar, y recibes 10 apps que reciben este rechazo o suspensión al mismo tiempo. Solo lo consideraríamos como una falta, ya que entendemos que estás creando muchas apps al mismo tiempo.

Mm-hm.

Interesante.

Creo que esa era la respuesta a la pregunta.

Sí, genial.

Gracias.

Y tengo una más para nosotros aquí.

Y esta pregunta, tal vez, muchas de estas preguntas han sido más para desarrolladores establecidos, pero esta es más sobre cuando te estás configurando por primera vez en Play Console.

Supongamos que se verificó tu perfil de pagos de Google Play.

Los errores de verificación de identidad ya no aparecen, y solo queda el de verificación del número de teléfono.

Por ejemplo, ¿qué hace un desarrollador en ese caso específico para asegurarse de que su cuenta de desarrollador esté lista para publicar apps?

A veces, es como si estuvieras recogiendo piezas individuales de un rompecabezas. Si no saben cómo terminar el proceso en un caso como ese, ¿qué pueden hacer?

Sí, hace poco me hicieron una pregunta similar en otro evento, pero creo que, si bien eso es obviamente cierto para los desarrolladores nuevos, creo que muchos de los desarrolladores existentes tuvieron que volver a realizar esa verificación.

Esto fue hace un año, ¿verdad?

No puedo recordar.

Muchos de ellos se verificaron automáticamente, pero algunos que no lo hicieron tuvieron que hacerlo.

Bien.

O tal vez si su dirección y su perfil de Dun & Bradstreet no coincidían, como…

Así es.

Así es.

El perfil de Google.

Bien.

Sí, digamos que es el número de teléfono.

Responderé la pregunta de dos maneras.

Bien.

Por ejemplo, muchas veces, cuando sigues estos pasos, aparecen notificaciones en Play Console.

Por lo tanto, solo recibirías una notificación que dice: "Oye, es hora de que registres tu número de teléfono".

Y esa es bastante simple.

Lo ingresas en un formato de número de teléfono internacional, más 1 408, cualquiera que sea el número.

Deberás realizar una verificación por SMS o llamada telefónica y seguir los pasos que se indican allí.

Pero, a veces, tal vez intentaste hacerlo y recibiste un mensaje de error o algo similar, porque tuvimos desarrolladores a los que también les pasó eso, o no recibían el código por SMS.

Te daré los pasos para que puedas ver que mencionas al equipo de apelaciones.

Ese es un equipo, pero en realidad hay, no sé si media docena o dos docenas de otros equipos que…

Will.

Responde las preguntas sobre Play Console a las que realmente tienes acceso, y hazlo a través del menú de ayuda.

Ahora que la IU cambió un poco,

Antes, se encontraba en un menú ubicado en el lado izquierdo de la pantalla principal.

En la parte inferior, había un botón de ayuda.

Ese botón desapareció, pero si ahora te desplazas hasta la parte inferior de cualquier página, verás el botón de ayuda en el pie de página.

Cuando hagas clic en él, verás un pequeño botón azul con forma de píldora que dice Crear ticket de asistencia.

Creo que eso es lo que dice.

Mm-hm.

Sí.

Luego, verás algunos menús desplegables en los que puedes hacer preguntas.

De hecho, hay una serie de menús desplegables que te llevarán directamente al número de teléfono. Creo que casi me lo sé de memoria, pero es algo como "Verifica tu cuenta de desarrollador". El segundo menú desplegable es bastante similar y verás un montón de botones de selección.

Uno de ellos es específicamente para la verificación del número de teléfono.

Y, luego, tal vez tengas un código de verificación por SMS o haya un error que aparezca en tu pantalla cuando intentes realizar ese proceso.

Puedes hacerlo para la verificación del número de teléfono, pero también para muchas otras preguntas que puedas tener relacionadas con tu cuenta de desarrollador de Play.

La mayoría de las veces, Play Console es muy buena para mostrar cuáles son los próximos pasos para la verificación, así que solo sigue los pasos y todo estará bien.

Excelente.

Genial.

Bueno, ya casi se nos acaba el tiempo, así que muchas gracias a todos por acompañarnos en este panel.