Un libro de códigos es la lista de categorías que un investigador usa para convertir respuestas abiertas de encuesta en algo que se puede contar. Preguntale a mil personas "¿qué podríamos mejorar?" y vas a tener mil frases distintas. Aplícale un libro de códigos y tienes una tabla: 34% mencionó el precio, 19% mencionó la velocidad de entrega, 11% mencionó una función puntual. El libro de códigos es lo que hace posible ese segundo paso.

Suena a un detalle de infraestructura, y es una de las pocas piezas de la investigación de mercados donde una mala decisión al principio sale cara de corregir después: cada ola, cada informe, cada tabla cruzada construida encima hereda lo que el libro de códigos tenía mal.

Qué es exactamente

Estructuralmente, un libro de códigos es una lista —plana o jerárquica— de categorías, cada una con una definición corta de qué entra ahí, aplicada a una pregunta abierta. "Precio", "Atención al cliente", "Calidad del producto", "Empaque", "Otros" es un libro de códigos para una pregunta de satisfacción. Cada categoría de la lista es un código; codificar una respuesta es asignarle uno o más de esos códigos.

En inglés al objeto completo se lo suele llamar codebook, y a la lista de categorías en sí, codeframe —una distinción que en español casi nadie hace: aquí "libro de códigos" cubre las dos cosas, y quien usa la palabra "codeframe" (cada vez más común por la influencia de software en inglés) generalmente se refiere a lo mismo.

¿Es lo mismo que un "codeframe"?

En sentido estricto, el codeframe es la lista de categorías —los nombres y la jerarquía. El libro de códigos (codebook) es esa lista más todo lo que un codificador necesita para aplicarla de forma consistente: una definición por código, un puñado de ejemplos reales, y las reglas de caso límite que se fueron decidiendo la segunda semana de codificación ("si mencionan a un empleado por su nombre, va en Atención al Cliente, no en un código propio para esa persona"). En la práctica diaria casi nadie distingue los dos términos, y no hace falta: lo que importa no es cómo lo llamas, sino si el documento del que trabajan tus codificadores —humanos o de IA— tiene esa segunda parte, definiciones y ejemplos, y no solo una lista de nombres. Una lista de nombres es una apuesta a la consistencia. Una definición con dos o tres ejemplos reales es lo que hace que dos codificadores distintos, o el mismo codificador en dos días distintos, lleguen al mismo código para la misma respuesta.

La anatomía de un libro de códigos

Un libro de códigos para "¿Qué podríamos mejorar?" en una encuesta de satisfacción de retail podría verse así:

Código                  Definición
Precio                  Menciones de costo, relación precio-valor, o pedidos de descuento
Calidad del producto    Quejas o elogios sobre durabilidad o desempeño
Entrega / envío         Velocidad, costo, daños o seguimiento del envío
Atención al cliente     Interacciones con personal, soporte o devoluciones
Sitio web / app         Facilidad de uso de la tienda online o la app
Otros                   No encaja en ninguna de las anteriores; demasiado vago para codificar

Dos cosas de esa lista hacen más trabajo del que parece. La fila Otros es un código como cualquier otro, y conviene vigilar su tasa: si el 30% de las respuestas termina ahí, al libro de códigos le está faltando una categoría real, no describiendo una muestra inusualmente vaga. Y las definiciones son cortas a propósito —una definición que toma un párrafo leer es una definición que nadie aplica igual bajo presión de tiempo.

Los libros de códigos reales rara vez son tan cortos. Una pregunta abierta bien trabajada en un estudio de tracking grande puede tener entre veinte y sesenta códigos, y a ese tamaño una lista plana deja de ser manejable —por eso la mayoría de las plataformas de codificación, la nuestra incluida, permiten agrupar códigos bajo una categoría y una subcategoría (Calidad del producto › Durabilidad, Calidad del producto › Desempeño) en vez de forzar sesenta ítems en una sola lista sin diferenciar. La jerarquía no cambia qué se cuenta; cambia si una persona puede escanear el libro de códigos y encontrar el que necesita en diez segundos en vez de dos minutos.

Qué hace bueno a un libro de códigos

Cuatro propiedades, en el orden en que suelen descubrirse como errores más que planearse como objetivos:

  • Las categorías no se superponen. Si una respuesta sobre "la app se cerró al pagar" puede ir tanto en Sitio web/App como en Atención al Cliente, un codificador va a elegir una y otro la otra, y la división entre esos dos códigos va a medir el comportamiento del codificador, no el del encuestado.
  • Entre todas cubren lo que la gente realmente dijo, no lo que esperabas que dijera. Un libro de códigos armado con la intuición de quien diseñó el cuestionario, antes de leer una sola respuesta, casi siempre se pierde los dos o tres temas que terminan siendo los más importantes. La corrección es mecánica: leer entre cincuenta y cien respuestas reales antes de cerrar la lista.
  • Cada código tiene una tasa de uso real. Un código que agarra dos respuestas sobre dos mil no es una categoría, es una nota —conviene fusionarlo a un código más amplio o dejarlo en "Otros" en vez de darle una fila en cada tabla cruzada futura.
  • Existen definiciones y hay ejemplos que las respaldan. No por prolijidad documental —por el momento, ocho semanas después, en que alguien pregunta por qué una respuesta puntual está codificada como está, y la respuesta tiene que ser una regla, no un "me pareció".

Cómo se construye uno

Tres puntos de partida, y en un proyecto real no son excluyentes:

