El informe de términos de búsqueda de Shopping que Google no te da

Añade un parámetro de URL a tus campañas de Shopping y Performance Max y, en una semana, GA4 te entrega el informe que Google retiró en silencio: cada clic de pago emparejado como consulta × producto — con sesiones, conversiones e ingresos pegados. Ese único emparejamiento es donde se esconde el dinero — qué productos atraen tráfico basura, qué títulos no captan la demanda real, qué consultas queman presupuesto y nunca venden. La implementación es ese único parámetro; el resto de este artículo es qué haces con lo que vuelve.

Si gestionas campañas de Shopping o Performance Max, conoces el informe de términos de búsqueda. Lo que quizá no hayas notado — porque Google nunca lo señala — es qué le falta: el producto.

Ves que alguien buscó «aspiradora sin cable menos de 200». Ves clics y coste. No ves cuál de tus 5.000 productos disparó esa consulta, recibió la visita o vendió.

Hace años, la AdWords API te daba este emparejamiento. Hoy no. Y para una cuenta de e-commerce eso no es una carencia cosmética — consulta-a-producto es donde vive la optimización de verdad: si tus títulos casan con la demanda real, qué productos atraen tráfico basura, por qué un producto recibe clics pero nunca convierte.

Antes de que preguntes: no, no hay un ajuste para esto. Ni informe, ni campo de API, ni script que lo traiga de vuelta desde el lado de Google. Tienes que reconstruirlo tú — y la reconstrucción es casi vergonzosamente simple.

El arreglo: un parámetro, dos dimensiones de GA4

El auto-tagging y el UTM manual no pelean entre sí: gclid sigue gestionando fuente, medio y campaña; tu UTM solo lleva el ID de producto.

Ten claro lo que obtienes (y lo que no)

Sacar el informe de GA4

En la interfaz: Explorar → formato libre. Dimensiones: Contenido manual del anuncio de la sesión + Consulta de Google Ads de la sesión. Métricas: sesiones, conversiones, ingresos por compra. Filtro: fuente/medio de la sesión = google / cpc.

Vía la Data API — para cualquier cosa seria, esto alimenta un dashboard o un join en BigQuery:

from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import (
    RunReportRequest, DateRange, Dimension, Metric, FilterExpression, Filter
)

request = RunReportRequest(
    property=f"properties/{GA4_PROPERTY_ID}",
    dimensions=[
        Dimension(name="sessionManualAdContent"),  # product ID
        Dimension(name="sessionGoogleAdsQuery"),    # search term
    ],
    metrics=[
        Metric(name="sessions"),
        Metric(name="conversions"),
        Metric(name="purchaseRevenue"),
    ],
    date_ranges=[DateRange(start_date="30daysAgo", end_date="today")],
    dimension_filter=FilterExpression(filter=Filter(
        field_name="sessionSourceMedium",
        string_filter=Filter.StringFilter(value="google / cpc"),
    )),
)

Une sessionManualAdContent contra tu product feed (id → título, precio, categoría) y el informe queda completo: consulta × producto × título × economía.

Verificado, no teorizado

Lo desplegamos en una cuenta real — un minorista de electrónica checo con 22 campañas de Shopping activas — y revisamos GA4 siete días después:

Ahora la parte divertida: qué te dicen los pares

1 · La brecha del título

Pon las consultas junto al título y la descripción que dispararon. El desajuste salta a la vista:

La hoja de ruta del feed se escribe sola. Y aquí es donde el enriquecimiento de feed con IA deja de ser un acto de fe y se convierte en un bucle medible: reescribe el título en torno a la demanda que acabas de probar, y luego observa cómo se mueven el CTR y el porcentaje de conversiones por consulta.

2 · Quién más está en «tu» consulta — y con qué producto

Una cosa que no puedes hacer: añadir keywords negativas por producto. Google no te da esa palanca en Shopping ni en PMax. Así que cuando un par consulta × producto rinde mal, la pregunta no es «cómo lo excluyo» — es «por qué rinde mal».

