#70 Building dashboards like a pro

This week Dan and Dara talk about their experiences in building automated dashboards. There’s 1,001 ways to approach building them, so Dan and Dara go through the common missteps, how to scope and plan it out effectively, and even ways to measure the usefulness and consumption of them! Listen to the end to hear their great new business idea…

Dan mentioned that April 3rd 2023 is when we launch our new GA4 Immersion 6-week cohort training course – 50% early bird discount per ticket available now!

So Dan bought ratemydash.com, but now we need someone that wants to help build it – is that you? Email Dan and Dara on podcast@measurelab.co.uk if you fancy it!

This is the last episode for a few weeks, Dan and Dara need their beauty sleep… Back in a few weeks with more nattering and the occasional guest!

In other news, Dan makes videos and Dara reads about wildlife!

Measurelab is hiring! Head over to our careers page to see what positions we have open and apply.

Follow Measurelab on LinkedIn.

Intro music composed by Confidential – check out their lo-fi beats on Spotify.

If you’re like what we’re doing here, please show some support and leave a rating on Apple, Spotify, or wherever really.

---

Let us know what you think and fill out the Feedback Form, or email podcast@measurelab.co.uk to drop Dan and Dara a message directly.

Quote of the episode from Dan: “…if you have a terrible looking dashboard with perfect data, no one’s ever going to use it unfortunately. If you have a very beautiful interactive dashboard with terrible data, people will use it.”

Quote of the episode from Dara: “…you don’t use dashboards when you are doing analysis work, you probably go into GA or wherever else you’re going to get the data from, because you just don’t quite get, no matter how sophisticated the dashboard is, you’re probably going to reach a point where you’re like, oh, I can’t quite get what I need out of here…”

---

Transcript

The full transcript is below, or you can download the transcript file here.

• Intro [00:15]
• Topic [02:18]
• Wind down [36:42]
• Outro [39:11]

Intro

[00:00:15] Dara: Today’s episode is episode number 70, as is tradition, after each 10 episodes, we take a break for a couple of weeks. On today’s episode, we talk about building dashboards, we trade a few tips and tricks and talk about some of the main dos and don’ts of dashboard building.

[00:00:31] Daniel: And in completely different news, we’ve now got an official date for our GA4 Immersion six-week cohort-based, GA4 training. So I’m pleased to announce it’s the 3rd of April, 2023. It’s a six-week program, so that’ll run until Friday the 12th of May. We’re currently running, if you’re listening to this on the day it comes out and maybe shortly after, we’re currently running a 50% off promo on our website where you can get an early bird discount of £600 off the original price or the equivalent currency wherever you are. So head over to a link in the show notes to our GA4 Immersion six-week GA4 program. I’m super happy with it, I’m super pleased with it and I hope to see you there. All right, enjoy the show.

[00:01:07] Dara: Hello, and welcome back to The Measure Pod, a podcast for analytics people to talk about all things data and analytics. I’m Dara, I’m CEO at Measurelab.

[00:01:16] Daniel: And I’m Dan, I’m an analytics consultant and trainer at Measurelab.

[00:01:20] Dara: The good news is no product has been announced as being sunset in the last week, so we’re going to talk about something a bit different today, something we’ve all been through, which is building a dashboard, and we’re going to have a discussion and share probably some of our horror stories maybe and also some tips and tricks and maybe try and come up with some kind of process for how you might want to go about building a dashboard like a pro.

[00:01:44] Daniel: Yeah, like you said, we’ve all been there. At least we have, and we’ve done our fair share of good dashboards and bad dashboards. Well, I thought it would be fun for us to kind of talk through this because it’s the kind of stuff that we talk about a lot anyway, but actually everyone’s got their own sort of unique approach to building a dashboard. And obviously the key term, it depends, because it depends on the data, depends on the tool and depends on the people you’re building it for. But I think there’s a lot of commonalities between all the dashboards I’ve built, there’s a lot of things that are applicable in any situation that I thought would be fun for us to, to reel off, to go through and in a sense kind of get each other’s opinions on.

Topic

[00:02:18] Dara: Yeah, sounds good. I guess let’s dive in at the beginning. How would you suggest kicking off, because often what happens is if you ask somebody what they want, they could just give you a big, long wishlist. So it’s not necessarily the best way to gather requirements. Starting at the very beginning, how would you suggest gathering requirements from, let’s say it’s from multiple stakeholders who maybe have different needs, either needs for different data or needs for it to be presented in different ways.

[00:02:44] Daniel: I almost think you’ve just jumped a step already and the first thing I would always do is check who the stakeholders are or to make sure there are stakeholders. Because often and I’m sure most of us have gone through this where someone says, I need a dashboard, but I don’t know what I want. Or maybe they don’t quite have that yet, or maybe they don’t know who’s going to be seeing it yet. A lot of the work we do in analytics is invisible and it’s not quite tangible, you can’t see visible result of the investment that often people are making in to work with people like us or you know, with staff or stuff like that, you know, around the analytics space. So often the dashboard is perceived to be the output, you know, it’s like the end visual result you can share to your stakeholders, to your boss, internally to say, look, we’ve worked with these guys and this is what they’ve done.

