Eliminar una cuenta en una app: datos, suscripciones y un cierre de verdad

Una solicitud al soporte revela lo que falta por diseñar

Imagina un marketplace donde una compradora pide borrar su cuenta. Tiene una entrega pendiente y una conversación abierta con el vendedor. Soporte encuentra el perfil y lo elimina. Días después, la compradora pregunta por su pedido; el vendedor ya no sabe con quién hablar y siguen apareciendo mensajes automáticos dirigidos a la antigua cuenta.

Es una situación ficticia, pero útil para diseñar. El problema no era encontrar el botón de borrar, sino decidir qué significaba la salida de esa persona mientras otras operaciones seguían existiendo. Eliminar un perfil y resolver una compra no son necesariamente la misma acción.

La respuesta tampoco debería ser bloquear indefinidamente la eliminación por cualquier trámite pendiente. Hay que ofrecer un proceso claro para esas operaciones y explicar qué datos se necesitan conservar, por qué y con qué límites. Las obligaciones contractuales y legales deben revisarse para el servicio y los mercados concretos.

Este artículo se centra en la función y sus criterios de aceptación. La política de privacidad de la app debe reflejar lo que realmente sucede, pero un documento bien redactado no ejecuta por sí solo la limpieza de los sistemas.

Dibuja primero las relaciones que vas a cerrar

Una misma persona puede tener un perfil público, una cuenta de acceso, pertenencia a una organización y una relación de pago. Decide cuál de esas cosas elimina cada acción. Si hay roles de comprador y vendedor, explica si la solicitud afecta a ambos o permite cerrar uno de ellos.

Separa también los verbos. Cerrar sesión termina una sesión. Desinstalar retira la app del dispositivo. Cancelar la renovación modifica un acuerdo de cobro. Eliminar la cuenta se refiere a la cuenta y sus datos asociados dentro del alcance aplicable. No presentes una desactivación temporal como si fuera una eliminación definitiva.

En un marketplace, el inventario incluye direcciones, imágenes, pedidos, mensajes, consultas de soporte y datos de notificación. Una conversación contiene aportaciones de varias personas; un pedido puede necesitar seguir visible para otra parte. No basta con borrar todo lo que comparta un identificador sin decidir antes el resultado esperado.

Si la persona puede descargar información útil antes de salir, ofrécele esa opción. Debe ser voluntaria y comprensible. Convertir la exportación o una encuesta en un requisito obligatorio añade una barrera que no ayuda a confirmar la intención del usuario.

Convierte el mapa de datos en tareas comprobables

Pide al equipo una relación de los sistemas implicados: acceso, base principal, almacenamiento de archivos, mensajería, soporte y proveedores externos. Para cada uno, anota el identificador, la acción acordada y cómo se comprobará que se ha ejecutado.

La cuenta de acceso suele ser solo una parte. Puedes impedir que alguien entre y mantener sus fotos o documentos almacenados. El tutorial práctico de Firebase sobre extensiones permite ver ese límite: una limpieza configurada actúa sobre datos concretos, no sobre cualquier copia imaginable en la aplicación.

Determina también quién coordina los pasos. Si cada proveedor recibe una petición independiente, alguien debe saber si todas terminaron. De lo contrario, el soporte solo podrá decir «en nuestra base ya no aparece», que no responde a lo que se prometió al usuario.

Cuando exista una conservación justificada, define la categoría, el motivo, el plazo y los accesos permitidos. «Guardaremos todo por seguridad» no es un criterio útil. Revisa además qué ocurriría al restaurar una copia de seguridad: las cuentas eliminadas no deberían volver silenciosamente al servicio activo. La implementación debe coincidir con la información publicada.

Comprueba quién está solicitando la eliminación

Una dirección de correo escrita en un formulario no demuestra por sí sola que el solicitante sea su propietario. El servidor debe asociar la acción con una identidad verificada de forma adecuada. Las credenciales privilegiadas para borrar datos deben permanecer fuera de la app.

Ahora bien, una comprobación segura no tiene por qué convertirse en un callejón sin salida. Quien se registró mediante Apple u otro proveedor quizá nunca creó una contraseña propia de la aplicación. Pedírsela en la última pantalla impediría terminar el proceso.

Diseña la confirmación de identidad junto con los métodos de acceso y recuperación de cuenta, e inclúyela en la revisión de seguridad de la app. Prevé una alternativa segura para cuando el método habitual ya no esté disponible. Esa alternativa debe ayudar a verificar a la persona, no obligarla a escuchar una oferta comercial para poder irse.

Revisa las sesiones en otros dispositivos. Si el producto ya confirmó la eliminación, un teléfono antiguo no debería seguir escribiendo datos personales bajo la misma cuenta. Las conexiones de inicio de sesión externo también requieren atención; la guía de Apple incluye la revocación de tokens de Sign in with Apple.

Haz que la pantalla explique una decisión, no una amenaza

La confirmación debe decir qué desaparece, qué sucede con las operaciones pendientes y qué se gestiona por separado. Una advertencia genérica de irreversibilidad no resuelve esas dudas. Es mejor nombrar el historial, los archivos o la conversación que realmente están en juego.

