Hola, Jonathan.
Si te he entendido bien, tu informe se debe dar un aire a este esqueleto que he preparado:
En lugar de un control de filtro (desplegable) como tú, he utilizado una tarjeta de resultados para mostrar el descuento y una tabla, cuya presentación he ajustado para que no se parezca a una tabla 😉, para visualizar el nombre del usuario que está interaccionando con el informe.
Parto de una hoja de cálculo con 2 pestañas, a partir de las cuales se configuran sendas fuentes de datos. La que recoge los datos del usuario filtra por email, naturalmente.
Tu objetivo es que el informe muestre los precios con el descuento aplicado correspondiente al usuario que lo está visualizando, ¿no es así?
El problema es que los parámetros no te van a ayudar a conseguirlo.
Los parámetros se confunden a menudo con los controles de filtro, dado que también pueden aparecer en pantalla con el aspecto de las típicas lista de elementos seleccionables. Pero son otra cosa muy distinta.
No obstante, sus valores son establecidos directamente por el usuario, escogiéndolos a partir de una serie de opciones prefijadas en la definición de la fuente de datos a la que pertenecen o mediante introducción directa. Esos valores no pueden ser tomados automáticamente de los registros de las fuentes / conjunto de datos, ni tampoco puede leer el valor o valores seleccionados por el usuario en un control de filtro (tal vez sí en un futuro, se me ocurren algunos casos de uso en los que esto sería desde luego ventajoso).
Los parámetros en cambio, constituyen un mecanismo que permite algo así como romper la 4ª pared de Data Studio. Con ellos podemos hacer que el usuario tenga una influencia más directa en el modo en que el informe presenta la información, utilizándolos en la definición de campos calculados dentro de las fuentes de datos. En este artículo27 que publiqué hace ya algunos meses por aquí tienes más detalles y algunos ejemplos de uso (dimensiones opcionales, campos protegidos por contraseña) que explotan esta posibilidad de diversos modos.
¿Entonces qué hacemos?
Pues hay que meterle mano a la definición de los conjuntos de datos.
En la hoja de cálculo que he preparado para responderte, he añadido una tercera pestaña en la que se establece una vinculación entre los productos y cada uno de los usuarios, asignando en cada caso un descuento (que ahora además puede particularizarse para cada producto).
La clave del asunto está en los emparejamientos (ID producto, Email). Estos emparejamientos, junto con el campo Descuento, contienen la mínima cantidad de información necesaria para caracterizar de manera unívoca qué descuentos deben aplicarse a cada usuario. El resto de datos registrados para los productos (descripción, categoría, precio base...) y usuarios (nombre...) se mantienen en sus tablas respectivas y no se repiten en esta para evitar duplicidades y optimizar el espacio de almacenamiento necesario para su representación.
¿Y qué haremos con esta tabla? Pues la llevaremos también a Data Studio como una nueva fuente de datos (Productos y descuentos), que de nuevo configuraremos para que quede filtrada automáticamente por email.
A continuación crearemos una combinación de datos16 que atará esta fuente de datos a la que contiene la información de los productos. Esto se consigue en:
Recurso → Gestionar datos combinados
Las combinaciones de datos son algo así como vistas que pueden ser utilizadas como si de fuentes de datos convencionales se tratase, creando elementos de visualización que tomen dimensiones y métricas de entre las que hemos integrado procedentes de las fuentes combinadas.
La clave (tecla, telita con la traducción de Data Studio 😂) de unión es, naturalmente, la dimensión ID producto.
Mi combinación se llamará, poco imaginativamente, Combinación. Puedes verla en acción en la tabla de la parte superior de esta segunda página de mi informe de ejemplo.
Pero, ¿de dónde ha salido el campo Precio usuario? Se trata de un campo calculado7, algo que seguramente ya conoces. Pero ojo, Data Studio no soporta en estos momentos la definición de campos calculados dentro de una combinación. Y tampoco podemos referenciar una dimensión de una fuente de datos en un campo calculado creado en otra.
¿Entonces?
Pues definiremos nuestro campo calculado a nivel del control (tabla en el ejemplo) que bebe de la fuente de datos combinada.
El cálculo para Precio usuario es inmediato. El campo Precio procede de la fuente de datos Productos, en tanto que Descuento lo tomamos de Usuarios y descuentos (@). Como ambas fuentes se han fundido en nuestra combinación de datos, ahora sí podemos utilizarlos libremente en la misma expresión de cálculo:
Precio - Precio * Descuento
Precio usuarioEl campo calculado aparece como uno más en el selector de datos de la tabla, aunque solo existe en este ámbito. Si lo necesitáramos en otro componente deberíamos definirlo nuevamente en él.
Y ya lo tenemos ✌️.
Podríamos definir nuevas combinaciones de datos, esta vez entre la fuente de datos Usuarios y Productos y descuentos para enriquecer la presentación con información relativa al usuario, aunque en este ejemplo tan sencillo no me ha parecido apropiado.
Es importante mencionar que las combinaciones de datos tienen, en general, ciertas peculiaridades que, de ser ignoradas, pueden hacer que nos tiremos de los pelos hasta quedarnos totalmente calvos. La cosa da para hablar largo y tendido, así que simplemente lo menciono y dejo para otra ocasión.
Lógicamente, todo esto es infinitamente matizable y adaptable de acuerdo con los requerimientos del problema de visualización de datos que tengamos que resolver.
Dejo por aquí tanto los conjuntos de datos datos (hoja de cálculo) como el informe Data Studio que se puede ver en las capturas anteriores. Solo hay que hacer duplicados para destriparlo todo tranquilamente.
En fin, espero haberte aportado algo.
👇 Respuesta ampliada 👇
Vamos a tirar de una idea feliz, poco elegante en mi opinión pero que resuelve el problema rápidamente, que explota el hecho de que las combinaciones de datos en Data Studio son externas por la izquierda.
En este tipo de relaciones se genera una vista que contiene todos los registros de la tabla izquierda y solo aquellos de la derecha que tienen una clave o claves (campo o campos) de combinación coincidentes.
Y esto puede suponer que dicha vista resultante de la combinación contenga:
- Registros a la derecha de la combinación que aparezcan asociados a múltiples elementos del lado izquierdo.
- Registros con campos nulos, cuando en algún caso no haya ningún registro en la tabla a la derecha de la combinación coincidente con el que se encuentra a la izquierda.
- Registros a la izquierda duplicados, cuando varios elementos de la tabla a la derecha de la combinación coincidan con un único elemento a la izquierda de la misma.
Es justamente la primera de estas tres circunstancias la que vamos a explotar. Para ello, modifiquemos primeramente la tabla de productos de este modo:
Añadimos un campo adicional denominado Token, que contendrá un valor constante arbitrario mágico.
Y ahora vamos a hacer lo mismo con la tabla Usuarios inicial, la que asociaba un descuento único a cada usuario (email):
Mismo campo, mismo valor arbitrario, igual para todos los usuarios de la tabla. Parece absurdo ¿verdad? Pues no lo es en absoluto, de ahí lo de idea feliz.
Ahora combinaremos las fuentes de datos correspondientes obtenidas a partir de estos conjuntos modificados, usando como clave de combinación nuestro enigmático token:
Y esto es lo que sale:
Hemos logrado de este modo calcular el precio con descuento sin necesidad de generar artificialmente una 3ª tabla que desglose los descuentos por producto y usuario, como tuvimos que soportar en nuestra primera solución, más limpia conceptualmente y versátil, aunque menos efectiva.
La idea feliz consiste en darse cuenta de que:
- Como la fuente de datos Usuarios (@) está filtrada por email, siempre contendrá un único registro, el que representa al usuario conectado, junto con su descuento general.
- Al usar una combinación externa por la izquierda sabemos que la vista resultante contendrá todos los registros de la tabla de productos y solo aquellos de la tabla de usuarios que estén relacionados. Como el token es siempre el mismo, el registro único correspondiente a cualquier usuario combinará con todos y cada uno de los productos, anexando automágicamente sus campos, descuento incluido, a los de cada registro de la tabla de productos, que como sabemos contiene el precio base.
El campo Precio usuario será nuevamente un campo calculado construido a nivel de control (tabla).
Y el resto es historia (ya advertí que las combinaciones de datos tenían su intríngulis).
