## Understanding How Audience-Specific Public Views Work
When a project in Atloria is published with audience targeting, readers can open the public documentation site and view content that matches a selected audience. The public experience stays focused on reading and navigation: readers arrive on a public page, use the page header controls, and browse a sidebar and page body that reflect the current audience view. This means the same documentation site can present different guidance to different readers without forcing them to sort through unrelated pages.

A key part of this experience is the audience selector in the public documentation view. When it is available, readers use it to switch between audience options. After a new audience is selected, the visible content updates to match that choice. Readers may notice changes in the left navigation, the sections shown inside the page, and the related links that appear around the content. Content meant for the selected audience stays visible, while content assigned to other audiences is hidden from that view.

Default public content remains available more broadly. Shared pages and shared sections continue to appear regardless of which audience is selected. Audience-targeted content is more specific and only appears when the matching audience is active. If no audience is selected, readers typically see the default public experience, which is the broadest view available on the published site.

From a reader’s point of view, the workflow is simple: open the public documentation URL, check the selected audience in the page controls, browse the filtered sidebar, read the page body, and follow links that stay aligned with that audience context.

[SCREENSHOT: Public documentation page showing the audience selector, left navigation, and page content area]

## Switching to the Right Audience View as a Reader
1. Open the published documentation site in Atloria and look near the top of the page for the audience selector. This control appears in the public reading experience when more than one audience view is available. If you are reviewing content for a specific reader group, confirm the current selection before you start reading.

2. Click the audience selector and choose the audience you want to view. After you make a selection, the page updates to match that audience. Depending on the page, you may see the content refresh immediately or reload into the selected view. Stay on the same page after switching so you can compare what changed.

3. Review the page body carefully. Audience-specific sections, notes, or callouts should now match the selected audience. You may also notice that some content disappears. That is expected when those sections belong to a different audience. Focus on whether the visible instructions, examples, and supporting details fit the audience you chose.

4. Check the navigation menu on the left side of the page. The available pages and section links should now reflect the same audience context. If the audience view is working correctly, the navigation should guide you only to pages that are relevant for that reader group.

5. Continue browsing by using the sidebar, related links, or in-page links. As you move through the public documentation, the audience context should stay in place so you do not have to reselect it on every page.

[SCREENSHOT: Audience selector opened with multiple audience options visible]

## Recognizing What Changes Between Audience Views
Audience views in Atloria can change more than just a single paragraph on a page. Depending on how the documentation team has prepared the public site, readers may see different section blocks, notes, supporting guidance, and related reading paths after switching audiences. In some cases, the page title may stay the same while the content inside the page changes. In other cases, the navigation itself may shift so that one audience sees a focused set of pages while another sees a broader or different path through the documentation.

The left navigation is one of the clearest places to spot these differences. Child pages that matter to one audience may appear only when that audience is selected. Related article links can also change, helping readers stay within a path that fits their role or use case. This keeps the public site easier to browse because readers are not distracted by pages that do not apply to them.

Shared content still remains visible. If a page section is meant for everyone, it continues to appear across all audience views. Only the content that has been targeted to a specific audience changes when readers switch. This mix of shared and audience-specific content is what makes the public documentation feel consistent while still being tailored.

Common reader cues include:

- The selected audience label in the audience selector
- A changed or filtered left navigation tree
- Different section blocks or callouts in the page body
- Audience-specific banner text or page messaging
- Related links that shift to audience-relevant pages

When reviewing a page, use these cues together rather than relying on just one visible change.

## Checking Audience Visibility Before Publishing Changes
Before you test the public documentation experience, make sure the content you want to review has actually been prepared for audience-based visibility. In Atloria, audience views only make sense when the relevant pages or page sections have been assigned to the correct audiences. If a page is still shared with everyone, switching the audience in the public view may not produce any visible change.

Start by confirming that the documentation has been published to its public destination. Audience filtering is best checked in the public reading experience, not only inside the editing workspace. If the latest changes have not been published, the public site may still show an older version of the content and navigation. That can make it look like audience targeting is broken when the issue is simply that the public site has not been updated yet.

Next, verify that the audiences you plan to test are available in the audience selector. If you expect to review multiple reader experiences, each target audience should appear as a selectable option in the public documentation header or page controls. If one is missing, you will not be able to validate that view from the public side.

It also helps to prepare a simple review list before testing. Include:

- Pages that should appear for each audience
- Pages that should stay hidden for each audience
- Section blocks or callouts that should change
- Related links that should update
- Navigation items that should remain shared

If you need help setting up audiences before this stage, review [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation) and [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation).

## Validating the Public Experience for Each Audience
1. Open the same public page for each available audience and compare what appears on screen. Start with a page that you know contains audience-specific content. Check the page body, the left navigation, and any related links shown nearby. Compare each view against your expected audience plan so you can quickly spot missing or extra content.

