Users, active users and retention

Lampwick counts the signed-in users of your app from the requests and exceptions it already receives: who was active on which day, how many came back the weeks after, and whether an error made them leave. There is nothing to install beyond the integration you already have.

Requirements

• Your app sends the signed-in user with its requests:
  • OpenTelemetry (Node, Python, Go, Java, .NET, Ruby): set enduser.id on the request span, as in the Node.js guide.
  • HTTP ingest: send user on each record.
  • Laravel: the lampwick/laravel package sends the authenticated user for you.
• Any plan. How far back it goes depends on the plan (see How long it is kept).

Active users

Open Users in the sidebar and choose Active users.

• Today, Last 7 days and Last 30 days count the users active in that window (DAU, WAU and MAU).
• Stickiness is the average number of daily users over the last 30 full days, divided by the users active in those days. 20 % means a typical user comes on 6 of 30 days. It shows once Lampwick has 30 full days of activity.
• The chart shows each day (30d, 90d) or week (12m) split into New users, first seen that day or week, and Returning users. Deploys show as dotted lines, so a drop after a release stands out.

A user is active on a day when your app sent a request or an exception of theirs that day. Days are UTC days.

The Overview shows the users active in the last 30 days next to the users of the selected range.

Retention

Users → Retention groups users by the week (Monday to Sunday, UTC) Lampwick first saw them. Each row is one of the last 12 weeks; each column the share of that group active in week 0, 1, 2 and so on after it.

• In the week counts users active in that week. Use it to see how often people come back.
• In it or later counts users active in that week or any later one. Use it to see how many are still around at all.
• The route menu limits the table to users who requested one route, such as POST /checkout. It looks at the newest 200,000 requests of that route within your plan's record retention, so on Free (3 days of records) it finds only recent users of the route.

The current week isn't over yet: each row's last value is striped and can still grow. Rows of fewer than 10 users are faded, because one user moves their shares a lot. A user's first week is the first one Lampwick still holds. In the week the kept data starts (marked *), users from before count as new.

Impact of an issue

An issue's page shows Impact on users when the exceptions carry a user:

• came back: of the users who first hit the issue more than 7 days ago, how many were active again within 7 days. Next to it, the usual share for your project: for each user active in the 30 days before last week, the share of their active days followed by another visit within 7 days, averaged over those users. Every user counts once, so people who use the app daily don't pull it up. On big projects it comes from a fixed sample of about 50,000 users. When the issue's share is more than 15 points lower, it shows in red: the error may drive people away. With fewer than 10 such users it shows counts ("4 of 6 came back") instead of a percentage.
• Not seen since: users with no request or job since their last hit, most recent first, linked to their user page.

Under the occurrence, Before the error lists that user's last 20 requests and jobs up to the exception, with status and duration. The request it happened in is highlighted.

The Deploys page shows per deploy how many users hit an issue that started with it.

Erase a user's data

For a data subject request (GDPR article 17), open the user's page (Users → the user) and choose Erase this user's data in the danger zone. Lampwick then:

1. deletes their name and username, their activity (active days and counts) and their attempts at your funnels;
2. removes the link to them from their requests and exceptions, with the user, ip, headers and payload (request body) fields of those records.

The records themselves stay, anonymous, so request and error charts don't change; active users, retention and funnel steps no longer count the user. The funnels' daily totals and the user paths hold no user ids and stay as they are. Lampwick doesn't search free text such as exception messages, log lines or URLs for the user. If your app keeps sending data about them, it is stored again. The team's audit log records the erasure with a keyed hash instead of the user's id. With the API: DELETE /api/v1/projects/{pid}/users/{uid} (see the API docs).

IP addresses

By default Lampwick stores client IP addresses as your app sends them. To store less, open the project's Settings → Privacy and choose Shorten them before storing: IPv4 addresses keep their first three parts (203.0.113.77 becomes 203.0.113.0) and IPv6 addresses their first 48 bits. It applies to the ip of requests and OpenTelemetry spans and to addresses in request headers (X-Forwarded-For, Forwarded and the like), for records stored from then on.

How long it is kept

Activity per user (which days, and counts per month) is kept longer than records, because it holds no details of what they did:

Check that it works

Open Users → Active users. If it says "No signed-in users yet", open a request on a Requests page and look for a user in it. No user there means your app doesn't send one: check the requirements above.

The numbers include the current hour. Activity is added to the long-term store once an hour; requests that reach Lampwick more than an hour after they happened still show on the request pages, but not in these numbers.

API and MCP

getUserActivity, getRetention, getIssueImpact and getUser (its activity) give the same numbers, and are tools of the MCP server. Erasing a user is in the API only, not an MCP tool.