Reports: The Consolidated View Across Every SGEN Data Source

How SGEN brings every analytics source into one structured reporting surface.

Reports is the SGEN surface where data from multiple sources comes together as a single reading view.

Live Analytics shows you what is happening right now. Site Explorer lets you crawl one source at a time. Reports is the layer above both — the place where the picture from every connected source is organized for review, communication, and stakeholder reading.

This page is the structural reference for the Reports surface. Read it when you need to understand what Reports is, what it covers, where it sits in relation to the source-specific surfaces, and how it differs from Custom Reports.

Read it end-to-end the first time you encounter the surface. Knowing how the sections relate before you open the surface on a real period makes the first read faster and the discussion items more meaningful. After the first read, the surface becomes a habit — the shape is consistent across periods, and the reading walk becomes a repeatable thirty-minute pattern.

What is this for?

Reports is the consolidated reporting body inside SGEN. It is where live dashboards and source-specific exploration get organized into something that reads as a report — structured, in-platform, oriented toward review and communication.

Reach for Reports when you need a consolidated view of how the site performed across every connected source over a stated period, a stakeholder-facing reading view rather than a raw operational dashboard, cross-source context — search performance alongside GA4 alongside ads alongside reviews — rather than seven separate browser tabs, or a formal in-platform record of a reporting period for internal or client-facing review.

Reports is also the right surface when the same shape of read needs to repeat — monthly, weekly, quarterly — and the reading should feel familiar each time. The structural consistency is itself part of the value: a stakeholder who learns the shape of the surface on one period reads every subsequent period faster, because the shape does not change between reads.

Reports is structured. It is not a live dashboard, and it is not a generated download. It is the platform's reporting layer.

Why a separate reporting surface

Live Analytics is good for current-state reading and Site Explorer is good for source-by-source exploration, but neither is shaped for the question "how did we do over this period?" That question wants a structured, multi-source, period-bounded view, and it wants that view to read the same way every time so consumption is fast. Reports answers that question. The surface is shaped around reading rather than exploration — fewer interactive controls, more structured sections, consistent shape across periods and sites.

The result: the surface that gets opened for a monthly review reads the same way as the surface that gets opened for a quarterly review or a campaign retrospective. The shape stays constant; the period and the discussion items change.

Good use cases

• A monthly client review where the agency walks through every relevant source in one structured pass.
• An internal performance read where the team needs the full picture in one place rather than seven dashboards.
• A leadership update where the question is "how did the site do" and the answer needs to cross sources.
• A campaign retrospective that needs ads, search, attribution, and reviews lined up against the same date range.
• A stakeholder briefing where the reading view matters as much as the data.
• A weekly portfolio scan across many sites, where the same shape of read produces a fast triage view per site.
• An incident retrospective where multiple sources need to be read against the same window to locate a cause.
• A handoff between a site owner and a new operator, where the period read provides shared context without long verbal briefings.

When the structured shape pays off most

The structured shape pays off most when the reading is recurring or comparative. Recurring reads — monthly cadence, weekly scan — benefit from a surface that reads the same way every time, because the consumption pattern becomes habit. Comparative reads — this month against last month, this campaign against the prior — benefit from a surface that holds shape across periods, because the reader can focus on differences rather than re-orient to a new layout each time. One-off reads work too, but the structural value is highest where the surface gets opened often.

What NOT to use this for

• Real-time monitoring — open Live Analytics for current minute-by-minute behavior.
• Single-source deep exploration — open the relevant integration page directly.
• Generated downloadable artifacts — that surface is Custom Reports, a separate body covered elsewhere.
• Per-event row-level audit — open Event Logs under SG-Admin Analytics for raw row-by-row data.
• Ad-hoc what-if queries that mix custom segments — the reading view is structured and pre-shaped, not freeform.
• Diagnostic deep-dives on a single visitor session — those live on the analytics surface or in the source's native interface.
• Anything that requires editing the underlying data — Reports is a reader, not a writer.

How this connects to other features

• SG-Admin Analytics — the per-site analytics surface. Reports rolls reading-view structure above the per-site module's underlying data.
• SG-Dashboard Analytics — the account-tier analytics rollup. Reports organizes that rollup into structured reading-view sections.
• Google Analytics 4 — the GA4 integration that supplies traffic + engagement data into the Reports view.
• Google Search Console — the GSC integration that supplies search performance into the Reports view.
• Google Business Profile — the GBP integration that supplies local-business signals into the Reports view.

