Analytics

What this covers
What is this for?
Good use cases
When NOT to use this
How this connects to other features
Before you start
Where to go
Steps — Read Event Logs
Steps — Read Reports
What success looks like
What to do if it does not work
Field	Value
---	---
Audience	sgen-admins
Updated	2026-05-14

How to read your site's traffic with the built-in Analytics surface

Most analytics stacks make you choose: install a third-party tracker that ad blockers strip out, or stay blind. SGEN ships a server-side Analytics surface that records what visitors requested — every page view, every 404, every form submit, every product touch — without injecting a single client-side script. Ad blockers do not interfere. The data is yours, on your site, in your admin.

Analytics in SGEN is two screens that share one underlying event table. Event Logs is the raw row-by-row audit trail. Reports is the visual aggregate — doughnut and line charts of your top paths over a date range. You filter on either screen by event type, path, and time window, and the URL captures the filter so any view is bookmarkable.

This page is the operator's map of both screens. Use it to decide which screen answers which question, what the numbers mean, and where Analytics stops and a third-party tool starts.

What is this for?

Analytics is the SGEN admin's window onto what visitors did on your public site. Every front-end GET that hits a page, a product, a 404, or a form-submission endpoint flows through a server-side tracker that writes one row to the analytics table. Event Logs renders those rows; Reports aggregates them.

Reach for Analytics when you need to answer questions like:

• Which pages drove traffic last week?
• Did launch day spike the way we hoped?
• Which broken inbound links are visitors hitting?
• Where did the spike in form submissions come from?
• Which products are getting viewed but not added to cart?

You will not reach for Analytics for time-on-page, scroll depth, cross-device behavior, or ad-attribution math. Native tracking is intentionally minimal — fast, private, server-side. Wire up GA4 or Meta Pixel through Integrations when the marketing team needs that depth.

The screenshot above shows the Event Logs landing page — six columns (Event / Path / Referrer / Date / User / Session), a filter toolbar at the top, and 20 rows per page of pagination. Every row is one front-end request the tracker recorded.

Good use cases

Example 1: Monday morning health check. Open Event Logs first thing on Monday. Scan the event-type tabs across the top — Page View / 404 Not Found / Form Submit / Product View / Phone Tap. A typical week for a small ecommerce site (your business, ~20 orders / week) reads roughly Page View (271) / Form Submit (22) / 404 Not Found (18) / Product View (9) / Phone Tap (4). The 18 broken-link hits are worth a five-minute audit — click the 404 Not Found tab to narrow the table.

Example 2: Find the broken links visitors are hitting. A 404 in Event Logs is a real visitor who tried a URL that does not exist. Set Event Type to 404 Not Found, sort by most-recent, and look for paths that repeat. Each repeating path is a candidate for a redirect rule under Redirects. The cycle: Analytics surfaces the broken path, Redirects fixes it, the next visitor lands somewhere useful.

Example 3: Trace a spike in form submissions. Forms shows 22 submissions this week — more than usual. Filter Event Logs to Form Submit and scan the Referrer column. If many rows show https://instagram.com/, the social post you ran on Friday drove the spike. Cross-reference with Forms → Submissions to see what the visitors typed.

Example 4: Confirm a campaign landed. your business sent a newsletter linking to /products/canvas-tote-bag on Apr 20. To confirm the traffic landed, type canvas-tote-bag into the Search path box. The table narrows to rows where the path contains that string. Hits dated Apr 20 and 21 confirm the newsletter pulled traffic. Empty referrers are normal for email clients, which strip referrer headers.

Example 5: See last week's top five pages at a glance. Switch to Reports. Pick Top 5 from the Top Paths selector and move the date-range picker to the last 7 days. The doughnut shrinks to 5 slices; the line chart shows 5 series; the Total Events tile updates. The doughnut centre shows total events across the chosen top-N for the period.

Example 6: Did launch day spike traffic? Pick the date range that brackets your launch (a day or two before, to a day or two after). The line chart fills in one series per top page over the window, with the y-axis showing events per day. A real launch spike is visible: one or more series jumps several times higher on the launch date than on neighbouring days. The line chart guarantees a data point for every day in the range — a single-day spike stands out instead of getting compressed.

Example 7: Make a 404 heat map. In Reports, set Event Type to 404 Not Found. The doughnut narrows to only the paths that returned a 404 across the date range, ordered by frequency. The line chart shows which 404s are climbing over time — a rising 404 series is a broken link that is getting worse, not better. Pair the result with Redirects to set up a rule for the hottest paths.

