Las cookies de terceros pueden bloquearse debido a restricciones del navegador, parámetros de configuración del usuario, marcas del desarrollador o políticas empresariales.
Debes asegurarte de que tu sitio o servicio proporcione una excelente experiencia a todos tus usuarios, ya sea que las cookies de terceros estén disponibles o no.
En esta página, se incluye información sobre los recorridos del usuario comunes que pueden verse afectados cuando se bloquean las cookies de terceros.
Recorrido comunes de los usuarios
Muchos flujos de trabajo de pago y compra dependen de las cookies de terceros. En la siguiente tabla, se enumeran algunos recorridos del usuario que pueden verse afectados si se inhabilitan las cookies de terceros y se sugieren APIs alternativas que los desarrolladores pueden usar para evitar interrupciones. Es posible que esta lista no esté completa y que se actualice a medida que haya más soluciones de Privacy Sandbox disponibles.
Prueba los recorridos del usuario relacionados con los pagos
La mejor manera de probar si tus flujos de usuarios se ven afectados por las restricciones de cookies de terceros es revisarlos con la marca de prueba de cookies de terceros habilitada.
Para asegurarte de que tu sitio web funcione según lo previsto, prueba el siguiente flujo con las cookies de terceros restringidas:
- Confirmación de compra en varios sitios: Prueba los flujos de pago que dependen de un proveedor de pagos externo (como Pagar con <proveedor-ejemplo>). Asegúrate de lo siguiente:
- El redireccionamiento se realiza correctamente.
- El portal de pagos se carga correctamente.
- El proceso de pago se puede completar sin errores.
- El usuario se redirecciona de vuelta a tu sitio web según lo previsto.
- Paneles de pagos: Prueba que los widgets del panel de transacciones funcionen según lo previsto con las cookies de terceros restringidas. Verifica que el usuario pueda hacer lo siguiente:
- Accede al panel.
- Ver todos los pagos como se esperaba
- Navegar sin errores entre las diferentes secciones del panel (p. ej., historial de transacciones, detalles de pago)
- Administrar formas de pago: Prueba que los widgets de administración de formas de pago funcionen según lo previsto. Con las cookies de terceros bloqueadas, prueba lo siguiente:
- Agregar o borrar una forma de pago funciona según lo previsto.
- El pago con formas de pago guardadas anteriormente no se ve afectado.
- Detección de fraudes: Compara cómo funciona tu solución de detección de fraudes con cookies de terceros y sin ellas.
- ¿El bloqueo de cookies de terceros introduce pasos adicionales que causan fricción adicional para el usuario?
- ¿Puede seguir detectando patrones sospechosos cuando se bloquean las cookies de terceros en el navegador?
- Botón de confirmación de compra personalizado: Prueba si los botones de pago se renderizan correctamente con las cookies de terceros restringidas.
- ¿El usuario puede completar compras incluso si el botón personalizado no muestra su método preferido?
Finalización de compra entre sitios
Algunos proveedores de pagos pueden depender de cookies de terceros para permitir que los usuarios accedan a su cuenta en varios sitios de comercios sin necesidad de volver a autenticarse. Este recorrido del usuario podría verse afectado para quienes elijan navegar sin cookies de terceros.
Formularios de pago incorporados
Considera los siguientes dominios:
payment-provider.exampleproporciona servicios de pago a los sitios de comercios y almacena los datos de pago y de sesión del usuario.merchant.examplees un sitio web que incorpora un formulario de confirmación de compra proporcionado porpayment-provider.example.
Un usuario acaba de acceder a payment-provider.example (por ejemplo, mientras completaba la confirmación de la compra en otro sitio). El usuario inicia un proceso de confirmación de compra en merchant.example.
Con las cookies de terceros disponibles, el formulario de confirmación de compra payment-provider.example incorporado en merchant.example tendría acceso a su propia cookie de sesión de nivel superior establecida en payment-provider.example en el contexto de nivel superior.
Sin embargo, si se bloquean las cookies de terceros, la incorporación no tendrá acceso a sus propias cookies de nivel superior.
Una solución personalizable con FedCM
payment-provider.example debería considerar implementar FedCM para actuar como proveedor de identidad. Este enfoque puede ser adecuado en los siguientes casos:
payment-provider.exampleestá incorporado en sitios de terceros no relacionados.payment-provider.exampleestá incorporado en más de cinco sitios relacionados.
El principal beneficio de FedCM es que la IU puede proporcionar a los usuarios más contexto para sus elecciones. Con el permiso del usuario, FedCM permite compartir datos personalizados entre la parte que confía (merchant.example) y el proveedor de identidad (payment-provider.example). La parte que confía puede optar por admitir uno o más proveedores de identidad, y la IU de FedCM solo se mostrará de forma condicional.
Según las necesidades, los desarrolladores pueden elegir entre el modo pasivo para que el mensaje de FedCM aparezca automáticamente cuando el usuario accede con el proveedor de identidad, o el modo activo, cuando el proceso de acceso debe activarse después de una acción del usuario, como hacer clic en un botón de confirmación de compra.
FedCM también actúa como un indicador de confianza para la API de Storage Access (SAA), que permite que el elemento incorporado acceda a sus cookies sin particionar de nivel superior después de que el usuario acepta acceder con el proveedor del elemento incorporado, sin necesidad de una solicitud adicional del usuario.
Solución enfocada en el acceso al almacenamiento
Otra API que se debe tener en cuenta es la API de Storage Access (SAA).
Con SAA, se le pedirá al usuario que permita que la inserción de payment-provider.example acceda a sus propias cookies de nivel superior. Si el usuario aprueba el acceso, el formulario se puede renderizar como lo hace cuando hay cookies de terceros disponibles.
Al igual que con FedCM, el usuario deberá aprobar la solicitud en cada sitio nuevo en el que se incorpore payment-provider.example. Consulta la demostración de SAA para comprender cómo funciona la API.
Si la instrucción predeterminada de la SAA no se adapta a tus necesidades, considera implementar FedCM para obtener una experiencia más personalizada.
Reducir los obstáculos para los usuarios en una pequeña cantidad de sitios relacionados
Si el sitio del comercio y el proveedor de pagos pertenecen a la misma empresa, puedes usar la API de Conjuntos de sitios web relacionados (RWS) para declarar relaciones entre dominios. Esto puede ayudar a reducir la fricción del usuario: por ejemplo, si insurance.example y payment-portal-insurance.example están en el mismo CWR, payment-portal-insurance.example obtendrá automáticamente acceso a sus propias cookies de nivel superior cuando se solicite acceso al almacenamiento dentro de la incorporación de payment-portal-insurance.example.
Otras soluciones experimentales
Otra API experimental que podría ser útil en esta situación es la de Popins particionados. Actualmente, la API se encuentra en una etapa de desarrollo activo.
Con las ventanas emergentes particionadas, se le puede pedir al usuario que ingrese sus credenciales para acceder a payment-provider.example dentro de una ventana emergente que abrió merchant.example. El almacenamiento se particionará según el abridor merchant.example. En este caso, la integración de payment-provider.example tendrá acceso a los valores de almacenamiento establecidos en la ventana emergente. Con esta solución, el usuario deberá acceder al proveedor de pagos en cada sitio.
Finalización de compra con vínculos de pago
Algunos proveedores de pagos ofrecen un servicio que genera un vínculo de pago, el cual renderiza una página de confirmación de compra personalizada para el sitio de un comercio. A menudo, un servicio de vínculos de pago y un portal del usuario para el proveedor de pagos se implementan en diferentes dominios, por ejemplo, payment-provider.example y payment-link.example.
payment-link.example incorpora un formulario de confirmación de compra proporcionado por payment-provider.example. Esta es una variación del patrón de formulario de confirmación de compra integrado.
FedCM, SAA y RWS también son buenas opciones para considerar en este caso.
Paneles de pagos
Algunas aplicaciones muestran paneles de transacciones a sus usuarios en varios sitios, lo que proporciona una vista centralizada de sus actividades financieras. Esto requiere que el panel acceda a datos específicos del usuario en varios dominios.
Considera los siguientes dominios:
earnings.exampleproporciona un panel de pagos que se puede incorporar en varias aplicaciones web. Este servicio almacena datos de ganancias del usuario e información de la sesión.catsitting.exampleydogsitting.exampleson sitios web independientes que incorporan el panel deearnings.example.
Un usuario accede a su cuenta de earnings.example. Cuando visiten catsitting.example o dogsitting.example, podrán ver sus ingresos. El panel earnings.example integrado se basa en cookies de nivel superior y muestra la información de ingresos personalizada del usuario.
Al igual que en otros ejemplos, el elemento earnings.example incorporado no tendrá acceso a sus cookies de nivel superior con las cookies de terceros inhabilitadas.
Paneles propios
En los casos en que los tres dominios pertenezcan a la misma entidad, considera usar SAA junto con RWS.
Con la SAA, earnings.example puede acceder a su cookie de nivel superior con el permiso del usuario. Si esta parte usa earnings.example en cuatro o menos dominios, declarar relaciones entre ellos con RWS puede proporcionar una experiencia del usuario más fluida.
Si la misma parte externa incorpora el widget en más de cinco dominios, no podrá declarar relaciones entre todos los sitios de incorporación y el dominio del widget, ya que el RWS solo admite hasta seis sitios en un conjunto: uno principal y cinco asociados.
Distribución de paneles a gran escala
En los siguientes casos, es posible que SAA y RWS no sean la solución óptima:
- Distribuyes una solución de panel para sitios de terceros.
- Tienes más de cinco sitios que incorporan tu widget de panel.
En este caso, earnings.example debería considerar implementar FedCM para actuar como proveedor de identidad. Esto significa que el usuario deberá acceder a dogsitting.example con una cuenta administrada por earnings.example.
FedCM ofrece una IU personalizable que puede ayudar a comunicar claramente al usuario qué información se comparte. Con FedCM, dogsitting.example puede solicitar a earnings.example que comparta permisos personalizados, por ejemplo, para acceder a los datos de transacciones.
FedCM también funciona como un indicador de confianza para la API de Storage Access, y el elemento earnings.example incorporado obtendrá acceso al almacenamiento de sus propias cookies de nivel superior sin un mensaje adicional para el usuario en la llamada a la API de SAA.
Configuración del panel específica del sitio
Si los datos no se deben compartir en varios sitios, considera particionar tus cookies con CHIPS. Las CHIPS pueden ser útiles para almacenar preferencias específicas del sitio, por ejemplo, el diseño del panel o los filtros.
Administrar las formas de pago
Otro flujo común es que el usuario vea y edite sus formas de pago en un elemento integrado sin salir del sitio host.
Considera el siguiente flujo:
payments.exampleproporciona una herramienta de administración de pagos que se puede incorporar en sitios web. Este servicio almacena datos de pago y de sesión del usuario.shop.examplees un sitio web que incorpora la herramientapayments.examplepara permitir que los usuarios vean, editen o elijan las formas de pago preferidas asociadas con su cuenta deshop.example.
Los proveedores de pagos que implementan la administración de formas de pago también deben considerar convertirse en proveedores de identidad con FedCM. Con FedCM, el usuario podrá acceder a la parte que confía (shop.example) con la cuenta administrada por el proveedor de identidad (payments.example).
Con el permiso del usuario, FedCM permite compartir datos personalizados entre la parte que confía y el proveedor de identidad. El principal beneficio de usar FedCM es que la IU puede proporcionar a los usuarios más contexto para sus elecciones. También actúa como un indicador de confianza para la API de Storage Access, lo que permite que el elemento incorporado acceda a sus cookies de nivel superior.
Con las cookies de terceros inhabilitadas, la inserción de payments.example no tendrá acceso a sus cookies de nivel superior. En este caso, SAA puede ayudar a garantizar el funcionamiento adecuado solicitando acceso al almacenamiento.
A veces, la información establecida en la incorporación no necesita compartirse en otros sitios de incorporación. payments.example solo puede necesitar almacenar diferentes preferencias del usuario para cada sitio de incorporación en particular. En este caso, considera particionar las cookies con CHIPS. Con CHIPS, la cookie establecida dentro de payments.example incorporado en shop.example no será accesible para payments.example incorporado en another-shop.example.
Otra API experimental que se puede usar en este flujo de usuarios es Partitioned Popins.
Cuando el usuario accede a payments.example dentro de una ventana emergente abierta por shop.example, el almacenamiento se particionará según el elemento que abrió la ventana, y la incorporación de payments.example tendrá acceso a los valores de almacenamiento establecidos dentro de la ventana emergente. Sin embargo, este enfoque requiere que los usuarios ingresen credenciales para acceder al proveedor de pagos en cada sitio.
Detección de fraudes
Los sistemas de análisis de riesgos pueden analizar los datos almacenados en las cookies para identificar patrones que se desvían de la norma. Por ejemplo, si un usuario cambia repentinamente su dirección de envío y realiza varias compras grandes con un dispositivo nuevo, es posible que aumente la puntuación de fraude potencial. Las cookies de detección de fraude suelen ser cookies de terceros que los proveedores de pagos o los widgets de servicios de prevención de fraude establecen en los sitios de los comercios.
Si bien las restricciones de cookies de terceros no deberían afectar los sistemas de detección de fraude, es posible que generen fricción adicional para los usuarios. Si el sistema no puede verificar con certeza que un usuario es legítimo debido a que se bloquearon las cookies, es posible que requiera verificaciones adicionales, como completar la verificación de identidad.
Para admitir la detección de fraudes cuando se bloquean las cookies de terceros, considera integrar la API de Private State Tokens (PST) en tu solución de detección de fraudes. Con PST, un proveedor de pagos puede registrarse como emisor de tokens y otorgar a los usuarios tokens que no dependen de cookies de terceros. Luego, estos tokens se pueden canjear en los sitios de comercios para verificar si el usuario es confiable. Consulta la documentación para desarrolladores de PST para obtener detalles sobre la implementación.
Privacy Sandbox está experimentando con otras APIs contra el fraude.
Botón de confirmación de compra personalizado
Los botones de pago (como Pagar con <forma de pago preferida>) integrados en los sitios de comercios suelen depender de la información entre sitios establecida por el proveedor de pagos. Esto permite la personalización, y los usuarios pueden disfrutar de una confirmación de compra sin problemas con su forma de pago preferida. Si se bloquean las cookies de terceros en el navegador del usuario, esto puede afectar la renderización de los botones de pago personalizados.
Si bien la SAA podría permitir el acceso al almacenamiento, es posible que el mensaje requerido no genere una experiencia del usuario ideal.
Estamos explorando una posible solución que se dirige específicamente a este caso de uso: Fenced Frames con acceso a datos locales sin particionar. Actualmente, la API se encuentra en una etapa de desarrollo activo, y puedes definir su futuro. Pruébalo y proporciona comentarios.
Obtener ayuda y enviar comentarios
Si tienes preguntas o comentarios sobre los recorridos del usuario o las APIs que se describen en esta guía, puedes compartir tus comentarios.