Reading the connection layer beneath Reports

Reports sits above a layer of source integrations. Each section of Reports reads from one or more of those integrations. Understanding which integration feeds which section is the key to interpreting an unexpected reading — a quiet section is almost always upstream, in the integration or the source, rather than in Reports itself. The connection layer is also where credential rotations, permission changes, and source-side configuration changes show up. If a section of Reports starts behaving differently after a change at the source, the connection layer is the first place to look.

Before you start

Reports is a reading surface. To see useful data in it, the underlying sources need to be connected and ingesting.

Confirm GA4 is connected and recording site events. Confirm Search Console is connected for the property you are reading on. Confirm Google Business Profile is connected if local-business signals matter for this site. Confirm Ads is connected if the period being reviewed had paid campaigns running. Confirm Reviews is connected if review velocity is part of the reading view.

Reports does not generate data. It organizes data that is already flowing.

Plan for ingestion delays. Most sources report current-period data within hours, but some have a longer lag — search-console clicks-and-impressions data, for example, typically lags by two to three days before stabilizing. When reading a period that ended very recently, the surface may show preliminary numbers that shift slightly as ingestion completes. For a clean read, wait until the lag windows for every contributing source have passed, then read once and trust the numbers.

Confirming the source connections one by one

For a first-time read on a new site, walk every source connection before opening Reports. Each connection has its own status indicator on the respective integration page. A green connection state means the integration is reachable and ingesting. A warning or error state means the integration needs attention before Reports can present anything meaningful from that source. The walk takes a few minutes the first time, and it prevents the common confusion of reading an empty Reports section and not knowing whether the section is empty because of no activity or because the connection is broken.

For sites that have been on SGEN for a while, the connection walk is a once-per-period sanity check rather than a recurring chore. Connections rarely break on their own — most breakage happens after a credential rotation, a permission change at the source side, or a domain change.

Where to find it

Open SG-Admin for the site you are reading. The Reports surface lives inside the analytics and reporting area of SG-Admin navigation.

A typical Reports view groups information into structured sections by source: a traffic section drawn from GA4, a search section drawn from Search Console, a local section drawn from Google Business Profile, an ads section drawn from Ads, an attribution section that crosses sources, and a reviews section.

The surface is per-site. For agencies and multi-site operators, the same Reports surface exists for every site in the portfolio, with each opening to its own reading view. The shape is identical across sites — what differs is which sources are connected for each site and what the period numbers look like. The consistency across sites is what makes a weekly portfolio scan feasible: the operator reads the same shape thirty times rather than thirty different shapes once each.

For sites with only some sources connected, the Reports view shows the connected sections and leaves disconnected sections as compact placeholder blocks rather than hiding them. The placeholder behavior is intentional — it makes the absence of a source visible, which is information in itself. A site that should have a connected Ads source and does not is more useful to know than to silently miss.

Each section is a reading block — sized for someone reviewing the period, not for someone debugging a single visit.

Section order and what it implies

The section order is not arbitrary. Traffic sits first because it establishes the volume context every other section reads against. Search and local follow because they answer where intent-driven visitors came from, which the traffic numbers cannot answer on their own. Ads sits after the organic story because paid is layered on top of organic, not separate from it. Attribution follows ads because attribution is the question of how the paid and organic mixes contributed to outcomes. Reviews closes the read because reviews are the lagging signal — what people said after the period rather than what they did during it.

Reading the sections in order is the fastest way to build a coherent period read. Reading them out of order is fine if a specific question pulls you to a specific section, but the in-order walk is what makes the cross-source story hold together.

How the period selector affects every section

The period selector is the single most consequential control on the surface. It governs every section at once. A period change shifts every reading block to the new window simultaneously, which is what makes cross-source comparison work — every number in the view covers the same time. Changing the period is a fresh read, not a tweak; the old reading and the new reading are two different reads of two different periods, not two views of the same data.

Save reading periods as comparable units. A calendar month is a comparable unit; an arbitrary 27-day window is harder to compare to anything. The period selector supports both, but the cleanest reads come from comparable units.

Steps

The most common path through Reports is the structured monthly read: pick the period, walk every section in order, note the headline reads, and surface the items worth discussion.

How the monthly read scales to other cadences

