Top-5 common design flaws for Klipfolio dashboards

19 August 2020 | 9 minutes of reading time

We have been a Certified Partner of Klipfolio since 2014. In recent years we have been able to build a lot of dashboards with this beautiful tool. We did this for many different customers with very different goals. We also help a lot of marketing agencies or customers with the further development of their dashboards that were initially set up by others. So, a lot of experience! Because of that experience we know what goes into building a sound Klipfolio dashboard. We often come across a number of things that we have encountered ourselves or that we have seen in other people's dashboards. Design errors, for example. Many of these design errors are often quite explainable because on the one hand you want to implement a change quickly. On the other hand, Klipfolio itself has gone through quite a bit of development, so now there are functionalities that make the design process easier. This is our top-5 of design errors in Klipfolio, and the solutions to avoid them

#1 - The “Swiss cheese”

Design error: do not take into account missing data Result: errors in the charts with all the risks involved Solution: use the lookup function What do we mean by this? Suppose you expect a file to have dates for every month, week, day. So you expect, for example: 2020-01 100 2020-02 300 2020-03 200 2020-04 100 2020-05 200 2020-06 300 2020-07 400 2020-08 200 2020-09 100 2020-10 200 2020-11 100 2020-12 200 But, the reality is this: 2020-01 100 2020-02 300 2020-04 100 2020-05 200 2020-06 300 2020-07 400 2020-09 100 2020-10 200 2020-11 100 2020-12 200 Here you can quickly see that there are no dates in March and August. However, if you have a larger dataset it can be difficult to notice these gaps. The next graph shows the line you expected to see. Here you can see all the dates; the line runs neatly from the first to the last month. But instead you get the following graph: At first glance, little is noticeable here. Almost identical to what you'd expected even, and that's exactly the nasty thing about this design flaw. When you take the column 'date' for the X-axis and the column with dates for the series, Klipfolio does exactly what you say and plots these dates for you. However, if you look closely you will see that the X-axis skips March and August and does not include them at all. This makes the graph seem correct at first sight, but on a closer look it actually is not. What can you do to solve this? In this case it is useful to work with a DATERANGE function on the X-axis.

DATERANGE(start, end, [format])

And since in this case we want to see the data per month, we have to combine the data range function with a GROUP. Suppose you use a dynamic source and you also want to display new data, you can also replace the parameter end with a function like TODAY().

GROUP(DATERANGE("2020-01","2020-12","yyyy-MM"))
GROUP(DATERANGE("2020-01",DATEVALUE(TODAY(),"yyyy-MM"),"yyyy-MM"))

By using one of the two functions above, you can be sure that the X-axis will display all possible dates, and it will not only read what it receives. It is important to combine this function with the LOOKUP function in your series. Earlier Tamara has written an extensive explanation about this. By using the lookup function for the series, Klipfolio will always link the correct values to the correct dates. If you don't, in this scenario you will get a graph with shifted dates, where April is reported as March, and so on. By using the LOOKUP function Klipfolio records that there is no matching value for the months March and August and will then report it as 0. In this way you do not sketch a distorted picture and you can quickly find errors in the data.

LOOKUP(X-as, Kolom A(datum), Kolom B(data))

Alternatively you can enable the setting 'Leave gaps for blank values'. The graph is then plotted as follows, with 'holes' where the data is missing for March and August

#2 - Slicing

Design Error: using the SLICE function inconsistently Result: errors in the charts with all the risks involved Solution: avoid slice where you can + be secure in your data quality process This is pure sloppiness and it happens to all of us. SLICE is a very useful feature in Klipfolio, where you can remove a number of rows at the beginning or the end of a column. Usually it's the first line of a column containing the title. A common problem when using the slice is that it is used inconsistently. If you are inconsistent, you may run into unexpected results. This is because there is a mismatch between the amount of data per component in the formula. Example data outcome - condition foo - 100 bar - 200 foo - 300 bar - 400 For example, the select function selects something when a condition is met, else it does not.

SELECT(B:B, A:A="foo")

This will give the results: 100 300 Suppose we want everything but ‘foo’, so

SELECT(B:B, A:A!="foo")

Now we get the following results: 200 400 We don't want that header here, so we'll remove it first

SELECT(SLICE(B:B), SLICE(A:A)!="foo")

Now, the result is: 200 400 But what if we forget this in one of the cases?

SELECT(SLICE(B:B),A:A!="foo")

Now we receive: 100 300 When you use the SLICE, it is important to always keep a close eye on the formulas. Is the slice included with all components in the formula? Do all evaluations (lightning bolt on the right side of the formula bar) show exactly the same amount of data? If so, then you have done well. Tip: have you used a SLICE but don't get the results you expect? Make sure you have used it everywhere before looking for the problem somewhere else.

#3 - The time factor

Design error: your clips do not take into account the time factor, so they report over the entire base without taking time into account. Result: limited usability to even wrong conclusions Solution: add a time dimension. Suppose you have several categories that you would like to display in a bar graph. Then it is sometimes very tempting to use and select all the data, put these categories on one axis, and the values on the other axis. This way you can compare the categories nicely with each other. However, what we recommend is to include a time dimension because this offers much more information. In fact, by not including the factor time, you run the risk of comparing apples with oranges. Suppose this concerns different products. Then you can use a graph without time to determine which product is the top seller. With a graph over time you can discover different trends:

