API ShopperContext en SFCC: cómo configurarla paso a paso
Cómo configurar la API ShopperContext de Salesforce Commerce Cloud paso a paso: feature switch, SLAS, customer groups y pruebas. Agenda una consulta.
La API ShopperContext de Salesforce permite adjuntar datos a nivel de sesión a la visita de un comprador en el storefront, información que SFCC puede usar después para activar promociones, contenido y customer groups personalizados. A diferencia de los enfoques de personalización más antiguos, basados en atributos estáticos del cliente, ShopperContext trabaja en tiempo real, a nivel de sesión, sin necesidad de login ni de un perfil persistente.
Esta guía recorre los pasos exactos de configuración: activar el feature switch, dar el scope correcto al token SLAS, construir customer groups basados en sesión y probar los endpoints de la API antes de conectarla a producción. Si tu equipo está decidiendo cómo estructurar la personalización en SFCC sin sobrecargar el front end, esta es la secuencia que funciona.
🎬 Cómo usar la API ShopperContext de Salesforce
Ofrecer experiencias personalizadas ya no es un diferencial en e-commerce, es una expectativa básica. Salesforce diseñó la API ShopperContext justamente para que los equipos de desarrollo puedan crear interacciones a medida sin reconstruir el modelo de datos del cliente. A continuación, el proceso paso a paso para configurarla correctamente.
Paso 1: Activar ShopperContext en Business Manager
Empieza en Business Manager y ve a Administration > Global Preferences > Feature Switches. Busca el toggle "Enable ShopperContext" y actívalo. Esto habilita la API ShopperContext en tu entorno y expone los endpoints que tu integración va a consumir.
Paso 2: Obtener un token SLAS válido
Para interactuar con la API ShopperContext necesitas un token SLAS válido. Verifica que tu cliente de API tenga el scope sfcc.shopper-context.rw agregado en su configuración. Este scope otorga acceso de lectura y escritura sobre los datos de shopper context; sin él, cada llamada a la API devuelve un error de autorización, sin importar qué tan bien esté configurado el resto del setup.
Paso 3: Construir customer groups basados en sesión
Los customer groups basados en sesión son donde ShopperContext entrega la mayor parte de su valor. Usa la API para crear grupos a través de session.custom, definiendo criterios según tipo de dispositivo, datos demográficos o cualquier otro atributo relevante para tu negocio. Este es el mecanismo que permite segmentar compradores sin esperar a que hagan login o acumulen historial de compras.
Paso 4: Crear promociones y campañas para cada grupo
Con los customer groups en su lugar, el siguiente paso es construir promociones y campañas dirigidas a cada segmento. Usa la API ShopperContext para servir descuentos segmentados, ofertas especiales y contenido de campaña alineado con las preferencias y señales de comportamiento de cada grupo. Aquí es donde el dato de sesión se convierte realmente en un resultado de negocio: mayor conversión en segmentos que, de otra forma, verían contenido genérico.
Paso 5: Probar los endpoints de la API ShopperContext
Antes de llevar esto a producción, valida los endpoints con la colección de Postman enlazada más abajo. Ejecuta requests contra cada endpoint y confirma que los datos de shopper context se están obteniendo y aplicando como esperas. Probar en esta etapa detecta los edge cases de manejo de sesión (tokens expirados, scopes faltantes, definiciones de grupo malformadas) antes de que aparezcan como tickets de soporte.
Siguiendo esta secuencia, puedes configurar la API ShopperContext de Salesforce y desbloquear la personalización para la que fue construida: promociones altamente segmentadas, recomendaciones a medida y experiencias conscientes de la sesión que no dependen de un login.
Descarga la colección de Postman en nuestro Github
Trade-offs de arquitectura: SFRA vs. headless
Vale la pena señalar que la forma en que el front end consume estos datos de contexto cambia según la arquitectura del storefront. Los equipos que están en medio de una migración de SFRA a PWA Kit necesitan revisar dónde y cómo se llama a ShopperContext, porque el renderizado server-side de SFRA y el modelo headless de PWA Kit manejan el estado de sesión y el cacheo de forma muy distinta. Una llamada que funciona sin problemas en un template SFRA renderizado en servidor puede comportarse de manera inconsistente en un setup headless si los límites de caché y la persistencia de sesión no se remapean de forma explícita.
Implementar la API ShopperContext involucra decisiones de arquitectura que van más allá de la configuración inicial: segmentación de datos, integración con SLAS, y decidir qué señales de contexto vale realmente la pena capturar para tu modelo de negocio. Capturar demasiadas señales agrega overhead y complejidad sin una mejora proporcional en conversión, mientras que capturar muy pocas limita lo que la personalización puede lograr realmente.
Si tu equipo está evaluando cómo estructurar una personalización escalable en SFCC, agenda una conversación con Develoci para revisar la arquitectura que se ajusta a tu contexto.
Por Fernando Ruch