Prodantix

O Prodantix é feito para quem constrói software. Todas as equipas de produto fazem as mesmas três perguntas: o que é que as pessoas fazem realmente dentro da nossa aplicação, quem deve poder ver que partes dela, e qual é o momento certo para lhes dizer alguma coisa.

A maioria das empresas compra uma ferramenta diferente para cada uma dessas tarefas, e é aí que os problemas começam. Cada ferramenta mantém o seu próprio registo separado de quem são os seus utilizadores, e esses registos vão-se afastando devagar. Uma acha que a cliente já terminou de configurar a conta. Outra ainda não acompanhou e envia-lhe instruções para um passo que ela concluiu na semana passada. Ninguém dá por isso até ela reclamar, ou até dois painéis começarem a mostrar números diferentes.

Como o motor está construído

Quatro primitivas compõem o motor, e tudo o resto assenta nelas. Vale a pena segui-las por ordem, porque cada uma alimenta a seguinte. A referência de conceitos cobre-as por inteiro.

Evento

Uma única coisa que um utilizador fez, captada no momento em que acontece: uma inscrição concluída, uma página aberta, um formulário abandonado a meio. Os eventos são o sinal em bruto e a única coisa que entra no sistema vinda de fora. Todo o resto deriva deles.

Estado do utilizador

Uma projeção viva e consultável de tudo o que se sabe sobre um utilizador, derivada dos seus eventos e atualizada no momento em que chega um novo. É a fonte de verdade que a análise, as feature flags e as mensagens leem. Não é uma agregação noturna nem uma cópia que algum processo mantém alinhada. Existe uma só.

Decisão

Uma regra avaliada sobre o estado do utilizador: quem pertence a uma coorte, quem recebe uma flag, quem cumpre os requisitos de uma mensagem. Como a decisão lê o estado vivo no momento em que é feita, não pode responder a partir de um retrato desatualizado.

Ação

O que o motor faz quando uma decisão dispara: expor uma funcionalidade, enviar uma mensagem, iniciar um fluxo de trabalho. A ação é ela própria registada como um evento, e é isso que fecha o ciclo: o que o motor fez passa a fazer parte do que ele sabe.

Análise é ler o estado

A análise no Prodantix não é um armazém à parte com a sua própria cópia dos utilizadores. É a leitura direta do estado do utilizador. Funis, retenção e coortes são consultas sobre a mesma projeção viva em que o resto do motor atua, pelo que não há ida e volta de SQL a um armazém nem espera por uma agregação noturna: o estado já tem a forma da pergunta. As coortes aqui são objetos de primeira classe: com nome, definidas por cláusulas, e com uma pertença mantida atualizada à medida que as pessoas passam a cumprir ou deixam de cumprir os critérios.

Guardar uma pergunta que voltará a fazer

Um painel é um conjunto com nome de mosaicos, e um mosaico é uma consulta que já correu mais a forma como a quer desenhada. A consulta fica guardada exatamente como o explorador a submeteu, pelo que um mosaico guarda a pergunta e não uma imagem da resposta: abrir um volta a correr a consulta e deixa-o outra vez no explorador nessa mesma consulta, livre para mover a janela ou mudar a repartição. Um painel nunca é, portanto, uma exportação velha. É um conjunto de perguntas que o motor responde a partir do estado vivo sempre que olha para ele.

Quando um número se mexe sozinho

Ninguém vigia todos os gráficos. A parte de vigiar é feita pelo Prodantix: lê uma série intervalo a intervalo, apura a linha de base e a dispersão dessa série, e assinala os intervalos que ficam demasiado longe dela, em qualquer dos sentidos. Tanto uma queda como um pico são comunicados, cada um com a linha de base de que se afastou e a distância a que ficou, para que distinga uma rutura verdadeira do ruído habitual. A sensibilidade é uma definição e não uma regra fixa, e o detetor recusa-se a adivinhar: uma série quase plana, ou ainda curta demais para ter forma, não produz nada em vez de dar um alarme falso.

As pessoas de que o estado fala

O estado do utilizador é uma projeção, e o diretório de pessoas é onde o lê uma pessoa de cada vez. A consola lista todos os que o projeto viu, primeiro os mais recentemente ativos, com uma caixa de pesquisa e uma lista que continua a carregar à medida que avança. Cada linha traz o que o motor acumulou sobre essa pessoa: quantos eventos, quantas sessões distintas, quando foi vista pela primeira e pela última vez, o que fez por último, a que grupos pertence, e os traços reservados (nome, e-mail, telefone, avatar) retirados para colunas próprias. Abrir uma linha mostra a tabela de propriedades completa, que contém aquilo que os seus eventos lá puseram e não um conjunto fixo de campos. Os grupos têm o seu próprio separador e as suas próprias propriedades, porque uma empresa ou um espaço de trabalho é uma coisa por direito próprio e os seus factos pertencem-lhe a ela, não a cada um dos membros.

