Bringing Our Site Analytics In-House

Tomohiro Iida · Published June 20, 2026

Netsujo Inc. built an in-house SEO dashboard that merges Google Analytics 4 (GA4) and Google Search Console (GSC) into a single screen, to improve its own site, netsujo.jp. This article publishes what the dashboard shows, which data it cites, and how it feeds into site improvement, based directly on the implementation. GA4 (post-visit behavior) and GSC (search visibility) are normally separate consoles; checking both every week takes effort and things get missed. So we pull both data sources, place them side by side on one screen, and layer on a mechanism that automatically surfaces improvement candidates. The dashboard itself is an internal tool protected by basic authentication and is not publicly accessible; this article explains its design and value rather than showing live data.

Why we built it in-house

Site-improvement data splits across two systems: GA4 on the traffic side and GSC on the search side. GA4 tells us what visitors did after arriving; GSC tells us how they found the page in search. The two live in separate consoles with different terminology and granularity.

Going back and forth between the two screens every week let things slip through. A page ranking well in search but not getting clicked, for example, is easy to miss when looking at GSC alone, and even when noticed, it is hard to judge how urgently to fix it. Checks tended to rely on individual judgment rather than a consistent standard.

So we built a dashboard that pulls GA4 and GSC data into one screen and mechanically judges where to start. The goal is to turn a manual check into a system, and to state improvement priority as a number rather than a feeling.

What you can see: six views

The dashboard is organized into six views, ordered to follow how we actually check the site: from the overall picture down to individual pages, and finally to a list of improvement candidates.

01. Overview

A one-glance read of site health: primary KPIs (sessions, conversions, CVR) shown large, supporting KPIs (users, new users, pageviews, engagement rate, average engagement time), a daily session trend line, and a bar chart of traffic channel breakdown.

02. Traffic channels

Sessions, users, conversions, and CVR by channel (organic search, direct, referral, social, and others), with each channel's share of total conversions shown alongside it.

03. Pages

GSC impressions, clicks, CTR, and average position matched against GA4 sessions and conversions for the same page, with period-over-period change, a drill-down into the queries driving traffic to each page, and CSV export.

04. Search queries

A ranked list of search queries by impressions, clicks, CTR, and average position, with period-over-period comparison, a query filter, and CSV export.

05. Diagnosis

Automatically compares expected CTR against actual CTR to surface pages losing clicks, classifies them into Critical, Warning, or Info, and sorts them by estimated additional monthly clicks, with a status flag for items already addressed.

06. About the data

States the connected GA4 property ID and GSC site URL explicitly, along with notes on the 24-to-48-hour data lag and measurement scope.

The site selector covers netsujo.jp and miyakodeit.com, the community site for our "Miyakode IT" community, on the same dashboard. Users can pick a 7-day, 28-day, or 90-day window, each automatically compared against the equal-length prior period.

Which data we cite

Every actual figure the dashboard displays comes from official Google data. There are exactly two sources, and no figure is invented. The opportunity-loss and estimated-additional-click figures used in the Diagnosis view, described below, are estimates our own logic derives from this official data, not raw figures from Google itself.

Authentication runs through a Google service account (JWT), calling the GA4 Data API and the Search Console API to read search and traffic data on demand. Nothing is cached in a database; every screen load fetches fresh from Google directly.

Both GA4 and GSC carry a 24-to-48-hour lag before data is finalized, so the current day's figures are provisional. This is stated explicitly in the "About the data" view, as a reminder not to over-read same-day numbers.

How it helps us improve the site

The dashboard's core is the Diagnosis view, and its purpose is raising conversion rate (CVR). Conversions come from how many search-intent visitors a page attracts and how well it turns them into action. Diagnosis handles the entry point: it mechanically surfaces pages that already rank in search results but are losing clicks they should be getting, widening the pool of visitors who could convert. The mechanism itself is simple: compare expected CTR by rank band against actual CTR, and quantify the gap as opportunity loss.

Who runs the diagnosis

Not a person — the dashboard's rule-based diagnosis logic runs it automatically, evaluating every tracked top page against the same standard every time, the way a standing analyst would.

How it diagnoses

It pulls each top page's rank, impressions, and actual CTR from Search Console, checks them against the expected CTR for that rank band, flags pages with meaningful room for improvement, classifies them by severity into Critical, Warning, or Info, and sorts by estimated additional clicks.

Why it matters

Reviewing many pages every week against a single consistent standard is hard for a person to sustain without some subjectivity or oversight creeping in. Handing this to the system cuts both, and surfaces, from current data, which page to fix next to widen the pool of potential conversions.

A page ranking 3rd, for example, would normally expect around 10% CTR. If a page has meaningful impressions but its actual CTR is well below that expectation, the system can mechanically flag it as underperforming.

Critical — losing clicks

A page on page one of search results (rank 1-10) with 50+ impressions, where actual CTR does not even reach half the rank-appropriate expected CTR. Already visible, so a title and description rewrite aligned to search intent is likely to lift clicks — the top-priority candidate.

Warning — page-one push candidate

A page buried on page two (rank 11-20) with 150+ impressions. Adding internal links or strengthening the body content could push it to page one, with meaningful upside in traffic.

Info — for reference

A page with 100+ impressions but under 1% CTR, not yet converting to clicks. Not urgent, but worth keeping in view as a reference for future work.

