Conector personalizado de Data Studio: cuándo crearlo, cómo funciona y cuánto cuesta

¿Qué es un conector personalizado de Data Studio?

Es código que enseña a Data Studio cómo iniciar sesión en una fuente, qué campos ofrece y cómo obtener filas cuando se le piden. La documentación para desarrolladores de Google los llama conectores de la comunidad (community connectors; mantuvieron ese nombre durante los años de Looker Studio), y se escriben en Google Apps Script sobre la Connector API de Google.

Todo conector debe definir cuatro funciones. getAuthType indica a Data Studio cómo inicia sesión el usuario. getConfig pide al usuario los ajustes, como un ID de cuenta o la obligación de indicar un intervalo de fechas. getSchema devuelve la lista de dimensiones y métricas con sus tipos. getData devuelve filas para los campos que un gráfico ha solicitado realmente. Una vez implementado, el conector aparece como fuente de datos igual que los conectores nativos de GA4 o Google Ads, y sus informes, campos calculados, filtros y envíos programados funcionan sobre él como siempre.

La documentación de Google enumera siete tipos de autenticación admitidos: OAuth 2.0, USER_PASS, USER_TOKEN, KEY, PATH_USER_PASS, PATH_KEY y NONE. Las credenciales deben guardarse en las propiedades del propio usuario (PropertiesService.getUserProperties), no escribirse en los campos de configuración, para que una clave de API nunca quede visible para otros editores del informe.

¿Necesita un conector personalizado, un conector de partner o un flujo de datos?

La mayoría de los equipos que me piden un conector personalizado acaban necesitando otra cosa. Antes de escribir una sola línea de código, someto la fuente a tres preguntas: ¿existe ya un conector para ella?, ¿cuántos datos necesita cada informe? y ¿con qué frescura deben estar?

Data Studio se conecta de forma nativa a GA4, Google Ads, Search Console, Sheets, BigQuery, YouTube, Campaign Manager 360, Display and Video 360, Ad Manager, Cloud SQL, MySQL, PostgreSQL, SQL Server y Redshift. Los conectores de partners de proveedores como Supermetrics, Windsor.ai, Porter Metrics, Funnel, Power My Analytics y Catchr cubren cientos de plataformas habituales a cambio de una cuota mensual. Un desarrollo a medida solo tiene sentido cuando ninguna de las dos opciones cubre su fuente, o cuando el proveedor no puede dar a los datos la forma que necesitan sus informes.

¿A qué se puede conectar un conector de la comunidad?

A casi cualquier cosa accesible por internet. La documentación de Google menciona cuatro vías: API web, bases de datos JDBC, archivos planos en CSV, JSON o XML, y otros servicios de Apps Script. En la práctica, las solicitudes que recibo se dividen en tres grupos.

El primero es un sistema interno con API, como una plataforma de pedidos, un motor de reservas o una herramienta de administración de pólizas. El segundo es un producto SaaS de nicho que los grandes proveedores de conectores no admiten. El tercero es una empresa de software que quiere que sus propios clientes creen informes sobre sus datos en Data Studio, que es el caso en el que tiene sentido publicar el conector.

• API REST internas con autenticación por clave o token.
• Herramientas SaaS sectoriales con API pero sin conector de partner.
• Bases de datos accesibles mediante JDBC que los conectores nativos no cubren.
• Archivos CSV, JSON o XML alojados que se actualizan de forma programada.

¿Cómo se crea un conector personalizado de Data Studio, paso a paso?

El desarrollo en sí es la parte menor. La mayor parte del esfuerzo está en acordar los campos, gestionar las peculiaridades de la fuente y probar con cifras en las que el negocio ya confía. Esta es la secuencia que sigo.

• Alcance: enumerar los informes que alimenta el conector, cada campo que necesitan, su tipo y los totales con los que conciliar.
• Revisión de la API: método de autenticación, paginación, límites de frecuencia, filtrado por fechas y hasta dónde llega el histórico.
• Autenticación: elegir el tipo de autenticación adecuado y guardar las credenciales en las propiedades del usuario, con errores claros cuando caduca una clave.
• Configuración y esquema: definir los ajustes que eligen los usuarios y un esquema tipado, con dimensiones y métricas nombradas como habla su equipo.
• getData: obtener solo los campos y el intervalo de fechas solicitados, recorrer las páginas de resultados y asignarlos al esquema.
• Caché: guardar las respuestas recientes para que las cargas repetidas de un gráfico no vuelvan a llamar a la API.
• Errores: devolver mensajes legibles en lugar de un gráfico en blanco, porque Data Studio no avisa cuando un conector falla.
• Implementación y pruebas: crear una implementación con versión, conectarla en un informe de prueba, conciliar los totales y después compartirla con su equipo.
• Entrega: el código en su propia cuenta de Google, un documento breve de campos y límites, y una sesión de explicación.

¿Qué límites debe prever antes de crear un conector?

Las cuotas de Apps Script marcan el techo, así que compárelas primero con su volumen de datos. Las cifras siguientes proceden de la página de cuotas de Apps Script y de la referencia del servicio Cache de Google, ambas consultadas en octubre de 2026. La cifra de URL Fetch es diaria para la cuenta que ejecuta el script, lo que importa cuando muchos usuarios abren un informe a la vez.

Los límites propios de Data Studio se siguen aplicando por encima. Las combinaciones de datos admiten hasta 5 fuentes de datos y solo uniones por igualdad, y las consultas muy grandes devuelven errores de demasiadas filas. Un conector no elimina ninguno de los dos límites.

¿Por qué son lentos los conectores personalizados y cómo mantenerlos rápidos?

