Participant Data Analytics

1What it is

Genesys Cloud flows write their working state into participant data — verification flags, lookup results, caller intents, bot outcomes, free-text summaries. Each conversation carries that map to its grave, and almost nothing in the platform lets you analyse it in bulk. Participant Data Analytics treats the participant-data map as a first-class dataset:

• Catalogue — every key written in a range: coverage %, class (boolean / enum / text-id), distinct values, top value buckets, first/last day seen — plus schema drift: keys that newly appeared or stopped being written inside the range (a flow-change fingerprint).
• Timeline — pick a key, see its value mix stacked per day (per hour for short ranges), with a plain-English trend verdict on a target bucket: “Account Verified = true: 30% → 62% of calls (improving, +1.1 pts/day)”. If a flow records whether an account was verified, you learn whether that has improved or decayed over time — the question this app exists to answer.
• Movers — a large-sparkline board: your own watchlist of keys, or (with nothing picked) every eligible key auto-ranked by how far its target share moved.
• Conversations — the filtered calls themselves, with their full raw maps, a must-carry-key quick filter and up to 500 rows per page.
• Key rules — tame volatile key names (a flow stamping a timestamp into the key itself) by ignoring or folding whole families, reversibly.
• Explorer filter — stackable conditions over participant data and routing context (media, direction, queue, disposition, division), applied to every tab and saveable as views.

The accumulating warehouse

Unlike a report you re-run, Participant Data Analytics keeps what it harvests. Each conversation is stored once, keyed by org; coverage intervals record which time ranges have been fetched; harvesting a new range fills only the gaps. Day by day the corpus grows — and because Genesys retains conversation detail data for the life of the contract by default (or up to your organisation’s maximum interaction data retention time, never less than 90 days), you can backfill history and then keep a small daily harvest running to stay current. Details-job data is populated nightly, so the most recent day may lag. Timelines get longer for free.

2Quick start

1. Sign in — region + OAuth client-credentials Client ID/Secret. The client needs analytics:conversationDetail:view; grant routing:queue:view and routing:skill:view too so ids resolve to names.
2. Harvest — pick a UTC day range on the entry screen and press Harvest range. Progress streams live; already-covered time is never re-polled.
3. Analyse — click two days on the coverage calendar (or use the date pickers) and press Analyse range. Start on the Catalogue, then click any key for its Timeline.
4. Iterate — add filters, pick a movers watchlist, set key rules for junk families, save the filter as a named view, export the lot to Excel.

No credentials to hand? The demo org (“Meridian Retail Group”, a fictitious demo organisation — ~1,950 synthetic conversations over 30 days) exercises every feature signed-out — including planted improvement/decay stories, schema drift and a volatile key family for the key-rules workflow.

3Harvesting & coverage

How a harvest runs

1. The requested range is compared against the org’s coverage intervals; only the gaps are fetched. The trailing 6 hours of covered time are re-scanned for stragglers (conversations that ended after the last pass) — re-saves are skipped, so nothing double-counts.
2. Each gap is split into one-day windows. Per window the app submits one org-wide asynchronous analytics details job (no flow filter — every conversation, all media), polls until Genesys compiles it (up to ~15 minutes), then cursor-pages the results 1,000 at a time.
3. Each conversation is reduced to: full participant-data map (all participants merged, caps in §7), started-at, media types, direction, division ids, first ACD queue (resolved to its name) and a coarse disposition — agent (handled), queueAbandon, or contained (never reached a queue).
4. Rows are saved (existing conversation ids skipped), the per-day aggregate is updated, and the window is added to coverage — unless it hit the 100,000-conversation cap, in which case it is stored but deliberately not marked covered so a re-run can pick up the remainder.

One harvest runs per org at a time; requests are capped at 92 days (run consecutive harvests for longer histories). Progress is reported live and survives a reload — you can navigate away and come back. Abort stops cleanly; already-saved windows are kept and stay covered.

The coverage calendar

Two months side-by-side (last month + this month, with ‹ › paging into history). Days shade by state — covered, partially covered, uncovered — with per-day conversation volumes. Click one day for a single-day range, a second day to span; the pickers and calendar stay in sync. The header shows total stored conversations for the org.

4The analysis workspace

Everything above the tabs is shared state: the date range (Apply), the Filter builder and its condition chips, Key rules, Saved views and Export .xlsx. Range, filter, active tab, selected key/target, share basis, movers watchlist and conversations settings all live in the URL — every analysis view is bookmarkable and shareable.

Catalogue

One row per key seen in the (filtered) range. Columns:

• Class — BOOLEAN (every value normalises to true/false), ENUM (≤12 distinct values), or TEXT/ID (high-cardinality: ids, phone numbers, free text).
• Coverage — % of conversations in range carrying the key. Distinct — distinct raw values. Active — first → last day the key was written.
• Top values — the biggest buckets with counts, “(not set)” included.

The search box filters keys; keys sort alphabetically (the Movers board does the surfacing job). Above the table, schema drift banners list keys that appeared or stopped inside the range — click through to their timelines. Clicking any key row opens its Timeline.

Timeline

A stacked share chart (~80% page width) of the key’s value buckets per day — per hour when the range is ≤3 days. Controls:

• Target — the bucket the verdict tracks. Auto-picked (success-toned bucket for booleans and result-style values, else the top value); click any legend bucket to re-target.
• Share basis — % of all calls (default; “(not set)” visible) or % of calls carrying the key, which rescues low-coverage keys whose not-set mass would drown the values.

The verdict line reads e.g. “Account Verified = True: 37.3% → 53.3% of calls (improving, +0.9 pts/day)” — see §8 for exactly how that’s computed.

Movers

Large sparkline cards (two-up on wide screens): area fill, gridlines, a 0–max% scale, the delta badge and volume. Two modes:

• Watchlist — “Add a key to watch…” builds your own list (chips, in pick order, kept in the URL). Picked keys bypass all eligibility thresholds — sparse and high-cardinality keys included; a picked key with no data in range greys out rather than vanishing. Up to 24 keys.
• Auto — with nothing picked: every eligible key (boolean/enum, ≥2% and ≥10 conversations coverage) ranked by |Δ share| × √volume, top 16.

Click a key name to open its full Timeline.

Conversations

The filtered calls themselves. Must carry key narrows to conversations where a chosen key is set (composing with the main filter); Per page offers 25 / 50 / 100 / 250 / 500. Each row shows started (UTC), media, direction, queue, disposition and key count; clicking a row expands the full raw participant-data map with the selected key highlighted. Both controls persist in the URL.

5Filters & saved views

The Filter builder stacks conditions over two field types:

• Participant data — any key in the range’s catalogue.
• Routing context — media, direction, queue, disposition, division.

Operators: is set, is not set, =, ≠, in (one of several values), contains (case-insensitive substring). Multiple conditions combine with match ALL or match ANY. Conditions render as removable chips; the whole set is URL-encoded JSON in the filter query parameter — shareable like everything else.

Saved views store a named filter per org (the demo keeps them in memory). Save the current filter from the views menu; applying one replaces the active filter. Filters apply to every tab and to the Excel export, and the header always says when a filter is active.

6Key rules — taming volatile keys

Some flows write the timestamp into the key name — EnteredAccountNumber_2026-08-12T05:51:40.685Z — minting a brand-new key per call. Left alone, such a family floods the catalogue, the key dropdowns and schema drift (every member “appears” and “vanishes” the same day). Participant Data Analytics detects these families automatically (shared stem + trailing date/timestamp/long-digit suffix, ≥3 members) and shows an amber “volatile key family detected — review” chip.

A key rule is a case-insensitive glob pattern (* wildcard, e.g. EnteredAccountNumber_*) with one of two actions:

• Ignore — matching keys disappear from the catalogue, every dropdown, drift, movers and exports.
• Fold into a stable key — matching keys are renamed (EnteredAccountNumber_2026-… → EnteredAccountNumber), rescuing the signal: the family becomes one real key with a coverage timeline. For timestamped families this is usually the better choice — the engineer’s bug is in the key name; the events are real.

Rules apply in three layers, so there is nothing to remember to run:

1. Read time — stored data cleans up the moment a rule is saved.
2. Write time — future harvests maintain their aggregates rule-applied.
3. Rebuild — any rule change rebuilds the per-day aggregate from the raw rows (tens of milliseconds per 20k conversations), so drift and fast timelines agree immediately.

The one-click suggestions on a detected family pre-fill the fold (recommended) or ignore rule. Rules are per-org; the demo supports them in memory for the full workflow.

7Names, buckets & caps

GUID → name resolution

Flows routinely write routing skill ids (and sometimes queue ids) into participant-data values. Participant Data Analytics keeps a per-org lookup — refreshed from /api/v2/routing/skills and /api/v2/routing/queues at every harvest, and primed on the first signed-in catalogue read for orgs harvested before the lookup existed — and translates values that are exactly one GUID (or a short separated list of GUIDs, all of them ids) into names: “Billing Enquiries” instead of a hash. Free text containing an embedded id is never rewritten; unknown GUIDs (contact ids, script ids…) pass through untouched. New harvests store names at rest; older rows translate at read time.

Value bucketing