Uma pessoa, vários identificadores

Um visitante chega antes de saber quem é. O SDK dá-lhe um identificador, ele lê três páginas, e só depois se regista. Enquanto ninguém disser ao motor quem ele é, o perfil simplesmente não tem nome, e o diretório di-lo em vez de adivinhar. Quando o registo acontece, os identificadores são ligados numa cadeia que dá numa única identidade canónica, pelo que o rasto anónimo se dobra dentro da conta com nome em vez de abrir um segundo perfil. Cada linha mostra quantos identificadores dão nela, e o perfil enumera-os. Onde o motor não consegue decidir sozinho, pode juntar dois perfis à mão: escolhe qual identidade fica, as propriedades dela vencem qualquer conflito, e as contagens somam-se. Essa já não se desfaz. O perfil tal como se lia antes da junção fica na trilha de auditoria, portanto o que dizia é recuperável, mas as duas pessoas deixam de ser separáveis depois de juntas.

Rever uma sessão

A analítica diz-lhe que ontem onze pessoas abandonaram o mesmo formulário a meio. Não lhe diz porquê. A repetição de sessão grava a própria página: o SDK do navegador capta o documento e cada alteração nele enquanto a pessoa trabalha, junta essas alterações em blocos ordenados e envia-os para o gravador, e a consola reproduz a sessão tal como aconteceu. Cada gravação fica sob o mesmo identificador que o resto do motor usa, pelo que uma sessão pertence a alguém que já consegue procurar, e não a um id de visitante que só existe dentro de uma ferramenta separada.

O que uma gravação pode guardar

O mascaramento está ligado antes de configurar seja o que for. Cada carácter escrito num campo é substituído por um asterisco no navegador, antes de o bloco ser enviado, pelo que o que chega ao gravador nunca conteve o texto: o comprimento e as fronteiras das palavras permanecem, o que mantém a repetição com o aspeto da página, e as palavras em si desapareceram. Os campos de palavra-passe, e-mail e telefone são ocultados esteja o mascaramento ligado ou desligado, pelo que desligá-lo não consegue expor um campo de credenciais. O texto visível da página fica guardado, a não ser que peça que também esse seja mascarado. Cada bloco regista se foi mascarado e a consola marca a sessão em conformidade, por isso sabe sempre qual das duas está a ver. As gravações ficam em armazenamento privado: a consola pede uma ligação assinada de curta duração para um bloco de cada vez, e nada é alcançável sem ela. Quanto tempo uma sessão continua disponível depois disso é definido pelo seu plano.

Mostrar coisas diferentes a pessoas diferentes

As equipas querem muitas vezes lançar algo novo primeiro a um punhado de utilizadores e ver como corre antes de chegar a toda a gente. O Prodantix decide quem vê o quê avaliando condições sobre o estado do utilizador: um atributo, um operador e um valor, verificados no momento em que a flag é consultada em vez de procurados numa lista guardada. Pode dar uma funcionalidade nova a dois por cento dos clientes, observar como a usam e depois alargá-la ou retirá-la sem esperar por outro lançamento.

Mensagens que chegam enquanto ainda ajudam

Uma mensagem só vale a pena enquanto ainda ajuda. O Prodantix pode enviá-la no momento em que alguém faz alguma coisa, ou deixa de a fazer. Se um cliente chega ao limite do seu plano, fica a saber ali mesmo, e não na manhã seguinte, depois de já ter desistido e ido para outro lado.

Quando respondem

As mensagens seguem num só sentido até alguém responder, e a partir daí é um fio de apoio. O Prodantix também trata desses, e a IA que lá está redige em vez de enviar. Ao modelo é dado o fio e o estado daquela pessoa, mais nada: não a conversa de outro cliente, nem o resto do seu projeto. Escreve uma resposta sugerida, e a resposta só passa a ser uma intervenção no fio quando o seu agente carrega em enviar, pelo que «sugerir, não enviar» é a forma como o código está feito e não uma regra de que alguém se tenha de lembrar. O fio traz também as suas próprias credenciais. Uma chave de projeto identifica um projeto e viaja dentro de cada página que instala o SDK, logo não pode fazer as vezes de uma pessoa; cada conversa recebe o seu próprio testemunho, limitado a esse único fio, e o identificador que vem no corpo do pedido nunca decide com quem está a falar. Abrir uma conversa é a única via que não precisa de nada além da chave pública, por isso tem limite de ritmo por projeto e por quem chama.

Montar a sequência por si

