Google Analytics dashboard: I connected my own site traffic into Power BI

The maze called Google Analytics

Have you ever tried using plain Google Analytics, straight in the web interface? Is it "easy"? Can you understand anything on the first try? I'll be honest: the experience is terrible.

There are multiple menus, submenus, reports with similar names, and filters that are far from clear. This might sound bold, but I think even people used to the tool don't fully enjoy the experience. Now imagine someone who isn't used to it at all?

Every time I wanted to answer a simple question like:

• "did the blog's traffic grow this month?"
• "where are visits coming from?"
• "which pages hold attention the longest?"

I had to dig through the whole tool to make sense of the charts, filters, and reports. Then save templates to use later. Not to mention the answers I wanted quickly.

That friction is what pushed me to build this dashboard: take everything that actually matters from Google Analytics and put it on a single screen, my way.

The tribute that came from a WordPress plugin

Anyone who has run a WordPress site has probably heard of MonsterInsights, a very popular plugin that pulls Google Analytics data straight into the WordPress dashboard, in a simple way, without needing to leave the site to understand its traffic. I used that plugin for many years, across several projects, before migrating to another stack.

That's why the blue mascot that shows up in the dashboard isn't random: it's a fond tribute to the MonsterInsights "little monster," which for a long time was my simplest entry point into a site's traffic data.

The Google Analytics connector in Power BI

Power BI has an official Google Analytics connector, available right inside Power Query (GoogleAnalytics.Accounts). That changes how the project gets maintained: instead of manually exporting a CSV periodically, the model connects directly to your account, navigates to the right property, and brings back metrics already structured as a cube — sessions, active users, pageviews, engagement rate, and others, broken down by whichever dimensions you prefer (date, page, source, country, device).

I set the refresh to run daily. In practice, that means the model shows up every day with the latest data ready for analysis — no manual export, no pasting into spreadsheets, no losing history because someone forgot.

How the model was structured

I followed a star schema approach, but split the facts by topic instead of using one giant table. Each analysis angle has its own fact table, fed by the same source, with the dimensions relevant to that context:

• fact_traffic: overview by date — sessions, active users, new users, average session duration, and engagement rate.
• fact_sources: sessions and engagement grouped by session source/medium (sessionSource).
• fact_pages: pageviews, engagement, and average duration per page (pagePath and pageTitle).
• fact_location: sessions and pageviews by country and city.
• fact_devices: sessions and users by device category and browser.

All of them connect to the same dim_calendar, generated in Power Query from the actual date range of the data.

It's worth remembering that the Google Analytics integration with Power BI has limitations from the Google Analytics Data API itself, allowing up to 9 dimensions and 10 metrics per request. That restriction doesn't come from Power BI, but from the API the connector uses.

Categorizing the raw data

Raw analytics data is messy. sessionSource brings values like lnkd.in, (direct), or google, and pagePath brings full URLs like /blog/tmhue/ or /en/dashboard-portfolio/. Without treatment, any bar chart turns into a long, hard-to-read list.

I created two calculated columns to fix that:

• _Source: groups the session source into readable categories — google, linkedin, direct, facebook, teams, local access (development environment), or "unidentified" — using SWITCH combined with CONTAINSSTRING.
• _PageCategory: classifies each URL into Home, Blog, Portfolio, About, Services, FAQ, Error, or Other, based on the path pattern. This turns dozens of individual URLs into a handful of categories that actually answer "what kind of content is performing best?".

Without these two columns, the dashboard would be technically correct but useless for quick reading — which is the whole point of any well-built panel.

Quick glossary

Before moving on, it's worth unlocking the vocabulary. Most of the confusion with Google Analytics isn't about where to click, it's about not knowing what each metric actually counts. Three terms show up constantly in this dashboard:

