Skip to main content

​
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. 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. App-level privacy notices still belong under App Settings → Privacy when you publish one.