Adding Looker Studio Dashboard to Squarespace Website
The first step on my journey toward adding a dashboard to my squarespace website is, interestingly, the last step! Looker Studio and Squarespace are supposed to play well with each other, but before I invest too much into setting up my data architecture I want to make sure it hits requirements.
Setting up a simple dashboard
Getting Data
Looker Studio has ~20 direct ways to bring data to your dashboard, mostly being through other Google products like Google Sheets, BigQuery, etc., but if you include Looker Studio partners there are thousands! I’m going to use Google Sheets for now to keep it simple.
If you’re ever looking for data to play around with, there are free datasets all over the internet. One of my favorite places to find them is Kaggle, so I found a fun one to use for this example (and maybe even more like this later) but if you’re looking for a good high-level resource I would recommend checking out this page from Tableau.
Building the Dashboard
When first navigating to Looker Studio, you’ll need to set up your account but it’s a very intuitive process. After importing data, you’ll have the opportunity to set data types, default calculations, things like that. I’m noticing a few quirks that will take some time to get used to - it makes things… a little too easy? Understanding what your calculations are actually doing is really important, so when using Looker Studio make sure to be thoughtful when it comes to aggregation, averages, indexes, etc.. But, that doesn’t matter for now since, ideally, most of the real work will be done outside of Looker Studio. This could be problematic for certain use cases though. For example, Reach and Frequency are common metrics to report on in Advertising. If the back-end calculation handles identity/device matching, that’s a dynamic calculation that is dependent on date ranges, ad sets, campaigns, etc., but when it makes it to the Dashboard those are interpreted as flat metrics at whatever level of granularity it was imported. If you were to generate that data based on a set date range, etc., and then filter that once again in Looker Studio, it wouldn’t necessarily go BACK to the transformation - it’s limited to the data that was imported. This is likely a benefit to using direct integrations, but that integration would need to be very deep for some use cases. This isn’t a “problem” per say, but a worthy observation.
After setting up the connection to a Google Sheet where my data now lives, I’ve built out a (very) simple dashboard for this test. Using the dashboard, you can check out the individual stats of a specific pokemon or analyze a pokemon type based on attack and defense. At the bottom, it shows an average of attack, defense, special attack, and special defense, and this average is overlayed with things like speed, height, and weight. The data could use some more clean-up, but that’s not what I’m doing right now.
Sharing the Dashboard
Now that the dashboard is available, Looker Studio has an option to enable embedding. First, adjust the share settings make the report public and then go to File > Embed Report > Enable. This will generate HTML that can be embedded on Squarespace. I adjusted the dimensions to 1200x900 for now, but may need to adjust later.
Adding to Squarespace
We have a public dashboard and code to embed it. This means I finally get to add a Projects tab! The dashboard can be embedded using the embed block. At first glance, it just works! But, as I expected it’s not responsive - after switching to mobile view, the fixed pixel size that Looker Data Studio incorporates stretches the screen.
There are an infinite ways to fix this, but I’ll bucket them all loosely as:
Adjust the HTML to be responsive, adjusting the iframe to screen size.
Adjust the HTML to include conditional logic that calls a desktop-friendly or mobile-friendly dashboard based on screen size.
Embed the dashboard differently, requiring a move away from Squarespace.
Obviously, the easiest would be to simply adjust the HTML to be responsive, but I have to call out the second option because for more complex dashboards I absolutely would want a mobile-friendly view. This is still not going to look great on mobile, but it will be good for now.
I found a helpful article that would accommodate the first two, but to save some time I prompted ChatGPT to revise the code instead. Seemed to work fine, other than some odd extra scrolling in the iframe. We seem to be in an okay spot, but I’ll probably work more on this later. You can check it out here, but no promises I’ll leave it as is.
What’s Next?
Next up I’ll be moving this dashboard to pull from BigQuery instead of Google Sheets. This will still only involve setting up data in BigQuery, not the full E2E solution where I may be pulling data from an API. But, I probably will take the opportunity to make it a more interesting dashboard.