[00:03:23] Daniel: It’s hard to get away from that fact and to kind of pull it right back and say, okay, let’s start from the very beginning. Do you have stakeholders? If you do, who are they? I’ve read up about this over the years and I’ve heard lots of people say, you know, maybe do some stakeholder interviews and find out what their goals are, do some kind of framework or strategy session. And yeah sure, if you can, that’s awesome, but sometimes that’s a bit overkill. And all we need to know really before you go in building a dashboard is, is there a person or a group of people that will be seeing this and what is it they want to do off the back of this. It’s not, you know, what data do they want to see? What KPIs, what metrics, what targets are they setting? It’s more like what decision do they want to be able to make that they can’t do right now and how’s that going to help? Because if you can’t identify who the stakeholders or who the kind of consumers of the dashboard is, and you can’t identify what it’s going to give them, you’re kind of stuck without even having a single number on a single page.

[00:04:15] Dara: Yeah, and that’s often how it has gone. I’ve experienced that numerous times where if you run those workshops, it’s what I mentioned at the beginning, you get that big, long wishlist it’s almost like let’s ask for all of the things we can possibly have in case we realise we need them at some point, we didn’t ask for them in that workshop. So what tends to happen, I think naturally if you don’t structure that conversation right, is you just get a list of metrics, KPIs, and chart types. And when you actually, if you just listen to that and then create the dashboard, you basically just end up with a whole lot of pages of charts and nobody really acts on it, and probably those same people will then come back to you and say, this dashboard’s really slow and clunky and I don’t really know what to do with it. Can you make a better one? So you’re right it’s like focus on what actions are going to be taken from it and then work your way backwards from there rather than what might be nice to have on a dashboard, which is just going to end up being everything.

[00:05:09] Daniel: If I am fortunate to get in front of the person, one of the stakeholders or the people that are going to be seeing the dashboard or the kind of the main consumers of it, I actively avoid asking them what they want to see. I actively avoid getting any kind of input in terms of visualisations of pie charts and bar charts and line charts. The kind of conversation I really want to be having with these people, if I do get a chance to speak to them, is are we talking about trends or do they need numbers? Are they looking at change over a period of time? Or are they looking just for totals or a cumulative total or a kind of, you know, a running total or a comparison total.

[00:05:44] Daniel: So I think for me, that’s the kind of thing that I’m trying to assess. I mean, when we talk about trends, like we know there’s going to be line charts and bar charts and things like that, right? And when we’re talking about total numbers for like a year-to-date number, we know we’re going to be talking about scorecards and pie charts and stuff like that, right? We don’t have to determine that kind of visualisation technique at that point, because a lot of the time that is dictated by the data itself. So if you do get an opportunity to talk to these people, then steer clear of the tactics and think more about the strategy and I say, oh, I almost hate myself saying that out loud. But it’s like, don’t try and build the dashboard with them in front of them. Just understand what their ambitions are and, or again, I hate myself just saying this out loud or at least the way it’s coming out, but find out what it is they’re after and in the broadest possible sense.

[00:06:28] Daniel: I spend two hours a month getting this number and I don’t want to do that anymore. I need to understand if we are up or down compared to last year. I mean these are the kind of broad things, how you visualise that is almost not important right now. It’s also worth just stating upfront is that when I talk about this kind of dashboard, I’m talking about any automated dashboard, if they’ve got data and they just need it visually presented, then that’s more of a designer you know, that’s not like where I would come into play. If they’ve got the data already to hand then they just need a better way of visualising it, that’s for someone else to do but what we’re, what we’re talking about at the moment is that kind of like straddling that line between data engineering and visualisation, right. When I talk about these kind of dashboards, that’s why it needs a bit of, or at least that’s the situation that we are kind of describing right now, automated data visualisations and I’ll try and steer clear of specific tools, but I suppose anyone listening to us at this point, Dara probably knows we’re talking about, or at least a lot of our experience is going to be Google Analytics and Data/Looker Studio, right?

[00:07:22] Dara: Yeah, I think so and I think it makes me think of that phrase, you know, just because you can do it doesn’t mean you should. And I think, you know, people do get very bogged down and this doesn’t just apply to dashboards really, but you do see it a lot with dashboards people do get bogged down in tweaking different, selecting different charts or trying to tweak the way it looks and fits and all the rest of it without actually just getting the data, even if it’s not the final data, but just getting, even if it’s some dummy data, just to kind of mock up how the dashboard is going to work. So coming up with like an interactive prototype to get the end users actually using it. Because I think it is difficult to be able to properly imagine how you’re going to use it. So you, there might be a difference between what data you think you need because you’ve always had it and you might’ve had your own workarounds for using that data. You know, you mentioned the example of spending two hours getting a number. If somebody did that, It’s very easy to then convince yourself that you need that number, and then you try and find a use for that number.

[00:08:17] Dara: If you’re trying to come up with a better dashboard, that saves people’s time you really want them to be able to actually interact with that as soon as possible and then see if that’s actually giving them the data in the right context in a way that they can actually draw a conclusion from. So, you know, things like, do they need to compare quarter on quarter, year on year? Do they need to compare one segment of data with another. If you can give that to them no matter how it looks, even if it looks rubbish, just the most basic design, but get the feedback on how they’re using it. Oh, actually when I did it, I realised that sometimes we need to do a quarter on quarter and year on year, but most of the time we don’t. Or sometimes we need to compare, you know, the UK with Germany, but other times we need to compare, like we need to look at all of EMEA as a whole or whatever. And then find out what they can’t actually do or what they don’t need and then get rid of those features and end up with something that they’re actively going to use and take action from, rather than just a nice bunch of pretty graphs.

