Skip to main content

Player observability

This page explains how admins can observe player behavior from the player detail page.

Data source note: sessions, routes, contacts, and embedded logs depend on imported server logs. For freshness and delay behavior, see Logs import concept.

Navigation path:

  • Server Admin -> Players -> Player details

Access requirements​

Opening the dossier needs admin.players.view. Each observability tool needs its own right on top:

  • admin.players.see_alt_accounts — the device list and the accounts sharing those devices
  • admin.players.manage_devices — linking or disconnecting a device
  • admin.players.create — creating a new player profile on an existing device
  • admin.logs.view — the raw log feed, and the data routes are drawn from

Everything positional sits behind the master switch admin.players.see_position plus its facet:

  • admin.players.see_routes — movement routes and the map
  • admin.players.see_contacts — the "Seen with" list
  • admin.players.see_places — saved places and subscription spawn coordinates

A denied see_position is absolute; it is checked outside the rights map. These four were deliberately excluded from the rights backfill, so a group that only ever held view has to be granted them by hand — see Player details.

Routes and the raw feed also need at least one non-empty in-game name in the current player or device context.

If a section is missing rather than empty, it is a missing right: sections you hold no right for are not rendered at all.

Where the tools live​

The observability tools are spread across two spokes of the player dossier:

  • Identity — devices and possible alt accounts
  • Presence — time played, session calendar, routes, contacts, raw log feed

Both are reached from the player hub. They are real URLs, so you can link a colleague straight to the view you are looking at.

The device list shows every device ID linked to this player and every player profile attached to each device, including alt accounts, with a shortcut into each profile.

Across servers: a device link holds on every server of your organization. Accounts linked on one server show up as linked here too, and accounts that never joined this server are listed with the server they play on.

What it is good for:

  • spotting account clusters that share one device
  • finding likely alt accounts, including ones only active elsewhere
  • checking whether suspicious behavior shows up across several profiles

Actions: disconnect a player–device relation (admin.players.manage_devices), or create a new player profile on an existing device (admin.players.create).

The accounts linked by web-tier signals — a shared browser profile, a shared address — are drawn separately in the player's identity area; how to read that picture is described in Player details. Devices are deliberately not part of that drawing; they are handled here.

Time played and the session calendar (Presence)​

Presence opens with a day-by-day strip of time played inside the current window. Open calendar expands it into a weekly session calendar, one column per day, built from sessions on every device in this player's context.

  • the current player is the primary context
  • related accounts on the same devices appear alongside
  • clicking a related account's session opens that account's dossier

This is the tool for overlap analysis: who was online at the same time, on which device.

Two behaviors worth knowing: the context is assembled from both device links and recorded session history, and a session with no valid end timestamp is drawn as a short placeholder block.

Routes (Presence)​

With see_position and see_routes, each day in the Presence strip lists the routes recorded for it. Opening one draws the movement on a map with start and end markers and coloring along the path.

The route window follows the dossier's time window. Use it to trace where a player moved, to spot repeated patterns, or to line movement up against a report.

Seen with (Presence)​

The contact list shows players who were repeatedly near the target. The model is fixed and deliberately strict:

  • compares PLAYER_ONLINE_PING events at the same timestamp
  • a rolling window of 14 days
  • a radius of 10 meters
  • at least 5 encounters before a contact is listed
  • at most 15 contacts
  • player identities on the same device are excluded

Per contact you get the name, the estimated shared playtime (derived from 5-minute ping steps) and the first and last time they were seen together. This is how regular co-play partners and repeated associations become visible.

Raw log feed (Presence)​

Open raw log feed shows the log events for this player and everyone sharing a device with them, pre-filtered. It needs admin.logs.view. For the wider query tool, see Log Explorer.

Working an investigation​

  1. Start in Identity to map the account relationships.
  2. Use the session calendar to confirm overlap windows.
  3. Use routes to look at movement inside those windows.
  4. Use Seen with to confirm repeated proximity.

Together these carry far more weight than any single view on its own.

Player impersonation​

Admins with players.impersonate_player can open the player view as that user. Use impersonation to validate what the player can see in the shop (missing buttons, opt-out warnings, feature access).

While impersonation is active, a one-line info bar is shown at the top in both the shop and the admin panel. The bar shows the currently impersonated player context and provides an Exit impersonation link in the top-right corner. The bar also uses small icons for quick visual recognition (impersonation context + exit action).

Exit behavior:

  • when impersonation is started from the player list, the exit link returns to the admin page where impersonation started
  • if no valid admin return page is available, exit falls back to the shop start page