Revvly
Docs
Guide

See how clients use your product.

Your product sends usage events, and Revvly shows them beside billing: who is active, which features each client uses and which clients are slipping. To send the events, see Send product events. For the limits, see Limits.

01What it shows

Product usage shows how each client uses your product, next to what they pay. Your product sends small usage events, such as a page was viewed or a report was exported, and Revvly counts them per client and per person. On a client you see who is active, how often, which features they use and how long a visit lasts. Across clients you see which features are used most. It needs the Product usage feature, which Revvly turns on for your workspace. Sending events is a developer task and is covered in the Send product events reference; this guide is for the people who read the results and organise the event names.

02Before anything shows up

Three things need to be in place. Your developers send events to Revvly with an API key that has the product events capability, which no existing key has until an admin adds it. Each event names the client it belongs to, or the user, so Revvly knows whose usage it is. And, to track in the browser, an admin lists the sites that may send events. Until the first events arrive the client’s Usage tab says there are no product events yet. Events are kept for 13 months.

Where
  1. Settings
  2. API Keys

Add the product events capability to the key your product uses.

03Read one client’s usage

Open the client and choose its Usage tab. Pick a period, Last 7, 14, 30, 60 or 90 days, and the cards compare it with the period just before. Active users shows how many of the client’s known people were active. Events is the total. Active days per user shows how often people come back. Value events counts events an admin marked as showing value, and Latest event says when anything last arrived. Below them are a weekly or daily trend, the most used events, the Feature set, a Sessions card and a list of every user. Days are counted in UTC and weeks start on Monday. Today is only partly counted, so changes against the previous period lean low until the day ends.

Where
  1. Clients
  2. a client
  3. Usage

04Read the feature set

The Feature set card groups what a client used by the feature flag, module or bundle each event name is tied to, with the number of events, the change since the previous period, the user-days and the active days. An event that is not tied to anything is not in it, so it is only as complete as the organising done in the next steps. Each feature also carries a health badge from the change in use. It is read from the overnight count, so it shows completed days only and updates once a day.

05Read sessions

A session is one person’s events sharing a session id, which the browser script sets and renews after 30 minutes of quiet. The Sessions card shows how many there were, the average length, the pages per session and the top pages with views and time on page. A session’s length is the time from its first event to its last, and a session with a single event is left out of the average. The card does not appear at all when no event carries a session id. Events sent for a whole client with no person named belong to no one, so they cannot be grouped into sessions.

06Open one person

Choose a person in the user list on a client to see their own days, top events and a timeline, newest first, with Load older events at the bottom. A person who appears for more than one client has a profile that lists every client they use. In a Support ticket, a Product usage section on the requester’s side shows their activity next to the conversation, when they are known to Revvly and have events. Workspace admins also see Erase events here: it removes every product event of that person across all your clients and cannot be undone.

Where
  1. Clients
  2. a client
  3. Usage
  4. a person

07Compare across clients

Product usage in the Clients menu ranks your clients and your features across the whole workspace for the last 7 to 90 days: active clients, events, value events, active days, and which features are used by how many clients. It is built overnight from completed days, so a new workspace shows nothing counted yet until the first overnight run after events arrive.

Where
  1. Clients
  2. Product usage

08Organise event names

The first time an event name arrives it waits under New. Open Settings, Product events and choose Organise to give it a readable Name and a Category, and to say what it Belongs to: nothing in particular, a feature flag, a module or a bundle, and which one. Tick Using this means the user got value from the product to count it as a value event. The drawer also shows how often it fired, the latest examples and the properties seen on it. Saving applies to every event of that name, old ones included, because the meaning is read when you look, never copied onto the events. Ignore sets a name aside so it is left out of the counts, and Restore brings it back. Reset on a Mapped name clears its organising. Only workspace admins can change any of this.

Where
  1. Settings
  2. Product events

Use the New, Mapped and Ignored tabs to filter, and the search box to find a name, display name or category.

09Let the documentation suggest

Suggest from documentation reads your own support knowledge base and proposes a name, category, feature and value flag for waiting events, with the reason and the pages it used. It looks at up to 15 events a run and does not ask again about the same event for a week unless you name it. A suggestion changes nothing: Accept maps the event as you would by hand, Adjust opens the drawer pre-filled so you can change it first, and Dismiss clears it and stops that event being suggested again. Each run uses AI and is counted in your workspace’s AI usage. Check feature documentation lists the features you track that your knowledge base never mentions.

10Track in the browser

Instead of sending every event from your servers, your product can load the Revvly script in the browser. Your own backend mints a short-lived token for the signed-in person, so the person and workspace are always the token’s, and an event naming someone else is refused. An admin must first list the sites allowed to send under Allowed sites, one per line, as a scheme and host such as https://app.example.com. A site that is not on the list is refused. The script records page views and the active time on each page, keeps a session, and strips ids from paths so a page is counted rather than a record. It can be switched off for one visitor, and it never sends a page title unless you ask for it.

Where
  1. Settings
  2. Product events
  3. Browser tracking

Save sites applies the list for the whole workspace.

11What is kept and what is protected

A property whose name looks like a credential, and any value that looks like an email address, a token or a card number, is replaced with [redacted] before it is stored. Events stay for 13 months. To remove a person, use Erase events on their page, or ask your developers to use the erase request in the reference. Each workspace can hold a limited number of event names: 2,000 that are not ignored and 10,000 in all. A browser can add at most 5 new names in one request, and none while 100 are still waiting to be organised, so a faulty script cannot flood the list. Who can see the raw properties follows your normal access rules.