[00:09:12] Daniel: Everyone loves a pretty graph.

[00:09:13] Dara: Well, yeah, we do.

[00:09:15] Daniel: And so I have to ask your opinion on this then. So I think this is the bit that divides a lot of analysts or people in the analytics space, I say divides, it’s a very strong word, but this is the thing that I see the, the differentiation, right? This is where lots of people have different approaches. What’s your opinion on before you get into a interactive wireframe with sample data before you get to that point, drawing it on paper, or even, you know, using a wireframing tool that’s not interactive, just some kind of mock-up of the overall layout of the thing before you get to something, even if it’s sample data.

[00:09:46] Dara: Oh, I’m going to really try and avoid those two, two dreaded words. It depends, but I can’t avoid it, I’m going to have to say it depends. I think if it’s, if it’s going to have a lot of data on there, if how it looks and how it’s presented and how it’s laid out is going to be a really important factor, then wireframing makes sense because it saves you wasting time getting to a stage too far down the line where then they say, oh, I don’t like it, I don’t like the way it’s presented, the layout needs to change. But if it’s more about what we’ve been talking about, which is having data presented in a kind of structure that you can act on and having you know the tools you need within that dashboard to do the right comparisons and to view the data in the right way to be able to spot trends, then actually I’d lean more towards getting it to a non-designed kind of semi-working interactive prototype that then you can visualise at the end, you can style it up at the end.

[00:10:39] Dara: So maybe it does depend on who the stakeholders are and the complexity of the dashboard because you know, and I know you’ll have done this many times before as well, but sometimes it really is just a fairly simple set of data. It could be something trended and you might want to have a couple of comparisons and actually just getting a sample of that data into an interactive prototype where maybe there’s a couple of basic filters or something, and the end user can use it and say, yep, that that’s going to do what I want. And then you can fully plumb it in and automate it and everything else. So yeah, I think it does depend on the stakeholders, it does depend on the complexity of the dashboard and what it’s going to be used for.

[00:11:15] Daniel: Do you think there’s an element there where it can also depend on kind of what you were saying at the beginning there is about saving time. So people like us, in a kind of an analytics agency, we charge on time and actually it, it’s that kind of that agile principle of fail fast fail often, right? And so if we are spending, in a sense, our clients’ money by doing this, do we want to spend four hours and give them something they can be like, nah, that’s not what we wanted. Or do we want to spend 15 hours and give them something interactive that they said they didn’t want? I think maybe there’s an element of saving time by kind of iterating quicker in sort of smaller incremental steps, whereas maybe if I had time that wasn’t directly tied to cost, maybe I was a full-time employee inside some organisation and I had the opportunity to invest my time in something that I think could be valuable and kind of present almost like a reveal, the kind of finished or like semi-finished product at the end, maybe that doesn’t matter so much.

[00:12:10] Daniel: But especially from where you know, my career, where I’ve been I’ve always felt a bit like working in secret is bad because in the sense spending their money, their time with us, without them kind of checking in, in a sense.

[00:12:23] Dara: No, I agree. But both ways are ways of reducing the risk of going too far and then realising it’s not right and lots needs to change, but it, you know, one might work better in one instance where, especially if you go back to that idea of doing like a workshop maybe, you could very quickly wireframe it up on a whiteboard and be like, okay, well we might use a time series chart here, and then we might have this broken down in a table and whatever. And you can very quickly get a sense of like, roughly is it going to be laid out in the right way? If you know for a fact, or you’re fairly certain that you know what the data is that’s needed and how it needs to be, you know, how they’re going to act on it. Almost like if it was needed for reporting purposes rather than necessarily any main action being taken from it, you already know what the end result is, so you can kind of get it working and you can do that in Looker Studio pretty quickly.

[00:13:07] Dara: You know, you don’t have to fully connect it up to the right data sources and finish visualising it. You can very quickly get, like, even if it’s just kind of a sample of the right data, add some filters in, get the client to play around with it, and then they’re like, yeah, okay I think that’s pretty much what I’m going to need and then you can add the bells and whistles afterwards. I guess I’m just thinking, I don’t know that you’d always necessarily need to do a hand drawn or a kind of traditional wireframe. You might be able to jump that step depending on, again, how certain you are of what that end result needs to look like. I’m definitely hedging my bets here.

[00:13:40] Daniel: Yeah, for sure. I mean, let’s say we had all the data available to us we didn’t have to do any data engineering basically, so there was no concern or confusion around where to source the data from or connecting it to Looker Studio. So let’s say all of that’s already handled, I think maybe at the time I’ve allocated towards this is purely a visual aspect and an organisational aspect and maybe I could, I could almost give myself that time to wireframe, to mock up and to be fair, I don’t think I’ve ever wireframed in a product before. I’ve only ever hand drawn, gone straight into the, into the product, into the tool of choice to build the dashboard. I’m wondering then if there’s an element of like data engineering involved as well, where we’re actually not sure how we’re going to get this data in, or even if it’s structured in the right way, then maybe, I think there’s kind of bigger fish to fry, as it were, and drawing stuff out and wireframing is not taking up too much space in my brain right now, there’s bigger fish to fry, right?