Example 8: Find products viewed but not added to cart. Set Event Type to Product View in Reports. The top paths in the doughnut are your most-looked-at products. Cross-check against the corresponding Add To Cart and Purchase event counts in Event Logs filtered to the same date range. A product with high Product View counts but low Add To Cart counts is a conversion problem on the product page itself — pricing, photography, copy, or a missing variant.

When NOT to use this

• Do not use Event Logs as a replacement for GA4 or Meta Pixel. Native Analytics is server-side and intentionally minimal. It does not track time-on-page, scroll depth, conversions other than ecommerce, or cross-device behaviour. If you need that depth, wire Google Analytics through Integrations and / or paste a Meta Pixel snippet in Custom Codes. The two systems coexist — native tells you what hit your server, third-party tells you about visitor behaviour.
• Do not read short-term event counts as signal on a low-traffic site. A site with 20 visits a day will jump around wildly day-over-day on noise alone. Use weekly or monthly windows for low-traffic trends, never single-day comparisons.
• Do not treat tracking-tagged URLs as distinct pages. /pricing?utm=google and /pricing?utm=email log as separate rows because the full URLs differ — even though they are the same page. To count visits to a page, filter by the base path (pricing) with Search rather than assuming each query-string variant is a unique page.
• Do not rely on the User column for unique-visitor counts. The User column populates only when a logged-in SGEN user (an admin or registered customer) hits your site. Anonymous visitors show a dash. Session is a much-less-reliable proxy — it rotates on browser restart and does not survive across devices.
• Do not assume the line chart shows all traffic. It only shows the Top N paths for the selected date range (default 10). Pages outside your top 10 do not appear as their own series and are invisible on the chart. Switch to Event Logs for the full-resolution view.

How this connects to other features

• Redirects — when Reports surfaces a 404 that keeps climbing, open Redirects and add a rule to forward the broken URL to the right destination. Analytics tells you which 404s to fix; Redirects is where you fix them.
• Forms — Form Submit events in Event Logs show the traffic moment (which page, which referrer). To see the data the visitor typed (name, email, message), open Forms → Submissions. The two views complement each other.
• Phone Taps — when a visitor taps your phone number on mobile, a Phone Tap event appears here alongside the page path and referrer. Detailed session data lives in Phone Taps → Sessions.
• Tracking Consent — governs third-party scripts injected by Integrations and Custom Codes. Native Analytics runs server-side and is not gated by visitor consent.
• SEO — 404 rows in Event Logs are direct evidence of broken inbound links that hurt crawlability. Pair Analytics with the SEO audit to prioritise which 404s to redirect.
• Integrations and Custom Codes — for GA4, Google Tag Manager, and Meta Pixel. Native Event Logs does not replace them; it complements them.
• Notifications — admin Notifications can alert you when event counts spike. The raw events those alerts fire from are what you see in Event Logs.

Before you start

• You are signed in to SGEN as an Administrator or Site Owner. Analytics requires admin access (validate_admin_access() runs before any Analytics route renders).
• The site has had at least a few public visits since the analytics surface was added. The tracker only records front-end GETs — admin visits are filtered out, so your own browsing in /sg-admin/ does not inflate the counts.
• For ecommerce event types (Product View / Add To Cart / Checkout Started / Purchase), your site has the storefront module enabled. Non-ecommerce tenants see only Page View, 404 Not Found, Form Submit, and Phone Tap.
• A clear question in mind. Analytics is most useful when you arrive with "I want to see X" rather than "I want to look at the dashboard." The filter toolbar rewards specific questions.

Where to go

1. Open the left navigation in the SGEN admin.
2. Click Analytics. You land on /sg-admin/analytics/ with the Event Logs table showing the 20 most-recent events.
3. The Reports tab in the same area opens at /sg-admin/analytics/reports.

Steps — Read Event Logs

1. Pick an event type

The Event Type select at the top of Event Logs filters the table to one event kind. The default All Types shows everything; the other options narrow to one category.

The list of available event types depends on whether your site has the ecommerce module enabled. Non-ecommerce sites see Page View, 404 Not Found, Form Submit, and Phone Tap. Ecommerce sites see those plus Product View, Add To Cart, Checkout Started, and Purchase.

Changing the value does not auto-submit — click the search magnifier (or press Enter in the path search box) to apply.

2. Search by path

The Search path box runs a contains-match against the Path column. blog matches /blog, /blog/post-1, and /about-the-blog. Useful for narrowing to a campaign URL, a section of your site, or a single product.