The monthly cadence is the most common shape, but the same path works for weekly scans, quarterly reads, and campaign-window retrospectives. The shape stays constant — pick period, walk sections, note items, summarize. The cadence is the variable. A weekly scan is a fast pass on each section, looking for material changes. A quarterly read is a deep pass on each section, looking for trend direction. A campaign retrospective is a focused pass tied to the campaign window, looking for cause-and-effect across sources.

Pick the cadence that fits the question. The Reports surface supports all of them with the same shape.

1. Pick the reading period

Open the Reports surface for the site. Set the reading period — most teams read on a monthly cadence, but quarterly and campaign-window cadences are equally supported.

The same period applies across every section, so the GA4 read, the Search Console read, the Ads read, and the Reviews read all cover the same window. Cross-source comparisons only work when the windows line up.

The period selector is a single change that affects every section. Set it once, then walk every section against that window. Avoid changing the period mid-walk — a partial walk against one period and a partial walk against another produces a read that does not hold together as a cross-source story.

2. Walk the traffic section

The traffic section, drawn from GA4, is typically the first read. It answers the high-level question: did the site get more, fewer, or the same number of visitors compared to the prior period? Which pages drove that change? Which channels brought visitors in?

This is the orientation section. Every following section reads against the traffic context this one establishes.

The three traffic reads worth capturing as headlines: the period-over-period direction (up, flat, down, and by how much), the top driving pages (which pages produced the most sessions in the period), and the top driving channels (which acquisition sources brought visitors in). With those three reads in hand, every following section has the context it needs.

3. Walk the search and local sections

The search section, drawn from Search Console, shows which queries the site appeared for and which queries drove clicks. The local section, drawn from Google Business Profile, shows local-business visibility for sites where local search matters.

Read these together when the site has a meaningful local footprint — they answer the question of where intent-driven visitors are coming from.

For sites without a local footprint — software businesses, national retailers without storefronts, online-only services — the local section reads as a small block or empty, and the search section carries most of the intent-discovery story alone. For sites with a strong local footprint — service businesses with locations, retail with foot traffic, healthcare practices — the two sections together are the read that matters most, often more than the traffic section itself.

4. Walk the ads, attribution, and reviews sections

The ads section covers any paid activity in the period. Attribution crosses sources to show which channels contributed to outcomes. Reviews covers external review velocity for the period.

These are the sections that turn a traffic read into a performance read — they answer not how many people came, but what they did, what brought them, and what they said afterward.

The ads read pairs spend against attributed outcomes. A campaign that spent heavily but produced no attributed outcomes is a signal worth understanding. A campaign that produced strong attributed outcomes for a low spend is a candidate to scale. The ads section reads as a winners-and-losers table that informs the next period's allocation decisions.

The attribution read crosses the channel mix to show which channels contributed to outcomes. A period where organic search did most of the heavy lifting reads differently from a period where paid social carried the load, even if the headline outcome number is the same. Attribution gives the cross-channel story the headline cannot.

The reviews read shows external sentiment for the period. Spikes in review velocity, sentiment shifts, and any review incidents (unresolved negative reviews, review-spam attacks, platform-side disputes) all show up here. For service businesses where reviews influence buying decisions, the reviews read is often the section that drives the most concrete follow-up actions.

5. Note the discussion items as you walk

The reading walk is also a notation walk. As each section reads, capture two to five items worth a follow-up conversation — a spike worth understanding, a drop worth investigating, a query worth doubling down on, a campaign worth scaling or pausing, a review worth a direct response. The discussion list is the bridge from data to decisions. A reading walk that produces no discussion items either covers a quiet period or under-reads the data.

The discussion list lives outside Reports itself — in a brief document, a team channel post, or a meeting agenda. The Reports surface holds the data; the discussion list holds the conclusions drawn from the data.

6. Close the read with a written summary

A short written summary — a paragraph or two — captures what the read produced. The summary names the period, the headline direction in each section, and the discussion items. It does not duplicate the Reports surface, which can be reopened on demand. It produces a self-contained artifact that someone who could not attend the read can absorb in two minutes, and that future-you can read to remember what the period looked like without having to re-derive it.

What success looks like

A successful Reports read produces three things: a clear answer for the period (did the site perform better, worse, or the same as the prior period — and where), a short list of items worth discussion (a spike, a drop, a query worth following up, a campaign worth scaling), and a reading record someone else can open later and understand without you in the room.

