FedCM y login sin cookies de terceros: qué revisar si tu web usa acceso con Google

FedCM cambia cómo algunos flujos de identidad federada funcionan cuando el navegador limita cookies de terceros. Si tu web usa inicio de sesión con Google, no basta con comprobar que el botón aparece: hay que probar alta, login recurrente, rechazo, consentimiento, medición y soporte en navegadores antes de tocar campañas o checkout.

Fuentes consultadas: Google Developers: FedCM migration, Google Developers: FedCM beta, AEPD: guía de cookies.

Por qué importa ahora

Google ha empujado FedCM como API para identidad federada en el contexto de Privacy Sandbox y reducción de dependencia de cookies de terceros. Las webs con login social, comunidades, SaaS o checkout deben probar flujos reales, no solo leer documentación. El punto práctico para una persona, una pyme o un equipo digital en España es no convertir una tendencia en una compra, ni una norma en una lista de miedo. La decisión madura empieza por definir qué riesgo se quiere reducir, qué evidencia existe y qué parte del proceso puede fallar si se actúa con prisa.

También importa porque muchas decisiones tecnológicas se acumulan sin responsable: un proveedor nuevo, una integración de pago, un script, una herramienta de soporte, una política de acceso o un dispositivo comprado para salir del paso. Cuando esa cadena crece, el coste no aparece solo en la factura. Aparece en incidencias, devoluciones, reclamaciones, soporte, pérdida de datos, caídas de web o decisiones que nadie sabe revertir.

La intención de búsqueda real

La intención concreta de esta guía es preparar una web con login federado ante cambios de cookies y FedCM. Si el lector solo se queda con una idea, debería ser esta: la herramienta o la norma no decide por ti. Decide el contexto: tamaño del negocio, datos tratados, dependencia de proveedores, capacidad técnica, exposición pública y coste de equivocarse.

Una forma rápida de aterrizarlo es escribir tres frases: qué problema tengo, qué pasaría si no hago nada durante 90 días y qué evidencia necesito para decidir. Si no puedes completar esas frases sin usar palabras vacías, todavía no estás ante una decisión; estás ante ruido.

Qué cambia en la práctica

En este tema pesan especialmente estos factores: proveedor de identidad, navegadores soportados, medición de conversiones, consentimiento, recuperación de cuenta. No todos importan igual, pero ignorar uno de ellos suele crear una deuda que aparece más tarde. Un ejemplo típico es mirar solo el precio visible y olvidar soporte, reversibilidad, integración, seguridad o experiencia de usuario.

• Un botón que funciona en Chrome de escritorio puede fallar en móvil si el flujo de consentimiento no está probado.
• Si el alta social no guarda email verificado o método alternativo, el soporte se complica cuando cambia el navegador.
• Una campaña de pago puede perder conversiones si el login rompe justo en el paso de cuenta.

La lectura práctica no es comprar más ni bloquear todo. Es separar decisiones reversibles de decisiones críticas. Una prueba limitada, un entorno de staging, una copia restaurable o un flujo de soporte bien escrito valen más que una implantación grande sin control.

Checklist antes de actuar

• Define el caso exacto y el usuario afectado.
• Revisa qué dato, permiso, contrato o proveedor interviene.
• Comprueba si existe una fuente oficial, documentación del proveedor o requisito legal aplicable.
• Prueba el camino normal y el camino problemático.
• Documenta quién decide, quién ejecuta y quién revisa.
• Mide una señal útil: error, conversión, tiempo, recuperación, ticket o reclamación.
• Prepara salida: exportación, reversión, proveedor alternativo o procedimiento manual.

Este checklist parece básico, pero evita el error más caro: decidir por intuición en un sistema que ya depende de varias piezas. Si hablamos de pagos, identidad, privacidad, seguridad, hosting o ecommerce, una pieza mal probada puede bloquear ventas, accesos, atención o cumplimiento.

Errores comunes

• probar solo el camino feliz
• mezclar cookies de marketing con sesión
• no ofrecer método alternativo de acceso
• atribuir caídas de conversión a SEO cuando el fallo está en identidad

Estos errores no suelen nacer de mala fe. Nacen de copiar un consejo genérico sin mirar la situación real. Una empresa pequeña puede necesitar menos tecnología y más claridad. Una web con tráfico puede necesitar menos cambios visibles y más pruebas. Un ecommerce puede necesitar menos plugins y más control sobre checkout, devoluciones y datos.

Marco de decisión

Usa una tabla sencilla antes de contratar, cambiar o publicar:

