Personyze suele instalarse como un fragmento de JavaScript: se carga en el navegador del visitante, decide qué mostrar y lo muestra en la página. Es la opción adecuada para la mayoría de los sitios.
Pero el mismo motor de decisión responde por HTTP, así que su propio servidor puede preguntar «¿qué debe ver este visitante?» y mostrar la respuesta él mismo. No se carga nada en el navegador, y la página llega ya personalizada.
¿Es para usted?
Use la personalización en el servidor cuando:
- Renderiza las páginas en el servidor y no quiere el breve destello de contenido por defecto antes de que se aplique la personalización. Una variante renderizada en el servidor es simplemente la página — no hay nada que sustituir ni nada que ocultar.
- Quiere hacer una prueba A/B de algo invisible. Otro algoritmo de ordenación, otro precio, otra respuesta de API. No hay ningún elemento de la página que cambiar, así que una herramienta visual no tiene con qué trabajar.
- No hay navegador. Una app nativa, un quiosco, un decodificador de televisión, un proceso de envío de emails, una herramienta de soporte. Todo lo que pueda hacer una solicitud HTTPS se puede personalizar.
- El fragmento está bloqueado. Los bloqueadores de anuncios, las políticas de seguridad de contenido estrictas y los proxies corporativos detienen los scripts de terceros. Una llamada desde el servidor es su servidor hablando con el nuestro.
Quédese con el fragmento del navegador cuando personalice elementos visibles de un sitio web normal y quiera crear campañas en el editor visual sin depender de un desarrollador. También puede hacer las dos cosas: las llamadas desde el servidor y las sesiones del navegador comparten un mismo perfil de visitante y una misma asignación A/B, siempre que ambas identifiquen a la persona de la misma manera.
Cómo funciona
Un único endpoint HTTPS lo hace todo. Usted le dice a Personyze lo que acaba de hacer el visitante, y Personyze le dice qué debe pasar a continuación:
- Su servidor llama a Personyze cuando va a renderizar algo — una página, una lista de productos, una respuesta de API.
- Personyze responde con ID de acción: las campañas que coinciden con este visitante en este momento, y lo que debe ver.
- Su código decide qué significa cada ID. La acción 88 puede ser «mostrar el banner de envío gratis» o «usar el algoritmo de ordenación B». Usted asigna los ID a comportamientos en su propio código, o lee de la respuesta el contenido ya preparado.
- Usted le dice a Personyze lo que ha hecho. Esto es lo que hace que los informes y los resultados A/B sean reales.
Todo lo que ya configura en el panel sigue aplicándose: audiencias, reglas de segmentación, programación, repartos A/B e informes.
Ejecutar una prueba A/B
Configure la prueba en el panel exactamente igual que para una prueba en el sitio — una campaña de pruebas A/B, una acción para cada variante y sus criterios de ganador. En una prueba solo en el servidor, las acciones no necesitan ningún contenido: el ID basta para que su código sepa qué rama tomar.
Después, en su código: llame a Personyze en el punto de decisión, ramifique según el ID de acción que reciba e informe del resultado.
Dos cosas que se suelen pasar por alto, y que conviene comprobar antes de lanzar:
- Informe de que ha mostrado la variante. Una acción de la que nunca informa parece que nunca se ejecutó. Su grupo no pierde la prueba — parece que no ha tenido tráfico en absoluto, y la prueba nunca puede concluir.
- Informe del resultado en la forma que mide su criterio de ganador. Una prueba que se puntúa por compras no se mueve informando de clics. Haga coincidir la señal con el criterio que eligió, o parecerá que el grupo no ha producido nada.
Los resultados aparecen en el panel exactamente igual que en las pruebas en el sitio — significación, mejora frente al control y el ganador — y también se pueden leer por programación si los quiere en su propio panel de control.
Bibliotecas oficiales
Puede llamar al endpoint directamente con cualquier cliente HTTP. Hay bibliotecas para los stacks habituales que se ocupan de los detalles fáciles de hacer mal — mantener la sesión, cortar rápido por tiempo de espera y no dejar nunca que una llamada de personalización tumbe la página que personaliza:
- Node.js / TypeScript —
npm install @personyze/node, con utilidades para Express y Next.js. - PHP —
composer require personyze/personyze. - Python —
pip install personyze, con utilidades para Django y Flask.
Cada una es una capa fina sobre el mismo endpoint, así que no se le oculta nada y puede bajar a HTTP sin procesar siempre que lo necesite.
Rendimiento y seguridad
Una llamada de personalización está en el camino del renderizado de una página, así que las bibliotecas usan por defecto un tiempo de espera de 1 segundo y fallan en abierto: si Personyze va lento o no responde, su código recibe una respuesta vacía y muestra su contenido por defecto. Su página nunca nos espera, y nunca se rompe por nuestra culpa.
La llamada se autentica con una clave de API por HTTPS. Manténgala en su servidor — tiene acceso completo a su cuenta, a diferencia del fragmento del tracker, que es público por diseño.
Lo que necesita para empezar
- Una clave de API. En el panel: Configuración → Integraciones → API completa.
- Un ID de visitante estable. Su propio ID de usuario, un ID de dispositivo, un hash — cualquier cosa que pueda reproducir para la misma persona la próxima vez. Es lo que permite que alguien se mantenga en el mismo grupo A/B entre visitas.
- Un sitio donde guardar la sesión. Personyze devuelve un valor de sesión con cada respuesta; devuélvaselo en la siguiente llamada. El lugar donde ya guarde el estado de la sesión es el adecuado.
Próximos pasos
La documentación técnica completa — formatos de solicitud y respuesta, el vocabulario de comandos, la receta A/B y un ejemplo resuelto — está en la guía para desarrolladores: Personalización y pruebas A/B en el servidor.
Si no está seguro de si la opción del servidor es la adecuada para su caso, contacte con soporte y describa lo que quiere personalizar; a menudo la respuesta es breve.