A fourth signal worth naming explicitly: the reading view holds together across sources. Numbers from GA4 should sit alongside numbers from Search Console without the operator having to mentally normalize date ranges, attribution windows, or filter selections. When the reading view holds together, the cross-source story is the value Reports adds over reading each source on its own.

How the reading view reads to a third party

A useful test for a finished Reports read: hand it to someone who was not in the room when you wrote it. They should be able to read the period, understand what happened, and identify which items deserve a follow-up — without needing you to narrate it. If the reading view requires narration, the read is not finished. The discussion list at the end is the bridge from data to decisions, and naming the source against each item is what lets the reader trust the discussion list without re-checking every number.

What to do if it does not work

Reports is a reading surface that depends on its sources. Most issues are upstream of the surface itself.

Distinguishing source issues from surface issues

A useful first triage: open the source's native interface for the same period. If the source's native interface shows the data Reports is missing, the issue is upstream of Reports — usually the integration or an ingestion delay. If the source's native interface also shows the data missing, the issue is at the source itself, and Reports is correctly reflecting an empty source. Reports is a reader, not a data store; almost every issue resolves to either an integration question or a source-side question, and reading the source directly is the fastest way to decide which.

Examples

Example 1: A monthly agency client review

An agency operator runs a monthly review for a multi-site client. On the first of the month, the operator opens Reports for each site, sets the period to the prior calendar month, and walks every section in order. The output is a structured monthly brief: traffic vs prior month, search performance trend, local visibility direction, paid campaign attribution, and review velocity. The same surface produces the same shape of read for every site in the portfolio, every month — the client sees consistency across sites and across months.

Example 2: A campaign retrospective

A marketing team ran a six-week campaign. The team needs to know whether the campaign moved the numbers, where the lift came from, and whether the paid spend produced attributable outcomes. The team opens Reports, sets the period to the campaign window, and reads every section against that window. The cross-source picture — traffic lift, query mix shift, ads attribution, review impact — comes together in one reading view rather than seven exports. The retrospective deck writes itself off the Reports read.

Example 3: A leadership briefing

A leadership stakeholder asks a one-line question: how did the site do last quarter? The site owner opens Reports, sets the period to the prior quarter, and produces a one-page read covering every connected source. The briefing answers the question with the data that supports it, without the leadership stakeholder needing to log into seven separate tools. The Reports surface is the answer — not a slide deck assembled by hand.

Example 4: A weekly portfolio scan across many sites

A portfolio operator manages thirty sites across multiple clients. Each Monday, the operator opens Reports for every site in turn, sets the period to the prior week, and runs the same fast scan: traffic direction, search direction, any ads anomaly, any review incident. Sites where every section reads steady get a one-line note; sites where a section shows a notable change get queued for a longer read later in the day. Reports compresses a portfolio-wide scan into a repeatable thirty-minute pass — every site reviewed every week, with the longer reads reserved for the sites that need them.

Example 5: An incident retrospective after a traffic drop

A site sees an unexplained traffic drop over a long weekend. On Tuesday morning, the operator opens Reports for the affected site and sets the period to the four-day window covering the drop. The traffic section confirms the magnitude. The search section shows query mix held steady, ruling out a search-side cause. The local section shows GBP visibility unchanged. The ads section shows a paused campaign that was active in the prior period — the cause. The cross-source read locates the cause in one pass, without three separate dashboard sessions and a hand-built timeline. The retrospective writes itself off the Reports read, with the source named against each finding.

Working a multi-period comparison

Reports also reads well when the question is about change over time rather than a single period. The same site, read on the same set of sources, with the period selector moved across consecutive months, produces a longitudinal view of how the site is trending. A site owner reading three consecutive months of Reports can see traffic direction, search-trend direction, and review-velocity direction without leaving the surface. The reading view holds its shape across periods, which is what makes the multi-period scan a fast operation rather than a fresh build per month.

Pairing Reports with Live Analytics for a complete picture

Reports answers the question "what happened over this period?" Live Analytics answers the question "what is happening right now?" The two surfaces are complementary. A site operator beginning a workday often opens Live Analytics first to confirm current behavior is normal, then opens Reports later to read the prior period. The two surfaces share the same underlying integrations, so a site connected for Reports is also connected for Live Analytics, and the read in either surface trusts the same data. Use Live Analytics for minute-to-minute current state; use Reports for structured period reads.