The path search and the event-type filter combine. To find every Form Submit row that came from your contact page, set Event Type to Form Submit and type contact into Search path.

3. Page through the results

The table shows 20 rows per page. Page 2 lives at /sg-admin/analytics/20, page 3 at /sg-admin/analytics/40, and so on. Filters survive pagination — if you click page 2 while filtered, the filter stays applied.

Filter selections are baked into the page URL. Any filtered Event Logs view is bookmarkable and shareable with a teammate.

Steps — Read Reports

1. Pick the date range first

The default range is "last 30 days" and drifts — bookmark the default view and come back a week later, the range has moved. For a stable comparison across visits, open the date-range picker and choose an explicit window (preset shortcuts cover Last 7 days / Last 30 days / Last quarter / a custom range). Click Apply on the picker; the form submits and the URL captures dates=YYYY-MM-DD - YYYY-MM-DD.

2. Pick the event type

Same options as Event Logs. All Types sums every category into one chart, which is rarely what you want for a focused look. Filter to one event type for apples-to-apples comparison — Page View for content traffic, 404 Not Found for broken links, Product View for shop interest.

3. Pick the Top N

The Top Paths selector caps how many series the doughnut and line chart draw. Choices are Top 5, Top 10 (default), Top 50, and View all. Use Top 5 for a focused storytelling view, Top 10 for the typical dashboard, Top 50 for an in-depth audit. View all is useful only on low-traffic sites — on a busy site, View all paints dozens of overlapping series and stops being readable.

4. Read the charts

• Total Events tile — sum of events across the top-N paths for the chosen range. If Top Paths is 10 but your site has 16 distinct paths with events, the tile sums those 10 only; anything outside the top 10 is not counted.
• Top Paths tile — the count of distinct paths charted (min(top-N, total distinct paths)).
• Doughnut — each slice is one path. Tooltip shows path: count (percent). The centre label is total events. Palette cycles through 8 colours — with more than 8 paths, colours repeat, so use the labelled legend to identify each slice.
• Line chart — x-axis is every day in the range (including days with zero events), y-axis is events that day for each path. Every path in the top-N is one line. Tooltip at each point shows the date and the count.

What success looks like

• The Event Logs table renders the 20 most-recent events in Event | Path | Referrer | Date | User | Session order, with humanised event badges (Page View, not page_view).
• A filter change rewrites the URL with ?type=... or ?s=..., so the filtered view is shareable.
• Reports renders both the doughnut and the line chart with populated data within ~2 seconds of opening or filter change.
• Filtering Reports to 404 Not Found gives you a doughnut of the most-hit broken paths and a line chart showing whether the 404 rate is climbing or stable.
• A real launch spike on the line chart is visible to the eye — at least one series jumps several times higher than its neighbours on the launch date.
• The page source of any public page on your site does NOT contain gtag, ga, fbq, or dataLayer script tags purely from native Analytics. (Those only appear if you have wired up Integrations or Custom Codes.)

What to do if it does not work

• Event Logs is empty on a site I know is getting traffic. Confirm a public-side visit happens AFTER the analytics surface was enabled — the tracker does not back-fill historical traffic. Open an incognito window, visit a few public pages, return to Event Logs, hard-refresh.
• Your own visits are not showing up. That is by design. Visits to admin routes (/sg-admin/...) are not logged. Open an incognito window and visit your public site to test.
• Referrer is blank for visits you know came from a link. Some sources strip the referrer header — HTTPS-to-HTTP downgrades, mobile apps, link shorteners, email clients. The blank cell is browser behaviour, not a tracker bug.
• Old events seem to have disappeared. They have not — the table only shows 20 per page. Page forward, or narrow with a date-filtered view in Reports.
• You see events you do not expect. Monitors, uptime checks, and link previewers (Slack, Facebook, X / Twitter) hit your public URLs and log as page views. Their referrers are usually identifiable in the Referrer column.
• Reports charts are empty. The empty-state message "No events yet for this period." appears when the filter resolves to zero rows. Widen the date range or clear the Event Type filter.
• The doughnut centre number does not match Event Logs. Expected — the doughnut only counts your top-N paths; Event Logs counts every event. If your site has many low-traffic pages, the doughnut total is lower.
• One path dominates the doughnut. Usually that is / (the homepage). Either set a narrower Event Type, or use Event Logs to see the long tail.
• The line chart has a flat zero series for a path. That path had events earlier in the range but zero in the window being charted, or it only fires on a subset of days. The zero-fill is intentional — it keeps the date axis continuous so a real spike stays visible.
• The numbers in Reports do not match GA4 / Meta Pixel. They will not. Native Analytics counts server-side requests; third-party trackers count client-side script loads. The deltas are real and have multiple explanations: ad blockers stripping the third-party tracker, bot traffic counted server-side but not client-side, third-party deduplication, sampling. Pick one source as the source of truth for each question.

