Participant data: the busiest dataset in your Genesys Cloud org, finally analysed

Picture the contact centre manager of a retail service line at 08:55 on a Monday. In August the IVR team changed the identification and verification step: a new data action looks the caller up by their number, and if that fails a bot asks for the account number. The flow records the result with a Set Participant Data action, Account Verified = true or false, on every call. The question on the manager's desk is simple. Did more callers get verified after the change, or fewer? And did the change quietly stop some other key being written at all?

The data to answer it already exists. Genesys Cloud keeps participant data on the conversation, so every one of those calls carries its verification flag, its intent, its lookup results and whatever else the flows, bots and agent scripts chose to write. What is missing is a way to look at that map across thousands of conversations and many weeks, key by key and day by day. That gap is where Participant Data Analytics lives.

Genesys treats participant data as a first-class part of the conversation. In Analytics Workspace, an interaction's Details tab has a Participant Data section where quality managers and evaluators can expand each participant's attributes and copy values, which is exactly what you need when reviewing a single call. For bulk work, the Interactions view export has an Include Custom Attributes option, governed by the Reporting > Custom Participant Attributes > View permission. Genesys notes that this attribute data is only available for conversations processed by the overnight data pipeline.

Developers have the Platform API too. The analytics conversation details jobs return participant attributes for every conversation in an interval, and a participant attributes search endpoint exists for finding conversations. These are the right building blocks. What none of them is designed to do is hand a manager a catalogue of every key the organisation writes, how often each value occurs on each day, and a plain-English verdict on whether a target value is rising or falling. That needs a dataset that accumulates, not a view that is queried and closed.

Our starting point was the shape of the data itself. On the analytics record each participant carries an attributes map: string keys, string values, written by many authors. Merge those maps per conversation and you have one row per call with a sparse, evolving set of columns. Some keys are booleans, some are short enumerations such as an intent, and some are identifiers, phone numbers or free text. A useful tool has to classify them automatically and treat each class differently.

Two subtleties shaped the design. First, the analytics record holds the attribute map as it stood when the conversation ended, so a flow that writes Verified=false and then overwrites it with true contributes one true; mid-call history is not available from this source. Second, coverage matters as much as values. If a key stops being written, a naive chart shows its values collapsing. So the app always keeps a visible (not set) bucket, and by default computes shares against all conversations in each time bucket, so a coverage change can never masquerade as a change in outcomes.

Participant Data Analytics signs in with an OAuth client-credentials grant that needs analytics:conversationDetail:view, plus routing:queue:view and routing:skill:view so ids resolve to names. You choose a UTC day range and press Harvest range. The app compares the request with the organisation's coverage intervals and fetches only the gaps. Each gap is split into one-day windows, and for each window it submits one org-wide asynchronous job to /api/v2/analytics/conversations/details/jobs, with no flow filter, so every conversation in every media type is included. It polls until Genesys has compiled the job, then cursor-pages the results 1,000 at a time.

Each conversation is reduced to its merged participant-data map, start time, media types, direction, divisions, first ACD queue and a coarse disposition: handled by an agent, abandoned in queue, or contained because it never reached a queue. Rows are stored once, keyed by conversation id, and the trailing six hours of covered time are re-scanned for stragglers without double-counting. A window that reaches the 100,000-conversation cap is stored but deliberately not marked covered, so a re-run picks up the remainder. Requests are capped at 92 days; longer histories are simply consecutive harvests.

Flows routinely write routing skill ids, and sometimes queue ids, into participant-data values. The app keeps a per-organisation lookup refreshed from /api/v2/routing/skills and /api/v2/routing/queues at every harvest, and translates values that are exactly one GUID, or a short list of GUIDs, into names. Free text is never rewritten. Throughout, the Genesys client is GET-only apart from one allowlisted POST, the job submission, which is itself a read query. The client secret is encrypted at rest for the life of the session, and every stored row is scoped to the organisation that harvested it.

Analysis starts on the Catalogue: one row per key seen in the chosen range, classed as BOOLEAN, ENUM (up to 12 distinct values) or TEXT/ID, with coverage as a percentage of conversations, distinct values, the first and last day it was written and its top value buckets. Above the table, schema drift banners list keys that appeared or stopped being written inside the range, with a day of slack at either end so partial days do not raise false alarms. A key that vanished on the Tuesday a flow was published is a flow-change fingerprint you can click straight into.

Clicking a key opens its Timeline: a stacked chart of value shares per day, or per hour when the range is three days or less. A target bucket is picked automatically and can be changed from the legend. The verdict combines the mean share in the first half of the range against the second half with a least-squares slope, and reads like the demo's Account Verified = True: 37.3% to 53.3% of calls, improving, +0.9 points a day. It is called stable when the halves differ by under two points and the slope is under 0.15 points a day. A second share basis, calls carrying the key, rescues low-coverage keys whose (not set) band would otherwise drown the signal.

The Movers board turns that into a watchlist of large sparkline cards, either keys you pick or, with nothing picked, every eligible boolean or enum key ranked by the size of its move multiplied by the square root of its volume, so a five-point move on 4,000 calls outranks a 20-point wobble on 40. The Conversations tab lists the calls themselves with their full raw maps, up to 500 rows per page. A filter builder stacks conditions over participant data and routing context such as queue, media and division, applies to every tab and the Excel export, and can be saved as a named view. Range, filter and selections all live in the URL, so every analysis is a shareable link.

Real organisations have flows that write a timestamp into the key name itself, minting a new key on every call: EnteredAccountNumber followed by a date and time. Left alone, such a family floods the catalogue and the key pickers, and every member appears to arrive and vanish on the same day. Participant Data Analytics detects these families automatically, by a shared stem with a trailing date, timestamp or long-digit suffix and at least three members, and flags them with an amber chip for review.

A key rule is a case-insensitive glob such as EnteredAccountNumber_* with one of two actions. Ignore removes matching keys from every view and export. Fold renames them to one stable key, which usually rescues the signal: the events are real, only the key name is wrong. Rules apply at read time, at write time and through a rebuild of the per-day aggregate, and raw stored conversations are never modified, so deleting a rule brings the keys straight back. The panel previews how many keys a pattern matches before you commit, so a typing slip cannot destroy anything.

Participant Data Analytics followed the QVCCS method. Our Senior Business Consultant turned the questions managers actually ask about flow outcomes into user stories with Given/When/Then acceptance criteria; the Solution Architect set the statistical semantics down in writing before a line of code, so every verdict has an exact definition; Senior Developers built to the Senior Platform Practice Lead's engineering standards with four-eyes review; and our Systems Integration Tester proved the harvest against failure paths such as capped windows, missing permissions and stragglers. A synthetic demo organisation with planted improvement, decay, drift and a volatile key family keeps every feature testable without customer data. It is the same multidisciplinary squad, mustered from our own bench, that delivers client projects.

For a client, the result is a living record of what their flows decide. Managers see whether verification, containment or bot outcomes are moving in the right direction. Flow authors see the day a key stopped being written, and the families of badly named keys to fix at source. Analysts get filtered workbooks with the filter recorded on an About sheet. Because the warehouse keeps what it has harvested and fills only gaps, a small regular harvest keeps the history growing long after any single export would have been closed and forgotten.