Working with Custom Reports as a complement

Reports is the in-platform reading surface. Custom Reports is the separate body covering generated downloadable artifacts — reports that get exported, shared as files, or scheduled for distribution outside the platform. The two surfaces share underlying data but serve different purposes.

Reach for Reports when the reading happens inside the platform, when the audience is internal or has platform access, or when the value is the live cross-source reading view. Reach for Custom Reports when the output needs to leave the platform — a client deliverable as a file, a scheduled distribution to a stakeholder who does not log into SGEN, or an archive copy of a reading period that lives outside the platform's own history.

Both surfaces can cover the same period and the same sources. The choice is about where the reading happens and who needs to read it.

For an audience that logs into SGEN, Reports is the surface — the reading view is structured for in-platform consumption and updates when the source data updates. For an audience that does not log into SGEN, Custom Reports produces an artifact that can be shared as a file. For an audience that mixes both — some who log in, some who do not — the team often uses both surfaces, with Reports as the source-of-truth reading view and Custom Reports as the distributable artifact for the wider audience.

The two surfaces are designed to coexist. Use the one whose shape fits the reading need.

Reading Reports as the start of a workflow

Reports is often the start of a workflow rather than the end of one. A Reports read produces a discussion list. The discussion list becomes the agenda for a review meeting. The meeting produces follow-up actions. The follow-up actions become work tracked in whatever the team uses for work tracking — campaign briefs, content backlogs, support tickets, ad-spend adjustments. Reading Reports this way frames the surface as the input to action rather than as a destination in itself.

The structural consistency of the surface makes this framing repeatable. Every month the same read produces the same shape of agenda, the same shape of action items, the same shape of follow-up. The recurring loop is what makes the surface useful over time.

Pairing Reports with the team rhythm

Teams that pair Reports reads with a fixed rhythm — the first Friday of each month, the day after each campaign closes, the first day after each quarter end — get more value than teams that read on an ad-hoc cadence. The fixed rhythm makes the read habitual, builds shared expectation across the team, and produces a longitudinal series of reads that hold their shape over time. Ad-hoc reading still works, but the recurring read is the pattern most teams settle into.

Related reading

One Reports surface, many shapes of reading

The same Reports surface supports many shapes of reading. The monthly review is the most common, but the surface is shaped to support whatever cadence and audience the team needs. A weekly internal scan reads it fast and looks for material change. A monthly client review walks every section in order and produces a structured brief. A quarterly leadership read summarizes the full quarter against the prior quarter. A campaign retrospective reads the campaign window against the prior comparable window. An incident retrospective reads the incident window across every source to locate a cause.

The variety of reading shapes is what makes the surface central rather than peripheral. One reading surface, many reads.

Knowing when to step outside Reports

For most reading needs, the surface is sufficient on its own. A few questions step outside it. Row-level detail belongs in event logs or the source's native interface, not in Reports. Real-time monitoring belongs in Live Analytics. Ad-hoc what-if exploration belongs in the source's native interface where freeform segmentation is supported. Generated downloadable artifacts belong in Custom Reports. Knowing when to step outside Reports is part of using it well — the surface is shaped for structured period reading, and other surfaces handle the questions Reports is not shaped for.

Reading Reports the first time vs the hundredth time

The first read of Reports on a new site is exploratory — the operator learns which sources are connected, what the period numbers look like, how the sections compose into a cross-source story. The hundredth read on the same site is fast — the operator knows the shape, knows the cadence, and reads for change rather than for orientation. Both reads use the same surface; what differs is the operator's relationship to the surface.

Build toward the hundredth-read pattern by reading on a fixed cadence and capturing discussion items each time. The longitudinal series of reads is what turns Reports from a periodic tool into a continuous reading practice.

The reading view as a shared artifact across the team

A Reports read is not always a solo activity. Teams that share the reading view — opening it together on a screen during a review meeting, walking the sections one at a time, capturing discussion items as a group — get more value than teams where one operator reads and reports back. Shared reading produces shared context, surfaces questions the solo reader would not have asked, and turns the surface into a meeting artifact in its own right.

• SG-Admin Analytics
• SG-Admin Overview
• SG-Dashboard Analytics
• Google Analytics 4 integration
• Google Search Console integration
• Google Business Profile integration

Scope

This Reference covers the platform-level shape of reports: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Fields