Un feature flag es un interruptor que prende o apaga una parte de tu producto para la gente que tú elijas, sin subir código nuevo.
Kilden evalúa los flags en un servicio hecho para esa única tarea, y los apunta con los mismos eventos, personas y segmentos sobre los que corre tu analítica.
Subir código y encenderlo son dos decisiones. Amárralas y cada release es una apuesta que se resuelve delante de todo el mundo a la vez.
El código llega a producción detrás de un flag apagado —desplegado, alcanzable por nadie— hasta que lanzar es mover un interruptor y no un deploy de viernes.
Apagar el flag es un clic. Revertir, reconstruir y volver a desplegar demora lo que demore tu pipeline, y mientras tanto los clientes están sentados en la versión rota.
Tu propio equipo, después una tajada del tráfico, después todos. Si la tasa de errores se mueve, se movió para una fracción de la gente.
Nada de esto necesita una rama de larga vida, un tren de releases ni una segunda copia de tu infraestructura.
Se crea en el panel, se evalúa en producción y se lee desde tu código en una línea.
Prendido para quienes calzan con tu targeting, apagado para el resto. El flag más común también es el más aburrido.
Dale al flag una lista de variantes en vez de prendido y apagado, y tu código lee de vuelta el nombre de la variante. Un botón reparte los pesos parejo.
Un despliegue gradual es un corte en un hash, no una fila. Súbelo y el flag solo agrega gente: nadie pierde la funcionalidad porque moviste el número.
Un interruptor apaga el flag para todos, diga lo que diga el targeting, y llega al servicio de evaluación en segundos. Sin deploy y sin caché que invalidar.
Un flag pertenece a un proyecto, y el proyecto es la frontera: staging tiene sus propios flags y sus propias llaves.
La primera vez que una sesión lee un flag, un evento registra el valor que recibió, así que puedes graficar un rollout en vez de confiar en él.
Una herramienta de flags suelta conoce un id y las propiedades que te acordaste de mandar, así que la audiencia termina siendo una lista pegada que alguien mantiene a mano.
Kilden es antes que nada una plataforma de datos de clientes, y el servicio de flags lee las mismas personas, eventos y segmentos que tus embudos y tus campañas. Una audiencia es una frase sobre comportamiento.
Armas la audiencia una vez como segmento, y el flag que abre la funcionalidad, la campaña que hace seguimiento y el embudo que la mide leen la misma definición.
La pertenencia se recalcula desde los eventos, así que alguien que volvió ayer sale solo de «no volvió nunca más».
La pertenencia a un segmento se recalcula por agenda, así que puede ir minutos atrasada. Sirve para targeting y no sirve para nada que tenga que ser cierto en este segundo exacto; para eso, las propiedades que mandas en la petición se aplican al tiro.
Un flag, veinte personas y la aritmética que decide dónde cae cada una. Arrastra el rollout: la misma persona cae siempre del mismo lado.
El flag está prendido. La gente dentro del rollout recibe esta variante; el resto recibe el checkout que ya tienes en producción.
El color del punto es la variante que le tocaría a esa persona: un hash independiente, así que no sigue al rollout.
Cada ficha es un distinct id. Sube el rollout y las fichas solo se encienden; bájalo y los últimos en entrar son los primeros en salir. Estas veinte están repartidas parejo en el rango, así que la cuenta sigue al control; veinte de verdad se moverían para un lado o para el otro.
Barajar cambia el orden en que se dibujan y nada más: cada persona se queda de su lado.
Ilustrativo: reproduce la propiedad que la página afirma —la posición depende solo de la clave del flag y del id— y no el hash que calcula el servicio.
La evaluación de flags es su propio servicio, y la única parte de Kilden que una carga de página espera. Esto es todo lo que hace.
Al arrancar, el SDK manda tu llave pública y el distinct id actual, y recibe todos los flags en una sola respuesta: los inactivos como falso, para que «apagado» no se confunda con «nunca supe de él».
Que alguien caiga dentro de un rollout es un hash de la clave del flag y de su distinct id, mapeado sobre la línea que corta el porcentaje. Mismas entradas, misma respuesta.
No hay tabla de asignaciones ni escritura en el camino de lectura. Subir un rollout alarga el corte, que es justo por lo que solo agrega gente. Las variantes salen de un segundo hash.
Después de esa primera respuesta, cada lectura de un flag es una consulta en memoria. La primera lectura de cada flag registra la exposición.
El bucket depende del distinct id, así que cuando alguien inicia sesión y su id anónimo es reemplazado, una persona justo en el borde puede cambiar de lado. Ese es el precio de evaluar sin estado guardado. El SDK recarga los flags apenas cambia la identidad.
Una vez que un flag reparte variantes con nombre, lo único que falta es la aritmética. Un experimento es un lente sobre un flag que ya tienes: eliges el flag, eliges la métrica, lees el resultado.
La conversión se cuenta solo después de que la persona quedó expuesta, así que una compra anterior a que viera el cambio no se le puede acreditar.
Un reparto que no calza con tus pesos, exposición demasiado delgada para concluir algo, tráfico anónimo mezclado con identificado: el reporte nombra el problema y se guarda el veredicto.
Agrega el SDK, inicialízalo con tu llave pública y lee el flag por su clave. Los flags cargan en segundo plano, así que condiciona el render al callback.
Los SDK de servidor evalúan los mismos flags con tu llave secreta, y el endpoint está documentado si prefieres llamarlo tú. La llave secreta se rechaza desde un navegador.
Leer la guía de flags →Una petición de flags es una respuesta que trae flags, no una por cada flag que lee tu código. El SDK pregunta una vez al cargar y responde cada lectura desde memoria, así que una página con cincuenta flags gasta una petición.
Eso sale más barato por flag que cobrar cada lectura, que castiga a cualquier app con muchos flags en una misma pantalla.
No hay ningún medidor contando peticiones de flags ni una línea para ellas en una factura. Un cupo que no puedes exceder es decoración y no un límite, así que esta página no imprime ninguno. El día que se midan, las páginas de planes reciben el número primero.
Ver qué se cobra →Un interruptor en tu código que prende o apaga algo para la gente que tú elijas, sin subir una versión nueva. Los dos caminos están desplegados; el flag decide cuál corre.
Un flag decide quién recibe algo. Un test A/B mide qué le hizo eso a un número que te importa. En Kilden el test es un lente sobre un flag con variantes: misma asignación, misma audiencia.
Leer uno no: el SDK carga todos los flags una vez, en segundo plano, y cada lectura posterior es una consulta en memoria. El servicio mismo responde en milisegundos de un dígito.
Creas el flag, dejas el targeting vacío y pones el rollout en diez por ciento. Recibe la funcionalidad todo aquel cuyo distinct id hasheado cae bajo el corte, y subir el número después solo agrega gente.
Sí, y es la razón para correr flags sobre una plataforma de datos de clientes. Un segmento como «pagó dos veces y no volvió nunca más» se define una vez desde tus eventos y se apunta directo.
Tu aplicación sigue funcionando. Un flag que nunca cargó se lee como desconocido, que el SDK reporta como apagado, así que tu código toma el camino que tomaba antes de que existiera la funcionalidad.
Crea un proyecto, mete el SDK y sube eso que te daba nervio: primero a tu propio equipo, después a quien se lo gane. Los flags vienen en el plan gratis.