Reviews
Reviews are the anomalies dzbot found that a person still has to judge. The system can tell you that two accounts share a browser, or that somebody linked a Discord account created last week — it cannot tell you whether that is a cheat, a household, or a coincidence. That decision is yours, and this page keeps it.
Navigation path:
Server Admin→Reviews
Access requirements
| Right | What it unlocks |
|---|---|
admin.reviews.view | See the reviews that touch this server |
admin.reviews.decide | Work the queue: take a case, add a note, link tickets, resolve it |
A review belongs to the organization, not to one server: it is about people, and two servers must never reach two different verdicts about the same people. You see the reviews where at least one of the accounts plays on your server, and the decision you record settles the matter everywhere.
What produces a review
Reviews are produced while the organization has at least one server that is paid or inside its trial. Without one, the server logs keep importing — nothing is lost — but no review is opened.
Multi-account
Two or more accounts share a browser profile or an address, as seen by the web app when their owners signed in.
Game devices do not produce a multi-account review. Some device links were entered by a moderator who had already worked out that the accounts belong together, and a review would hand them their own conclusion back; the rest come from an older DayZ build's server logs, and DayZ no longer reports a hardware id at all. Either way they are handled on each player's own page rather than here. They do produce the next kind of review, which asks the opposite question.
Fresh account
Somebody linked a Discord account that was created shortly before. This is the check many teams run by hand against ban evasion: a banned player comes back with a new Discord account, links it, and carries on. The account's age comes from the Discord id itself, so it is exact and needs no lookup.
Account sharing
Two accounts that used the same game device were online at the same moment.
Where the multi-account check asks is this the same person, this one starts from the answer: two accounts on one machine are normally one player, and one player cannot be in two places. If both are in the game at once, somebody else is on the second account — the account was lent out, sold, or handed to a friend to dodge a ban.
The connection runs through devices and nothing else. Browser and address links are left out on purpose: a household shares an address, and a household plays together all evening, so those would produce nothing but noise here. The link is also chained — if A and B shared a machine and B and C shared another, all three are treated as one person.
The evidence is not "their sessions overlapped". Every few minutes your game server writes down everybody currently connected, and the review counts how often both accounts stood in the same list. Two accounts in one list were online in the same second; there is no grace period to argue about, and it reads back to a player in one sentence. A crashed session that looks online for another quarter of an hour — the usual way this kind of check goes wrong — cannot reach the threshold.
The case shows every sitting with the time, the proven duration and how many lists it rests on. The duration is a floor, not the length of the sitting: it spans the first shared list to the last, and both were online before and after.
When the two accounts were never on the same machine — they reached each other through a third account — the case says so. Check which account links them before you act.
The check starts from the day it is switched on and only looks a few days back, so a server that has been running for months starts with an empty queue. Ask us to run the catch-up if you want the ones that already happened: it reaches back as far as the logs go and opens them all at once. Those cases are opened without triggering actions — a sitting from March must not set an automatic ban off today — so they simply wait in the queue for somebody to look.
Device switch
One account switched to another on the same device — a second account played on one console, often one nobody registered. It is its own review type, apart from multi-account: a browser or an address shared by two registered accounts is a different finding from an in-game second account, and teams follow them up and punish them differently.
On PlayStation and Xbox, DayZ makes the next account on a device wait before it can play when another account was just on the same server from that device: 5 minutes after the first switch since the server's last restart, 15 after the second, 30 from the third on. The wait ends to the second one step after the previous account left, so dzbot reads it from the server log and works out which account was played before.
- When exactly one account fits, that is strong evidence and opens a review by default.
- When several accounts left at that moment, each is weak evidence — friends logging off together fit just as well — and only opens a review with ambiguous device switches switched on (see Settings).
- Accounts already linked to the same device in device management are left out: the check exists to find the ones nobody registered.
- An account coming back after its own logout is not a switch and never counts.
- The game only does this on servers where the multi-account protection is on (the default in the Nitrado panel), and only within one server: switching to another server carries no penalty.
The case lists every switch: who came after whom, when, how long the wait was, the penalty step and the server. A new switch reopens a case that was already resolved. The same links also appear on each player's page under Possible alt accounts, as a Device connection.
Working the queue
The list is a queue: one line per case, showing what it is, who is on it and how old it is. Opening one gives you the whole case in a panel — and its own address, so a review can be linked to from a ticket, from Discord or from a colleague.
A queue line names the channels involved — browser, IP — and nothing more. Which account hangs on which piece of evidence is a question for the case, not for a line you are scanning past.
Opening one draws it. The accounts are chips, and between them sits one labelled connection per channel: they share a browser profile, or an address, or both. Several shared addresses between the same accounts are one connection, not five lines — the individual addresses are in its detail. Where more than two accounts sit on the same value, the lines meet in a small hub carrying the label, so a browser profile shared by four accounts is one statement rather than six lines. Colour and line style say which channel it is; the legend under the drawing says how much each is worth.
Pointing at a chip or a connection puts the rest of the case in the background: point at an account and its own connections and the accounts on the other end of them stay lit, point at a connection and the accounts sharing that value stay lit. In a case with a dozen accounts that is the difference between a tangle and an answer. Keyboard focus does the same as the pointer.
Clicking a connection's label opens what is known about it: how many values it stands for, the observation period of each — and for an address, the internet provider and the country. You never see the address itself, and never a place more precise than the country. The provider is the useful part: two accounts on Deutsche Telekom AG is a household, two on a commercial VPN exit is two strangers who happen to use the same VPN.
Clicking an account chip shows its Discord identity and opens their page on this server, where their playtime, bans, notes and balance are. An account that belongs to the review but does not play here leads to their organization page instead.
Reviews recorded before this display existed keep their old evidence pills. Their record is only rewritten when the case is reported again, and some never will be.
Taking a case
Several people work this queue, so a case can be taken. Taking one marks it in progress under your name, and everyone else sees at a glance that it is being handled. Hand it back and it returns to the queue; take over and the history records that too. You can also set in progress or open by hand, for a case that is waiting on an answer rather than on you.
The queue shows open and in-progress cases together — taking a review must not make it disappear from the list you took it in. Unclaimed cases sort first, oldest first within that.
When a decided review reopens, its owner is cleared. Whoever settled it decided a smaller case than the one now in front of you, and a reopened case with somebody's name still on it looks handled.
Tickets
A review can produce tickets, and the link holds in both directions: the review lists them, and each ticket names the case it came from. Create one straight from the review — leave the player out and it stays internal, which is what an alt-account check usually needs to be. Existing tickets can be attached from the ticket's own page.
A ticket on another server of your organization stays visible but is not clickable from here, and a ticket in a support level you cannot see keeps its number and withholds the rest.
Resolving
A review is closed with a note, and the note is required — it is the entire record of the outcome. Write what you checked and what happened: "Brüder, gleiche Wohnung, geduldet", "gebannt, hat sich nicht gemeldet", "Ticket #7KQM geklärt, nichts dran".
There is deliberately no list of verdicts to pick from. An earlier version offered three per type, which assumed the reviewer already knew the answer at the moment they looked — in practice they open a ticket or ban precautionarily and only learn it later. And a growing catalogue of review types would each need its own vocabulary, with "confirmed / not confirmed" fitting almost none of them.
Everything that happens to a review — opened, taken, ticket linked, resolved, reopened — stays in its history, including resolutions that were later superseded. Resolving an already-closed review is allowed and adds a new entry rather than overwriting the old one.
When a review comes back
A decided review reopens only when an account joins it that you had not seen when you decided. The same evidence turning up again does not reopen anything, and neither does more of it about the same people — you already looked at those.
When it does reopen, the new account is marked, so you can see what changed instead of reading the whole case again.
Account sharing is the exception, because its evidence is of a different kind. A shared browser is a standing fact — seeing it again tomorrow is the same fact, not a second one. Two accounts caught online together is an event, and a second one after you decided is somebody doing again what you thought you had stopped. So every sitting that happens after your decision reopens the case.
Accepting a combination
Which is wrong for brothers. When you close a case you can tick stop reporting this combination, and those accounts stop producing account-sharing reviews for good.
It covers exactly the accounts on the case at that moment. If a third account later turns up in the same net, nobody has judged that one, so the case opens again — an accepted household must not become a hiding place.
Accepted combinations are listed at the bottom of the review queue, with who accepted them and why, and can be revoked there. Revoking does not reopen the old case; it only means the next sitting is reported again.
Automating around reviews
Ready-made actions
The marketplace has one action per review type — Multi-Account Review Automation, Fresh Account
Review Automation, Account Sharing Review Automation and Device Switch Review Automation. Install the ones you want from the
Marketplace tab under Admin → Actions.
Each is built from independent steps. Every step has its own switch and settings, and none changes what another one does; a step's settings only appear once it is switched on:
- Ban the affected players — reason, length and org-wide scope are settings.
- DM the affected players on Discord.
- Ticket — one per player with the player in it, or a single internal one.
- Close the review, with a note of what the action did, so the queue only holds cases a human still has to look at.
- Post to a Discord channel — every case, with what the action did.
To watch the cases for a while before the action acts, switch off ban, DM, ticket and closing and only set the channel.
Who counts as affected depends on the type. For multiple accounts you choose between all accounts (the default) and all but the oldest, where the oldest Discord account — usually the main account — is spared even if it plays on another server. By default only a shared browser triggers it, not a shared address alone. It never runs on device switches — those are their own review type. For account sharing it is the registered owner. Device switches offer the same choice as multiple accounts and by default only act on strong matches, where exactly one account fits; a weak match, where several accounts could have been the one before, needs its own switch. On a reopening, only the account that just joined is affected.
Writing your own
Opening and reopening a review writes a review_opened log event, which means Actions
can react to it: ban automatically on a strong match, post to a Discord channel, whatever your team
needs. One event covers both cases — reason is created or reopened — so a single action covers
"somebody has to look at this".
Each account in the event carries is_new, so an action can act on just the account that caused a
reopening rather than the whole group that was cleared last week, and is_oldest, which marks the
oldest Discord account of the whole review.
What details holds depends on review_type:
multi_account:tier(e.g.browser_new),evidence,linksfresh_account:accountCreatedAt,accountAgeDays,maxAgeDaysaccount_sharing:observations,provenMinutes,incidentCount,lastIncidentAt,incidents,sharedDevicesdevice_switch:strength(strongwhen only one account fits,weakwhen several did),switchCount,lastSwitchAt,switches,links
An action can also open a ticket and attach it to the review that triggered it, so automatic work lands in the same place as the manual kind:
server.create_ticket(
"Check alt account: " .. data.accounts[1].username,
"Review " .. data.review_id .. " opened (" .. data.reason .. "). " .. data.url,
nil,
data.review_id
);
If the review has since merged into another one and its id no longer exists, the ticket is still created and the action carries on — only the link is skipped, with a note in the action log.
Once the action has settled the case, server.close_review(data.review_id, note) closes it with the
note as the outcome, shown as closed by System. The event reaches every server the accounts play on,
so the call is safe to repeat: only the first one closes the review.
Settings
Under Organization → General you can configure which matches produce a review, how young a Discord
account has to be to trigger the fresh-account check (90 days by default; 0 switches it off), and how
many shared online lists account sharing needs before it opens a case (3 by default, roughly a quarter
of an hour; 0 switches it off).
Browser matches open a review by default; IP matches are off: about half of all matches and almost never a finding, since flatshares, families, mobile networks and VPNs all share addresses. Switching both off turns multi-account reviews off entirely.
Device switches open a review by default when exactly one account fits; ambiguous device switches — several accounts left at that moment — are off. Every review type can be switched off.
Where else reviews appear
A player's own page shows the reviews they are part of, in the moderation timeline next to notes and restrictions. That is usually where you meet one: while deciding something else about that player.
The organization-wide overview
Organization → Multi-account detection shows every case in the organization at once, whether or
not it became a review. It exists because a review only opens for the tiers you configured; the
overview holds the rest, and it is the place to work through them in one sitting. It needs
org.linked_accounts.view.
The cases are drawn the same way as in a review, and grouped by what the evidence is worth — a shared browser on top, a shared address alone below it. Game devices are not part of this picture at all — they are handled on each player's own page, where the device list names them and everyone else seen on them. Three things are worth knowing when reading one of these pictures:
- The label sits on the connection, and says which channel produced it: browser or address. That is the single most important thing on the card, because the two are worth very different amounts.
- A hub means one value, not several. Lines meeting in a small dot are all on the same browser profile or address.
- A highlighted account holds the picture together. Remove it and the card falls into separate pieces — which is exactly the case where two accounts are not really linked to each other at all, only to a common third party.
A case with more than ten accounts is listed rather than drawn. At that size no arrangement stays readable, and the same details are one click away on each row.