Cómo construir un pipeline GeoX con la API de Google Ads y datos del CRM

Un pipeline GeoX bien construido extrae el coste de campaña por día y geografía mediante la API de Google Ads, y lo combina con resultados empresariales brutos procedentes del CRM, del punto de venta o de una base interna de ventas. Google pide que esos resultados sean datos sin filtrar y sin atribuir. Por tanto, exportar conversiones atribuidas desde la interfaz publicitaria no reemplaza el archivo de resultados del negocio.

Para la extracción, Google documenta GoogleAdsService con Search o SearchStream. La consulta debe incluir campaign.id, segments.date, el segmento geográfico ajustado al nivel del estudio y metrics.cost_micros. geographic_view representa el lugar donde estaba el usuario o por el que mostró interés; location_view ofrece la perspectiva de las ubicaciones seleccionadas como objetivo de campaña.

La interpretación operativa de CreatikLab es sencilla: no se analiza el incremento mientras no exista trazabilidad de cada fila hasta su campaña, fecha, unidad geográfica, sistema de origen y regla de transformación. Un total razonable no compensa una cadena de datos opaca.

La elección de vista no debe depender de cuál devuelve un total más familiar. Debe responder a la definición del experimento. Si se comparan resultados según la geografía del usuario, se valida geographic_view. Si el análisis se estructura según las ubicaciones a las que se dirigió la campaña, se valida location_view.

Antes de programar, redacte una frase que describa la unidad: cada resultado se asignará según la ubicación del usuario, o cada coste se organizará según la ubicación objetivo de la campaña. Si negocio, paid media y analítica interpretan esa frase de forma distinta, todavía no existe una especificación ejecutable.

1. Nombrar la unidad geográfica con lenguaje de negocio.
2. Indicar si representa geografía del usuario o geografía objetivo.
3. Seleccionar la vista de la API que corresponda a esa definición.
4. Contrastar varias filas con campañas y ubicaciones conocidas.
5. Registrar y aprobar la decisión antes de automatizar.

Google requiere que los resultados internos estén agregados por día y asociados a las unidades geográficas exactas utilizadas en el test. Los valores deben ser totales absolutos no negativos. Pueden representar ingresos brutos o número total de conversiones. Cuando un CRM guarda ingresos netos e introduce reembolsos negativos, la indicación de Google es utilizar cifras brutas en el experimento y aplicar después la proporción de reembolsos.

• Tabla de inversión: campaña, fecha, geografía experimental y coste expresado originalmente en micros.
• Tabla de resultados: fecha, la misma unidad geográfica y el resultado bruto seleccionado.
• Diccionario territorial: nombre de recurso de Google, nombre canónico, código interno y celda experimental.
• Registro de transformación: valor original y división entre 1.000.000 para presentar la moneda normal.
• Registro de celdas: inversión separada para cada grupo en estudios con varias celdas.

Los segmentos geográficos no entregan directamente un nombre territorial corriente. Devuelven un nombre de recurso asociado a GeoTargetConstant. Google permite consultar el nombre canónico en geo_target_constant o resolverlo localmente mediante su CSV estático de objetivos geográficos. El diccionario resultante debe versionarse como parte del activo de medición.

Esta matriz convierte cada riesgo en evidencia revisable, una acción y un propietario. No acepte confirmaciones verbales donde debería existir un archivo o una prueba.

• Granularidad — Evidencia: consulta y muestra exportada. Fallo: el coste no puede reagruparse por unidad experimental. Acción: corregir antes de recuperar el histórico. Responsable: ingeniería analítica.
• Mapa geográfico — Evidencia: tabla entre recursos y nombres canónicos. Fallo: se mezclan códigos ISO, Nielsen e IDs de Google. Acción: crear un diccionario único. Responsable: ingeniería de datos.
• Conversión monetaria — Evidencia: columnas de micros y moneda. Fallo: importes desproporcionados o redondeo prematuro. Acción: aplicar el divisor documentado y reconciliar. Responsable: analítica.
• Origen del resultado — Evidencia: especificación del CRM o punto de venta. Fallo: aparecen conversiones atribuidas al anuncio. Acción: recuperar totales brutos no atribuidos. Responsable: Revenue Operations.
• Fechas — Evidencia: perfil diario de ambos sistemas. Fallo: formatos alterados o días desplazados. Acción: conservar YYYY-MM-DD y resolver diferencias. Responsable: propietario de datos.
• Celdas — Evidencia: gasto separado por grupo. Fallo: grupos agregados. Acción: reconstruir el detalle. Responsable: líder del experimento.
• Aprobación — Evidencia: especificación firmada y registro de excepciones. Fallo: cambios no controlados. Acción: detener la publicación. Responsable: dirección de medición.

