> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shieldlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Investigate a risky user
> Find a risky user in the analytics dashboard, see what it is linked to and why, and act on it in your backend.
This page describes the new analytics dashboard, which is rolling out to all accounts.
This tutorial follows one account from the Overview to your backend. You find the users that need a look, narrow them to one, read its user card, check the identification that set its band, and then act on the account in your backend. It uses the analytics dashboard and the History API, and it takes a few minutes.
## What you will learn
* How to find risky users and users with a High-Risk Event for any period.
* How to read a user card: its band, its High-Risk Events and the devices, visitors and IP addresses linked to it.
* How to read the same account through the History API and act on it at its next sensitive action.
## Before you start
* **The authenticated snippet on your signed-in pages.** Pass a hashed User HID with `checkAuthenticatedUser` on every signed-in page. Users, account-level risk and all four High-Risk Events are built on it. See [Identify signed-in users](/setup/snippet#identify-signed-in-users).
* **Access to the analytics dashboard**, and your domain's **Private API Key** for Step 5 ([API keys](/setup/keys)). No account yet? [Start Free](https://app.shieldlabs.ai/) with 5,000 identifications, one time, no credit card.
## Step 1: Find risky users
Open **Overview** and pick a period at the top, for example **Last 7 days**. Two panels answer the first question:
* **Users** splits the accounts active in the period into **Trusted**, **Risky users** and **High-Risk Event users**.
* **High-Risk Events** shows how many users have each of the four events, Multi-accounting, Account sharing, Impossible travel and Account takeover, at **Medium confidence** and at **High confidence**, counted for the users active in the selected period.
Select the arrow next to the user count at the top of the **Users** panel (its tooltip reads Explore users), or one of its tiles, to open the Users tab of Analytics.
## Step 2: Narrow the list
In **Analytics**, on the **Users** tab, narrow the list one of two ways:
1. **By event.** Open **Filters**, pick **High-Risk Events**, tick **Multi-accounting** and select **Done**. The table keeps the users with that event.
2. **By band.** Select the **Dangerous** band pill to keep the users with at least one Dangerous identification in the period.
A High-Risk Event is a separate axis from the band, so a user with a Multi-accounting event can be Trusted on every identification. Review an event on its own, and add the band pill when you want the users that are both. Each row shows the user's band, its identifications and how many devices, visitors and countries are linked to it; the user card in Step 3 shows the event and its confidence. Keep the combination with **Views** to open it again tomorrow.
## Step 3: Open the user card
Select a User HID in the table to open its [user card](/dashboard/entity-card). Read three things, numbered on the screenshot:
1. **The band**: the worst band of the user's identifications in the period. The band split under it shows how many identifications fell in each band, so one Dangerous identification among ten Trusted ones stands out.
2. **The High-Risk Event**: the pill names the event, and its colour gives the confidence, red for High and orange for Medium. These are the colours of the Dangerous and Suspicious bands, but the pill is an event, separate from the band.
3. **Linked devices**: open the counter to list every device the account used, each with the band of the account's identifications on it. Open a device to see every other account on it under **Linked accounts**.
Linked visitors and public IPs list the same way, each with a band, and each opens its own card. **Linked local IPs** lists the addresses the browser itself reported, with their identification counts; a local IP can differ from the public IP behind a VPN or proxy.
## Step 4: Check what drove the band
Scroll to **Identifications** at the bottom of the user card and expand the Dangerous identification (its Risk Score column shows the band). The expanded [identification card](/dashboard/identification-card) shows the Risk Score and each risk signal with its weight: here Anti-detect Browser (60) and Proxy (10) make 70, Dangerous.
Read a high Risk Score together with its named risk signals and the user's history. A real customer on a corporate VPN can reach the Suspicious band; the signals show why, and you choose the action for each case.
## Step 5: Act in your backend
High-Risk Events are available in the analytics dashboard, the API and webhooks. When you review one in the analytics dashboard, as in the steps above, act on the account: read it in your backend by its User HID, record your decision, and check that record at the account's next sensitive action. The Risk Score and risk signals of the identification remain the input at that action.
Read every identification of the account from the History API by `user_hid`. Reads use none of your included identifications.
```bash theme={null}
curl "https://account.shieldlabs.ai/api/v1/history/user_hid/a91f3c7e5b2d4086?limit=100&offset=0" \
-H "Authorization: Bearer sec_your_private_api_key"
```
In code, the `accountView` and `accountsBehindDevice` helpers from the [tutorials overview](/use-case#the-shared-helpers) roll the newest 100 identifications up into an account view like the one on the user card:
```js theme={null}
const account = await accountView('a91f3c7e5b2d4086');
// { identifications, worstBand, devices, visitors, publicIps, countries }
const sharedDevices = [];
for (const deviceId of account.devices) {
const accounts = await accountsBehindDevice(deviceId); // distinct accounts on this device
if (accounts > 1) sharedDevices.push({ deviceId, accounts });
}
```
[Read every identification of one account](/api/server-api#read-every-identification-of-one-account) covers paging with `offset`.
Store the account and the devices linked to it, with the reason you saw in the analytics dashboard.
```js theme={null}
// watchlist: a table in your datastore, keyed by User HID and Device ID
await watchlist.add({
userHid: 'a91f3c7e5b2d4086',
reason: 'Multi-accounting, High confidence',
worstBand: account.worstBand,
devices: [...account.devices],
});
```
At a payout, a promo claim or a signup bonus, check the incoming identification against your watchlist, next to its own Risk Score and risk signals. `waitForScore` and `band` are helpers from the [tutorials overview](/use-case#the-shared-helpers) as well.
```js theme={null}
app.post('/api/payout', async (req, res) => {
const userHid = req.user.hashedId;
const risk = await waitForScore(req.body.shieldlabsRequestId, 2000);
if (!risk) return res.status(202).json({ status: 'review' });
if (risk.user_hid !== userHid) return res.status(202).json({ status: 'review' });
if (risk.risk_score > 100) return res.status(202).json({ status: 'review' }); // 999 rate-limit marker
const flags = risk.detection_flags ?? {};
const signals = risk.signals ?? []; // null on the History fallback
if (await watchlist.matches(userHid, risk.device_id)) {
return res.status(202).json({ status: 'review' }); // you choose the action for each case
}
if (
band(risk.risk_score) === 'Dangerous' ||
flags.anti_detect_browser ||
signals.some((s) => s.name === 'browser_automation')
) {
return res.status(202).json({ status: 'review' });
}
return res.json({ status: 'approved' });
});
```
Choose the action for each case (allow, step up, review or block) in your backend. ShieldLabs stops fraud and abuse and helps block fraudulent and abusive traffic.
## Summary
* The Overview's **Users** and **High-Risk Events** panels show how many accounts need a look in the period.
* **Analytics** narrows them by event or by band, and the **user card** shows the account's band, its High-Risk Events and every device, visitor and IP linked to it.
* The **identification card** shows the risk signals and weights behind the band.
* In your backend, read the account by `user_hid`, record your decision, and check it at the account's next sensitive action.
## Next steps
Everything on a user, device, visitor or IP card.
The four events detected on your users, at Medium or High confidence.
Turn a reviewed event into an action in your backend.
The five identities and how they link.
Every risk signal with its weight.
Catch one person running many accounts at signup and at the reward.