[00:14:27] Dara: Yeah, I think so. It’s hard, isn’t it? You’re usually trying to create something from a less than certain set of requirements. Because I mean, how many times have you built a dashboard and then even though the dashboard meets the original brief very quickly, whoever’s asked you to build it realises that the brief needs to be modified because they didn’t quite know what it was that they needed until they had something. And then once you’ve got that something, you can then realise what it doesn’t do and what you don’t use, and then you build version two and version two is closer to what was actually needed in the first place. But it’s like you often have to go through version one because it’s a difficult thing to brief in even because often the dashboard is to replace something that you’ve either been doing manually or it’s to introduce something that you haven’t really had before to surface some data that you haven’t really used or whatever. So it’s not a like-for-like replacement of something else, so you don’t necessarily know until it’s in your hands. When you’re using it, you don’t really know what you don’t like about it and what you would like to add to it to make it even better. So not necessarily saying this would be advice as such, but I guess I would say don’t beat yourself up if version one ends up not being fully fit for purpose, because that is sometimes part of the process.

[00:15:36] Daniel: Here’s a good question for you, Dara. When was the last time you ever built an automated report or dashboard that worked and was received well, first time and needed no changes.

[00:15:45] Dara: Never.

[00:15:47] Daniel: Exactly yeah. I don’t think anyone’s ever been out to do that unless you also happen to be the stakeholder and you gave the requirements too, and it’s just your thing.

[00:15:55] Dara: Even then, it often, even when I built one for myself, I often realise it’s not what I actually wanted.

[00:16:01] Daniel: This is the key point, right? Is that however you’ve approached it, however you’ve got to a point of having a V1.0. The thing to remember, and this is probably the advice we’re kind of giving at the moment, which is don’t invest emotionally too much into the first version, but also time as well, save time wherever possible. Just because it will change, it’s guaranteed to change. No dashboard has ever stayed the same from V1 ever. I always account for at least three iterations, so we do the kind of V1 exactly as you said, quite often there’s not a very clear scope, and it’s not that they haven’t given us a clear scope to build a dashboard, it’s almost like the consumer of the dashboard, the stakeholders don’t know what to ask for until they know what they don’t want right.

[00:16:36] Daniel: So quite often it’s a process of elimination and then, you know, it’s that kind of you know, the kind of data maturity aspect of like, you know, better questions start coming out and can we see it this way? Or do we have this kind of data? Is there a way to answer this question? And those only start coming out after you have something already, after you have something to see. And so whatever you start with, no matter how much time you’ve put into it, it’s going to change, and I think this is the biggest factor. And a lot of times when it comes to building reports or dashboards, it’s so underestimated and almost forgotten about or ignored or not thought about. And it’s like, oh okay, I can build a dashboard in a couple of hours or a day or two days or whatever. But actually it takes weeks in reality because it takes, you know, and it will take three rounds of that in terms of getting it right, getting feedback. Again, if you can get in front of the stakeholders, awesome. If not, you know, just getting some feedback around the interaction of the uses of the dashboard.

[00:17:27] Daniel: But the point is they don’t know what they want, we don’t know how to provide that until there is something. So quite often it’s the, I’m going to say the, in generic terms, the analyst’s role to provide a starting point, you know, a conversation starter in a sense. And that’s the hardest point because you stare at a blank screen and you’ve got some random kind of like sentences of like, ah, I need to see trends over time, and you have to start from somewhere, right? And I think that’s the most important thing, account for multiple iterations, just go for it, don’t get too attached.

[00:17:59] Dara: Yeah, I think that’s good advice. And there’s other kind of, you hinted at one earlier, but there’s, there’s other kind of practical issues as well where you can’t always foresee what’s going to slow down the dashboard or break the dashboard or what’s just not going to work visually or whatever until it’s done. And then when you layer on top of that, things like the API quotas, you know, there’s various factors that could mean that even if you’ve mocked it up, and even if you’ve done like a prototype and got it all signed off, when you finally fully automate it, plum everything in, and then say, here you go here’s your dashboard. You can realise it’s really painfully slow, or you can hit those API limits, or you can have some other error that you didn’t know about, or some data source might not quite work in the way that you expected. So there might be other reasons why you need to adapt as well. You might realise that it doesn’t quite practically work in the way that you hoped it would, and then you need to go through and optimise in some way.

[00:18:55] Daniel: This often happens with old more established dashboards as well, or reports, right? And it’s this scope creep that comes in and it keeps kind of like, oh, can we just add this and this and this? And it starts to kind of expand until it kind of collapses in on itself. The amount of times I’ve worked with dashboards like that, that’s the thing where it’s like you know, understanding the kind of purpose of a dashboard, and it can’t be solving every single purpose, or it can’t be answering every single question and having them you know, tailored I suppose to individual again, requirements is a broad term, but requirements, or at least the initial requirements. It’s okay to turn dashboards off, they’re finite and they will eventually become redundant and you can replace them as something else, right? Data changes, requirements change, needs change. So yeah, just especially when we’re using something like Looker Studio, just know that you obviously have multiple tabs within each dashboard you can use.