Toma la consulta y extrae la página de resultados en vivo para ella. En concreto: DataForSEO, endpoint serp/google/organic/live/advanced — un POST con el texto de la consulta y el location_code de tu mercado, y te devuelve la página de resultados entera como JSON estructurado: anuncios de pago, bloques de shopping con nombres de comercio y precios, orgánicos debajo. A ~0,0035 $ por consulta, comprobar 200 consultas cuesta unos 0,70 $.

Un hallazgo típico: tu saco de dormir de gama media recoge clics en una consulta genérica — y la misma consulta muestra tres marcas económicas en la misma categoría a la mitad de tu precio. Tu producto no es malo; está superado en precio en esa subasta concreta.

Ahora tienes opciones reales: reprecia; lleva el diferenciador al título («relleno de plumón, confort −15 °C»); mueve el producto a una campaña con un bidding que case con la realidad de su margen; o acepta la consulta como upper-funnel y júzgala por métricas asistidas en vez de por el último clic.

3 · Decisiones de estructura y bidding

Los productos que atraen consultas de alta intención merecen sus propios grupos de recursos y presupuestos. Los productos que solo recogen tráfico genérico van en grupos de cajón de sastre con objetivos conservadores. Este informe es la base de evidencia para la segmentación de shopping — no la intuición.

4 · Un chequeo de salud para PMax

PMax casi no te dice nada sobre búsqueda. Este informe es lo más parecido a una auditoría de lo que PMax de verdad compra para ti en la superficie de búsqueda — por producto.

Te llevo por una exportación real, paso a paso

Todo lo de arriba es el porqué. Aquí está el cómo se ve de verdad — cada paso, qué descargas, qué miras fijamente, y el número real que vuelve.

Los datos son de una segunda cuenta: una e-shop checa de tamaño medio distinta (no el minorista de electrónica del recuadro de GA4 de arriba — la uso porque su catálogo es lo bastante amplio como para que cada patrón aparezca a plena escala). Saqué su informe de términos de búsqueda de Shopping en bruto a través de la Google Ads API a una tabla SQLite local y ejecuté las agregaciones de abajo. Una advertencia primero: este informe en bruto te da el grupo de anuncios / grupo de productos bajo el que se sirvió la consulta, no el producto individual. Esa es precisamente la brecha que cierra el truco del UTM — pero incluso a nivel de grupo de productos, los resultados intermedios son lo bastante ruidosos como para dejar claro el punto.

Fuente de cada número de esta sección: informe de términos de búsqueda de Shopping de Google Ads, una cuenta de e-shop checa de tamaño medio, ~22,6 M de líneas, datos sacados en abril de 2026.

Paso 1 · Saca el informe en bruto y mide el montón

Qué haces: exporta el informe de términos de búsqueda de Shopping vía la Google Ads API (search_term_view) a una tabla local — SQLite o BigQuery, cualquier cosa sobre la que puedas correr GROUP BY. Por qué primero: antes de unir nada, necesitas sentir lo grande y lo ruidoso que es el montón en bruto. Ese único hecho recalibra todas las expectativas que siguen.

Ejecuta un simple COUNT(*) y un par de SUM y esto es lo que aterriza:

Lo que tienes: 22,6 millones de líneas, 5,4 millones de consultas únicas. Ningún humano lee eso. El único trabajo del número es decirte el siguiente movimiento — colapsa este montón por la dimensión que paga las facturas — y advertirte de que cualquier triaje manual por filas es inútil.

Paso 2 · Tira el 96 % antes de analizar nada

Qué haces: cuenta las líneas con cero clics, y luego fíltralas. Por qué: el informe de términos de búsqueda de Shopping registra cada consulta en la que tu anuncio apareció, la mayoría de las cuales nadie clicó. Esas líneas de solo impresión no pueden costarte ni convertir — son ruido que hace que la tabla parezca aterradora.

Situación: 22,6 M de filas, no sabes por dónde empezar. Acción: WHERE clicks > 0. Resultado: la tabla se colapsa a 738.444 líneas — un tamaño manejable.

Lo que tienes: el 96,7 % del número aterrador nunca fue otra cosa que ruido. Ahora trabajas una tabla de 738K líneas, no una de 22,6 M — y cada agregación de abajo corre sobre la parte que de verdad gasta dinero.

Paso 3 · Haz la única pregunta que reencuadra la cuenta

