## Opening project analytics and choosing the reporting scope
In Atloria, open the project you want to review, then use the project navigation to go to **Analytics**. Make sure you are looking at the analytics view for that specific project, not an admin-wide reporting area. If you do not see **Analytics** in the project navigation, your account may not have access to project reports. In that case, ask an administrator to confirm your permissions in the admin workspace.

Once the **Analytics** page opens, start with the date range control at the top of the report. Use it to switch between a recent window, such as the last few days or weeks, and a longer view that shows broader patterns. Short ranges help you review the impact of a recent release or content update. Longer ranges are better when you want to understand whether a trend is stable over time.

[SCREENSHOT: Project Analytics page showing the project navigation and date range selector]

Before reading any numbers, confirm the reporting scope is limited to the current project. This matters when your team manages several projects in Atloria. A project-only view helps you judge the performance of one documentation set without mixing in traffic from other teams or products.

As you review the page, pay attention to how the report groups content. In many project analytics views, totals may reflect published documentation, versioned content, or release-related pages connected to the current project. If the screen offers grouping by version, section, or content area, use that grouping early. It gives you a cleaner starting point for deciding whether readers are finding the right release notes, setup guides, or reference pages inside this project.

If you need a refresher on the broader project analytics workflow, see [Using Project Analytics and Audit Signals for Ongoing Operations](doc:using-project-analytics-and-audit-signals-for-ongoing-operations).

## Reading the core project metrics that show documentation performance
At the top of the project **Analytics** view, start with the summary cards or headline metrics. Focus first on the numbers that show reach and usage, such as **Views**, **Unique Visitors**, and any engagement measure shown on the page. These top-level figures tell you whether people are finding the project documentation and whether they are spending meaningful time with it.

Read these numbers together instead of one at a time. For example:

- High **Views** with low **Unique Visitors** can suggest repeat use by a smaller audience.
- Strong **Unique Visitors** with weak engagement can point to pages that attract clicks but do not hold attention.
- Flat traffic with stable engagement may mean the content is serving a steady audience well, even without growth.

Next, look for the change indicator beside each metric. Atloria may show whether the current period is up, down, or unchanged compared with the previous period. Use those comparisons to spot movement quickly. A rise in views after a release can be a healthy sign, but only if engagement also stays strong. If views increase while engagement drops, readers may be landing on the right pages but not getting what they need.

Below the summary area, review the traffic trend chart. This chart helps you separate a one-day spike from a sustained pattern. A single sharp jump usually means a release event, announcement, or temporary burst of interest. A steady upward line is more useful when planning ongoing content investment.

[SCREENSHOT: Top metric cards and traffic trend chart in the project Analytics view]

If the analytics screen breaks performance down by **Version**, **Section**, or another content grouping, use that view to connect traffic to specific documentation areas. This is especially helpful when one release version is drawing most of the attention, or when a section such as setup, upgrade, or reference content is carrying most of the project’s reader activity.

## Finding weak spots by drilling into low-performing pages and sections
After reviewing the top-level numbers, move down to the page list or performance table in the **Analytics** view. This is where Atloria becomes most useful for content decisions. Open the list of pages, sections, or grouped content items and sort it using the available columns, such as **Views**, **Engagement**, or similar performance measures shown on the screen.

1. Sort the list by **Views** to find pages that receive meaningful traffic.
2. Re-sort by **Engagement** to find pages where readers appear less involved.
3. Compare the two results to spot pages that attract attention but do not perform well once opened.
4. Use the page labels, section names, or path-style names in the list to identify where those pages sit in the project structure.

This comparison helps you find weak spots that matter. A page with low traffic and low engagement may simply be new, niche, or not yet promoted. A page with high traffic and weak engagement is usually a stronger candidate for revision because readers are already arriving there and may be leaving without finding clear answers.

Look closely at section or folder labels to see whether underperformance clusters in one area. You may notice patterns such as weaker setup guides, thin release notes, or version-specific pages that are not getting attention after publication. If the report includes version grouping, compare older and newer release content side by side.

[SCREENSHOT: Analytics table with sortable columns for views and engagement]

Before deciding a page is failing, cross-check timing. Newly published pages, recently renamed pages, or content added under a new release version often need more time before their numbers become meaningful. Use the project context you already know—recent launches, publishing dates, and version changes—to judge whether the issue is discoverability, release timing, or the content itself.

## Using analytics trends to support release planning decisions
Project analytics are especially useful when you read them against your release calendar. In Atloria, use the date range control to look at the period before, during, and after a release. Then compare which pages or sections gained attention at each stage. This helps you understand what readers need earliest and what they return to after launch.

1. Set the date range to include a recent release window.
2. Review the traffic trend chart for spikes around the release date.
3. Open the page or section list and identify which release-related pages rose during that period.
4. Compare those results with another release period or a longer date range to see whether the pattern repeats.

Pages that spike every time you ship a release are usually release-critical. These often include upgrade instructions, change summaries, feature availability notes, and pages that help readers move from one version to another. If those pages consistently draw traffic before release day, they may need earlier publication. If they surge only after release, readers may be searching for help after encountering issues, which can signal that the content needs clearer placement or stronger links from release announcements.

Use version or section grouping, if available, to compare performance across release-related content. For example, one version’s release notes may draw strong traffic while the matching setup updates do not. That can mean readers know a change happened but cannot easily find the practical guidance that follows from it.