Where Analytics ends, third-party tracking starts

Native Analytics answers questions about what visitors requested. It does not answer:

• How long did they stay on the page?
• How far did they scroll?
• Did they convert on the goal you defined?
• Did they come back next week?
• What device, browser, country, language?

For any of those, wire up a third-party tracker through Integrations (GA4) or paste a snippet through Custom Codes (Meta Pixel, LinkedIn Insight, others). Native Analytics and third-party trackers run side-by-side without conflict — native is server-side, third-party is client-side.

The architectural choice: Analytics ships in the platform so you have something to lean on day-one, and so the operator who runs the site has a private record of what visitors did. Anything more sophisticated is a deliberate tooling choice you make later, not a default.

Go next

• Event Logs — the raw row-by-row view of the same data. Use it for specific path / specific date / specific session questions.
• Reports — the aggregate doughnut and line charts. Use it for top-N and trend-over-time questions.
• Redirects — when 404s show up in Event Logs, this is where you fix them.
• Integrations — for GA4 and Google Tag Manager wiring.
• Custom Codes — for Meta Pixel, LinkedIn Insight, and any tracker that needs a script snippet on the public site.
• Tracking Consent — for the consent overlay that governs the third-party trackers above.
• Changelog — when reporting changes ship, the entry explains the new field and how it changes the views described here.

The event-type catalogue

A complete reference for every event type the native tracker emits, when it fires, and what the row looks like.

Event type	Fires when	Path column reads	Available on
Page View	A visitor requests a published page or post on the front-end	The page URL path (e.g. /blog/intro-to-roasting)	All sites
404 Not Found	A visitor requests a URL that does not resolve to any page	The requested path (e.g. /blog/old-brewing-guide)	All sites
Form Submit	A visitor submits any form on the public site	The page the form was on (e.g. /contact)	All sites
Phone Tap	A visitor taps a phone-number link on mobile	The page the tap fired on (e.g. /contact)	Sites with the Phone Taps module
Product View	A visitor opens an ecommerce product page	The product URL (e.g. /products/canvas-tote-bag)	Ecommerce sites only
Add To Cart	A visitor adds a product to their cart	The product URL	Ecommerce sites only
Checkout Started	A visitor opens the checkout page	/checkout	Ecommerce sites only
Purchase	A successful order completes	/checkout/complete (or order confirmation path)	Ecommerce sites only

The four ecommerce events only appear in the Event Type filter when your site has the storefront module enabled. On a content-only site, those tabs are absent.

Anatomy of an Event Logs row

A single row in Event Logs has six cells. Reading each one quickly is the difference between scanning the table for a question and getting lost in it.

• Event — the human label of the event type (Page View, not page_view). Colour-coded badge: green for traffic events, red for 404s, blue-ish for ecommerce. The badge colour helps the eye find the row pattern you care about while scanning.
• Path — the URL path the visitor requested, no domain. Query strings are preserved verbatim, so /pricing?utm=google and /pricing?utm=email appear as distinct rows. Use the Path column to identify which page the event fired on.
• Referrer — the URL the visitor was on immediately before this request. A dash means no referrer was sent (typed-in URL, bookmark, app, link shortener, HTTPS-to-HTTP downgrade, email client). The Referrer column is your inbound-traffic source.
• Date — YYYY-MM-DD HH:MM in the server's local time zone. Format does not change with browser locale; the server's timezone is what you see.
• User — the logged-in SGEN user (admin or registered customer) who triggered the event. A dash means anonymous. Useful when an admin is testing a user-facing flow and wants to confirm their own session is registering.
• Session — the first 8 characters of the PHP session identifier, truncated. Use it to confirm whether two events came from the same browser session — but do not treat it as a stable visitor ID, since it rotates on browser restart.

Sharing a filtered view with a teammate

Every filter you set on either Event Logs or Reports is captured in the URL. To share a view:

1. Set the filters and date range you want.
2. Apply (or wait for the page to reload after a filter change).
3. Copy the URL from the address bar.
4. Paste it to your teammate. They land on the same view, with the same filters applied.