Si el trabajo tarda en completarse, distingue «Solicitud recibida» de «Cuenta eliminada». No muestres un resultado final mientras quedan tareas pendientes. Explica cómo llegará la confirmación y qué referencia puede usar la persona para consultar el estado sin tener que registrarse de nuevo.

En el ejemplo del marketplace, el pedido abierto necesita una explicación concreta y un canal de seguimiento. No insinúes que se cancela si no se cancela. Tampoco prometas conservar el acceso a un historial que dejará de estar disponible.

Una pregunta opcional sobre el motivo de salida puede aportar información. Varias pantallas de ofertas o una respuesta obligatoria no mejoran la comprensión de la consecuencia. El recorrido debe proteger frente a errores sin castigar una elección deliberada.

Respeta los dos puntos de acceso que pueden exigir las tiendas

Para las apps dentro de su alcance, Apple exige iniciar la eliminación desde la aplicación. Desactivar el perfil no es suficiente. Su guía diferencia además las verificaciones razonables de las gestiones innecesarias con soporte.

Google Play contempla un recurso web externo, además del acceso dentro de la app, para los productos sujetos a su política. Tiene sentido: una persona puede haber desinstalado y seguir queriendo eliminar sus datos.

Abre la página sin la aplicación instalada. Debe identificarse con el producto y permitir iniciar una solicitud real, no limitarse a mostrar un texto general o mandar al usuario a instalar otra vez. Prueba también quién recibe esa solicitud y cómo la tramita.

No conviertas estas indicaciones en una promesa de cumplimiento legal universal. Plazos, retención y sectores regulados requieren un análisis específico. La aprobación de la tienda y las obligaciones del negocio son comprobaciones relacionadas, pero distintas.

Compras y suscripciones necesitan su propia revisión

El artículo de ingeniería de RevenueCat sobre eliminación de cuentas explica por qué borrar un cliente puede dejar una suscripción activa. Es una lectura práctica para detectar el problema. Para implementarlo hoy, hay que contrastar el comportamiento actual del proveedor.

La documentación vigente del perfil de cliente de RevenueCat concreta esa diferencia: borrar un cliente no cancela automáticamente sus suscripciones móviles ni las de Stripe Web Payments. Las suscripciones de RevenueCat Billing, en cambio, se cancelan de inmediato. Por eso, una única advertencia copiada para cualquier forma de pago puede ser incorrecta.

*Eliminar datos y detener renovaciones son comprobaciones independientes. Hay que confirmar cómo se relacionan en cada canal de compra.*

Comprueba el origen de la compra, aunque el usuario esté utilizando ahora otro dispositivo. Un enlace a la gestión de suscripciones debe corresponder a su operación real. La plataforma del teléfono actual no basta para saber dónde se contrató el servicio.

También hay que separar cancelación de renovación, reembolso y pérdida de acceso. En la guía de aplicaciones con suscripción tratamos ese modelo. Para la salida, especifica exactamente qué se hará y qué tendrá que gestionar el usuario, sin prometer devoluciones o cancelaciones que el sistema no puede realizar.

Una avería parcial no debería convertirse en un éxito falso

Una eliminación puede recorrer varios servicios. Usa estados distinguibles, por ejemplo: recibida, verificada, en proceso y completada. Si un proveedor no responde, la tarea debe seguir pendiente con información suficiente para retomarla.

Supongamos que ya se borró el perfil, pero no se pudieron retirar los archivos. El sistema necesita recordar ese trabajo y repetirlo de forma segura. Repetir una petición no debería recrear la cuenta, afectar a otros usuarios ni obligar a comenzar desde cero una operación ya encaminada.

Conserva un registro mínimo del proceso, con estado y referencia segura. No mantengas una copia completa de todos los datos solo para demostrar que fueron borrados. Decide quién puede consultar el seguimiento y durante cuánto tiempo resulta necesario.

Prueba además la conexión interrumpida. Si el teléfono no recibió la respuesta, la app debe poder consultar el estado en lugar de inventar un resultado. Esa situación es habitual en móvil y merece el mismo cuidado que el recorrido perfecto de la demostración.

Qué pedir en la entrega de la función

Crea cuentas ficticias con archivos, mensajes, un pedido de prueba y otra sesión abierta. Para los pagos, utiliza el entorno de pruebas del proveedor. Después, comprueba el proceso normal, la solicitud desde la web, el doble envío, la caída de un servicio y el comportamiento al volver a entrar.

El resultado esperado debe poder verificarse en cada sistema. La restauración de una compra o un nuevo inicio de sesión no deberían recuperar sin explicación los contenidos personales eliminados. Una nueva cuenta vacía creada por voluntad del usuario es distinta de resucitar automáticamente la anterior.

Incluye esos casos en la lista de pruebas antes del lanzamiento. Son criterios propuestos de aceptación del producto, no un sustituto de la revisión jurídica. Su utilidad está en transformar «parece que funciona» en comprobaciones concretas.

Cuando prepares el trabajo con Appfyl, reúne métodos de acceso, lugares donde se guardan datos y canales de compra. Con esa información se puede definir una salida completa. El usuario no debería recordar cuántos sistemas había detrás; debería recordar que pudo terminar su relación con el servicio sin sorpresas.

Preguntas frecuentes