Prodantix
De un vistazo
- Categoría
- Plataforma para desarrolladores
- Sitio web
- prodantix.com
- Consola
- app.prodantix.com
- Documentación
- prodantix.com/en/docs/overview
- API de GraphQL
- api.prodantix.com/graphql
- Recepción de eventos
- eu.api.prodantix.com/v1/events
- Tiempo real
- eu.ws.prodantix.com
- Superficie MCP
- eu.mcp.prodantix.com/mcp
- Repetición de sesión
- eu.replay.prodantix.com
Prodantix está hecho para quienes construyen software. Todos los equipos de producto se hacen las mismas tres preguntas: qué hace realmente la gente dentro de nuestra aplicación, quién debería ver cada parte de ella y cuál es el momento adecuado para decirles algo.
La mayoría de las empresas compra una herramienta distinta para cada una de esas tareas, y ahí es donde empiezan los problemas. Cada herramienta guarda su propio registro por separado de quiénes son tus usuarios, y esos registros se van separando poco a poco. Una cree que la clienta ya terminó de configurar su cuenta. Otra no se ha puesto al día y le envía las instrucciones de un paso que completó la semana pasada. Nadie se da cuenta hasta que ella se queja, o hasta que dos paneles muestran cifras distintas.
Cómo está construido el motor
Cuatro primitivas componen el motor, y todo lo demás se apoya en ellas. Conviene tomarlas en orden, porque cada una alimenta a la siguiente. La referencia de conceptos las cubre por completo.
Evento
Una sola cosa que hizo un usuario, capturada mientras ocurre: un registro completado, una página abierta, un formulario abandonado a medias. Los eventos son la señal en bruto y lo único que entra al sistema desde fuera. Todo lo demás se deriva de ellos.
Estado del usuario
Una proyección viva y consultable de todo lo que se sabe de un usuario, derivada de sus eventos y actualizada en el momento en que llega uno nuevo. Es la fuente de verdad que leen la analítica, las feature flags y la mensajería. No es una agregación nocturna ni una copia que algún proceso mantiene alineada. Hay una sola.
Decisión
Una regla evaluada sobre el estado del usuario: quién pertenece a una cohorte, quién recibe una flag, quién cumple los requisitos de un mensaje. Como la decisión lee el estado vivo en el momento en que se plantea, no puede responder desde una imagen caduca.
Acción
Lo que hace el motor cuando se dispara una decisión: exponer una función, enviar un mensaje, iniciar un flujo de trabajo. La acción se registra a su vez como un evento, y eso es lo que cierra el ciclo: lo que el motor hizo pasa a formar parte de lo que sabe.
La analítica es leer el estado
La analítica en Prodantix no es un almacén aparte que guarde su propia copia de tus usuarios. Es leer el estado del usuario directamente. Embudos, retención y cohortes son consultas sobre la misma proyección viva sobre la que actúa el resto del motor, así que no hay viaje de ida y vuelta de SQL a un almacén ni espera a una agregación nocturna: el estado ya tiene la forma de la pregunta. Las cohortes aquí son objetos de primera clase: con nombre, definidas por cláusulas, y con una pertenencia que se mantiene al día según la gente empieza o deja de cumplir los criterios.
Guardar una pregunta que volverá a hacer
Un panel es un conjunto con nombre de mosaicos, y un mosaico es una consulta que ya ejecutó más la forma en que quiere verla dibujada. La consulta se guarda exactamente como la envió el explorador, así que un mosaico guarda la pregunta y no una imagen de su respuesta: abrir uno vuelve a ejecutar la consulta y lo deja de nuevo en el explorador sobre esa misma consulta, libre de mover la ventana o cambiar el desglose. Un panel nunca es, por tanto, una exportación caducada. Es un conjunto de preguntas que el motor responde desde el estado vivo cada vez que usted mira.
Cuando una cifra se mueve sola
Nadie vigila todos los gráficos. Prodantix se encarga de la parte de vigilar: lee una serie tramo a tramo, calcula la línea base y la dispersión de esa serie, y señala los tramos que quedan demasiado lejos de ella, en cualquiera de los dos sentidos. Se informa tanto de una caída como de un pico, cada uno con la línea base de la que se apartó y a qué distancia quedó, de modo que puede distinguir una ruptura real del ruido corriente. La sensibilidad es un ajuste y no una regla fija, y el detector se niega a adivinar: una serie casi plana, o todavía demasiado corta para tener forma, no produce nada en lugar de una falsa alarma.
Las personas de las que habla el estado
El estado del usuario es una proyección, y el directorio de personas es donde lo lee de una persona a la vez. La consola enumera a todos los que el proyecto ha visto, primero los activos más recientemente, con un campo de búsqueda y una lista que sigue cargando a medida que avanza. Cada fila lleva lo que el motor ha acumulado sobre esa persona: cuántos eventos, cuántas sesiones distintas, cuándo se la vio por primera y última vez, qué hizo por último, a qué grupos pertenece, y los rasgos reservados (nombre, correo, teléfono, avatar) sacados a columnas propias. Abrir una fila muestra la tabla de propiedades completa, que contiene lo que sus eventos hayan puesto allí y no un conjunto fijo de campos. Los grupos tienen su propia pestaña y sus propias propiedades, porque una empresa o un espacio de trabajo es una cosa por derecho propio y sus hechos le pertenecen a ella, no a cada uno de sus miembros.
Una persona, varios identificadores
Un visitante llega antes de que usted sepa quién es. El SDK le da un identificador, lee tres páginas, y solo después se registra. Hasta que alguien le dice al motor quién es, el perfil sencillamente no lleva nombre, y el directorio lo dice en vez de adivinar. Cuando el registro ocurre, los identificadores se enlazan en una cadena que desemboca en una sola identidad canónica, así que el rastro anónimo se pliega dentro de la cuenta con nombre en lugar de abrir un segundo perfil. Cada fila muestra cuántos identificadores desembocan en ella, y el perfil los enumera. Donde el motor no puede decidirlo por sí solo, usted puede unir dos perfiles a mano: elige qué identidad sobrevive, sus propiedades ganan cualquier conflicto, y los recuentos se suman. Eso ya no se deshace. El perfil tal como se leía antes de la unión queda en el registro de auditoría, así que lo que decía es recuperable, pero las dos personas dejan de ser separables una vez unidas.
Volver a ver una sesión
La analítica le dice que ayer once personas abandonaron el mismo formulario a mitad. No le dice por qué. La repetición de sesión graba la página misma: el SDK del navegador capta el documento y cada cambio en él mientras la persona trabaja, reúne esos cambios en fragmentos ordenados y los envía al grabador, y la consola reproduce la sesión tal como ocurrió. Cada grabación queda bajo el mismo identificador que usa el resto del motor, así que una sesión pertenece a alguien a quien ya puede buscar, y no a un id de visitante que solo existe dentro de una herramienta aparte.
Lo que una grabación puede conservar
El enmascarado está activo antes de que configure nada. Cada carácter escrito en un campo se sustituye por un asterisco en el navegador, antes de que el fragmento se envíe, de modo que lo que llega al grabador nunca contuvo el texto: la longitud y los límites de las palabras se mantienen, lo que conserva a la repetición el aspecto de la página, y las palabras en sí han desaparecido. Los campos de contraseña, correo y teléfono se ocultan esté el enmascarado activo o no, así que desactivarlo no puede exponer un campo de credenciales. El texto visible de la página se conserva, salvo que pida enmascararlo también. Cada fragmento registra si fue enmascarado y la consola marca la sesión en consecuencia, de manera que siempre sabe cuál de las dos está viendo. Las grabaciones residen en almacenamiento privado: la consola pide un enlace firmado de corta vida para un fragmento cada vez, y sin él no hay nada alcanzable. Cuánto tiempo sigue disponible una sesión después de eso lo fija su plan.
Mostrar cosas distintas a personas distintas
Los equipos suelen querer sacar algo nuevo a un puñado de usuarios primero y ver qué tal va antes de que lo tenga todo el mundo. Prodantix decide quién ve qué evaluando condiciones sobre el estado del usuario: un atributo, un operador y un valor, comprobados en el momento en que se consulta la flag en lugar de buscarse en una lista almacenada. Puedes dar una función nueva al dos por ciento de los clientes, observar cómo la usan y luego ampliarla o retirarla sin esperar a otra publicación.
Mensajes que llegan cuando todavía sirven
Un mensaje solo merece la pena mientras siga ayudando. Prodantix puede enviarlo en el momento en que alguien hace algo, o deja de hacerlo. Si un cliente llega al límite de su plan, se entera ahí mismo, y no a la mañana siguiente, cuando ya se ha rendido y se ha ido a otra parte.
Cuando contestan
La mensajería va en un solo sentido hasta que alguien contesta, y a partir de ahí es un hilo de soporte. Prodantix también lleva esos, y la IA que hay dentro redacta en lugar de enviar. Al modelo se le da el hilo y el estado propio de esa persona, nada más: ni la conversación de otro cliente, ni el resto de su proyecto. Escribe una respuesta sugerida, y esa respuesta solo pasa a ser un turno del hilo cuando su agente pulsa enviar, de modo que «sugerir, no enviar» es cómo está construido el código y no una regla que alguien deba recordar. El hilo lleva además sus propias credenciales. Una clave de proyecto identifica un proyecto y viaja dentro de cada página que instala el SDK, así que no puede hacer las veces de una persona; cada conversación recibe su propio testigo, limitado a ese único hilo, y el identificador que venga en el cuerpo de una petición nunca decide con quién está hablando. Abrir una conversación es la única ruta que no necesita más que la clave pública, por eso está limitada en ritmo por proyecto y por quien llama.
Montar usted mismo una secuencia
Algunas respuestas tienen más de un paso, y usted quiere disponerlas a su manera. Un flujo de trabajo es un grafo pequeño: arranca de forma manual, o cuando alguien entra en una cohorte o sale de ella, y desde ahí avanza de nodo en nodo. Un nodo de acción hace algo (escribir una línea de registro, llamar a un webhook suyo). Un nodo de espera aguarda, hasta treinta días. Un nodo de señal se detiene hasta que llega una señal con nombre, con su propia salida si la señal no llega nunca. Un nodo de bifurcación comprueba condiciones contra el estado del usuario y toma el camino que coincide, o el de reserva. Las ejecuciones avanzan de un nodo en un nodo, y cada paso queda asentado antes de reclamar el siguiente, de modo que un reinicio continúa donde la ejecución había llegado de verdad en vez de repetirla desde el principio. Los webhooks se comprueban antes de llamarlos: el destino tiene que ser una dirección https pública, la petición va a las direcciones que la comprobación aprobó, no se siguen redirecciones, y una llamada que se queda colgada se corta.
Orquestación de IA, y cómo se cierra el ciclo
Las superficies anteriores siguen dejándote a ti el trabajo de encadenar los pasos: advertir algo, averiguar a quién se aplica, decidir qué hacer al respecto. Prodantix puede recorrer ese ciclo por sí mismo. El motor detecta el momento relevante en el estado vivo, selecciona la cohorte a la que afecta y elige la acción. Lo que va más allá de la automatización corriente es la última parte: la acción se registra como un evento, así que vuelve a plegarse en el mismo estado del usuario que leerá la siguiente decisión. El propio comportamiento del sistema pasa a formar parte de lo que sabe de esa persona, en lugar de ser algo que le ocurrió aparte.
Una propuesta espera a una persona
El motor no actúa por su propia conclusión. Lo que produce es una propuesta, y una propuesta es un plan escrito: estas banderas, estas cohortes, este mensaje. Antes de que pueda aprobarse, cada bandera, cohorte y conversación que nombra se resuelve contra su propio inquilino, y una referencia que no resuelve hace caer la propuesta entera en vez de descartarse en silencio, y eso es lo que impide que un modelo que ha leído algo hostil alcance nada más allá de su proyecto. La aprobación es un acto humano, y es el punto en el que ocurre algo: la ejecución pasa por los mismos caminos de banderas y mensajería que usted usa a mano, así que los permisos, el registro de auditoría y los límites de su plan siguen aplicándose. Aprobar dos veces no hace nada la segunda vez.
Cómo entran los eventos
Todo empieza con un evento enviado al punto de ingesta, que el motor integra de inmediato en el estado del usuario. Los SDK cubren web, móvil y servidor. React es la única excepción: su ciclo de vida necesita un adaptador dedicado, un provider y un hook que instalan el cliente una sola vez y resisten StrictMode. La guía rápida lo conecta en unas pocas líneas.
Claves y entornos
Cada llamada del SDK lleva una clave de proyecto, que sale de la consola. Crear un proyecto produce dos entornos, live y test, cada uno con su clave: desarrollas con la de prueba y publicas con la de producción. Ambas claves se muestran exactamente una vez, justo tras crearlas, porque el servidor guarda solo un hash y ninguna pantalla puede volver a mostrarlas. La rotación emite un reemplazo para el entorno que elijas, y tú decides si la clave antigua deja de funcionar de inmediato o tras un periodo de gracia.
Cuatro formas de hablar con él
REST se reparte entre tres hosts, uno para flags y mensajería, otro para la ingesta de eventos y otro para la repetición de sesión, cada uno sirviendo su propio documento OpenAPI en /openapi.json. La ingesta responde 202, lo que significa que el evento se aceptó para procesarlo y no que quedó almacenado: un evento mal formado todavía puede descartarse más adelante. GraphQL cubre el modelo completo de la aplicación, incluidos proyectos, flags, flujos de trabajo, analítica, mensajería, cohortes y facturación. La superficie de tiempo real difunde cambios de flags, mensajes y ejecuciones de flujos, y corta al instante las conexiones no autenticadas. La superficie MCP permite a los agentes leer y escribir mediante llamadas a herramientas; es de máquina a máquina y rechaza las peticiones de navegador.
Los datos siguen siendo tuyos
Puedes ejecutar Prodantix en nuestros servidores o en los tuyos, y funciona igual de las dos maneras. Todo lo que metas puedes volver a sacarlo entero, cuando quieras. No vendemos tus datos ni los usamos para entrenar modelos de IA. Por su propio diseño, Prodantix acaba guardando el registro más completo que tienes de tus clientes en ninguna parte, así que esa promesa pesa más aquí que en otro sitio.
Para quién es
Prodantix encaja con equipos que llevan dos o tres herramientas separadas para esto y están cansados de que se contradigan. Resulta más útil cuando ya tienes suficientes clientes como para no poder seguir lo que hacen preguntando por ahí.
Visitar Prodantix: prodantix.com