[00:19:40] Daniel: First things first, don’t try and cram everything onto the same page. There’s a certain number of charts per page limit anyway, less is more always when it comes to visualisation. Spread them out across multiple tabs, and if you need to do multiple dashboards, right? There’s no harm in that, it’s a free product and you’re not going to waste or use up anything that you didn’t think about.

[00:19:56] Dara: I’ve got a question for you. You often hear people talk about, especially when there’s like an internal analytics team or an internal person who’s responsible for managing analytics for the company. You’ll often hear them talk about kind of building self-serve dashboards. So the idea being that they can hand them over to the different teams internally and say, there you go you can grab whatever you need to do your job. Do you think that’s possible? Do you think it’s possible to build a quote unquote self-serve dashboard?

[00:20:24] Daniel: Yes and no. The thing is there are platforms out there, a lot of popular ones and less known ones, where in a sense you create a bank of widgets and you provide access to those widgets and they can build their own dashboards but using predefined, basically queries off the back of a data warehouse right. So like the SQL is all handled, you know it’s right, there’s like a governance layer that they are using unknowingly sometimes, but they get to build their own dashboard. But actually this is a more of a conversation around data democracy, right? It’s about do you give everyone access to the data to be more democratic, but then it can cause issues, problems, misinterpretations of the data, pulling wrong data accidentally because it’s very nuanced. Or do you lock it all down and provide no access to the data, but there’s no risk, right? So there’s no, no kind of like democracy to it, but there’s no risk of getting something wrong.

[00:21:14] Daniel: And quite often people are treading this halfway outside or trying to find this kind of like line within their organisation, within their teams where they can tread. So, you know, for example, most organisations will say, you know, self-serve dashboarding is being able to change the date range and some filter dropdowns inside of a Looker Studio dashboard, right? Because in a sense, they’re doing their quote unquote, own reporting, but it’s all predefined. And so the edges of what that entails is kind of very well maintained and very well defined and rigid in a sense. And they can kind of play within this sandpit, right? When we talk about self-serve analytics or self-serve data or whatever, then if it truly was, we give people access to the databases, to GA, to Google Ads and things like that, which I don’t think is what often people mean when they say that. It’s really hard to know what that line is and you’d have to figure that out, and I think it’s just by trialling it really. I think I would always start a bit more strict, I would always lock it down a bit more and then open it up slowly. It’s kind of like getting a haircut, you can always take more off, but it’s really hard, if impossible to put it back. It takes a little bit longer for it to grow back, whereas you can always cut a bit more off if you need to.

[00:22:18] Dara: Yeah, I think you’re right. And yeah, it’s something you said at the end of that it, it’s kind of where my question came from. You said, you know, if you really wanted to make it self-serve, you just give people access to all of the individual platforms and data sources. And that’s partly where my question came from because, or maybe it came from two places. One is I’ve seen when people try to build those self-serve dashboards and often it’s difficult to get the end users to use them as much as intended. Because what will happen is they’ll either, this is just from my experience at least, they’ll either end up for some reason, not trusting the dashboard because maybe it’s gotten a little out of date or it’s too slow and then they get annoyed with it. Or they, and sometimes both of these things can happen, or they’ll come to us as the, as their kind of analytics partners and say, can you just get this data for me?

[00:23:05] Dara: So that was kind of one avenue that made me think of that question. And then the other one is actually, I think I know the answer to this for you, or at least I’m going to take a guess and you can tell me if I’m wrong. I bet you don’t use dashboards when you are doing analysis work, you probably go into GA or wherever else you’re going to get the data from, because you just don’t quite get, no matter how sophisticated the dashboard is, you’re probably going to reach a point where you’re like, oh, I can’t quite get what I need out of here, so I’m just going to, I’m just going to bounce back into GA. Great for reporting, I think if you want to grab some numbers, it can be really useful, but as an analysis tool, for me at least, I always found it a bit better to just go to source.

[00:23:43] Daniel: 100% yeah. I mean, I don’t think I would ever try and do analysis or any kind of exploratory, well explorations, for lack of a better word within the data, within a dashboard. I mean, the whole point of a dashboard is that it’s got boundaries. It is predefined, it’s arranged, it’s manicured, it’s designed to perform a very specific function and quite often when we’re doing analysis or anything exploratory, we don’t have a function in mind. We don’t know what the answer is, we don’t even know what the question is often. And so, if we need to have that kind of Infinite flexibility, we need to go to the source, right?

[00:24:13] Daniel: We need to be able to see what the data tells us, go down that direction, come back, it was a dead end, and go down this direction and this might kind of provide something more fruitful. And the dashboard, it’s kind of like you’ve already done that in a sense. It’s like, I’ve already done that, I understand what’s valuable and I just need that again and again and again and again. That’s what dashboards are really for, but the way I talk about it often when I’m talking to clients or even training in Google Analytics, because Google Analytics 4 definitely brings that Venn diagram of like, Looker Studio and dashboarding and GA’s UI, kind of the Venn diagram of the two kind of overlap somewhat, especially considering you can customise the reports and the dashboards in there.