Algumas respostas têm mais do que um passo, e você quer dispô-las à sua maneira. Um fluxo de trabalho é um pequeno grafo: começa manualmente, ou quando alguém entra ou sai de uma coorte, e daí avança de nó em nó. Um nó de ação faz alguma coisa (escrever uma linha de registo, chamar um webhook seu). Um nó de espera aguarda, até trinta dias. Um nó de sinal fica retido até chegar um sinal com nome, com a sua própria saída caso o sinal nunca chegue. Um nó de ramificação testa condições contra o estado do utilizador e segue o caminho correspondente, ou o alternativo. As execuções avançam um nó de cada vez, e cada passo fica gravado antes de o seguinte ser reclamado, pelo que um reinício retoma onde a execução tinha realmente chegado em vez de a repetir desde o início. Os webhooks são verificados antes de serem chamados: o destino tem de ser um endereço https público, o pedido segue para os endereços que a verificação aprovou, os redirecionamentos não são seguidos, e uma chamada que fica pendurada é cortada.

Orquestração de IA, e como o ciclo se fecha

As superfícies acima continuam a deixar-lhe o trabalho de ligar os passos: reparar em algo, perceber a quem se aplica, decidir o que fazer. O Prodantix consegue correr esse ciclo sozinho. O motor deteta o momento significativo no estado vivo, escolhe a coorte a que se aplica e seleciona a ação. O que faz disto mais do que automação corrente é a última parte: a ação é registada como um evento, pelo que regressa ao mesmo estado do utilizador que a decisão seguinte vai ler. O próprio comportamento do sistema passa a fazer parte do que ele sabe sobre essa pessoa, em vez de ser algo que lhe aconteceu à parte.

Uma proposta espera por uma pessoa

O motor não age sobre a sua própria conclusão. O que produz é uma proposta, e uma proposta é um plano escrito: estas bandeiras, estas coortes, esta mensagem. Antes de poder ser aprovada, cada bandeira, coorte e conversa que nomeia é resolvida contra o seu próprio inquilino, e uma referência que não resolve faz cair a proposta inteira em vez de ser descartada em silêncio, e é isso que impede um modelo que leu algo hostil de chegar para além do seu projeto. A aprovação é um ato humano, e é o ponto em que alguma coisa acontece: a execução passa pelos mesmos caminhos de bandeiras e de mensagens que usa à mão, pelo que as permissões, a trilha de auditoria e os limites do seu plano continuam todos a valer. Aprovar duas vezes não faz nada à segunda.

Fazer entrar os eventos

Tudo começa com um evento enviado para o ponto de receção, que o motor integra de imediato no estado do utilizador. Os SDK cobrem web, móvel e servidor. O React é a única exceção: o seu ciclo de vida exige um adaptador dedicado, um provider e hook que instalam o cliente uma só vez e aguentam o StrictMode. O arranque rápido liga tudo em poucas linhas.

Chaves e ambientes

Cada chamada de SDK leva uma chave de projeto, obtida na consola. Criar um projeto produz dois ambientes, live e test, cada um com a sua chave: desenvolve com a de teste e publica com a live. Ambas as chaves aparecem exatamente uma vez, logo após a criação, porque o servidor guarda apenas um resumo e nenhum ecrã as consegue mostrar de novo. A rotação emite uma substituta para o ambiente escolhido, e é você que decide se a chave antiga deixa de funcionar de imediato ou após um período de tolerância.

Quatro formas de falar com ele

O REST estende-se por três anfitriões, um para flags e mensagens, um para receção de eventos e um para repetição de sessão, cada um a servir o seu próprio documento OpenAPI em /openapi.json. A receção responde 202, o que significa que o evento foi aceite para processamento e não que ficou guardado: um evento malformado ainda pode ser descartado mais à frente. O GraphQL cobre todo o modelo da aplicação, incluindo projetos, flags, fluxos de trabalho, análise, mensagens, coortes e faturação. A superfície de tempo real difunde alterações de flags, mensagens e execuções de fluxos, e corta ligações não autenticadas de imediato. A superfície MCP permite que agentes leiam e escrevam através de chamadas de ferramentas; é de máquina para máquina e recusa pedidos de navegador.

Os dados continuam seus

Pode correr o Prodantix nos nossos servidores ou nos seus, e funciona da mesma maneira em qualquer dos casos. Tudo o que lá puser, pode voltar a tirar por inteiro, quando quiser. Não vendemos os seus dados nem os usamos para treinar modelos de IA. Por construção, o Prodantix acaba por guardar o registo mais completo dos seus clientes que tem em qualquer lado, por isso essa promessa pesa mais aqui do que pesaria noutro sítio.

Para quem é

O Prodantix serve a equipas que andam a usar duas ou três ferramentas separadas para isto e estão fartas de as ver discordar. É mais útil a partir do momento em que tem clientes suficientes para já não conseguir acompanhar o que fazem só a perguntar por aí.

Visitar Prodantix: prodantix.com