La buena decisión no siempre es la opción más avanzada. A veces es mantener lo que funciona, documentarlo y cambiar solo la parte que crea riesgo. Otras veces es migrar porque el sistema actual ya no sostiene seguridad, velocidad o confianza.

Cómo aplicarlo en una pyme española

Empieza con un inventario pequeño. No hagas una auditoría infinita: lista las herramientas, personas, datos y proveedores que intervienen. Después marca tres niveles: crítico, importante y cómodo. Lo crítico es aquello que, si falla, impide vender, cobrar, atender, cumplir o recuperar información.

El segundo paso es una prueba. No pruebes solo el camino feliz. Si es un checkout, fuerza un pago rechazado y una devolución. Si es backup, restaura. Si es login, prueba recuperación. Si es hosting, simula DNS, SSL, formularios y caché. Si es privacidad, comprueba qué datos quedan guardados y durante cuánto tiempo.

El tercer paso es asignar dueño. Una decisión sin responsable caduca en cuanto cambian proveedor, norma, navegador, campaña o equipo. El dueño no tiene que hacerlo todo, pero sí debe saber cuándo revisar, qué mirar y a quién avisar.

Enlaces internos que refuerzan el cluster

Esta pieza no vive sola. Conecta de forma natural con cookies y AEPD, Google AI Overviews y SEO, passkeys. La idea es que el lector pueda ampliar contexto sin abrir diez búsquedas nuevas ni saltar a contenido repetido. Si ya existe una guía pilar, este artículo baja a una decisión concreta y vuelve a enlazar hacia ella.

Señales de que vas bien

Vas bien si puedes enseñar una evidencia, no solo una intención. Puede ser una prueba de restauración, una captura de configuración, una política revisada, una compra de prueba, una lista de permisos o un registro de incidencias. La evidencia convierte una decisión opinable en una decisión revisable.

También vas bien si el proceso funciona sin la persona que lo montó. Si solo una persona sabe cómo recuperar una cuenta, revertir DNS, cambiar una pasarela, desbloquear una copia o explicar una política, la empresa no tiene proceso: tiene dependencia.

La tercera señal es que hay una fecha de revisión. En tecnología, privacidad, ecommerce y seguridad, lo correcto hoy puede quedarse corto cuando cambian proveedores, navegadores, normas, precios, dispositivos o expectativas del cliente.

Plan de 30 días

Semana 1: inventario y riesgo. Escribe qué sistema, proveedor, dato o flujo se ve afectado. Marca lo que puede bloquear ventas, accesos, soporte, cumplimiento o recuperación.

Semana 2: prueba controlada. Ejecuta el caso normal y el caso problemático. Conserva capturas, resultados y errores. No cambies producción si la prueba básica ya muestra dudas.

Semana 3: corrección. Arregla el punto de mayor impacto: datos excesivos, backup no restaurable, checkout frágil, plugin inseguro, proveedor sin salida, política confusa o permisos demasiado amplios.

Semana 4: rutina. Define cuándo se revisa, quién mira la señal y qué cambio exigiría una nueva decisión. Una rutina pequeña es mejor que una gran auditoría que nadie repite.

Hooks sociales reutilizables

• Un login roto puede parecer un problema de marketing.
• No pruebes solo que el botón aparece: prueba que el usuario vuelve.
• Identidad y analítica no son la misma cookie.

Preguntas frecuentes

¿FedCM afecta al SEO?

Indirectamente. Si el login bloquea contenido, compra o registro, afecta experiencia y conversión, aunque no sea una etiqueta SEO.

¿Tengo que eliminar el login con Google?

No necesariamente. Lo razonable es probarlo, actualizar librerías y mantener un método alternativo de acceso.

¿Es lo mismo que cookies de analítica?

No. FedCM se relaciona con identidad federada; las cookies de analítica y publicidad tienen otro tratamiento y consentimiento.

¿Qué prueba mínima haría hoy?

Alta nueva, login recurrente, rechazo de permiso, cambio de navegador, recuperación de cuenta y conversión posterior.

¿Dónde falla más a menudo?

En callbacks, dominios mal configurados, políticas de cookies mezcladas, cuentas ya existentes y ausencia de soporte claro para el usuario.

Resumen accionable

La acción útil es convertir fedcm y login sin cookies de terceros: qué revisar si tu web usa acceso con google en una prueba documentada: caso real, fuente verificable, responsable, evidencia y fecha de revisión. Si puedes explicar qué cambia, qué riesgo reduces y cómo volver atrás, estás decidiendo con criterio.