[00:24:47] Daniel: The way I phrase it all the time is that GA4 is great if you don’t know what you want and you want to go in and have a look and see if something’s up or see if there’s a change or see where a thing might be pointing you towards. Whereas a dashboard is just giving you the same thing over and over again. And there is an element of like, oh, you can change a filter, or there’s a dropdown, or you can change the date range, but that isn’t exploring. That is just changing a variable within the predefined output, right. Without doing it, it’s really hard to explain exactly when and where one will be useful because I’m sure there’s lots of grey area in between. But the reality is I don’t think I could do any analysis or exploration work in a dashboard.

[00:25:22] Dara: Maybe that’s getting to the point isn’t noticed that there can be a little bit of confusion around what it should be for, because if the dashboard’s being used to flag issues or to kind of spot trends, sometimes there’s a kind of a requirement to be able to dig down a level or two as well. But you do reach a point eventually where it’s your exploration’s going to end and you’re going to need to jump into GA or you know, if it’s a campaign issue, you might jump into Ads or whatever. So it’s not confusing the two, it’s not thinking of the dashboard as a deep exploration tool. It’s more of a surface some issues, and then you can go and dig into them, into them elsewhere.

[00:26:00] Dara: I think like the explorations in GA4 are almost like a bit of a bridge, aren’t they? They’re almost kind of, I mean, I know they’re not dashboards, but they’re almost like an exploration tool where you can end up with something that might become a reusable report, whether you want to call it a dashboard or not, you know, you almost get a little bit of the best of both worlds. You can get something nicely visually presented, and it could even be something you use multiple times. But it starts out as an exploration from a hunch or a problem you’re trying to dig into.

[00:26:27] Daniel: Well, I think that’s the point is you’re exploring the data and then you find something of value and you can just click save or, well, it auto saves rather, but you can come back into that point. I mean, there’s lots of flaws in explorations, it’s not perfect. I mean, you know, it’s good to visualise it if you pick one of the seven or six visualisations. And also no one else can edit it, so only the creator can edit it, even if you’ve shared. So there’s lots of issues and maybe things I’d like to see addressed over the next couple of months, hopefully. But the idea with the explorations is exactly that, you explore the data, you find something, and you can come back to it time and time again. But the thing about that is that, even if you did share that they have to have access to Google Analytics to go get that exploration data or get that visualisation.

[00:27:05] Daniel: The thing would be is that you can’t export that into something like Looker Studio. So if I’ve got a custom 10 step funnel, I’ve cut it by country or device type, I’ve got a segment laid on top of that of like our high value customers and I’ve got a number of the drop-off rate of step six to seven, for example, something crazy random and specific in the middle there. I can’t take that one number and put that into a Looker Studio dashboard. If someone just wants that one number, because the danger, and this is the data democracy argument is like, do I give them access to GA4? In which case then, they need to learn GA4, how to use GA4, what not to look at, what things to avoid, but also how to get that number. Or do I just put it in a dashboard and give it to them? But the thing is we don’t necessarily have the opportunity to do that in that specific example.

[00:27:47] Dara: Hmm yeah, fair point.

[00:27:48] Daniel: Unless of course you need some high class, amazing GA4 training, in which case I know a guy, I can point you towards them.

[00:27:55] Dara: Oh, do you? I don’t know anyone.

[00:27:58] Daniel: So when it comes to like, back onto the dashboards, right? Let’s say Looker Studio, let’s just call it Looker Studio dashboard, let’s say well, whatever we’ve done, we’ve got our first V1 dashboard. We’ve presented it, we’ve shared it, we’ve emailed people, whatever and we’ve got it in front of the people, they’re starting to use it. We know that that’s not going to be the final one, we know there’s going to be feedback, we know there’s going to be something. How do you go about getting feedback? How the hell do you go about finding out whether or not they’re using it, if it’s fit for purpose and what needs to change? What’s your kind of go-to or what’s happened before when you’ve done this kind of stuff?

[00:28:27] Dara: I’ll tell you what I’ve done before, which isn’t necessarily the same as what’s the right thing to do, but I have done a follow-up workshop with the end users, maybe not all of them it depends on sometimes the dashboard gets used by lots and lots of people and you’d never get a big bunch of people in a room and try and ask them for feedback because it would be a disaster. But you might get the same core group of people that you had at the beginning but then rather than just saying, so what do you like and what do you not like? Maybe step through it and ask very probing questions of like, okay, so you know, when you provided the requirements, you said you were going to use this aspect of the dashboard to optimise your campaign, your Ads campaigns, or you were going to use this to see if you needed to do any A/B testing on your website, you know, whatever.

[00:29:07] Dara: And then actually say, did you do that and how did you do it? Can you show me how you would use it to do that? And do a kind of, quite an in-depth walkthrough of the dashboard to see not just are they using it, but how they’re using it, and then kind of refine it from there. Because the danger with just asking, is you could just send an email out saying, hey, how’s the dashboard working out for you? And you might get something back saying, yeah, it’s okay. Or, oh it’s so slow I don’t use it. It doesn’t really, doesn’t really answer, answer the question in detail.

[00:29:35] Daniel: Well, I mean you say that, speed is a big issue, right? And it doesn’t matter how much work you put in, if the dashboard loads slowly it’s a big barrier for a lot of people, which is possibly one of the most gut wrenching things. Which is like you put all this work in, the dashboard’s amazing, you’re really proud of it. You go there and it takes 20 seconds to load and people are like, nah, I’m not going to use it.