No conviene esconder extracción, resolución geográfica, conversión y unión dentro de un único script. Cada fase debe generar una salida intermedia inmutable o versionada. Así es posible averiguar si una diferencia nació en Google Ads, en el CRM, en el diccionario territorial o en una transformación posterior.

1. Extraer el coste con GoogleAdsService y guardar intacta la respuesta inicial.
2. Seleccionar campaña, fecha, segmento geográfico y metrics.cost_micros según el contrato.
3. Resolver cada nombre de recurso hacia su GeoTargetConstant, nombre canónico y unidad interna.
4. Crear la tabla monetaria sin eliminar la columna original en micros.
5. Exportar del CRM, punto de venta o base comercial los resultados diarios brutos y sin atribución publicitaria.
6. Validar que todas las geografías internas coincidan con las unidades aprobadas para el estudio.
7. Unir por fecha y clave geográfica, conservando las filas sin correspondencia.
8. Reconciliar totales por campaña, día, territorio y celda antes de entregar la tabla analítica.

Las filas sin correspondencia no deben borrarse para embellecer el dataset. Pueden revelar zonas sin cobertura del CRM, recursos todavía no resueltos o inversión fuera de las celdas previstas. Google no establece en esta guía una tolerancia universal para esas filas; el umbral de aceptación debe quedar definido en el contrato del proyecto.

Google documenta segments.date con el formato YYYY-MM-DD y advierte de que programas como Excel pueden modificar fechas automáticamente. Su recomendación es cargar primero el archivo en Google Sheets para comprobar que el intervalo se interpreta con el formato requerido. En una arquitectura automatizada, la protección equivalente consiste en imponer un tipo de fecha explícito y validar los valores antes de cualquier agregación.

Los ceros iniciales de los códigos postales también deben conservarse. Google utiliza como ejemplo 01234 y aconseja forzar una cadena de cinco caracteres en Google Sheets. En un pipeline, el código postal debe entrar como texto, superar una prueba de longitud y permanecer separado de cualquier campo numérico.

Los identificadores de activación merecen un control adicional. Para cambiar segmentación, Google exige el ID exacto de GeoTargetConstant; no admite un código ISO o Nielsen bruto como sustituto. Guarde en columnas diferentes el nombre visible, el código externo, el identificador interno y la clave válida para Google.

La tabla unida debe responder a una definición empresarial del resultado. Puede ser una compra completada, ingreso bruto o una oportunidad aceptada por ventas, siempre que el sistema interno pueda producir un total diario no negativo en la geografía del experimento. Si la cualificación de un lead sucede días después, conserve por separado el evento original, su estado posterior y la fecha de actualización.

• Unidad de observación: una fecha y una geografía aprobadas por fila, con campaña o celda cuando proceda.
• Inversión: coste de Google Ads transformado a moneda y valor en micros conservado para auditoría.
• Resultado: total bruto del CRM, POS o base comercial, no conversión atribuida por la plataforma.
• Cualificación: estado empresarial definido y gobernado por ventas o Revenue Operations.
• Actualidad: hora de extracción y última fecha completa de cada sistema.
• Cobertura: fechas y unidades esperadas frente a las realmente observadas.
• Excepciones: reembolsos, retrasos de cualificación, territorios ausentes y fallos de mapeo.

La documentación técnica no prescribe un modelo estadístico, un presupuesto mínimo, una duración fija ni un umbral de incremento. Esos números no deben deducirse de la consulta de la API. El especialista de medición debe decidirlos después de revisar el diseño, la historia disponible y la calidad de los datos.