• Sessions: a period of interaction between a user and the site. If someone comes in, browses a few pages, and leaves, that's a single session — even across five different pages. If that same person comes back after 30 minutes of inactivity, GA4 already counts it as a new session.
• Pageviews: every time a page loads or reloads, it counts as a pageview, regardless of the session. That's why the pageview count is almost always higher than the session count: a session might have just one pageview (someone who comes in and leaves) or several (someone browsing the whole blog).
• Engagement rate: the percentage of sessions GA4 considers "engaged" — meaning sessions that lasted more than 10 seconds, had a conversion event, or had more than one pageview. It's the direct opposite of the old bounce rate from Universal Analytics: instead of measuring who left quickly, it measures who actually stayed.

What the dashboard shows in practice

Here's a list of views you'll find in this dashboard:

• KPI cards: sessions, pageviews, engagement rate, and average session duration — a quick read on "how is the site doing" for the selected period.
• Monthly trend: a line chart with sessions over time, to see whether traffic is rising, falling, or flat.
• Devices: a donut chart with the share of sessions by device category (desktop, mobile, tablet).
• Traffic sources: a bar chart with sessions and engagement rate by categorized source — showing not just where visits come from, but whether they actually engage.
• Page categories: pageviews grouped by Home, Blog, Portfolio, About, Services, FAQ — the view of which area of the site gets the most attention.
• Location: a table and chart by country and continent, with sessions and pageviews.
• Page table: a ranking of pages with the most pageviews, crossed with engagement rate and average session duration — the most direct cut for knowing which content actually holds visitors.
• Period and segmentation filters: relative-date slicers and dropdowns to slice the analysis without leaving the page.

This is just the starting point

Worth making clear: the indicators built here are the beginning, not the ceiling. There's a lot more room to go beyond what's published today — cross traffic source with page category to understand which channel brings the most qualified visitor, build a month-over-month goal tracker, add a conversion funnel down to the "contact me" click, or even bring in data from other sources (like a CRM) to cross traffic with business outcomes. I started with what I use day to day; the model is already structured to grow as the need shows up.

How this becomes a decision, not just a pretty chart

A few real examples of using this panel day to day:

• A specific post drives a lot of traffic but barely engages: the page table crosses pageviews with engagement, so it's easy to spot when a title attracts clicks but the content doesn't hold attention.
• A source started bringing in more visits: the sources chart shows the shift, and the engagement rate next to it helps judge whether it's qualified traffic or just volume.
• Comparing before and after a site change: since the model is connected to the real property, it's possible to compare different periods — before and after publishing a post, changing a CTA, or launching a new page — without exporting anything new.

A vertical layout: breaking from the usual pattern

Most of the dashboards I've built in Power BI follow the same widescreen 1280x720 mold, cards side by side.

Here I wanted to try the opposite: a more vertical layout, with the visuals concentrated in a center column, read almost like a top-to-bottom scroll instead of several charts competing for attention at once.

I also scattered the "little monster" — the same tribute to MonsterInsights mentioned earlier — around the dashboard's margins, between one indicator and another. Besides reinforcing the tool's visual identity, it's a way of making the panel feel less cold: it gives that sense of company while you're analyzing the numbers, instead of just a wall of KPIs. That care even shows up functionally in the footer, where the little monster with a magnifying glass lays out a mini glossary right on the canvas — the same doubt about sessions, engagement, and pageviews I already explained here, resolved without leaving the screen.

As a consequence of this more vertical format, the dashboard wasn't designed to fit entirely on a screen at 100% zoom. I recommend browsing with zoom between 100% and 120%, adjusting based on your monitor's resolution.

Check out the dashboard

The dashboard is published and interactive. Use the period filters to explore the traffic.

Tip: compare the "Blog" category against "Portfolio" in the page category filter and see which one has the better engagement rate — the result might not be what you expect.

Conclusion: analyzing your own product is the best training

Building this dashboard using the "real data" from my own site was different from working with a fictional dataset: every modeling decision (how to categorize a page, how to group a source, how to handle the privacy of the numbers) had to answer a genuine need, not a hypothetical exercise. That kind of real friction is what separates a portfolio dashboard from a tool someone actually uses — and I use this one.

Enjoyed this content?

Share it and keep following my posts.
Feel free to check out more articles!