> ## Documentation Index > Fetch the complete documentation index at: https://docs.genieforge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Product usage > See which pages and jobs people actually use, separate from Credit Usage, and let unused screens come back as Signals. # Product usage **Usage** shows how real people use a project after you invite them: which pages they open, which forms and jobs they finish, and whether a new person completes a first job. Open it from the project sidebar, next to **Signals**. That is not **Credit Usage** (the app-level page for Build vs Chat credits). GenieForge records this automatically. You do not name events or add tracking snippets. Preview as a role is excluded, so empty Usage usually means nobody has signed in as a real end user yet. Impersonate sessions are stored, but they do not count in Usage numbers, first jobs, or unused-page Signals. ## What you will see Pick 7, 30, or 90 days. * **Overview:** people, first jobs, returning people, and (when you have a public landing) landing visitors. Cards tell you what to do next: unused published pages, a first-job stall, the biggest journey drop-off, and counts since the last Publish. Unused-page cards open Preview and Signals. * **Pages:** ranked screens and host views such as chats, files, or billing, with views and unique people. * **Actions:** ranked tools, forms, tabs, filters, and row opens, with a Page column so the same job on two screens stays distinct. Opening a row is not a first job. * **Journeys:** three fixed funnels (grow from a landing, invite, and in-app), with drop-off between steps. Click a step to see who stopped there. There is no funnel builder. * **People:** named people in this workspace, with role, first job, last page, and a link to their Activity. * **Recent events:** recent usage events with names. You can open a person's session path of page slugs and in-page jobs (tab, filter, open), not a video. This tab is not the project **Activity** page (who viewed or changed a record). Apps with more than one workspace also have **Usage by workspace** at the app level (admin or owner). Dormant workspaces sit at the top. ## After launch After the first real week, open **Usage** and check: * Did anyone complete a first job? * Which published pages have zero views while other pages are busy? * Where does the invite or landing journey drop off? Unused published pages that sit in navigation while the rest of the workspace is busy can become **Signals** automatically (friction). Published tabs and filters that nobody uses on a page people *do* open can become Signals the same way. An empty table is not treated as an unused widget. A control that only appears for some roles, capabilities, or conditions is not treated as unused either. When people start using that page or control, that signal can resolve itself. See [Signals and in-app feedback](/usage-and-improvement/signals-and-feedback). New apps also send a **Weekly usage digest** on Mondays (people, first jobs, top page, one unused page). It stays quiet when nobody used the app. Turn **Product usage** or **Weekly usage digest** off under App Settings → Agent if you do not want collection or the email. ## Tenant owners in the portal If this project uses App Registration and the person is the workspace owner, the portal can show **Usage**: how your team uses this workspace (overview, pages, and people by role and last seen, without coworker names). **People** is the identified directory (name, email, role, last seen) for inviting staff and changing roles. Portal **Activity** is who viewed or changed a record (ids and slugs, not field values). Builders see the same Activity trail from the project sidebar (**Activity**, next to Usage). You do not need to open Preview or sign in as an end user. Preview traffic stays out of that feed. That page is not Usage → Recent events (session paths). A person on Usage → People opens their Activity, and a name on Activity opens that person on Usage → People. Other portal roles do not see Usage aggregates. Portal Activity can be granted to a custom role or to Admin in one project. ## Privacy Authenticated portal use is first-party operational telemetry of the app someone signed into. Public landings and intake forms keep a first-party guest id on the app host so Usage can connect a visitor to the person they become after they register, log in, or accept an invite. HIPAA-enabled apps do not keep that guest id on public pages. They still collect first-party Usage after sign-in (so you are not flying blind), keep events for a shorter window, and never send this data to a third-party analytics product. Properties are page slugs, action names, and role names, not emails, form values, row ids, or chat text. Guests do not get chat or a signed-in portal session. For the platform notice that covers end users, see the [End-User Privacy Policy](https://genieforge.ai/end-user-privacy). App-level privacy notices still belong under App Settings → Privacy when you publish one. ## Related * [Signals and in-app feedback](/usage-and-improvement/signals-and-feedback) * [Usage-Driven Development](/concepts/usage-driven-development) * [Launch checklist](/getting-started/launch-checklist) * [Credit usage in an app](/account/credit-usage)