Cada solicitud de datos ejecuta Apps Script antes incluso de consultar su fuente, y las páginas con muchos gráficos y muchos usuarios generan muchas solicitudes. En un hilo de julio de 2025 del foro para desarrolladores de Google (discuss.google.dev, titulado Custom Connectors Very Slow), un desarrollador explicó que los gráficos tardaban más de 10 segundos en mostrarse incluso cuando el conector devolvía un resultado mínimo fijado en el código, y en el hilo no se publicó ninguna solución. Coincide con lo que yo veo: una sobrecarga por llamada, multiplicada por los gráficos de cada página.

Las soluciones son sobre todo decisiones de diseño más que código ingenioso. Ayudan tener menos gráficos por página, filtros que acoten la solicitud y respuestas agregadas antes de llegar a Data Studio. Cuando los datos son grandes o la API es lenta, la mejor respuesta es cargarlos en BigQuery de forma programada y apuntar Data Studio a una tabla particionada, lo que saca por completo Apps Script del proceso de visualización.

• Devuelva solo los campos y el intervalo de fechas que ha solicitado el gráfico.
• Agregue en la API o en una capa de caché, no fila a fila en Data Studio.
• Use caché por usuario y por consulta para que las visitas repetidas no lleguen a la API.
• Limite las páginas a los gráficos que la gente lee de verdad.
• Pase a una carga programada en BigQuery cuando crezca el volumen o el número de usuarios.

¿El conector debe ser privado o publicarse en la galería?

Manténgalo privado si lee los datos de su propia empresa. La documentación de Google confirma que un conector se puede compartir directamente con cualquier usuario, que es todo lo que necesita un equipo interno de reporting, y así se evita un proceso de revisión pensado para productos públicos.

Publíquelo si es una empresa de software y quiere que sus clientes creen informes sobre sus datos. Los requisitos de Google para conectores de partners son concretos: una implementación de producción, acceso de lectura compartido con las direcciones de revisión de Google, una página alojada en su propio dominio con política de privacidad y condiciones de uso, una página de soporte en lugar de un enlace de correo electrónico, un logotipo alojado bajo su control, ámbitos de OAuth explícitos, la verificación del cliente OAuth completada y un conector terminado, no en beta. Reserve tiempo para esa revisión además del desarrollo.

¿Cuánto cuesta un conector personalizado de Data Studio?

El desarrollo es el coste principal, y los costes de funcionamiento suelen ser pequeños. Apps Script no tiene cuota de licencia dentro de los límites anteriores, y Data Studio es gratuito para creadores y lectores. Data Studio Pro, a $9 por usuario, por proyecto y al mes, solo es necesario si su equipo quiere espacios de trabajo Pro y contenido propiedad de la organización, no para usar un conector.

Lo que mueve el precio del desarrollo es la fuente, no los gráficos. Una API con autenticación por clave, JSON limpio y filtro de fechas es un trabajo modesto. OAuth, una paginación profunda, nombres de campo incoherentes, histórico incompleto o límites de frecuencia estrictos añaden trabajo cada uno, y una solicitud de publicación en la galería añade más. Como referencia, las tarifas que publican agencias como halo-lab.com sitúan a los consultores freelance de Data Studio entre unos $100 y $200 por hora, aunque un precio cerrado sobre un alcance por escrito es más fácil de comparar.

Haga la comparación con honestidad. Si un conector de partner ya cubre su plataforma, su suscripción suele salir más barata que desarrollar y mantener su propio código, y se lo diré en la revisión.

Errores habituales y cuándo no crear un conector personalizado

La mayoría de los proyectos de conectores que fracasan comparten las mismas causas, y ninguna es el código. Son problemas de alcance y de propiedad que aparecen meses después, normalmente cuando alguien se marcha o cambia la API de la fuente.

A veces la respuesta correcta es no tener ningún conector. Para una correduría de seguros australiana que recibía archivos .xls desordenados de varias aseguradoras, un proyecto que dirigí en Greenwolf Tech Labs automatizó la llegada de los archivos a Google Drive, los volcó en una Google Sheet central con las reglas de negocio aplicadas y alimentó el dashboard desde ahí. La preparación de informes pasó de 4-5 horas a menos de 5 minutos, y la precisión de los informes subió de alrededor del 75% al 99%. Un conector no habría arreglado esos archivos; un flujo de datos sí.

• Desarrollar para una plataforma que ya admite un conector de partner.
• Obtener filas sin procesar y agregarlas en Data Studio, lo que agota las cuotas enseguida.
• Dejar el script en la cuenta personal de un contratista.
• Poner las claves de API en campos de configuración en lugar de en las propiedades del usuario.
• Saltarse la conciliación, de modo que nadie confía en el primer informe.
• No cree uno cuando la fuente sea una exportación de archivos, los datos sean muy grandes o nadie vaya a mantener el código después del lanzamiento.

Cómo trabajo en los proyectos de conectores

Trabaja conmigo directamente, desde la primera revisión hasta la entrega. Empiezo leyendo la documentación de su API o una exportación de muestra y los informes que quiere, y después recomiendo la vía más barata que vaya a aguantar: un conector de partner, un conector personalizado o un flujo de datos a Sheets o BigQuery. Tras una revisión gratuita recibe un presupuesto cerrado para esa vía, con los costes de funcionamiento indicados por separado.

El código, las implementaciones y las fuentes de datos están en su cuenta de Google desde el primer día, así que nada depende de que yo siga implicado. Si el conector alimenta un nuevo dashboard, también lo creo, y si un informe existente dejó de funcionar tras un cambio en la fuente, puedo repararlo.