A mano, a partir de una muestra. Un investigador lee un lote de respuestas —típicamente entre cien y unos cientos— y arma las categorías de forma inductiva, como se hizo siempre la codificación cualitativa. Prolijo, lento, y sigue siendo la decisión correcta para un estudio sin precedente en qué apoyarse.

Generado a partir de los datos reales. En vez de partir de una plantilla genérica, un modelo lee una muestra de las respuestas abiertas reales de esa pregunta puntual y propone un libro de códigos a partir de lo que la gente efectivamente escribió —categorías, definiciones y ejemplos iniciales incluidos, listo para que un investigador lo edite antes de arrancar a codificar. Es más rápido que la versión manual y, como lee tus respuestas y no una plantilla, suele capturar algún tema específico del estudio que una lista genérica se habría perdido. Tampoco reemplaza que alguien revise el resultado: un libro de códigos propuesto por IA es un buen primer borrador, no uno terminado.

Importado desde un documento existente. Las agencias y los equipos internos suelen tener ya un libro de códigos —un archivo de una ola anterior, o uno que entrega el cliente como parte del brief. Importarlo significa que cada código y definición ya existen; el trabajo es mapear columnas (Categoría, Código, Definición, Ejemplos) en vez de escribirlas de cero, y en un estudio de tracking el mismo archivo se reutiliza ola tras ola para que el libro de códigos no se desvíe en silencio.

Qué pasa cuando una respuesta no encaja

Ningún libro de códigos sobrevive intacto al contacto con la base completa. En algún punto después de la respuesta doscientos aparece algo que no encaja en ninguna categoría de la lista. Le pueden pasar tres cosas, y cuál es la correcta depende del proyecto:

  • Va a "Otros". Correcto cuando es un caso realmente aislado —vago, fuera de tema, o demasiado raro para justificar una categoría nueva.
  • El libro de códigos gana un código nuevo. Correcto cuando el mismo tema aparece más de un puñado de veces —lo incompleto era el libro de códigos, no rara la respuesta. Este es el caso que vale la pena atrapar, porque es fácil perderlo de vista: nadie nota que un tema está sub-cubierto leyendo una sola respuesta, sino notando que "Otros" es inusualmente grande o que una revisión sigue marcando el mismo tipo de comentario.
  • No cambia nada, a propósito. En un libro de códigos de tracking cerrado —el que cada ola tiene que compartir para que las líneas de tendencia signifiquen algo— agregar un código a mitad de estudio a veces es la decisión equivocada aunque el tema sea real, porque rompe la comparabilidad con todas las olas anteriores. Lo correcto ahí es anotarlo para el próximo rediseño, no para la ola actual.

El trabajo de una plataforma de codificación en este punto es hacer visibles las primeras dos opciones en vez de dejarlas pasar en silencio: marcar lo que no encaja en ningún código existente, dejar que un investigador decida caso por caso si es ruido o un hueco real, y —esta es la parte que es fácil hacer mal— aplicar esa decisión retroactivamente a cada respuesta anterior con el mismo tema, no solo a la que disparó la revisión. Y en un estudio donde el libro de códigos realmente no se puede mover, un modo estricto que bloquea directamente la creación de códigos nuevos, para que nadie bajo presión de plazo amplíe en silencio las categorías de un tracking sin que nadie lo decida.

Preguntas frecuentes

¿Hay una diferencia real entre codeframe y libro de códigos?

En sentido estricto, el codeframe es la lista de categorías; el libro de códigos (codebook) es esa lista más las definiciones, ejemplos y reglas de caso límite que la hacen aplicable por más de una persona. En el uso diario entre investigadores, los dos términos se usan indistintamente —ambos significan "lo que uso para codificar las respuestas".

¿Cuántos códigos debería tener un libro de códigos?

No hay un número fijo —depende de qué tan variadas sean realmente las respuestas, no de una meta a cumplir. Lo que conviene vigilar es la forma: un puñado de códigos que cubran cada uno 15%+ de las respuestas, una cola más larga de códigos chicos, y un balde "Otros" de un dígito. Si "Otros" supera el 15-20%, al libro de códigos le falta algo real.

¿Se puede reutilizar el mismo libro de códigos entre olas?

Sí, y en un estudio de tracking debería hacerse —eso es lo que hace que la comparación ola contra ola signifique algo. En la práctica es mantener un único archivo compartido y reutilizarlo en cada ola en vez de reconstruirlo, para que un código no se renombre o se divida en silencio entre la ola 1 y la ola 2.

¿Qué pasa con una respuesta que no encaja en ningún código existente?

Se marca en vez de forzarla en la categoría más parecida. A partir de ahí es un caso aislado real (va a "Otros"), evidencia de que al libro de códigos le falta una categoría (se agrega un código nuevo y la decisión se aplica retroactivamente), o —en un libro de códigos de tracking cerrado— queda anotada para el próximo rediseño en vez de actuarse de inmediato.

Dónde encaja esto

El libro de códigos es el insumo; codificar es el proceso de aplicarlo a cada respuesta, y eso está cubierto de punta a punta en nuestra guía de codificación de preguntas abiertas. Los errores más comunes al construir uno están en errores comunes al codificar encuestas. Y una vez que las respuestas están codificadas, lo que el cliente termina leyendo se construye encima del libro de códigos: ver tabla de contingencia para cómo se arma y se lee esa tabla.

Si quieres ver un libro de códigos generarse en vez de leer sobre uno, nuestra herramienta gratuita de codificación toma hasta 100 respuestas, propone un libro de códigos a partir del texto real, y lo devuelve en un Excel —sin necesidad de crear cuenta.