Qué haces: sobre las líneas con clic, separa el gasto en «convirtió al menos una vez» vs «nunca convirtió», y suma el coste de cada uno. Por qué: este es el número que convierte «la cuenta está bien, el ROAS es 6,8» en «la mayor parte del presupuesto no hace nada». Es el resultado intermedio principal — calcúlalo antes de cualquier idea de optimización.

Lo que tienes: el 85 % del presupuesto fluyó por combinaciones de consulta × grupo de productos que ni una sola vez convirtieron. Eso no es un error de redondeo que optimizas más tarde — es el evento principal. Y solo pudiste verlo porque colapsaste la consulta hasta aquello contra lo que se vendió.

Paso 4 · Comprueba si el despilfarro son unos pocos villanos o toda la multitud

Qué haces: ordena las líneas con clic por coste, toma el top 1 % y el top 10 %, y mira cuánto del gasto total acaparan. Por qué: esto decide tu táctica. Si un puñado de términos queman el presupuesto, los pausas y listo. Si el despilfarro está repartido fino, pausar términos es inútil — necesitas arreglos estructurales.

Lo que tienes: el lastre es de cola larga, no unos pocos infractores — el top 1 % de líneas costosas acapara apenas una décima parte del gasto. Así que pausar 20 términos malos no cambia nada. Esta es la razón respaldada por datos para arreglar la estructura (qué productos están en qué campaña con qué objetivo) en vez de perseguir consultas individuales — y un recordatorio de que Google ni siquiera te deja añadir una negativa por producto de todos modos.

Paso 5 · Descubre por qué gotea la cola larga: una consulta, muchos productos

Qué haces: para cada término de búsqueda, cuenta bajo cuántos grupos de productos distintos se sirvió. Por qué: explica el despilfarro mecánicamente. Shopping empareja una consulta contra las señales de todo tu feed, no contra la relevancia de un producto — así que una sola consulta gotea por rincones inconexos de tu catálogo, y pagas por cada error.

Situación: «dispositivo antiladridos» sigue quemando presupuesto. Acción: COUNT(DISTINCT ad_group) para ese término. Resultado: se sirvió bajo 139 grupos de anuncios / productos distintos por 976 CZK y ~0 conversiones. «lego technic» tocó 300.

Lo que tienes: casi la mitad de tus consultas están desperdigadas por varios grupos de productos, y los peores infractores alcanzan miles. Ese es el motor del lastre de cero conversiones del Paso 3 — y justo lo que por fin puedes ver una vez que cada clic lleva su ID de producto.

Paso 6 · Mira a ojo los peores desajustes — son absurdos

Qué haces: saca las líneas de mayor coste que nunca convirtieron y lee la consulta junto al grupo de productos contra el que se vendió. Por qué: los números agregados convencen a tu hoja de cálculo; estas tres filas convencen a tu jefe. Son la cara legible por humanos del Paso 5.

Una consulta de collar de adiestramiento para perros pagada bajo tu grupo de Bolsos. Un dispositivo antiladridos vendido contra Productos para bebé. El grupo de productos no tiene nada que ver con la consulta — Google emparejó por señales amplias del feed, recogió el clic y te cobró. Con consulta × producto ves esto de un vistazo; con el informe estándar de Google, nunca. (Ejemplo ilustrativo — categorías traducidas y anonimizadas.)

Paso 7 · Ahora la recompensa: el 0,25 % que paga toda la cuenta

Qué haces: invierte el Paso 3 — aísla solo las líneas que sí convirtieron y suma su coste e ingresos. Por qué: esta es la razón por la que todo el ejercicio importa. Una vez que puedes separar a los ganadores del lastre, proteges a los ganadores y matas de hambre al resto.

Lo que tienes: un cuarto del uno por ciento de las líneas corre a 46,8× de ROAS y carga de hecho la cuenta; el otro 99,75 % arrastra la cifra combinada hasta 6,8×. Encontrar esa porción, proteger su presupuesto, y estructurar todo lo demás lejos de ella es todo el trabajo — y nada de eso es posible hasta que cada línea lleve el producto contra el que se vendió. Eso es lo que te compra el UTM de un solo parámetro del principio de este artículo.

{lpurl}?utm_content={product_id}

FAQ