[00:29:53] Dara: Yeah, they might do exactly what they need, but if it’s slow and we’re not, you know, sometimes it’s like it’s, we’re talking relatively slow, everybody will tell you a story about some report they used to run that took X number of hours to run, and you’d have to go away and have lunch and come back and it might have the data. So really, like we’re not talking about, you know, it’s not objectively long periods of time, but when everybody’s busy, if you’ve got to wait, and especially if it’s an interactive dashboard and you’ve got to wait each time you’ve select a filter or you add a segment, it’s just going to put you off. I mean, we’ve experienced it, we can’t pretend it’s not frustrating when that happens.

[00:30:27] Daniel: I’ll talk about like my approach just in case you don’t get access to the stakeholders, because there’s a whole other element of this, which is kind of like what we were saying at the beginning. What if you can’t get in front of the stakeholders? What if you can’t have a workshop or create a group, or even let’s say you don’t even know, let you say it’s a big group, or you don’t have their email addresses to even send out an email. So one of the things that I quite, I say enjoy doing. One of the things I’ve got into a bit of a habit of doing, which I’ve found has worked really well especially in something like Looker Studio where you can embed things, right? You can embed things on the tab, so what I generally do within my dashboards is I’ve got my kind of standard approach to things. I always have a homepage, which has no or very little data on there at all. So it’s like a landing page that kind of helps people. You can put outbound links to different help centre articles or whatever you’ve written.

[00:31:11] Daniel: I’d always have a kind of FAQs or a kind of guide page as well, which shows them how to interact with certain elements of Looker Studio full stop. But I always have a page where I embed a Google Form. So the whole tab of the dashboard is just one giant Google Form, which is a feedback form. So there’s, in a sense, within the dashboard, there’s a way to provide feedback wherever we go or wherever they go while they’re browsing the dashboard. So if something’s broken, something’s wrong, something’s not quite right, you can give them an email address at the top to say email dan@support.com but then there’s also a Google Form for them to fill out.

[00:31:39] Daniel: So first of all, they can be anonymous if they want to, if that’s a kind of a prevention factor for them to do it if they had to be identified. It’s easy to submit a form because you are in there, you are there in the moment, you can do it and if you’re annoyed, you can send the form. You don’t have to get people to then do something additional on top. And this is the thing that I quite like using as well because again, using Looker Studio as an example here, you can actually implement Google Analytics tracking on top of your dashboard. And some of the stuff with GA4 specifically with the enhanced measurement and the automatically collected events is you get a bunch of stuff, a bunch of information about people’s usage off the dashboard.

[00:32:11] Daniel: So first of all, each tab of the dashboard, when they navigate between them or open the dashboard, it counts as a session start, a user, page view. There’s also things like the scroll event as well and the outbound click events as well in most cases that I’ve used at least have our, our work and they track. I mean, that’s as much as we can get, right? We can’t put GTM on there, but the point is, we actually get to see, I mean, how many times has this dashboard been viewed in the last month? So if you’ve rolled out a dashboard, handed it to the stakeholders, and then you come back and you’ve got 20 people saying, yeah, it was great, and you see that it’s been used once a day, or once a week, you know, by two people, then you can already tell that there’s some untruths or some bent truth, should we say, from those people or those stakeholders. Maybe it’s perfect, maybe it hit all the requirements, but maybe they don’t use it for one reason or another, the thing is, we don’t know.

[00:32:52] Daniel: So yeah, it’s not about catching people out and pointing the finger, but it’s more around understanding consumption and beyond that first phase of build actually, it’s like, well, like I said, there’s a lifetime to all dashboards, over the next couple of months is it tailing off? Or is it consistently being used? Is this a dashboard people go in every day, every month, every quarter, or is this a dashboard that people use for the first week and then forgot about it? It didn’t bother them, didn’t do what they needed to ultimately, and they stopped using it all together within the first couple of weeks. And I think these are the things that the GA implementation stuff inside of the Looker Studio dashboard can be really valuable for. Of course, as well as the form which is a bit more specific, but GA does a decent job right there.

[00:33:28] Dara: Well definitely, yeah. It at least shows you what’s being used and what isn’t, and you can’t really argue with that can you? I really like the idea of embedding the form as well because I think you’re right. If you’re expecting somebody to then jump out of that and then somehow contact you or remember if you check in with them once a quarter and say, how’s the dashboard? They might have forgotten that. Whereas in the moment it’s frustrating you want to tell somebody about that frustration. You want to share it and say, hey, you know, why does this not work the way I thought it did? Or why is this so slow? And you get that like real feedback in the moment.

[00:33:57] Daniel: So just to kind of wind things up Dara, I just have to end with a spiel that I give to a lot of people just because it’s so important that I think a lot of probably you and my colleagues are sick of me saying this, but when it comes to dashboards, when it comes to any kind of data representation or presentation, the design and the presentation aesthetic is as valuable as the quality of the data. And this is one of those really annoying things, both to designers and also to data analysts, is that if you have a terrible looking dashboard with perfect data, no one’s ever going to use it unfortunately. If you have a very beautiful interactive dashboard with terrible data, people will use it. And so this is where I always say, whenever I’m doing anything along these lines of building reports or dashboards or anything automated like this, it’s 50/50. Always think of it as 50/50, the design, the aesthetic, the layout, the compatibility based on the screen size. Is it portrait, landscape? Is it responsive?