• Is the ratio between two products always the same?
• Or does it differ per month/season?
• When one product is sold less, the other is sold more (competing products)?
• Or has product A sold the most in the past year but not much in the years before?

Then perhaps a graph without time dimension would show that this product has sold less than product B, that did well in the last year but less in the previous years. If that is not feasible or convenient, at least make sure that you do not select all data, but all data from the past x period; it is then at least delimited. The time factor and the understanding thereof, is crucial within the data analysis. The longest discussions and biggest misunderstandings often have something to do with time. The subject is too big and too diverse to describe in detail in this blog article. For now it is important that you at least think about it and don't forget it.

#4 - Redundancy

Design error: redundancy, writing out the same pieces of formula more often Result: complex formulas that are difficult to maintain. Solution: add hidden data elements and refer to them in your formulas. If you work with multi component Klips, you can also reuse these. Does this look familiar to you: you have been puzzling with "or", "and", and "if" statements for a while, but you have now written the function that selects exactly the data you need. You are enthusiastically going to put it into several series and you are satisfied with the result. But after a while this function has to be changed, and you have to change it again in all those seperate places. Not a very entertaining task. Luckily there is a solution that makes your work more organized, and also makes maintenance easier. This is the "Hidden data field" function. In this field you can make the calculation you want. Then you can use this field in other functions by referring to it via "&Data:" followed by the name you gave it. A nice example comes from a client for whom we built a dashboard. This client has data from different websites, and would like to be able to distinguish them from each other. Below is the function, if you don't work with hidden data fields: But if we do, the function will look like this. The large middle part is now put in the hidden data fields "channel" and "sessions" (which in turn refer to other hidden data fields) and is used in several places in the Klip. What can you do if something changes to one of the website URLS? Then you can easily change it in one place and you're done quickly. Besides that it's much easier to keep the overview while writing the function.

#5 - Spaghetti Graphs

Design error: too many values of one dimension in a chart. Result: cluttered charts Solution: reduce number of series and merge data Something else we come across a lot are cluttered graphs. Also called "Spaghetti Graphs". These graphs are so busy that they actually lose their value: you can't clearly read the trends anymore. We use as a rule of thumb: show a maximum of 7 series. The rest of the values go in the category 'other'. However, it is important to consult with the customers or your team about which data is going to be included in 'other'. What's also very useful is to add a small note to the clip that shows exactly which values are in it, so that someone who is looking at the clip for the first time also knows this. Finally, 2 bonus design errors specific to Google Analytics

Bonus #1 - Calculations with users

Design error: users from the API, unlike sessions and pageviews and other metrics, you may often not simply add up. Result: wrong data, with all the risks that entails. Solution: 2 sources and toggle with user input control. Suppose you have a source from Google Analytics with date and number of sessions and number of users. Then you want the number of users per month. You may not add up the number of users! At least not if you want to calculate the number of users according to the method of Google Analytics itself. This is best indicated with an example. Suppose you have 1 user on your website the whole month. He comes every day 1 time on your website. Google Analytics will say that in that month you have 1 user with 30 sessions, aggregated. When you split these on a daily basis, the Google Analytics API will give you 1 session and 1 user per day. If you then add up the number of users again, you would get 30 users. That's just not right. As a solution you can create a source that only fetches the users and extracts the date from the dimensions. Instead you use a start and end date in the filters (which you read dynamically from variables), or you use a different aggregation, for example month, as a dimension.

Bonus #2 - Data from a sample

Design error: not taking into account the sampling of Google Analytics. Result: skewed proportions Solution: increase sampling precision or apply dynamic dimensions When you request a large amount of data in Google Analytics, Google Analytics can apply sampling. This also happens when you make an API call to Google Analytics via Klipfolio. However, there will be no warning so you can see that the data is sampled, so it is often not immediately noticeable. For this reason it is important to check in advance whether or not sampling is applied in Google Analytics. Is this the case? Then there are still options to get to the non-sampled data. The first option is one that is also available in GA itself, and that is the "report higher precision" option. You can also use this option in your query for an API call by adding the following to the query:

&samplingLevel=HIGHER_PRECISION

This sometimes helps, but not always. A second option is to use dynamic parameters in the API call. Variables you create in the clip can be used again in the query to the API. This is done with {props.[variable]} where [variable] is the name of the variable you created. An example of what this looks like is:

https://www.googleapis.com/analytics/v3/data/ga?ids=start-date={props.firstmonth}&end-date={props.lastmonth}&metrics=ga%3Asessions&dimensions=ga%3AyearMonth%2Cga%3AlandingPage&samplingLevel=HIGHER_PRECISION

What we always recommend is to use the Google Analytics Query Explorer. In this tool, created by Google itself, you can login with your GA account and click on all possible metrics and dimensions. Click on run and the page will show you the complete query at the bottom of the page, as well as the results and above an indicator that shows whether sampling has taken place. This was our list of common and avoidable errors in Klipfolio. Undoubtedly you can mention more mistakes or tricky examples from your practice, do you have any questions or do you want to know more about faultless or easier clip building in Klipfolio. Please let us know: contact us Do you have a specific problem for which you are looking for a good solution, then please don't hestitate to contact us.