Hi everyone,
INTRO
Before diving into the 3 feature ideas, and the bug to fix, find some context first.
CONTEXT
I’ve lately been working on 2 separate versions of a custom date range comparison tool for Looker Studio.
Short note : Even though the following systems work, you sincerely don’t want to manage them in the long term.
VERSION 1
[CAN ADD ONLY 3 IMAGES, SORRY]
6 parameters and ~10 custom dimensions to make it work. This setup is to repeat for each datasource used in a given report.
Pros
- OK to manage
- UX Friendly for “analysts”
Cons
- Hard to manually type “DD-MM-YYYY” format for many people.
- Impossible to simply use multiple datasources in a single page.
- Even if i properly replicate field IDs, labels, etc, the system is bugged when using multiple sources in 1 page.
VERSION 2
14 parameters, same amount of custom dimensions as V1. As V1, you must repeat the process for each datasource.
Pros
- Super UX friendly for anyone
Cons
- You don’t want to maintain this.
- To achieve the “visual hack” of having no param name in the dropdown, you must replace its name with some blank param name such as “alt+255”.
- First, you place everything correctly, then once you are certain it won’t need to move (spoiler, it will move sooner than you expect
), you go to the datasource fields list and rename each param to alt+255. - If you already have all your datasources ready with 50+ custom metrics, you don’t want to restart it since the beginning. So if you want to implement this with the dropdown, be ready to repeat the tedious process of typing all the day numbers in multiple fields (times data source number).
Wonderful for viewers, awful for editors.
How to make an analyst to not want to work with a Dashboard ? Do this.
If you want to work with multiple datasources with this system, be ready to develop an extension that binds all your reports and parameters in it so people will only be able to access your multi-source report this way.
You will be able to add +600chars of url params to make it work :
- 3 params : current period start date
- 3 params : current end date
- 3 params : comparison start date
- 3 params : comparison end date
- The comparison mode
- Multiply this by your number of data sources for a given report
You’re all set with your unnecessary labyrinthic system.
FEATURE IDEAS
Parameter duplication
As we can do for dimensions and metrics, being able to duplicate parameters would reduce frictions.
[CAN ADD ONLY 3 IMAGES, SORRY]
Component level rename for parameters
Title says it all. Report editors must have the ability to keep their technical naming conventions that do not have any negative impact on data viewers.
This feature already exists for dimensions and metrics, not yet for parameters.
[CAN ADD ONLY 3 IMAGES, SORRY]
[CAN ADD ONLY 3 IMAGES, SORRY]
[CAN ADD ONLY 3 IMAGES, SORRY]
(Also, please fix the fake “Invalid” parameter bug, that’s annoying)
Report-level / Cross-source parameters
Instead (or complimentary to) of creating parameters for a single data source, we would create them for a given report and assign datasources to use these parameters.
- We could import parameters from other Looker Studio reports to avoid repeating the creating process. By default, they would not be assigned to any source, but you can toggle access for the sources you want.
- Each datasource would have the ability to interprete the parameter the way it wants.
- Being able to tag parameters locally to a report would be a great option to categorize them nicely.
Since many people already have tons of parameters created, the assignation principle already exists.
What’s missing would be :
- A new UI segment of Looker Studio that allows managing parameters
- Being able to assign a given parameter to multiple data sources
- Being able to automatically assign a given parameter to any new datasource added to the report.
- Tagging system to categorize those parameters (Sexy to me yet optionnal with a great naming convention)
Other things could be done this way, but that’s good for today.
BUG TO FIX
INVALID PARAMETERS
Whatever happens to a data source, if you create a parameter, it will end up appearing as “Invalid” even if it works.
This bug has been in LS for a long time and is ANNOYING. We need to test all the “Invalid” params 1 by 1 to finally reach the one we wanted to target.
OUTRO
Looker Studio is a brilliant free tool.
It still has some bugs that have been reported by community for 1year+ that should have never persisted for such a long time.
Will I pay for licences knowing these bugs exist ? Never.
Will I pay for licences to make it used globally in my company knowing its bugs are fixed and essential features are developped ? Take my money.
Yours,
