AIREITERExtraes trescientos titulares de la competencia de una biblioteca pública de anuncios y quieres entender qué están vendiendo realmente tus rivales. Lo más fácil es pegarlos todos en el chat y pedir: "resume los argumentos de venta de estos anuncios". La respuesta llega enseguida: buena relación calidad-precio, foco en la experiencia de usuario, urgencia y un tono emocional positivo. Cuatro frases que podrías haber escrito sin leer ni un solo anuncio.
El problema no está en los datos. Las bibliotecas de anuncios y los centros creativos de las plataformas son públicos, puedes consultarlos con tu propia cuenta y no estás eludiendo nada. El fallo está en la pregunta. Has planteado una cuestión agregada, así que el modelo solo puede devolverte una respuesta agregada. Comprimir trescientos anuncios en cuatro adjetivos implica perder casi toda la información; al final quedan afirmaciones verdaderas, pero inútiles.
Para que el análisis masivo de copy sirva de algo, primero hay que definir qué significa que sea útil. "Apuesta por el ahorro" no permite actuar. En cambio, "promesa de ahorro, respaldada con una cifra y limitada en el tiempo; una combinación presente en el 40% de esta muestra y orientada a públicos sensibles al precio" sí lo hace, porque te indica directamente qué variables ajustar en la siguiente pieza. Y para llegar ahí no basta con una sola llamada: hay que dividir el proceso en dos.
Por qué pedir un resumen de los argumentos de venta acaba en vaguedades
El problema del enfoque de una sola pasada es estructural, no se arregla con un prompt mejor redactado.
Estás pidiendo al modelo que resuelva al mismo tiempo dos tareas de naturaleza distinta: extraer datos de cada anuncio y clasificar esos datos. La extracción es determinista: qué promesa hace un anuncio o si aporta pruebas suelen tener una respuesta prácticamente única. La clasificación exige criterio: decidir qué promesas pertenecen a la misma categoría y dónde están sus límites requiere razonamiento. Si juntas ambas cosas en una sola llamada, el modelo toma el atajo: evita la extracción anuncio por anuncio, resume el bloque de texto por impresión general y entrega una colección de adjetivos positivos que cree que quieres leer.
Además, el enfoque de una pasada no deja ningún producto intermedio. Recibes "apuesta por la relación calidad-precio" como conclusión, pero no puedes rastrear qué anuncios la sustentan, qué proporción representan ni si existen contraejemplos. Si ejecutas el mismo proceso sobre otra muestra, la conclusión cambia. Un análisis sin resultados intermedios no se puede revisar ni iterar.
Dos fases: primero extraer campos, después agruparlos
La forma correcta de hacerlo tiene dos fases y una capa de campos estructurados entre ambas.
En la primera fase, extraes los campos de cada copy por separado usando un esquema fijo. Como mínimo, cuatro dimensiones: la promesa principal, el tipo de evidencia, el recurso de urgencia y la audiencia implícita. Se analiza un anuncio cada vez y la salida debe ser JSON estricto, sin texto explicativo.
You will receive one ad headline. Break it apart along the fixed fields below.
Output JSON only, no explanation.
<copy>
{{one piece of copy}}
</copy>
Fields and allowed values (pick only from the given enum; when unsure pick
unknown; do not invent values):
- promise: [save money, save time, look better, get healthier, make money,
learn a skill, belong, identity, unknown]
- evidence: [testimonial, data/numbers, authority, before/after, demo,
none, unknown]
- urgency: [time limit, scarcity, price-rise warning, fear of missing out,
none, unknown]
- audience: a short phrase, inferred from the wording, for who it's talking to
(e.g. "night owls", "moms with kids", "junior designers")
Output:
{"promise":"...","evidence":"...","urgency":"...","audience":"..."}
Cuando has extraído trescientos anuncios, tienes trescientos registros estructurados en lugar de trescientos bloques de texto. A partir de ahí, "resume los argumentos de venta" deja de ser una tarea semántica difusa y se convierte en un problema de datos: puedes contar, agrupar y representar distribuciones.
La segunda fase consiste en agrupar, pero se agrupan los campos, no el texto original. Si agrupas el texto bruto, vuelves a la misma niebla de similitud semántica. Agrupar campos significa trabajar con unas pocas dimensiones discretas y límites claros.
Cómo agrupar y por qué debes exigir contraejemplos
La clave del prompt de agrupación no es pedir simplemente que agrupe. Es obligar al modelo a presentar un contraejemplo.
Below are N ad headlines already extracted into structured records.
The categories are frozen. Do not add categories.
<records>
{{JSON array, each with promise/evidence/urgency/audience}}
</records>
Output three things in order:
1. Combination clustering
Group by (promise x evidence x urgency), and give each group's record
count and one representative sample.
2. Counterexample check
For the top 3 groups by record count, pick one record per group whose
audience clearly departs from the group's mainstream, and explain why it
got grouped there. Is it really the same selling point, or did step one
extract a field wrong?
3. Gaps
Which combinations that should be common don't appear even once in this
batch? Are those gaps "nobody's doing it" or "my sample didn't cover it"?
La segunda sección es la que hace que este prompt merezca la pena. El modelo tiende de forma natural a complacerte y, si no le exiges más, todos los grupos que genere parecerán sospechosamente coherentes. Pedirle que extraiga de cada grupo un registro que no encaja del todo le obliga a seguir comprobando cuando ya cree que ha terminado. Así puede revelar que el límite de una categoría es demasiado amplio o que en la primera fase se extrajo mal algún campo.
Hacer que el modelo cuestione su propio trabajo no es exclusivo del análisis de anuncios. En ingeniería inversa de código se conoce como sección de contraevidencia: cuando el modelo identifica una familia de algoritmos, no lo aceptas sin más; le pides que responda "en qué se diferencia esto de la implementación estándar". Es el mismo principio que ayuda a contener la tendencia del modelo a darte la razón al trabajar con código ofuscado y al identificar la huella de algoritmos. En la agrupación de copy, la comprobación de contraejemplos cumple esa función.
Qué modelo usar en cada fase
Las dos fases exigen capacidades opuestas, así que usar el mismo modelo para ambas es desperdiciar recursos:
Fase | Capacidad necesaria | Elección | model id |
|---|---|---|---|
Extraer campos por anuncio (cientos o miles, una llamada por pieza) | Bajo coste, alta concurrencia y salida estructurada estable | Claude Sonnet 5 |
|
Definir categorías (leer toda la muestra una vez e inducir el enum) | Contexto largo | Kimi K3 |
|
Agrupar campos, detectar contraejemplos y huecos | Razonamiento sólido y disposición a cuestionarse | Claude Opus 5 |
|
Atribución de frecuencia (¿un recuento alto funciona o es una cadena de imitadores?) | Razonamiento intermedio y explicación basada en datos | GPT-5.6 Sol |
|
La diferencia de coste de un orden de magnitud nace precisamente de esta división. La extracción de campos es la única fase que escala linealmente con el volumen: trescientos anuncios son trescientas llamadas; mil anuncios, mil llamadas. La agrupación se ejecuta una vez por lote. Reserva el nivel de razonamiento más caro para la agrupación, que se hace una o dos veces, y deja la extracción, que se repite cientos de veces, al nivel más económico: la factura total puede variar por un factor de diez. Si lo haces al revés, con el nivel caro en extracción y el barato en agrupación, caes en el desperdicio más habitual: la extracción no necesita tanto razonamiento y la agrupación falla justo en aquello para lo que el nivel barato es más débil.
No hace falta creerme sobre cuánto ahorra bajar de nivel: prueba una ronda.
Elige entre 20 y 30 anuncios de los que ya has recopilado.
Extrae los campos: ejecuta el mismo lote con
claude-sonnet-5yclaude-opus-5, y compara registro por registro la coincidencia en los cuatro campos.Agrupa: toma esos mismos registros extraídos, agrúpalos con ambos niveles y revisa dos cosas. ¿La comprobación de contraejemplos cuestiona realmente los grupos o solo reafirma la hipótesis? ¿Los huecos sugieren un siguiente paso accionable?
La conclusión se lee sola: si el acuerdo en extracción es alto, baja esa fase al nivel económico y ahorra; si el nivel barato no produce un contraejemplo útil al agrupar, esa fase debe permanecer en el nivel de razonamiento.
Trampa uno: dejar que el modelo invente las categorías
La trampa más fácil consiste en no proporcionar un enum durante la extracción y dejar que el modelo cree categorías por su cuenta.
Con un lote puede parecer que funciona. El modelo devuelve categorías razonables. El problema aparece en el segundo: el copy es parecido, pero cambian los nombres de categoría, el nivel de detalle y los límites. Intentas comparar ambos lotes para detectar una tendencia y resulta que no encajan. ¿El "descuento" del primer lote equivale al "ahorra dinero" del segundo? Nadie lo sabe. Si las categorías cambian de lote en lote, cualquier comparación entre lotes es ficticia.
La solución es separar la definición de categorías de su uso. Primero, utiliza el nivel de contexto largo para revisar de una sola pasada una muestra grande, cientos de piezas cada vez, que es precisamente su trabajo, e inducir un conjunto de enums completo y consistente en granularidad. Después revísalo manualmente y congélalo. A partir de ahí, toda extracción solo podrá escoger valores de ese enum fijo, con unknown como categoría residual, sin inventar categorías sobre la marcha. La instrucción del prompt de extracción, "pick only from the given enum, do not invent", materializa exactamente esa restricción.
En una frase: tú defines las categorías; el modelo solo rellena las casillas.
Trampa dos: confundir frecuencia con efectividad
Una vez extraídos y agrupados los datos, es natural ordenar por número de registros y asumir que el argumento de venta más frecuente es el más eficaz. Es un error fácil de pasar por alto.
Una frecuencia alta solo dice que todo el mundo escribe de esa manera. No demuestra que funcione. La cadena de imitadores existe en publicidad: un anuncio despega y, en una semana, todo el sector se sube al carro; de la noche a la mañana aparecen decenas de titulares idénticos en el centro creativo. El recuento incorpora todos esos imitadores y concluye que ese argumento es el más popular, aunque quizá estén fracasando en bloque y nadie se haya detenido a comprobarlo. La frecuencia mide conformidad, no efecto.
Para separar frecuencia y efectividad, debes asociar datos de rendimiento a cada registro. Cada pieza de una biblioteca pública de anuncios incluye campos como reproducciones, likes, CTR y similares. Lo que realmente deberías ordenar es "la proporción de una combinación concreta de argumentos de venta que cae en un percentil alto de rendimiento", no el número bruto de registros. Cómo convertir la retención segundo a segundo y los percentiles de CTR en señales útiles se trata en otro artículo. Aquí conviene insistir en algo: la tabla de frecuencia y la tabla de efecto deben ser dos tablas distintas; en cuanto las fusionas, arruinas la conclusión.
En esta fase, el trabajo del modelo es atribuir, no ordenar. Dale al nivel de razonamiento intermedio una combinación frecuente junto con su distribución de rendimiento y pregúntale: "¿esta frecuencia es alta porque funciona o porque se están copiando entre sí?". Debe juzgarlo contra los números. Equivocarse en esa atribución tiene poco coste, porque al final seguirás validando con datos reales de rendimiento.
Trampa tres: analizar solo a los ganadores
La tercera trampa se esconde en la fuente de datos y puede pasar desapercibida: las bibliotecas de anuncios y los centros creativos muestran por defecto los anuncios que han rendido bien. Secciones como "hot ads" o "Top Ads" son, en esencia, supervivientes que la plataforma ya ha filtrado según su rendimiento.
Agrupas un conjunto de ganadores, detectas "los rasgos comunes de los anuncios de éxito" y los copias. Eso es sesgo de supervivencia de manual, porque los anuncios que fracasaron muy probablemente compartían esos mismos rasgos. Supón que el 90% de los ganadores usa un "límite de tiempo" y concluyes que los límites de tiempo funcionan. Pero si el 90% de los anuncios fallidos también los usa, ese rasgo no tiene ningún poder discriminativo. Es una convención del sector, sin relación con el éxito o el fracaso.
La solución es dar un grupo de control a los ganadores. Una biblioteca pública de anuncios suele permitir filtrar por sector, objetivo de marketing y periodo. Aplica los mismos filtros para localizar piezas que tuvieron impresiones pero una interacción claramente baja, extráelas y agrúpalas también, y compáralas con el grupo ganador. Lo valioso no es "lo que tienen los ganadores", sino el conjunto diferencial: "lo que tienen los ganadores y no los perdedores". Solo merece la pena incorporar a tu siguiente pieza un rasgo que aparezca en esa diferencia.
No conseguirás una muestra completa de perdedores, y no pasa nada. Incluso un pequeño grupo de control de bajo rendimiento es mucho más creíble que una conclusión obtenida solo a partir de Top Ads.
El resultado debe ser una tabla de variables, no un resumen
Si recorres las dos fases y evitas las tres trampas, el producto final no debería ser un párrafo del tipo "los competidores de esta muestra apuestan por XX". Eso nos devuelve a la vaguedad. El resultado debe ser una tabla de variables:
Qué valores adopta cada dimensión: promesa, evidencia, urgencia y audiencia.
Qué combinaciones ya están validadas como eficaces, presentes en el conjunto diferencial y en percentiles altos de rendimiento.
Qué combinaciones nadie ha probado todavía, detectadas en la sección de huecos.
Esta tabla puede usarse directamente como entrada de una tarea de generación. Las combinaciones validadas como eficaces sirven para producir variantes a escala; las combinaciones vacías se convierten en pruebas de bajo coste. Las variables de copy alimentan a un modelo de texto para redactar guiones, mientras que las variables visuales y de tono alimentan modelos de imagen y vídeo para producir piezas. Así se cierra el recorrido entre el copy de la competencia y tu propio anuncio terminado. Esa tabla de variables es exactamente lo que consulta la fase de briefing en el pipeline creativo.
El objetivo de agrupar no es crear un gráfico de clasificación bonito. Es generar la tabla que impulsará el siguiente lote de producción.
Una sola clave para los cuatro niveles
El flujo anterior necesita cuatro niveles: uno económico y de alta concurrencia para extracción, uno de contexto largo para definir categorías, uno de razonamiento para agrupar y uno de razonamiento intermedio para atribución. Proceden de varios proveedores, con distintos SDK, esquemas de autenticación y formatos de error. Conectar tu cliente a varias interfaces solo para cambiar de modelo entre fases no compensa. Esa es la verdadera razón por la que la mayoría acaba usando un único modelo para todo y sufre el desperdicio anterior: o un nivel caro quemando presupuesto en extracción, o un nivel económico incapaz de producir un contraejemplo al agrupar.
AIReiter unifica esa capa: una clave, una interfaz compatible con OpenAI y los cuatro niveles detrás. Para cambiar entre ellos basta con modificar el campo model del cuerpo de la solicitud.
# Extract fields: the cheap high-concurrency tier
curl https://aireiter.com/api/v1/chat/completions \
-H "Authorization: Bearer $AIREITER_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-5",
"messages": [{"role": "user", "content": "<extraction prompt + one piece of copy>"}]
}'
# Cluster: switch to the reasoning tier, leave the rest
# "model": "claude-opus-5"
# Frequency attribution:
# "model": "gpt-5.6-sol"
Si ya utilizas el SDK de OpenAI, apunta base_url a https://aireiter.com/api/v1 y no cambies nada más. Con el SDK de Anthropic, usa POST /api/v1/messages con la misma clave.
En precio, los modelos Claude tienen un 30% de descuento sobre tarifa y los modelos GPT cuestan la mitad; el descuento se aplica justo donde más cuesta este flujo. La extracción de campos es la única fase que escala linealmente con el volumen: trescientos anuncios son trescientas llamadas; mil anuncios, mil llamadas. Se ejecuta con el nivel Sonnet más económico y con un 30% de descuento adicional, y ahí se concentra el ahorro. La agrupación y la atribución se ejecutan unas pocas veces por lote, por lo que usar un nivel de razonamiento en ellas no penaliza. La definición de categorías se hace una vez por lote con Kimi K3, de contexto largo, disponible con la misma clave.
Pruébalo sin registrarte: analiza primero unos cuantos anuncios a mano, compara el nivel económico y el de razonamiento tanto en la coincidencia de extracción como en los contraejemplos de agrupación, y automatízalo cuando el proceso sea sólido.
Conclusión
El análisis masivo de copy publicitario acaba en vaguedades no porque el modelo sea débil, sino porque has metido extracción y clasificación en una sola llamada.
Divídelo en dos fases: extrae campos estructurados por anuncio usando un enum congelado, ejecútalo cientos de veces en el nivel económico y, después, agrupa los campos y obliga al modelo a aportar un contraejemplo en una única ejecución con el nivel de razonamiento. Vigila las tres trampas: no dejes que el modelo invente categorías sobre la marcha, no interpretes la frecuencia como efectividad y da un grupo de control a los ganadores. Termina con una tabla de variables que impulse la siguiente producción, no con una frase como "apuesta por la relación calidad-precio".
En este flujo, el modelo son dos herramientas distintas: un extractor económico y un clasificador dispuesto a cuestionarse. Úsalos por separado, en los niveles adecuados, y unos cientos de anuncios te darán información accionable. Mézclalos en un único modelo y solo obtendrás adjetivos.