Uma feature flag é uma chave que liga ou desliga parte do seu produto para as pessoas que você escolher, sem subir código novo.
A Kilden avalia as flags num serviço feito só para isso, e as direciona com os mesmos eventos, pessoas e coortes onde o seu analytics já roda.
Subir código e ligar são duas decisões. Amarre as duas e cada release vira uma aposta, resolvida na frente de todo mundo ao mesmo tempo.
O código vai para produção atrás de uma flag desligada — implantado, alcançável por ninguém — até que lançar seja virar uma chave, e não um deploy de sexta-feira.
Desligar a flag é um clique. Reverter, reconstruir e implantar de novo demora o que o seu pipeline demorar — e nesse meio-tempo os clientes ficam na versão quebrada.
O seu próprio time, depois uma fatia do tráfego, depois todo mundo. Se a taxa de erro se mexer, se mexeu para uma fração das pessoas.
Nada disso precisa de branch de vida longa, trem de releases ou uma segunda cópia da sua infraestrutura.
Criada no painel, avaliada em produção, lida do seu código em uma linha.
Ligada para quem bate com o seu direcionamento, desligada para o resto. A flag mais comum também é a mais sem graça.
Dê à flag uma lista de variantes em vez de ligado e desligado, e o seu código lê de volta o nome da variante. Um botão distribui os pesos por igual.
Uma liberação gradual é um corte num hash, não uma fila. Aumente e a flag só acrescenta gente: ninguém perde o recurso porque você mexeu no número.
Uma chave desliga a flag para todo mundo, diga o que disser o direcionamento, e chega ao serviço de avaliação em segundos. Sem deploy e sem cache para invalidar.
Uma flag pertence a um projeto, e o projeto é a fronteira: staging tem as próprias flags e as próprias chaves.
Na primeira vez que uma sessão lê uma flag, um evento registra o valor que ela recebeu — então dá para colocar um rollout num gráfico em vez de confiar nele.
Uma ferramenta de flags avulsa conhece um id e as propriedades que você lembrou de mandar, então o público acaba virando uma lista colada que alguém mantém na mão.
A Kilden é antes de tudo uma plataforma de dados de clientes, e o serviço de flags lê as mesmas pessoas, eventos e coortes dos seus funis e das suas campanhas. Um público vira uma frase sobre comportamento.
Você monta o público uma vez como coorte, e a flag que libera o recurso, a campanha que faz o acompanhamento e o funil que mede leem a mesma definição.
A participação é recalculada a partir dos eventos, então quem voltou ontem sai sozinho de “nunca voltou”.
A participação numa coorte é recalculada por agendamento, então pode estar minutos atrasada. Serve para direcionamento e não serve para nada que precise ser verdade neste exato segundo; para isso, as propriedades que você manda na requisição valem na hora.
Uma flag, vinte pessoas e a aritmética que decide onde cada uma cai. Arraste o rollout: a mesma pessoa cai sempre do mesmo lado.
A flag está ligada. Quem está dentro do rollout recebe esta variante; o resto recebe o checkout que você já tem no ar.
A cor do ponto é a variante que aquela pessoa receberia — um hash independente, então não acompanha o rollout.
Cada ficha é um distinct id. Aumente o rollout e as fichas só acendem; diminua e os últimos a entrar são os primeiros a sair. Estas vinte estão distribuídas por igual na faixa, então a contagem acompanha o controle; vinte de verdade oscilariam para um lado ou para o outro.
Embaralhar muda a ordem em que elas são desenhadas e mais nada: cada pessoa continua do seu lado.
Ilustrativo: reproduz a propriedade que a página afirma — a posição depende só da chave da flag e do id — e não o hash que o serviço calcula.
A avaliação de flags é um serviço próprio, e a única parte da Kilden pela qual um carregamento de página espera. É isto tudo o que ela faz.
Na inicialização o SDK manda a sua chave pública e o distinct id atual, e recebe todas as flags numa resposta só — as inativas como falso, para que “desligada” não se confunda com “nunca ouvi falar”.
Se alguém cai dentro de um rollout é um hash da chave da flag com o distinct id da pessoa, mapeado na reta que a porcentagem corta. Mesmas entradas, mesma resposta.
Não há tabela de atribuição nem escrita no caminho de leitura. Aumentar um rollout estende o corte, que é justamente por isso que ele só acrescenta gente. As variantes vêm de um segundo hash.
Depois daquela primeira resposta, cada leitura de flag é uma consulta em memória. A primeira leitura de cada flag registra a exposição.
O bucket depende do distinct id, então quando alguém entra na conta e o id anônimo é substituído, uma pessoa bem na borda pode trocar de lado. É o preço de avaliar sem estado guardado. O SDK recarrega as flags no instante em que a identidade muda.
Depois que uma flag distribui variantes com nome, só falta a aritmética. Um experimento é uma lente sobre uma flag que você já tem: escolhe a flag, escolhe a métrica, lê o resultado.
A conversão só é contada depois que a pessoa foi exposta, então uma compra anterior a ela ver a mudança não pode ser creditada à mudança.
Uma divisão que não bate com os seus pesos, exposição fina demais para concluir qualquer coisa, tráfego anônimo misturado com identificado — o relatório nomeia o problema e segura o veredito.
Adicione o SDK, inicialize com a sua chave pública e leia a flag pela chave dela. As flags carregam em segundo plano, então condicione o render ao callback.
Os SDKs de servidor avaliam as mesmas flags com a sua chave secreta, e o endpoint está documentado se você preferir chamá-lo direto. A chave secreta é recusada a partir de um navegador.
Ler o guia de flags →Uma requisição de flags é uma resposta que traz flags — não uma por flag que o seu código lê. O SDK pergunta uma vez no carregamento e responde cada leitura da memória, então uma página com cinquenta flags gasta uma requisição.
Isso sai mais barato por flag do que medir cada leitura, o que castiga qualquer app com muitas flags na mesma tela.
Não existe medidor contando requisições de flags nem linha para elas numa fatura. Uma cota que você não consegue estourar é enfeite, não limite, então esta página não imprime nenhuma. No dia em que forem medidas, as páginas de planos recebem o número primeiro.
Ver o que é cobrado →Uma chave no seu código que liga ou desliga algo para as pessoas que você escolher, sem subir uma versão nova. Os dois caminhos estão implantados; a flag decide qual roda.
Uma flag decide quem recebe alguma coisa. Um teste A/B mede o que isso fez com um número que te interessa. Na Kilden o teste é uma lente sobre uma flag com variantes: mesma atribuição, mesmo público.
Ler uma não deixa: o SDK carrega todas as flags uma vez, em segundo plano, e cada leitura depois disso é uma consulta em memória. O serviço em si responde em milissegundos de um dígito.
Crie a flag, deixe o direcionamento vazio e coloque o rollout em dez por cento. Recebe quem tiver o distinct id com hash abaixo do corte, e aumentar o número depois só acrescenta gente.
Dá, e é justamente o motivo de rodar flags sobre uma plataforma de dados de clientes. Uma coorte como “comprou duas vezes e nunca voltou” é definida uma vez a partir dos seus eventos e direcionada direto.
O seu app continua funcionando. Uma flag que nunca carregou é lida como desconhecida, o que o SDK reporta como desligada, então o seu código segue o caminho que seguia antes de o recurso existir.
Crie um projeto, coloque o SDK e suba aquilo que estava te dando frio na barriga — primeiro para o seu time, depois para quem merecer. Flags estão no plano gratuito.