Antes de interpretar diferencias entre regiones, cierre esta revisión con evidencias almacenadas junto al dataset.

• Evidencia: consulta y respuesta sin transformar. Acción: repetir una extracción de muestra. Responsable: ingeniería analítica.
• Evidencia: justificación de la vista. Acción: verificar geografía del usuario frente a geografía objetivo. Responsable: líder del test.
• Evidencia: diccionario GeoTargetConstant. Acción: rechazar recursos desconocidos. Responsable: datos.
• Evidencia: definiciones del CRM. Acción: eliminar filtros de atribución y confirmar totales brutos. Responsable: Revenue Operations.
• Evidencia: pruebas de fechas y códigos postales. Acción: impedir cambios automáticos de formato. Responsable: calidad de datos.
• Evidencia: reconciliación por celda. Acción: comparar origen y destino sin fusionar grupos. Responsable: analista de medición.
• Evidencia: registro de excepciones. Acción: explicar días, zonas y uniones ausentes. Responsable: dirección del proyecto.
• Evidencia: aprobación final. Acción: congelar la versión o emitir un reemplazo versionado. Responsable: revisor sénior.

No suponga que la API valida el experimento estadístico, que geographic_view y location_view son intercambiables o que un nombre legible sirve como identificador de segmentación. Tampoco dé por hecho que una conversión atribuida satisface la necesidad de resultados brutos. Una unión técnicamente correcta demuestra trazabilidad; por sí sola no demuestra causalidad.

La entrada comercial prioritaria es una auditoría de Google Ads centrada en el contrato GeoX. El entregable debe incluir revisión de consulta y vista, mapa de campos y fuentes, diccionario geográfico, prueba de conversión de costes, definición del resultado CRM, informe de calidad de unión y registro priorizado de correcciones. No debe prometer ROAS, incremento ni volumen de leads.

Si la auditoría descubre desacuerdo sobre la unidad territorial, la pregunta experimental o el resultado cualificado, la consultoría de Google Ads es el siguiente paso de decisión. Para comparar proveedores, pida ejemplos de evidencias, responsables identificados, lógica de reconciliación, manejo de excepciones y separación explícita entre capacidades verificadas de Google y metodología profesional.

La ruta de Expertos en Google Ads conecta la revisión técnica con decisiones de campaña. Para continuar el diagnóstico con contexto, explique a Lia la estructura de la cuenta, regiones propuestas, sistema de resultados y restricciones de datos. El punto de partida útil es el problema real, no una petición genérica de más conversiones.

¿Qué servicio de la API debe utilizar la extracción?

Google indica GoogleAdsService y señala Search o SearchStream como métodos aplicables. La documentación no impone una elección universal entre ambos; el responsable técnico debe justificarla según el flujo de extracción.

¿Sirven las conversiones atribuidas de Google Ads como resultado del experimento?

No para el flujo descrito por Google. El coste procede de la API de Google Ads, mientras que las conversiones o los ingresos deben llegar sin filtrar y sin atribución desde el CRM, el punto de venta o una base interna de ventas.

¿Cuándo corresponde usar geographic_view?

Corresponde cuando la unidad refleja el lugar donde estaba el usuario o por el que mostró interés. Google lo identifica como la configuración habitual de GeoX. location_view se reserva para el rendimiento según ubicaciones objetivo de la campaña.

¿Cómo se convierte metrics.cost_micros?

Google indica que el campo se expresa en micros y debe dividirse entre 1.000.000 para obtener el valor monetario normal requerido en el archivo. Conviene conservar tanto el valor original como el transformado.

¿Se puede activar una ubicación con un código ISO?

Google exige el identificador exacto de GeoTargetConstant para cambios de segmentación. Un código ISO o Nielsen sin transformar no puede sustituirlo.

¿Qué estructura necesitan los datos del CRM?

Deben formar una serie diaria, estar vinculados a las mismas unidades geográficas del experimento y contener totales absolutos no negativos, como ingresos brutos o número total de conversiones.

¿La guía define duración, presupuesto o significancia?

No. No fija una duración universal, un presupuesto, un umbral de muestra, una metodología estadística ni un incremento esperado. Esas decisiones pertenecen al diseño específico del experimento.