Views

Which screens and pages get seen, how long they hold attention, and where sessions end. Views turn navigation into traffic, engagement, and drop-off metrics per screen.

What a view is

A view is any screen, page, or state your product presents. On the web it is usually a page URL or a route. In a mobile app it is a screen. In a game or a kiosk it can be a level, a step, or a modal. The SDK records a view when it becomes visible and closes it when the next view opens or the session ends.

Countly stores every view as the [CLY]_view event, which is why views also show up in Drill, Funnels, and Flows. This section is the dedicated report for them.

Landings, exits, and bounces

Because views are tied to sessions, three navigation facts come for free:

• Landings are the first view of a session, so you can see where sessions begin.
• Exits are the last view of a session, so you can see where sessions end.
• Bounces are sessions that contained a single view, so you can see where sessions begin and end immediately.

Together with view count, unique profiles, and time on view, this turns navigation into a per-screen scorecard. Use it to decide which screens deserve investment, which ones lose profiles, and whether a release changed how sessions flow through the product.

Use Cases

Find the drop-offs

A high bounce rate means sessions land on a view and end without going anywhere else. On landing screens that is usually a problem, for example a campaign link that lands on the wrong page, a deep link that opens an empty state, or an onboarding step that stalls.

1. Open the Overview tab and read the Highest bounce rate column under Top views. The views listed there lose the most profiles relative to how many land on them.
2. Click a view to open it in Glance. Pick Bounce rate together with Landings to see whether the rate is driven by a handful of landings or by real volume.
3. Add a segment filter (platform, app version, or a custom view property) to check whether the problem is specific to one platform or one release.
4. Use Continue in Drill to list the profiles behind those sessions and inspect what else they did.

See what a release changed

The Movers section compares views against the previous period and surfaces the biggest risers, decliners, and views seen for the first time. It is the fastest way to answer "what changed after we shipped".

1. Set the date range to cover the days since the release. Movers compare that window against the window immediately before it, and the subtitle names the exact baseline.
2. Read the risers and decliners. A screen that jumped is either newly promoted or newly broken. Open it in Glance to see the daily curve and whether the change holds.
3. Check the new views. A brand new name is either a new feature being adopted or a screen that was renamed in the SDK. A renamed screen splits its history in two, so give the old and new names a matching display name in Manage Views, or fix the name in the next SDK release.
4. Turn on comparison in the date picker to put the previous period next to the current one across the KPI strip and the table.

When an app has many views, Movers are computed from the top views by count and the subtitle says how many were scanned.

Know where attention goes

View count tells you what is popular. Average duration tells you what holds attention. Read together, they separate pass-through screens from the ones that hold attention.

1. In the Overview tab compare Most viewed with Longest avg. duration. Views that appear in both are your core screens.
2. Sort the All views table by Avg. duration to find the screens sessions linger on. A long duration on a form or a settings page can signal confusion rather than engagement, so read it next to bounces and exits.
3. For web apps, add Avg. scroll to see how much of a long page is actually read. A long page with 25% average scroll is content that mostly goes unread.
4. Open any view in Glance and pick up to three metrics to see whether attention is stable, growing, or fading over time.

Analyze one part of the product

The scope filter at the top of the Overview narrows the whole tab to views whose name contains a term. Every section below it (KPIs, Top views, Movers, and the table) then describes only that subset.

Typical scopes

1. /blog/ or /docs/ to report on one content area of a website.
2. checkout to follow every step of a purchase flow.
3. settings to see how much of the product's configuration surface is actually used.
4. Click All views in the scope bar, type the term, and apply it.
5. Optionally add a segment filter to narrow traffic further, for example to one platform or one app version.
6. Export the matching table when you need the numbers elsewhere, or use Continue in Drill to keep the same scope in an ad-hoc query.

The scope is kept in the URL, so a filtered Overview can be shared as a link. When a scope matches many views, the sections describe the top matches by view count and say so.

FAQs

Why is bounce rate empty for some views?

Bounce rate needs landings. A view that never starts a session has no landings and therefore no bounce rate.

Why do daily Profiles not add up to the monthly total?

Profiles are unique per bucket. The same profile seen on five days counts once in the monthly value.

Why did a view disappear?

It was probably renamed in the SDK, so its history continues under the new name, or it was deleted in Manage Views. Check Movers for a new view with a similar name.

Why is Avg. scroll empty or zero?

Scroll depth is reported only by the Web SDK. For web apps, make sure scroll tracking is enabled in the SDK.

Can I see who viewed a screen?

Yes. Open the view in Glance and use Continue in Drill to list the profiles behind the numbers and what else they did.

Do views work without sessions?

Views are recorded on their own, but landings, exits, and bounces need session tracking to know where a session started and ended.