¿No sabes qué es el mensaje «Ha accedido a este conjunto de datos demasiadas veces» (o «This data set has been accessed too many times») que aparece tu dashboard en Looker Studio?: te has encontrado con el temido error de cuota. En este artículo, explicamos qué es, por qué aparece y, lo más importante, cómo puedes solucionarlo.
En octubre de 2022, Google sustituyó nuestra ya conocida (y querida) herramienta de creación de cuadros de mando, Google Data Studio, por la que entonces era una alternativa de reciente creación, Looker Studio. En principio, este paso de una plataforma a otra se percibía más como una cuestión de rebranding resultante de la compra de Looker por parte de Google que como una actualización técnica, sobre todo porque no parecía haber diferencias notables entre una versión de la herramienta y la otra.
Sin embargo, esto distaba mucho de la realidad, ya que, con el paso de las semanas, se empezaron a detectar numerosas actualizaciones y novedades, algunas de ellas positivas y otras… no tanto. Entre esos cambios no tan buenos estaba la aparición de la cuota de Looker Studio, la cual es posiblemente una de las modificaciones más conocidas y, a la vez, más problemáticas de esta plataforma.
De cualquier forma, si aún no sabéis qué es la cuota, no pasa nada, aquí os lo explicamos. Y si ya se ha cruzado por vuestro camino, no os preocupéis, os contamos cómo evitarla. Eso sí, ya os adelantamos que, después de probar todas las soluciones, en aditu tenemos ya una favorita: BigQuery.
La cuota de Looker Studio: qué es y por qué es tan preocupante
Qué es la cuota de Looker Studio y cómo sabemos que tenemos un problema de cuota
En cuanto a la pregunta qué es la cuota de Looker Studio, Google como tal la define como un límite de solicitudes de datos a través de la API de Google Analytics. Dicho así puede no ser una definición excesivamente clara, así que nosotros solemos explicarlo de forma más sencilla describiéndola como: una advertencia en el dashboard que nos indica que hemos sobrepasado el límite de solicitudes de datos desde Looker Studio a Google Analytics.
De hecho, eso es justo lo que nos aparecerá en la interfaz de Looker Studio en el momento que hayamos rebasado ese límite que comentábamos, más concretamente, lo que sucederá es que desaparecerán todos nuestros gráficos que usen como fuente Google Analytics y en su lugar nos saldrá dentro de cada recuadro un mensaje de error que dice “Ha accedido a este conjunto de datos demasiadas veces”.
Por qué la cuota de Looker Studio es tan preocupante
Es evidente que ya el hecho en sí de que no podamos ver nuestros gráficos es un problema bastante estresante y molesto, ya que, ¿de qué nos sirve un cuadro de mando que no podemos consultar? Además, la razón principal por la que la cuota de Looker Studio nos da tantos quebraderos de cabeza es que no hay nada que podamos hacer para solucionarlo de forma inmediata.
Si tenemos la mala suerte de que nuestras visualizaciones se ven sustituidas por estas molestas notificaciones, podemos probar dos cosas. Lo primero que tenemos que intentar, sí o sí, es recargar el dashboard. Esto puede funcionar en los casos en los que hemos sobrepasado el límite de peticiones por hora o peticiones simultáneas.
Si tenemos la mala suerte de que hemos superado el límite diario, lo único que podremos hacer es esperar hasta las 9:00 CET (Central European Time) del día siguiente para que la cuota se reinicie y nuestros gráficos vuelvan a aparecer. Pero ojo, que la cuota se reinicie quiere decir que empezamos de cero con nuestro límite diario de solicitudes de datos y que, si volvemos a superarlo, también volveremos a tener un error de cuota.
Soluciones para la cuota de Looker Studio
Como ya hemos dicho antes, la cuota de Looker Studio no tiene una solución inmediata, así que si queremos evitarla tendremos que ser capaces de anticiparnos a ella. Para ello, en aditu os traemos 12 alternativas, clasificadas y ordenadas según el impacto que suponen, de modo que el error de cuota de Looker Studio nunca más vuelva a ser un inconveniente.
Soluciones de bajo impacto
Conocer los límites de la cuota y controlarlos
Empezamos nuestro listado de soluciones con la que probablemente sea la opción más obvia: controlar el consumo de cuota.
Una de las labores de los analistas digitales, más concretamente de los especialistas en visualización de datos, es el mantenimiento de los cuadros de mando. Esta tarea, como podréis suponer, implica revisar y optimizar todos los aspectos que nos podemos encontrar en los dashboards, desde los gráficos hasta las fuentes de datos o los filtros. En este caso, lo que debemos hacer es añadir una capa más y pasar a monitorizar también el consumo de cuota, es decir, a controlar cuántos tokens hemos gastado.
En cuanto a qué son los tokens, dicho de forma sencilla podríamos resumirlo en los créditos diarios que tenemos disponibles para gastar en la API de Google Analytics y que sirven para gestionar el consumo de cuota. En el momento en el que se acaben los tokens nos aparecerá el error de cuota.
Para ver el consumo de cuota o tokens, como prefiráis llamarlo, tenemos dos opciones.
Ver el consumo de cuota desde Looker Studio
La primera alternativa es verlo directamente en Looker Studio. Para ello solo hay que entrar en Looker Studio y clicar con el botón derecho bien en la propia página o bien sobre un gráfico o filtro. Ahí se nos abrirá un cuadro donde tendremos, entre otras opciones, Uso de tokens de Google Analytics.
Acto seguido se nos abrirá un informe bastante completo donde no solo podremos ver los tokens gastados, sino también los tokens disponibles (por hora, por día y por proyecto), un ranking de los mejores gráficos según su consumo de tokens y un informe específico por cada uno de los componentes del dashboard.
Ver el consumo de cuota desde Google Analytics
La otra posibilidad es entrar dentro de Google Analytics e ir al panel de administración.
Aquí podremos encontrar el consumo de tokens de la API de Google Analytics tanto a nivel de cuenta como de propiedad.
Esta alternativa es más rápida y sencilla si no nos hace falta tanta granularidad como en el caso anterior, es decir, si únicamente necesitamos saber el consumo general de cuota.
Como ya supondréis, el control de por sí no va a tener efectos en la disminución directa del consumo de cuota, pero sí que nos servirá para tener una visión clara de cómo de cerca estamos de llegar al límite, en dónde estamos gastando más tokens y, por lo tanto, tenemos que hacer optimizaciones y, sobre todo, tomar medidas en el caso de que vayamos a pasarnos.
Posponer la actualización de los datos
Otra de las opciones que tenemos a nuestro alcance cuando el problema de la cuota es mínimo, o casi inexistente, es el de reducir la frecuencia de actualización de los datos. Al fin y al cabo, cada vez que se actualizan los datos de nuestro cuadro de mando, lo que sucede por detrás es que se hacen llamadas a la API para solicitar esos datos “frescos” a Google Analytics y traerlos al dashboard. Esto, como ya supondréis, deriva también en que se consuma cuota y aumente el peligro de sobrepasar esos límites diarios de los que hablábamos en el punto anterior.
Lógicamente, de todo esto podemos concluir que una de las posibles soluciones pasa por retrasar al máximo posible las actualizaciones de datos.
Aquí tendríamos dos tipos de actualizaciones de datos dentro de Looker Studio:
- Manuales → las cuales las forzamos nosotros cuando editamos la conexión de una fuente de datos.
- Automáticas → aquellas que realiza el propio Looker Studio sin necesidad de intervención por nuestro lado.
Las primeras son fáciles de reducir, ya que dependen enteramente de nosotros y podemos decidir cuándo y cómo queremos que se produzcan.
En cuanto a las segundas, estas son algo más complicadas. Por defecto Looker Studio ofrece la posibilidad de actualizar los datos cada hora, cada 4 horas o cada 12 horas, siendo esta última la opción marcada de forma predeterminada.
Aunque el plazo por defecto sean 12 horas, es bastante común ver que se han seleccionado frecuencias más bajas para conseguir datos más frescos sin tener en cuenta que esta práctica puede provocar problemas como la ralentización de la carga o incluso un error de cuota. Así que, si queréis revisar o cambiar vuestra configuración de frecuencia de datos, seguid estos pasos:
- Dentro de Looker Studio, seleccionar un gráfico que esté conectado con GA4 y clicar en Fuente de datos.
- Buscar la opción de Actualización de datos justo en el encabezado del listado de datos.
- Escoger la frecuencia que más se adapte a las necesidades del proyecto.
Antes de ponerla en práctica, recordad que, aunque esta solución es una buena opción si vuestros errores de cuota son pequeños y poco frecuentes, supone reducir la frescura de los datos y tener que esperar algo más para tener información actualizada.
Centralizar credenciales de propietario
En el día a día de trabajo con nuestros clientes, una de las recomendaciones que más solemos hacer de cara a la gestión general de los proyectos de analítica es: no concentrar la propiedad de ninguna plataforma, herramienta o activo en un solo usuario.
La razón para esto es simple: si un usuario es el único propietario de un dashboard o solo hay un miembro en el equipo que tenga acceso a las fuentes de datos, corremos el riesgo de que, si esa persona abandona la empresa y su perfil de usuario desaparece, nosotros perdamos el acceso a esos activos de forma irremediable y, normalmente, irreparable.
Sin embargo, con el tema de la cuota hay que cambiar esta lógica y, si es posible, centralizar la propiedad y la gestión de los datos en una sola persona.
El motivo que hay detrás de esto es que las credenciales de propietario de Looker Studio suelen aprovechar mejor los datos en caché, reduciendo así las constantes solicitudes de actualización en busca de datos nuevos. Esto, a su vez, también minimiza de forma considerable el consumo de la cuota en comparación con las credenciales de visualizador, que generan más solicitudes a Google Analytics.
Como sabemos que después de lo que hemos dicho algunos de vosotros podéis ser reticentes a dejar todo en manos de una sola persona, en aditu os proponemos una solución intermedia: crear un usuario común y compartido al que todo el equipo tengáis acceso. Así, podréis centralizar la propiedad sin depender de una persona concreta, manteniendo el control y la continuidad de los proyectos de visualización.
Soluciones de impacto medio
Minimizar los accesos y el uso del dashboard
Empezamos las soluciones de impacto medio con una sugerencia que puede sonar un poco exagerada: limitar la cantidad de usuarios que pueden ver y usar el dashboard y la frecuencia con la que pueden hacerlo.
Quizá parezca algo excesivo, sobre todo teniendo en cuenta que una de las virtudes que se suelen destacar de Looker Studio es que es una herramienta de trabajo en equipo, ya sea para la creación de cuadros de mando o para el posterior análisis de los datos.
No obstante, volvemos a la máxima de antes de que cuantos más usuarios accedan al dashboard también habrá más solicitudes de carga de datos y, por lo tanto, un mayor consumo de cuota y más probabilidades de exceder el límite diario.
En este sentido, lo mejor es reducir el número de usuarios con acceso al dashboard al mínimo indispensable e incluso conceder permisos puntuales y concretos para aquellos miembros del equipo que solo necesiten consultar los datos de forma muy ocasional.
Programar el envío de los informes
De forma complementaria a la medida anterior podemos optar por, en lugar de consultar los dashboards directamente desde Looker Studio, automatizar el envío de informes periódicos por correo electrónico.
De esta forma, lo que vamos a hacer es programar el envío de informes en PDF con la frecuencia que más nos convenga (diaria, semanal, mensual, con una periodicidad personalizada…).
Esto al final lo que hace es, al igual que la solución anterior, reducir el número de accesos directos al dashboard, minimizar la solicitudes de carga de datos y ayudar a controlar y reducir el consumo de la cuota.
Pasar de ELT a ETL
Lo habitual cuando trabajamos con datos en Looker Studio es seguir un proceso ELT (Extract, Load, Transform). Esto quiere decir que primero extraemos los datos de la fuente original, como por ejemplo Google Analytics, para después cargarlos en Looker Studio y, finalmente, realizar todas las transformaciones, modificaciones y cálculos dentro de la propia herramienta de visualización de datos.
Pero, una vez más, vamos a tener que cambiar nuestra mentalidad y forma de trabajar. El sistema ELT puede generar un alto consumo de cuota dentro de Looker Studio, ya que cada campo calculado que creemos o cada cálculo que le solicitemos a la plataforma va a requerir una solicitud de datos a Google Analytics y, por lo tanto, va a generar un consumo adicional.
Dicho esto, lo lógico aquí sería pasarnos a un proceso ETL (Extract, Transform, Load), donde cualquier cálculo o transformación lo hagamos antes de llevar los datos a Looker Studio. Si bien es complicado, y a menudo imposible, agrupar datos o crear campos adicionales dentro de Google Analytics, sí que podremos hacerlo en bases de datos intermedias enfocadas precisamente a esa labor; de las cuales os hablaremos un poco más adelante.
Por ahora, quedaos con la idea de que hay que hacer todos los cálculos fuera de Looker Studio para así reducir las peticiones de datos y obtener un efecto positivo en el consumo de la cuota. Además, esto conlleva otro beneficio y es que, al estar ya todos los datos calculados y procesados, el dashboard tendrá una velocidad de carga superior.
Reestructurar el cuadro de mando
Continuamos el listado de soluciones con la que quizá sea la medida más drástica hasta ahora: modificar el cuadro de mando.
La labor de elaborar un cuadro de mando supone un trabajo considerable de diseño y estrategia previa. De ahí que empezar a cambiar las visualizaciones que tanto nos ha costado crear pueda sonar algo extremo. Pese a ello, es una de las alternativas más efectivas en los casos en los que el error de cuota sea una incidencia recurrente que nos afecte casi a diario.
Dicho esto, si de verdad tenemos que ponernos a replantearnos nuestro cuadro de mando, aquí tendríamos que combinar 3 medidas complementarias:
1. Eliminar y reducir
Todo lo que añadamos al dashboard genera consumo de cuota, así que cuanto menos tengamos, menos cuota gastaremos. Teniendo esto en cuenta, lo primero de todo es quitar todo aquello que no aporte valor al dashboard, desde dimensiones o métricas hasta filtros, controles, gráficos o fuentes de datos completas.
Al fin y al cabo lo que buscamos aquí es quedarnos solo con lo fundamental y evitar tener en nuestro cuadro de mando gráficos que no nos sean de utilidad, fuentes de datos que no se estén usando en ninguna visualización o filtros que alteren innecesariamente los datos.
2. Combinar y reutilizar
Otra de las opciones es, siempre que sea posible, buscar reutilizar los distintos elementos. Aquí nos referimos sobre todo a las fuentes de datos, las cuales podemos marcar manualmente como reutilizables para que se puedan usar en varios informes y así no tener que cargar una distinta para cada cuadro de mando.
Esto al fin y al cabo lo que hace es incrementar el uso del caché y evitar tener que cargar múltiples fuentes de datos redundantes, reduciendo el tiempo de carga del dashboard y al mismo tiempo el consumo de cuota.
3. Ajustar a lo esencial y replantear
El tercer y último paso es también el más radical, ya que supone modificar, en mayor o menor medida, nuestro cuadro de mando. Cuando hablamos de cambiar el dashboard, realmente estamos hablando de:
- Configurar filtros de fecha para que el período de consulta predefinido sea lo más corto posible (ej. pasar de trimestre a mes)
- Crear subpáginas y dividir el contenido entre ellas para controlar mejor qué información se carga (ej. separar en páginas diferentes los datos de la web de los datos de la app)
- Elaborar cuadros de mando adicionales y trasladar ahí los datos que menos se consuman para evitar que se cargue contenido prescindible
Esto puede parecer, y es, mucho trabajo, pero puede marcar la diferencia a la hora de tener que lidiar con la cuota. Además, todo lo que acabamos de listar no dejan de ser optimizaciones para los dashboards, así que también pueden servir para mejorar la forma en la que se consumen los datos y se lleva a cabo el proceso de análisis.
Soluciones de alto impacto
Utilizar conectores de terceros
Normalmente, sobre todo cuando trabajamos con Google, jamás se nos pasaría por la cabeza recomendaros cambiar una conexión directa entre Google Analytics y Looker Studio, por un conector de terceros. No obstante, hoy es el día.
La razón en este caso es muy sencilla: la cuota de Looker solo afecta al conector nativo de Google Analytics. De este modo, los conectores de terceros, o de partners, quedarían fuera de la limitación de la cuota y pasarían a ser una opción más que aceptable.
Eso sí, antes de que vayáis corriendo a Looker Studio a utilizar uno de estos conectores, tenéis que tener en cuenta que muchas de estas alternativas tienen un coste asociado. Aquí el importe que tengáis que pagar dependerá sobre todo de la plataforma y el plan que escojáis.
En cuanto a recomendaciones, hay muchas alternativas totalmente válidas, pero nosotros después de probar muchas de ellas, confiamos plenamente en dos conectores: Windsor.ai y Supermetrics.
Extraer datos
Siguiendo con las alternativas que implican dejar de lado la integración directa entre Google Analytics y Looker Studio, pasamos en este caso a aconsejar el uso de un conector relativamente nuevo: Extraer datos.
Poco después de que Google Data Studio pasase a ser Looker Studio, se lanzó este conector que permite, tal y como su propio nombre indica, la extracción de datos. Esta opción permite utilizar las fuentes de datos habituales, como pueden ser Google Analytics, Search Console, BigQuery, MySQL o Google Ads y, en vez de importar la totalidad de los datos, seleccionar únicamente aquellos campos (dimensiones y métricas) que tengamos claro que vamos a utilizar dentro de nuestro dashboard.
Esto deriva en la creación de un subconjunto de datos mucho más pequeño que el que tendríamos si optásemos por los conectores directos de esas herramientas y, por lo tanto, una reducción significativa de la carga de datos y del consumo de cuota.
Una de las grandes pegas de esta alternativa es que puede haber discrepancias, normalmente mínimas, entre los datos de la fuente original y los de la extracción de datos. Además, es un conector que todavía necesita mejoras por parte de Google, ya que puede generar incompatibilidades a la hora de combinar fuentes de datos, crear visualizaciones… Así que hasta que no se produzca esa actualización, este es un conector todavía algo limitado.
Contratar Google Analytics 360
Una de las características más representativas, y más conocidas, de las herramientas de la suite de Google es que la mayoría de ellas son totalmente gratuitas. Ahora bien, eso no quiere decir que todas lo sean. De hecho, seguro que muchos de vosotros habéis oído hablar de Google Analytics 360 (GA360), es decir, de la versión de pago de las principales herramientas que forman parte del stack de Google.
Pues justamente esa versión 360 es otra de las posibles soluciones al problema de la cuota. No porque lo arregle del todo, sino porque proporciona un mayor número de tokens, o dicho de otra manera, unos límites más amplios de solicitudes de datos, haciendo que sea más difícil que rebasemos el tope diario.
Como podéis ver, los límites de Analytics 360 en cuanto a la API de datos son bastante generosos si los comparamos con la versión estándar, por lo que se posiciona como una buena opción si tenemos un problema de cuota muy grave que ninguna de las soluciones anteriores ha conseguido solventar, queremos una alternativa sencilla y rápida y podemos dedicar buena parte de nuestro presupuesto a arreglarlo.
Siguiendo con el tema del dinero, GA360 tiene un coste variable que depende de muchos factores como: las funcionalidades que se necesiten, el volumen de datos con el que se trabaje o el partner de Google con el que colaboremos. No obstante, para que os hagáis una idea, el precio suele empezar a partir de los 50.000 euros anuales y puede subir hasta alrededor de los 150.000€.
De todas formas, antes siquiera de pensar en pasaros a la versión 360, prestad mucha atención a la siguiente alternativa que os proponemos.
Utilizar BigQuery como fuente de datos
Llegamos a la que casi seguro es la solución más apropiada para la mayoría de los proyectos: el uso de BigQuery como fuente de datos.
Decimos que seguramente sea la solución más apropiada porque BigQuery no solo nos va a permitir solucionar el problema de la cuota de Looker Studio, sino que también nos va a ayudar a:
- Unificar distintas fuentes de datos en un mismo sitio y tener una visión completa de todos nuestros activos digitales
- Crear un histórico de datos sin fecha de caducidad y sin límites de almacenamiento
- Evitar el muestreo y poder analizar los datos en bruto (sin que hayan sido previamente procesados)
- Calcular nuevas métricas y dimensiones que sean útiles para nuestro negocio
Ahora que ya sabéis el potencial que tiene BigQuery, pasamos a contaros los pasos que tenéis que seguir para poder incluir esta herramienta dentro de vuestro stack y, sobre todo, cómo podéis usarla para evitar la cuota de Looker Studio.
Antes hemos dicho en varias ocasiones que el problema de la cuota está directamente relacionado con la integración directa de GA4 y Looker Studio, así que no es de extrañar que en este caso la solución pase por utilizar BigQuery como fuente de datos de Looker Studio. Lo cual ya os adelantamos que es un proceso bastante largo y complejo, pero que merece totalmente la pena.
Como podéis ver en el esquema de arriba, lo primero de todo es enviar los datos desde GA4 a BigQuery. Esto es bastante sencillo de hacer a nivel general, pero algo difícil de llevar a cabo de forma optimizada, sobre todo teniendo en cuenta que vais a encontrar distintas opciones de exportación. Sin embargo, en principio no es algo que suela dar muchos quebraderos de cabeza.
Después, esos datos se transforman para unificarlos y darles un formato que Looker Studio pueda procesar correctamente. Avisamos de que este es el paso más complicado y que más trabajo técnico requiere, pero es también fundamental para que Looker Studio pueda entender correctamente la información.
Por último ya solo quedaría conectar los datos ya consolidados de BigQuery y utilizarlos directamente como fuente de nuestras visualizaciones de Looker Studio. Esto se hace directamente desde Looker Studio siguiendo el proceso habitual para añadir cualquier fuente de datos, así que no tiene pérdida.
Como no todo podía ser perfecto, ahora vamos con las dos inconvenientes que podemos sacarle a esta solución.
- Lo primero que hay que decir es que BigQuery es una herramienta de pago por uso, es decir, que dependiendo del volumen de datos que almacenemos, procesemos y transfiramos a través de ella, podremos tener ciertos costes adicionales.
Y decimos “podremos tener” porque realmente BigQuery tiene unos límites de uso gratuito bastante generosos, por lo que lo más común es que el importe a pagar sea bajo o incluso nulo.
De todas formas, aquí os dejamos dos recursos que os pueden ayudar a estimar este coste: el listado de precios de BigQuery y la calculadora de costes de Google Cloud. - Por último, la segunda y última desventaja que le podríamos achacar a BigQuery, es que hay un límite de exportación de un millón de eventos al día por cada propiedad de Google Analytics (no es común superarlo, pero puede darse el caso). Si se supera este tope durante una semana, se parará la exportación de datos y solo se reanudará cuando el número de eventos vuelva a estar dentro de los límites.
Una solución posible es separar los diferentes activos (web, app, AMP…) en propiedades diferentes de Google Analytics.
Si esto no fuera posible, deberíamos pasarnos a la versión de pago que comentábamos en el apartado anterior, Google Analytics 360, donde el límite pasaría de un millón a 20.000 millones de eventos al día —no, no hemos metido ningún cero de más, la cifra es correcta—.
Bonus track: la transferencia de datos desde BigQuery
Cerramos nuestro listado con la programación de transferencias desde BigQuery.
Realmente esta es una opción que a día de hoy es bastante novedosa y que todavía presenta muchas incógnitas. De ahí que por ahora no la pongamos como una solución propiamente dicha, sino como una posibilidad a tener en cuenta, pero todavía con cierto recelo.
En lo que respecta a la programación de transferencias, estas consisten en la utilización del conector de BigQuery para cargar e importar directamente los informes desde GA4 sin necesidad de un procesado intermedio; concretamente estos serian los informes que entrarían dentro de esta transferencia:
- Adquisición de usuarios
- Adquisición de tráfico
- Eventos
- Páginas y pantallas
- Páginas de destino
- Compras en comercio electrónico
- Promociones
- Detalles demográficos
- Audiencias
- Detalles de la tecnología
De entrada es una posibilidad que suena muy bien y que puede postularse como una opción muy interesante para solucionar el tema de la cuota.
De cualquier modo, tendremos que esperar un poco más para ver cómo funciona realmente esta transferencia de datos y hacer los testeos necesarios para asegurar que es una alternativa viable y fiable. Os mantendremos informados 😉
Con esto hemos llegado al final de nuestro listado.
Como ya hemos dejado claro, la cuota de Looker Studio es un problema bastante grave y preocupante que nos limita mucho a los profesionales del marketing digital, pero que también afecta a empresas de cualquier tamaño que confían en los dashboards de Looker Studio para visualizar y analizar sus datos.
Sabiendo esto, ahora es vuestro turno de escoger la solución, o soluciones, que más se adapten a vuestro negocio, y a vuestro error de cuota, y ponerlas en práctica.
Si en algún momento tenéis alguna duda o no sabéis cómo aplicar alguna de las soluciones, contactad con nosotros y desde el equipo de aditu estaremos encantados de ayudaros.