When planning the next release, prioritize the documentation areas that historically attract the most reader activity. This does not mean chasing every temporary spike. Instead, look for recurring patterns across multiple release windows. Those patterns give you a more reliable basis for deciding which pages should be updated first, reviewed earlier, or highlighted more clearly in the upcoming release cycle.

## Turning project analytics into content improvement priorities
Once you have identified strong and weak areas, turn those findings into specific editing decisions. In Atloria, the most useful pattern is often a page with high traffic but weak engagement. That combination usually means the page is important, but readers are not getting enough value from it in its current form.

Use the analytics view to build a short list of pages that need attention. Focus on pages that show one or more of these patterns:

- High traffic with weaker engagement than nearby pages
- Repeated traffic during release periods but inconsistent reader follow-through
- Strong performance in one version and weaker performance in the next
- Section-level underperformance that affects a whole content area

For each page or section, connect the analytics finding to a likely content action. A setup guide may need clearer steps. A release note may need better links to related documentation. A heavily visited reference page may need better examples or easier scanning. On the other hand, pages with very low traffic over a longer reporting window may be better candidates for merging, simplifying, or deprioritizing rather than expanding.

[SCREENSHOT: Project Analytics view beside a content review or editing workflow]

Record these decisions in your team’s normal review process. When you assign an update, note the specific analytics reason behind it, such as weak engagement on a high-traffic page or repeated release-period spikes on a page that lacks enough detail. This makes content planning easier to defend and easier to revisit later.

After you publish the update, return to the same **Analytics** view in the next reporting period. Use the same project scope and a comparable date range so you can see whether the revised page shows stronger traffic, steadier engagement, or better performance relative to similar content.

## Resolving misleading analytics readings before making decisions
Analytics are only useful when you are confident you are reading the right view. If the numbers in Atloria seem too low, too high, or inconsistent with what your team expects, check the report setup before changing content plans or release priorities.

1. Confirm the selected date range at the top of the **Analytics** page.
2. Make sure the report is showing the current project, not a broader workspace or admin reporting area.
3. Check any grouping or filtering options, such as **Version**, **Section**, or page grouping, to be sure you are comparing the same type of content.
4. Re-open the page list and verify that the pages you expect are included in the results.

A page that looks underperforming may simply be too new to judge fairly. If it was recently published, moved to a different section, renamed, or added under a new release version, its traffic history may not yet reflect its long-term value. In those cases, compare a longer date range or wait until the next reporting period before making a final decision.

Release-related traffic can also be misleading when you focus only on short-term spikes. A sudden jump around launch week may look important, but it may not represent lasting demand. Compare the short window with a broader range to see whether the page remains useful after the release rush passes.

If stakeholders question the numbers, make sure everyone is reviewing the same project analytics screen with the same date window and the same grouping choices. Most disagreements come from looking at different scopes rather than from the content itself. Aligning those settings first makes the discussion much more productive.

## Overview
This guide focuses on how to use the **Analytics** view inside a single Atloria project to make better content and release decisions. The goal is not just to read traffic numbers, but to connect those numbers to practical actions in your documentation workflow.

You use this project-level view to answer questions such as:

- Which pages are getting the most attention?
- Which sections attract readers but do not keep them engaged?
- Which release-related pages spike every time a new version goes live?
- Which content areas deserve updates, expansion, merging, or less effort?

The process starts by opening the project’s **Analytics** page and choosing the right date range and project scope. From there, you read the headline metrics, compare current results with the previous period, and use trend charts to separate temporary bursts from steady demand. The page list or performance table then helps you identify weak spots at the page or section level.

This guide assumes you already understand the broader use of project analytics and audit information in day-to-day operations. If you need that wider context, review [Using Project Analytics and Audit Signals for Ongoing Operations](doc:using-project-analytics-and-audit-signals-for-ongoing-operations) before working through the steps here.

What makes this guide different is its focus on decision-making. You are not just monitoring activity. You are using project analytics to decide what to improve before the next release, what to publish earlier, what to revise after launch, and what content may no longer justify continued effort. That makes the **Analytics** view a planning tool as much as a reporting screen.

## Prerequisites
Before you use project analytics for content and release decisions in Atloria, make sure the following are true:

- You can sign in to Atloria and open the project you want to review.
- Your account can access the project’s **Analytics** view.
- The project already has published or versioned documentation that readers can access.
- Enough time has passed since publication or release for the analytics to show meaningful activity.
- You know which release period, version, or documentation area you want to evaluate.

It also helps to have some working knowledge of the project’s structure so you can recognize page names, sections, and release-related content when they appear in the analytics table. If your team uses versioned documentation, be ready to compare one version’s performance with another rather than looking only at total project traffic.

For the most useful review, gather a small amount of context before opening the report:

| What to have ready | Why it helps |
|---|---|
| Recent release dates | Lets you compare traffic before, during, and after a release |
| Key documentation sections | Helps you recognize whether setup, release, or reference content is underperforming |
| Recent page changes | Prevents you from misreading new, moved, or renamed pages |
| Team review priorities | Makes it easier to turn analytics into editing decisions |

If you are still getting familiar with project navigation, start with [Analyzing Project Performance and Activity](doc:analyzing-project-performance-and-activity). After you finish this guide, continue with [Using Project Activity Signals to Prioritize Work](doc:using-project-activity-signals-to-prioritize-work) to turn these findings into a practical work queue for your team.