2. Test direct page access by opening links to pages that should only matter to one audience. Then switch to a different audience and confirm that restricted sections or audience-specific paths do not appear where they should be hidden. This is especially useful for checking whether a page is truly filtered in the public experience rather than only hidden from the sidebar.

3. Move through the documentation using normal reader actions. Click sidebar items, follow breadcrumbs if they are available, and use in-page links to open related content. As you browse, confirm that the audience context stays consistent. The navigation and page content should continue to reflect the same audience without unexpectedly showing content from another view.

4. Repeat your checks in an incognito window or a signed-out browser session. This helps you verify the public-facing experience as an external reader would see it. It is a useful final check because editing access or saved session state can sometimes make internal testing feel different from the published view.

For a broader review process after switching is working correctly, continue with [Reviewing Audience Specific Pages in Public Documentation](doc:reviewing-audience-specific-pages-in-public-documentation).

## Fixing Mismatched or Missing Audience Content
If the public page does not behave as expected, start with the most visible sign: the audience selector. When the selector does not appear, there may not be multiple public audience views available for that site, or the published documentation may not currently expose audience choices. In that case, first confirm that the project has audience views prepared and published.

When the wrong content appears after switching audiences, review the audience assignment on the affected page or section in Atloria. A page can remain visible to everyone if it was left as shared content, and a section can stay hidden if it was assigned to a different audience than intended. If only part of a page looks wrong, focus on the specific content block or note that should change between audiences.

Missing navigation links usually point to visibility settings on child pages or sidebar entries. If one audience cannot see a page in the left navigation, check whether that page is included in that audience’s public view. Also confirm whether the page should be shared content instead of audience-specific content.

If you have updated content but the public site still shows the old version, publish the latest changes again and reload the public page. Then switch audiences one more time to confirm the updated content appears.

Use this quick troubleshooting table when reviewing issues:

| What you see | What to check |
|---|---|
| No audience selector | Whether multiple audience views are available in the public site |
| Wrong page content | Audience assignment on the page or section |
| Missing sidebar links | Audience visibility for child pages or navigation items |
| Old content after changes | Whether the latest documentation was published and the page was reloaded |

## Overview
Public audience views in Atloria let one published documentation site serve different reader groups without creating separate public sites for each one. Readers open the same public documentation experience, then use the audience selector to view the version of the content that fits them best. Once an audience is selected, Atloria updates the visible page content, left navigation, and related links so readers stay on a path that matches their needs.

This is most useful when your team maintains shared documentation with a mix of common guidance and audience-specific instructions. Shared content stays available across all views, while targeted sections only appear for the matching audience. As a result, readers can move through the public site with less noise and fewer irrelevant pages.

When you review audience views, focus on three things:

- Whether the correct audience options appear in the selector
- Whether the page body changes as expected for each audience
- Whether the navigation and links stay aligned with the selected audience

This document focuses on the public reading experience and the validation steps that help you confirm it is working correctly. If you need to build the audience structure first, start with [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation). If you want help browsing public docs more generally, see [Using Public Navigation to Browse Documentation](doc:using-public-navigation-to-browse-documentation) and [Using Public Navigation with Audience Specific Content](doc:using-public-navigation-with-audience-specific-content).

The next step is [Planning Audience Specific Documentation Experiences](doc:planning-audience-specific-documentation-experiences).

## Prerequisites
Before you review public documentation by audience in Atloria, make sure these basics are already in place:

- You have a published documentation site to open in a public browser view
- The project already includes at least one configured audience, and ideally more than one if you want to test switching
- The pages or page sections you want to review have been prepared with the correct audience visibility
- The latest documentation changes have been published so the public site reflects current content
- You know which pages, sections, and navigation items should appear for each audience you plan to test

It also helps to have a simple audience review plan ready before you begin. For example, list one or two representative pages for each audience, note any sections that should be shared across all views, and identify any pages that should disappear from navigation when a different audience is selected. This makes it much easier to tell whether the public experience is behaving correctly.

If you are still setting up the audience structure, review these related guides first:

- [Defining Audiences for Targeted Documentation](doc:defining-audiences-for-targeted-documentation)
- [Managing Audience Settings Across the Organization](doc:managing-audience-settings-across-the-organization)
- [Managing Project Audiences for Targeted Documentation](doc:managing-project-audiences-for-targeted-documentation)
- [Publishing Documentation for Specific Audiences](doc:publishing-documentation-for-specific-audiences)

If your goal is to validate the published site from a reader’s point of view, use a signed-out browser session or an incognito window during testing. That gives you a cleaner view of what external readers will actually see.