[00:34:50] Daniel: The colour palette used, any imagery, are things overlapping? Does it look good? It doesn’t have to be perfectly designed by like a graphic designer, but the point is, does it look good enough to not draw attention away for how bad it looks? And is the data good? Just focusing on one of them is never enough. And I’m not a designer, I don’t have an eye for design, but you know, there’s loads of guides out there. Or we’ll try and put some in the show notes to this, but the whole point of that is to make sure that the design isn’t distracting from the data, and that only happens with good or well thought through design. So it’s not about having big, flashy rounded edges or shiny objects or logos everywhere. It’s just about having an efficient design that doesn’t detract from the digestion of the data that supports it. But the point here is consider the design as 50/50 part of the data.

[00:35:35] Daniel: So if you haven’t considered the design and how it’s going to look and be compatible from the end user’s perspective until the end, and you’ve focused all on the data, then you’ve forgotten 50% of it. I always consider both throughout the process on equal level with each other so that by the time you get to an end, you have a, even just call it sufficiently looking dashboard with sufficient quality of data. And that is enough, that is perfect, that’s all you need. And then you can make improvements and make it perfect both ways around. Again, like I said before, if you focus on one and forget the other, unfortunately it’s destined to fail.

[00:36:05] Dara: You should set up a little side-line, little moonlighting venture for yourself where you review people’s dashboards for a fee and tell them on those two, both on the, you know, usefulness of the data and the ease of use, the design aspect.

[00:36:20] Daniel: Well, maybe that’s my next business idea. My wife being a graphic designer and me being an analyst. I’m wondering if we can go into business, actually, she’ll never do that, she’ll never go into business with me.

[00:36:29] Dara: ratemydash.com

[00:36:30] Daniel: ratemydash.com, all right let’s make it a thing.

[00:36:35] Dara: Yeah and you have to, obviously, now that I’ve given you the idea, you’ll owe me some commission.

[00:36:39] Daniel: Yeah well, everyone needs a CEO, right?

Wind down

[00:36:42] Dara: Yeah, yeah, of course yeah. What I’m actually doing here is filling time, because I can’t think of a wind down, which is what we’re going to cover next. So I’m desperately trying to think of something, so you can definitely go first this time just to buy me an extra few seconds.

[00:36:55] Daniel: On the spot, if I had to think of something, but what I’m currently focused on, I’m really enjoying, is I’m spending an awful lot of my time building out a new Google Analytics training program because it’s such a departure from the way of historically and traditionally people would teach Google Analytics 4 or any kind of analytics platform, Tag Manager, any kind of data tool. And so we are working with professional learning designers and we are working on a way of creating a multi-week program that has lots of different mediums in it to kind of teach this syllabus, which is fascinating, and I’m just really enjoying the ride. I’m learning so much around education, around teaching, as well as creating all the resources, the videos, the guides, the designing out these live sessions. So it’s not an escape route from work, it’s work related, but it’s such a departure from what I’ve done before. Sort of being in this world of learning design and really kind of stepping up the game in teaching Google Analytics. How about you Dara? I’ve bought you enough time, what is your escape route? What’s your wind down?

[00:37:49] Dara: I, for the first time, got up and walked out of the room while we were recording because I needed to check the name of the book. Thankfully at the very last second, something came to me. I’ve just started reading a really amazing looking book that Hannah got me for Christmas, which is all about Britain’s wildlife and it’s called Wonderland a Year in Britain’s Wildlife, day by day. So it talks about a different animal for each day of the year. So I’m going to treat our listeners and I’m actually going to tell them what the animal that’s covered on the day that this episode is going to come out, which is the 10th February. Oh, I have no idea what this is, oh, maybe this isn’t only animals. Maybe this is plant life, it’s whitlow grass, which surely isn’t an animal.

[00:38:31] Dara: Yeah okay. So it’s not just animal life, but plant life as well. But it covers a different thing for every day of the year. I’ve only just started, it’s a big old book. Obviously our listeners can’t see, I’m holding it up for Dan. It’s a big old book, it goes into a lot of detail and there’s no cheating, there’s no pictures in it, it’s all words. So I’m looking forward to educating myself a bit more about the nice wildlife that’s around us here in the British countryside.

[00:38:54] Daniel: God, it sounds almost like the opposite of the kind of book that I’ll be into. It’s factual, it’s big, and there’s no pictures. I don’t think that’s for me.

[00:39:02] Dara: But it’s about animals though, so.

[00:39:03] Daniel: Yeah, except for today.

[00:39:05] Dara: Yeah, except for today yeah. I feel slightly cheated.

Outro

Dara: That’s it for this week, to hear more from me and Dan on GA4 and other analytics related topics, all our previous episodes are available in our archive at measurelab.co.uk/podcast. Or you can simply use whatever app you’re using right now to listen to this, to go back and listen to previous episode.

Daniel: And if you want to suggest a topic for something me and Dara should be talking about, or if you want to suggest a guest who we should be talking to, there’s a Google Form in the show notes that you can fill out and leave us a note. Or alternatively, you can just email us at podcast@measurelab.co.uk to get in touch with us both directly.

Dara: Our theme is from Confidential, you can find a link to their music in the show notes. So on behalf of Dan and I, thanks for listening. See you next time.