When you define a link or html parameter in a measure that references a value from another field using the {{ view.field._value }} or {{ field._value }} syntax, Looker pulls the field into the SQL query in order to grab the field value. Because of this, Liquid can affect how SQL queries are generated and how many columns the GROUP BY clause uses, which can cause unexpected behavior when working with aggregate measures, like count.
For example, if you have the two following measures:
measure: count_without_liquid {
type: count
}
measure: count_with_liquid {
type: count
link: {
label: "Status Count"
url: "https://www.google.com/search?q={{ status._value }}"
}
}
When you generate a query using the count_without_liquid measure, you get the following results:
The SQL generated for the above results is below:
But, when you generate a query using the count_with_liquid measure, you get the following results:
As you can see, instead of a count for each month in the query, you receive a count for each month AND each status. That is because in the generated SQL, the status field was added to the query so that its value could be retrieved. And because it was added to the query, it was also added to the GROUP BY clause:
You can stop this from happening using the row[] function with the Liquid variable, which does not add the referenced field into the query:
link: {
label: "{% if row['view_name.field_name'] %} some_label {% endif %}"
url: "https://www.google.com/search?q={{ row['view_name.field_name'] }}"
}
Note that when using this syntax, the link works only if the field is selected or included in the query by some other means.
To sum up, the use of the row[] syntax will not cause the field to be added to the query like {{ field_name._value }} does. The dynamic label will cause the link to have no label if the field is not available, which causes the link to disappear from the link menu.