How to Use SGEN Analytics

Open Analytics with a question in mind, not just a habit.

SGEN Analytics is most useful when operators open it to answer a specific question — is this page being found, did the recent publish move the conversion rate, are lead submissions trending — rather than to scroll through numbers passively. The platform surfaces traffic, leads, SEO signals, and operational events; the value is in using those signals to drive decisions.

What is this for?

Read this guide to understand how to use SGEN Analytics in practice — the questions to bring, the surfaces to read, the patterns to recognize, the actions to take.

Good use cases

What NOT to use this for

Before you start

You should have:

• A live SGEN site with at least a few days of traffic. Analytics on day-zero sites doesn't have data to work with.
• A specific question you want to answer.
• An open mind about what the data might show.

How this connects to other features

Where to go

Open SG-Admin → Analytics. The two main surfaces are Event Logs (raw event view) and Reports (aggregated view).

How to use SGEN Analytics

Steps — Use Analytics for decisions

1. Start with a specific question

Open Analytics with a decision in mind. Examples of decision-driving questions:

• "Did the homepage redesign last week increase or decrease the conversion rate?"
• "Which traffic source is bringing in the most lead-quality visitors?"
• "Why did form submissions drop yesterday?"
• "Is the new blog post getting any organic search traffic?"

Vague questions produce vague reviews. "Let me check Analytics" is the wrong starting point; "Let me check whether last Tuesday's publish moved the contact form's conversion rate" is the right one.

2. Use the Dashboard for operational signals

The Dashboard inside the Analytics module surfaces site vitals, leads, SEO health, and recent activity in one view. Use it as a control view — what's the state right now — rather than as a vanity board.

When opening the Dashboard, switch the time period to a relevant window. A single day rarely tells you anything; a week or a month gives you context. The Dashboard's period switcher is in the top-right of the surface.

The Dashboard is most useful for the "is the site running normally?" question. For deeper investigation, move to Reports.

3. Read leads as operating data

Form submissions, phone taps, and consent-on events are operating data — they tell you what visitors are actually doing, not just what they're seeing.

Read leads alongside traffic. A drop in submissions could be a traffic issue (fewer visitors), a path issue (visitors not finding the form), or a conversion issue (visitors finding the form but not filling it out). The three problems have different fixes; mixing them up wastes time.

The Submissions view inside Forms shows each submission's source page and traffic-source attribution. The Phone Taps view shows similar data for click-to-call interactions. Together they give a fuller picture of operating behavior than page views alone.

4. Use SEO and content signals together

If a page is underperforming, don't look at search rankings in isolation. Review the page itself: is the content answering the visitor's question, is the metadata correct, are the internal links connecting it to the rest of the site, is the business value of the page clear?

Search visibility and content quality compose. A page can rank well and still convert poorly if the content doesn't match the intent. A page can have great content and still fail to rank if metadata or internal-linking work hasn't been done.

The Analytics module surfaces both signals — search-driven traffic in the traffic reports, content-engagement signals in the per-page reports. Reading them together is the difference between "this page has a problem" and "this page has a content problem versus a visibility problem."

5. Use Analytics after publishing

After meaningful changes, use Analytics to validate the outcome. Did the target page get more engagement? Did form activity shift? Did the traffic pattern move the way the change was supposed to move it?

Validation closes the loop on the publish. Without it, operators publish and assume the change worked; with it, they confirm and adjust. Most publishes don't need adjustment, but the ones that do are the ones validation catches.

A practical cadence: review Analytics 24-48 hours after a meaningful change. Earlier than that, the data is too noisy to read; later than that, the next change has already started landing and the signals get muddled.

What success looks like

What to do if it does not work

The numbers don't seem to match what you expect. Check the time window first. Many "the data is wrong" conversations turn out to be "the time window doesn't match the question." Adjust the period and re-read.

Submissions are dropping but traffic is flat. Path or conversion issue, not a traffic issue. Walk the site as a visitor; look for what changed in the conversion path recently. Check whether a form is broken, a CTA was renamed, or a landing page got rearranged.

