wxrks Analytics runs on Metabase and gives every account a set of datasets (tables) covering projects, tasks, users, costs, and quality data. This article is a reference to what each dataset contains and what its columns mean — useful when you're building a custom Question, adding a Join, or creating a Custom Column and need to know which field to pick.
​
If you're looking for a walkthrough of the Analytics interface itself — requesting access, navigating default dashboards, adding filters, or building joins and custom columns step by step — see Analytics in wxrks instead. This article assumes you're already in a Question or Dashboard and need to know what a specific dataset or column represents.

💡 Who is this for? This guide is for data analysts and report builders who need to look up what a specific Analytics dataset or column represents while building custom Questions, Joins, or Custom Columns in wxrks Analytics.

Most datasets store date/time values as standard timestamps. A few raw event tables instead store time as epoch milliseconds — the number of milliseconds since January 1, 1970 — which Metabase can still filter and group on once you tell it the column is a date/time field.

Some datasets are pre-aggregated by month, with the period represented as a plain string like 2024-08 (YYYY-MM) rather than a full date. Account Metrics, described below, works this way.

Several datasets include columns holding structured JSON data — for example, a project's target languages or an account's custom fields. In Metabase these are queryable with standard JSON operators when you write a native (SQL) question.

Custom fields deserve a special note: wxrks lets accounts define their own custom fields on Projects, Organizational Units, Organizations, Users, Tasks, and invoices. Because every account's custom fields are different, they're stored as a JSON array on the base record rather than as fixed columns. To make them usable without knowing the field names in advance, Analytics exposes a matching *_custom_fields dataset for each of these (e.g. Project Custom Fields) that flattens the array into one row per field, with a key and a value column — join it back to the base dataset on its UUID to pull a specific custom field into a report.

Ref: PostgreSQL JSON functions and operators

These are the datasets most reports are built from.

Volume processed on the account, in characters, words, or tokens, broken down by month (YYYY-MM) and metric type.

Every user on the account, with their Organization and Organizational Unit associations, rates, and status. Use this when you need an account-wide view of users rather than one scoped to a single Organization or Org Unit.

The same user data as Account Users, scoped to a specific Organization instead of the whole account.

The same user data again, scoped to a specific Organizational Unit, and additionally including each user's role within that unit.

A log of account user access, including IP-derived location (city, country, coordinates). Access is logged in intervals — repeated activity from the same user within a short window is recorded as a single access event rather than one row per request, so this reflects session-level activity, not a row-per-click log.

Every Project on the account, with its status, dates, currency, cost, and language pair. A few columns worth knowing:

A log of every status transition a Project has gone through — who requested it (for example, who requested APPROVAL or DELIVERY) and when, including the previous and new status and any recorded reason.

Every tag associated with a Project, including its CI tag where applicable. One project can have multiple tags, so this dataset has one row per tag rather than one row per project.

Every file (resource) uploaded to a Project, with its type, name, and upload date.

The cost line items billed against a Project. The description column holds the name of the price applied to that line — for example, a row might show description: Words Translation 0% - 49%, match_start: 0, match_end: 49, unit_type: WORD, units: 250, cost_per_unit: 0.01, total: 2.50, meaning 250 words in the 0–49% match band were billed at $0.01/word under this account's pricing configuration.

Every Work Unit (a file within a Project, in a specific language pair), with word/character counts, cost, and savings. Where both words and net_words are present, the difference reflects how much of the file was already leveraged from Translation Memory during analysis. project_resource_id links back to the matching row in Project Resources.

Every Task in the system — who it's assigned to, its workflow step, dates, and status. When a payable_amount is present, it reflects what the assignee is being paid for that task, which is what makes profitability and margin reporting possible at the task level.

Review data recorded whenever content moves through a review step in a workflow — a fine-grained record of what was changed between the translator's and reviewer's versions, categorized (e.g. fluency, grammar, terminology) and scored.

A few more datasets are also available for less common reporting needs:

For the Analytics/Metabase interface itself — requesting access, default dashboards, filters, duplicating content, joins, and custom columns — see Analytics in wxrks.