This is the SGEN-native equivalent of a shared analytics dashboard. No saved-view concept, no permissions wrangling — the URL IS the dashboard.

A weekly Analytics rhythm that holds up

A site that runs without anyone looking at Analytics for months is a site where broken links go unfixed and successful campaigns go unmeasured. A short weekly walk takes about ten minutes:

1. Monday — Event Logs scan. Filter to All Types for the last 7 days. Scan the event-type tab counts. Anything more than ~20% off last week's pattern is worth a closer look.
2. Monday — 404 audit. Filter to 404 Not Found for the last 7 days. Any path that appears more than twice is a candidate for a redirect rule. Open Redirects and add the rule.
3. Friday — Reports top-pages check. Open Reports, set Top Paths to 10, last 7 days, Page View. Note the order. Compare against last Friday — a new entry in the top 10 is either a successful campaign you should double down on, or unexpected traffic you should understand.
4. Friday — Form Submit referrer scan. Filter Event Logs to Form Submit for the last 7 days. Look at which referrers drove submissions. The top referrer is your most-effective traffic source for conversions; reinforce it.

A team that runs this rhythm four times a month has a much shorter feedback loop than a team running quarterly reports.

Privacy posture

Native Analytics records what visitors requested from your server — page paths, referrers, timestamps, the logged-in user when one is signed in, and a session identifier. It does not record:

• Visitor name, email, IP address (the IP is used to dispatch the request and then discarded — not stored against the row).
• Mouse movements, scroll depth, or any client-side behaviour.
• Form field values typed into the body of a form. Form Submit events log that a submission happened on a page; the data lives in Forms → Submissions, governed by that module's retention policy.
• Cross-site or cross-device identity. The Session column is a per-browser PHP session that rotates on browser restart.

Visitor consent (per Tracking Consent) governs third-party trackers — GA4, Meta Pixel, anything else loaded via Custom Codes. Native Analytics is not gated by consent because it does not track behaviour beyond the request the visitor's browser already made to your server.

For a published privacy notice, the practical wording is something like: "We log front-end page requests on the server. We do not use third-party trackers without your consent." Adapt to your jurisdiction with legal review — this doc does not substitute for that.

When the marketing team needs more depth

Native Analytics covers operator-side questions: did launch day work, which 404s to fix, where form submissions came from. It does not cover marketing-side questions: how long visitors stayed, whether they completed a goal funnel, what device or country they were on, did a paid-ad click convert.

The path forward when those questions arrive:

1. GA4 via Integrations. Wire GA4 through the Integrations panel. Configure goal events on the GA4 side. The native Analytics panel keeps running in parallel — operator questions stay native, marketing questions go to GA4.
2. Meta Pixel via Custom Codes. Paste the Pixel snippet in Custom Codes. Use Tracking Consent to gate it behind visitor consent. Conversions report to Meta, not to native Analytics.
3. Server-side conversion API for ad networks. When the ad network needs server-confirmed conversion events (Meta CAPI, Google Conversion API), set those up on a per-network basis. Each ad network has its own server-to-server requirements.
4. A standalone product analytics tool (Mixpanel, PostHog, Amplitude) for funnel and cohort questions. None of these replace native Analytics; they sit alongside it.

The intent: native Analytics ships as the operator's day-one window, third-party tools sit on top when the team needs depth. Neither blocks the other.

Reading the line chart correctly

The line chart in Reports has one axis convention worth understanding. The x-axis is every day in the date range, contiguous, including days with zero events. The day-fill is intentional — without it, a single-day spike on an otherwise-empty week would visually compress against neighbouring data points and lose its shape.

Practical consequences:

• A flat zero series for a path means that path had events earlier in the range but zero in the current window. Not a render bug.
• A long, mostly-flat line that ramps up sharply at one end is the visual signature of a successful campaign or a viral inbound link. Worth opening Event Logs for that path on that date.
• A line that climbs steadily over the whole range — without a single-day spike — is organic growth, not campaign-driven. Treat the underlying page or product as a candidate for more investment.
• A line that drops to zero and stays there means the page stopped getting traffic. Either it was unpublished, the inbound link broke, or the audience moved on.

One last operator note

The point of native Analytics is not to be the only number you ever look at. The point is that the operator who runs the site has a private, server-side, ad-blocker-proof window into what visitors did — every day, no setup, no consent overlay required for the basic view. Use it as the ground-truth check on whatever else you wire up.