Traffic is dropping but submissions are flat. Either the dropping traffic was low-conversion (so it didn't affect submissions) or the conversion rate is rising to compensate. Check the traffic-source breakdown to see which source is dropping.

A specific page shows zero activity. Could be the URL changed and the old URL is what's being indexed, the page isn't published, or the page was excluded from analytics. Check publishing status, URL, and per-page tracking configuration.

The Dashboard shows different numbers from Reports. Usually a period or filter mismatch. The Dashboard typically defaults to a different window than Reports; align the windows and the numbers usually agree.

Best practices

• Use Analytics to prioritize action, not to generate decorative reports.
• Bring a specific question every time. Vague reviews waste time.
• Compare windows that mean something — week-over-week, before/after a change, against a baseline period.
• Read leads alongside traffic, not separately.
• Validate publishes 24-48 hours after they land.
• Across multiple sites, compare patterns, not just totals.

Common questions

How fresh is the data? Page views, form submissions, and most events appear in Analytics within minutes of happening. Aggregated reports may have a slightly longer delay (up to an hour for some surfaces).

Can I export the data? Yes. The Reports surface offers CSV export. Submissions can be exported from the Forms module. For deeper analysis, the export-and-analyze pattern is the standard path.

Does Analytics work without cookies? Mostly. Many event types fire regardless of cookie state; some attribution data degrades when visitors haven't consented to tracking. The Tracking Consent module governs the contract; the platform respects it automatically.

Can I add custom events? Yes, through the Custom Events configuration in the Analytics module. Most workflows are covered by default events; custom events fill gaps when the standard set doesn't reach.

How does this compare to Google Analytics? Different scope. SGEN Analytics is built into the platform and always works; Google Analytics is an external service that operators configure separately. Many sites use both — SGEN Analytics for operating signals, GA for marketing-attribution analysis.

Where do I find lead activity specifically? Submissions inside the Forms module is the primary lead view. Analytics shows lead-related events in context with other site activity.

Common patterns

Weekly review pattern. Open Analytics weekly, on a fixed day. Compare the past seven days to the prior seven. Note what changed in traffic, leads, conversion rate. Most teams settle into this rhythm; weekly is frequent enough to catch issues early but infrequent enough not to be busywork.

Post-publish validation pattern. After every meaningful publish, open Analytics 24-48 hours later. Compare the new state to the prior baseline. Capture any unexpected movement.

Source-attribution pattern. Once a quarter, run a deeper review of where lead-quality traffic is coming from. The breakdown can shift; rebalancing marketing effort follows the data.

Underperforming-page pattern. When a page is identified as underperforming, walk through traffic source, search visibility, content quality, and conversion path before concluding what to fix. Most underperforming pages have issues at multiple levels; the right fix is usually the one that addresses the most-common visitor experience.

Patterns to avoid

Vanity-reporting pattern. Producing reports for stakeholders that show flattering numbers but don't drive action. The reports take real time to produce and rarely change behavior; the time would be better spent acting on the data directly.

Daily-checking pattern. Opening Analytics every day looking for changes. Most days produce noise; the operator burns attention on signals that aren't significant.

Setting-and-forgetting pattern. Configuring Analytics once and then never checking. The data accumulates without informing decisions; the work that produces the data goes unverified.

Reading order

Read this guide once at the post-launch stage. Pair with SG-Admin Analytics for module-level reference. Return to this guide when establishing or revising the team's analytics review cadence.

Related reading

Working with stakeholders

Analytics gets used by operators directly and shared with stakeholders (clients, executive team, marketing partners) indirectly. The two uses have different shapes.

Operator use is decision-driven, time-windowed to a specific question, and short. Read the data, decide, act, validate later.

Stakeholder communication is summary-driven, time-windowed to whatever the stakeholder cares about, and longer-form. The data needs framing — what changed, what does it mean, what's being done about it.

The platform's export tooling supports stakeholder reports without requiring operators to manually transcribe data.

Avoid common stakeholder pitfalls

Reporting numbers without context invites misinterpretation. A 20% traffic drop sounds bad until the operator notes that the prior period included a one-time spike from a viral mention; a 5% conversion-rate increase sounds modest until the operator notes that the absolute volume is up substantially too.

The stakeholder communication that lands well frames the numbers, not just the numbers themselves.

Privacy and consent

Analytics in SGEN respects visitor consent state. The Tracking Consent module governs what data flows into Analytics; the Analytics module honors the contract.

When a visitor has not given consent, identifying signals (cookies, return-visitor flags, attribution chains) are stripped from the events that fire. The events themselves still fire — operators still get site-internal counts — but the visitor-identifying parts of the payload are removed before transmission.

This is the same pattern every event-emitting feature in SGEN follows. Operators don't configure per-feature consent handling; the platform-level consent state propagates automatically.

For sites in jurisdictions with stricter requirements, the Tracking Consent module can be configured to suppress events entirely until consent is given. The trade-off is fewer signals on visitors who haven't consented; the benefit is meeting compliance requirements without per-event configuration work.

Comparison: Reports vs Event Logs

Analytics surfaces fall into two shapes. Knowing which to use for which question saves time.

Reports is the aggregated view — counts, rates, time-series charts, breakdowns by source / page / device. Best for: "how is the site doing overall, by week or month?", "which pages get the most traffic?", "what percentage of visitors convert?"

Event Logs is the raw event-stream view — each individual page view, form submission, popup-shown, custom-event firing. Best for: "what exactly happened on this specific submission?", "did this event fire when I expected?", "is the tracking configuration working correctly?"

Most operator work is in Reports. Event Logs comes out for debugging, custom-event verification, and detailed investigation.

When to switch from Reports to Event Logs

A useful signal: when Reports shows a number that surprises the operator (a spike, a drop, an unexpected zero), Event Logs is the next surface to open. The aggregated number could be aggregated over many things; the raw events show exactly what is happening.

Another signal: when setting up custom events, Event Logs is the verification tool. The custom event should appear in Event Logs immediately after the operator triggers the action that fires it.

Time-window choices

Analytics surfaces almost always come with a time-window picker. Choosing the right window is half the work.

Last 24 hours — useful for "what just happened" or post-publish validation when the publish was very recent.

Last 7 days — the most common operator window. Captures a full weekly cycle, smooths out day-to-day noise.

Last 30 days — useful for trend reading. Captures multiple weekly cycles, reveals seasonal effects.

Last 90 days — quarterly review window. Good for strategic decisions and identifying long-term patterns.

Custom range — for comparing specific events (campaign windows, before/after a major change).

The right window depends on the question. "Did yesterday's publish work?" → 24-48 hours. "Is the site trending up or down?" → 30-90 days. "Did this campaign succeed?" → custom range matching the campaign window.

About analytics decisions

Analytics decisions are choices the operator makes based on what the data shows. Examples: keep iterating on a page that's underperforming versus accepting it as-is, double down on a traffic source that's converting well, retire a page that's not earning its keep.

Analytics decisions don't have to be big. Most are small adjustments — copy tweaks, navigation rearrangements, CTA reorderings — that compound over time. Operators who treat analytics decisions as a steady habit rather than as occasional events get more cumulative benefit.

The discipline that makes analytics decisions productive is bringing a question, reading the data, deciding what to change, making the change, and then validating. Each step matters; skipping any of them weakens the loop.

When data isn't enough

Some decisions can't be made from analytics alone. Brand-positioning decisions, strategic-direction decisions, ethical decisions — the data informs but doesn't decide. Operators who try to make every decision data-driven get stuck on questions that aren't actually data questions.

The right calibration: data informs the decisions where data has something to say; judgment informs the decisions where it doesn't.

A framework for reading the Dashboard

The Analytics Dashboard surfaces a lot of signals at once. A useful reading order:

Top-of-funnel — traffic. Did total traffic move? In which direction? Compared to what window?

Mid-funnel — engagement. Are visitors who arrive sticking around? Reading more than one page? Spending meaningful time on the priority pages?

Bottom-of-funnel — conversion. Are submissions, taps, and other lead-events trending? Did the conversion rate change?

Lateral — sources. Where is the traffic coming from? Did the source mix change?

Anomalies — outliers. Anything spiking or crashing on a single day? What was the cause?

Reading top-down gives a coherent narrative: traffic state → engagement state → conversion state → source mix → anomalies. Operators who jump around the Dashboard randomly get fragmented impressions; operators who read top-down get the full picture in two or three minutes.

Customizing the reading order

The five-stage reading order isn't strict. Different sites prioritize differently — an ecommerce site cares more about cart conversion than about source mix; a content site cares more about engagement than about conversion. Adjust the order to fit the site's goals.

The five stages stay the same; the priority shifts based on what the operator is responsible for.

About operational signals

Operational signals are the data points that tell you whether the site is doing its job. Page views are visibility signals; form submissions are conversion signals; phone taps are intent signals; bounce rate is engagement signals. Reading them together produces a fuller picture than any one in isolation.

The platform surfaces operational signals in the Analytics Dashboard. Operators who develop fluency reading the operational signals make faster decisions; operators who treat Analytics as a number-display rather than a signal-source spend more time and get less out of it.

About publish validation

Publish validation is the practice of using Analytics to confirm that a publish moved metrics the way it was supposed to. The discipline is small in any single instance — checking 24-48 hours after a publish — but accumulates: teams that validate consistently catch regressions earlier, build a feedback loop that improves their publishing decisions, and develop intuition about what changes produce what effects.

The platform supports publish validation through the time-window comparison features in Reports. Set the prior week as the baseline, the current week as the comparison, and the deltas surface immediately.

About cross-site analysis

For operators managing multiple sites, the per-site Analytics surfaces are siloed. Cross-site analysis (comparing patterns across the portfolio) usually involves exporting data from each site and combining externally, or using the multi-site dashboard view where available.

The pattern most teams settle on: use per-site Analytics for operational decisions on each site; use a cross-site comparison surface (or external tooling) for portfolio-level patterns. The two views answer different questions; both have a place.