Flagged candidates are sorted by estimated additional monthly clicks, so the pages with the largest traffic upside get worked on first. Once a title or description fix ships, the page is marked "addressed" in a ledger, with the date (and pull-request number, where one exists) shown on the diagnosis result. Because Google's re-crawl cycle and the CTR moving average mean it takes 2 to 4 weeks for a fix to show up in the numbers, keeping "addressed" separate from "not yet addressed" makes progress visible during that lag.

• Step 1, diagnosis (system): automatically surfaces pages losing clicks and the opportunity to recover them
• Step 2, improvement (human): rewrites the title, body, and call to action to match search intent
• Step 3, outcome (CVR uplift): the quality and volume of visitors rises, and more of them take action

Tech stack

• Front end — built on the same Next.js codebase as netsujo.jp itself, calling internal APIs on every tab switch or period change to render current data.
• API layer — split into five API groups (overview, pages, search queries, diagnosis, per-page query drill-down), each with caching disabled so it always returns current Google data.
• Data layer — service-account authentication calls the GA4 Data API and the Search Console API, then joins the two into page-level records.
• Access control — protected by basic authentication and not registered with any search engine, since it is an internal-only tool.

Stack: Next.js, TypeScript, GA4 Data API, Search Console API, Vercel.

Caveats and limits

The expected-CTR figures are general trends by rank band; actual levels vary by industry and query. Diagnosis is meant only to give a rough read on improvement candidates, not to guarantee a rank or click increase after a fix. Because both GA4 and GSC carry a 24-to-48-hour reporting lag, we operate on the assumption that any single day's number should not be over-interpreted, and read period-over-period trends instead.

Frequently asked questions

What is the difference between GA4 and Google Search Console?

GA4 measures what happens after someone reaches the site (sessions, time on page, conversions); Search Console measures how the site appears in search results before that (impressions, clicks, average position, search queries). GA4 is post-visit data, Search Console is pre-visit data, and combining them shows the full path from search to on-site action.

Why merge GA4 and Search Console at all?

A page that ranks well but is not getting clicked is something Search Console alone can surface, but whether that page converts once visitors land is only visible in GA4. Putting search (pre-visit) and behavior (post-visit) on one screen removes the effort, and the missed checks, of switching between two separate consoles, and makes it easier to prioritize fixes.

Can anyone view this dashboard?

No. It is an internal tool protected by basic authentication and is not registered with any search engine. This article does not publish live data — only the dashboard's design and value.

Where do the displayed figures come from?

Official data from GA4 (property ID 382871067) and Google Search Console (https://netsujo.jp/), retrieved via API with Google service-account authentication; no figure is invented. The opportunity-loss and estimated-additional-click figures used in diagnosis, however, are estimates our own logic derives from that official data.

What is expected CTR?

The rough click-through rate typically seen at a given search rank, for example about 28% at rank 1, 10% at rank 3, 5.5% at rank 5, and 2.5% at rank 10. A page whose actual CTR falls well short of the expectation for its rank can be mechanically flagged as losing clicks it should be getting.

Who runs the diagnosis, and how?

Not a person — the dashboard's rule-based diagnosis logic runs it automatically. It checks each top page's rank, impressions, and actual CTR from Search Console against the expected CTR for that rank band, surfaces pages with meaningful room for improvement, and auto-classifies them into Critical, Warning, or Info. Because the same standard applies every time, personal judgment and oversight play a smaller role.

What is the point of the diagnosis?

Ultimately, raising conversion rate (CVR). Conversions depend on how many search-intent visitors a page attracts and how well it turns them into action. Diagnosis is the entry point: it finds pages already appearing in search results but losing clicks, widening the pool of potential conversions. From there, a person sharpens the page copy and call to action to actually raise CVR.

How is the priority order for fixing pages decided?

By quantifying the gap between expected and actual CTR as opportunity loss, then sorting by estimated additional monthly clicks. This lets us start with the pages carrying the largest traffic impact (it does not factor in effort or the value of a conversion, so the final call on what to work on still rests with a person).

Why not just use an existing tool like Looker Studio?

An existing tool can visualize the same data. The advantage of building this in-house is designing the whole flow around action: automatically computing opportunity loss from the CTR gap, logging addressed fixes, and tracking progress, tailored to how we actually operate.

When does a fix show up in the numbers?

Because of Google's re-crawl cycle and the CTR moving average, it typically takes 2 to 4 weeks after a title or description fix ships in production before the diagnosis metrics reflect it. During that window, the fix is logged as "addressed" and kept visually distinct from anything not yet addressed.

Is the data real-time?

It is fetched on demand from Google every time the screen is opened, but both GA4 and Search Console carry a 24-to-48-hour lag before data is finalized, so same-day figures are provisional. We operate on the assumption that decisions should be based on period-over-period trends rather than any single day's number.

Summary

Looking at GA4 (traffic) and GSC (search) separately tends to stop at "checking the numbers." Merging them into one screen, and quantifying opportunity loss from the gap against expected CTR, is what turns the exercise into an actual next action.

This dashboard is a working tool Netsujo built in-house to keep improving its own site. Every figure it displays is sourced only from official GA4 and Google Search Console data, and its diagnosis logic runs on the clear, explicit standard of expected CTR by rank band.

Building the tools we use ourselves, by ourselves, is something we think feeds directly into the speed at which our site improves, and into the quality of the development and analytics work we deliver for clients.