• Booleans — true/yes/y/1 and false/no/n/0 normalise to True/False.
• Enums — ≤12 distinct values → one bucket per value.
• High-cardinality — top 10 values + Other.
• “(not set)” — always a bucket, so coverage is always visible.
• Value labels clip at 60 characters for display.

Capture caps (defensive only)

Per conversation: at most 150 keys, values clipped at 300 characters (aggregate rows at 80). In the per-day aggregate, a key that exceeds 24 distinct values collapses to a (set) sentinel — account numbers can never explode the aggregate — while raw rows keep everything for filtered analyses and drill-downs. Nothing is redacted.

8Statistical semantics

Trend verdict (improving / decaying / stable)

Per time bucket the target share is computed against the chosen basis (all conversations, or conversations carrying the key). Two measures combine: the mean share of the first half of the range vs the second half (the headline “X% → Y%”), and a least-squares slope in points/day. The call is stable when |Δ| < 2 pts and |slope| < 0.15 pts/day; otherwise the sign of Δ decides improving vs decaying. Buckets with zero denominator are skipped; fewer than two usable points → no verdict.

Movers ranking (auto mode)

|Δ pts| × √(conversations carrying the key) — a 5-pt move on 4,000 calls outranks a 20-pt wobble on 40. Boolean/enum keys only, coverage ≥ 2% of range and ≥ 10 calls. Watchlist mode skips all of this — you asked for the key, you get it.

Schema drift

From the per-day aggregate: keys whose first day is after range-start + 1 day slack (“appeared”), or whose last day is before range-end − 1 day (“stopped”), with ≥5 total occurrences. The slack stops partial first/last days from false-positiving. Top 12 each way.

Share basis

% of all calls answers “how often does the org get this outcome?”; % of calls carrying the key answers “when the flow records it, how often is it X?” — and hides the “(not set)” band, since its denominator excludes those calls. Verdict wording follows the basis.

End-of-call state

The analytics record carries the participant-attribute map as it stood when the conversation ended. A flow that writes Verified=false then overwrites with true contributes one true. Mid-call history is not available from this API.

9Genesys endpoints & permissions

OAuth client permissions: analytics:conversationDetail:view (required) · routing:queue:view and routing:skill:view (optional — without them those ids display as GUIDs).

10Storage, privacy & security

• Warehouse — harvested conversations (with their raw participant data), coverage, the per-day aggregates, the name lookup, key rules and saved views are kept in the app's own private store.
• Owner scoping — everything is keyed to the org credentials that harvested it. Different orgs never see each other’s data; the same org signed in again sees its own warehouse.
• Credentials — credentials are held encrypted on the server and never sent to the browser; your Client Secret is never written in plain text.
• No redaction — participant data is stored verbatim (deliberate: analysts need real values). The mitigations are owner scoping and a strictly read-only Genesys client. Treat the harvested data and exports with the same care as call recordings.

11Technology

• Web application — a server-side, read-only Genesys Cloud client with live harvest progress and Excel exports.
• Browser interface — state lives in the address bar, so every analysis view is a shareable link; the timeline and sparklines are drawn directly in the page.
• Analytics engine — a per-day aggregate maintained as data is harvested keeps unfiltered catalogues and timelines instant at any corpus size; filtered analyses scan the stored conversations and are cached per range + filter.

12Troubleshooting

The harvest log says a window hit the conversation cap.

A single day exceeded 100,000 conversations; the day is stored but not marked covered. Harvest it again to pick up the remainder.

Queues or participant-data values show as GUIDs.

Grant routing:queue:view / routing:skill:view to the OAuth client. The name lookup refreshes on the next harvest — or simply reload the catalogue signed-in, which primes it and retro-translates stored values.

The catalogue is flooded with timestamped keys.

That’s a volatile key family — accept the amber chip’s suggestion (fold, usually) in Key rules. See §6. And tell the flow’s author: the timestamp belongs in the value, not the key.

A key’s timeline is mostly “(not set)”.

The key isn’t written on those conversations. Switch the share basis to “calls carrying the key”, or read the coverage story together with schema drift — a key that stopped being set will show there.

Trend verdicts differ between filtered and unfiltered views.

They should — filters change the population. The header says when a filter is active; exports carry it on the About sheet.

403 warnings right after granting a permission.

Genesys token scopes are minted at sign-in. Sign out and back in so the client credentials pick up the new permission.

“No such key in this range/filter.”

The key exists in the org but not inside the current range + filter (or a key rule now hides or folds it). Widen the range, relax the filter, or check Key rules.

Everything 401s mid-session.

The session ended after a period of inactivity. Sign in again — the warehouse is untouched; coverage and views are keyed to the org, not the session.