Every Player Has a Timeline

The support agent's nightmare

"What happened to this player's account last Tuesday?" It sounds like a simple question. In most gaming platforms, it is anything but. Without a unified timeline, the answer involves checking six different screens: payments, game history, bonus log, KYC status, communications, and compliance events. Each screen has its own query interface. Each has its own time format — some show UTC, some show the operator's local time, some show the player's local time. Each has its own pagination, its own filters, its own way of describing what happened.

The support agent tabs between screens, mentally stitching together a chronology from fragments. A deposit at 14:32. A bonus credit that might be related — or might not, because the bonus log shows a different timestamp and no reference to the deposit. A KYC status change at some point that afternoon, but was it before or after the player's complaint? The communications log shows an email was sent, but the timestamp is in a different timezone, so the agent has to do mental arithmetic to figure out the sequence.

This is not a tooling problem. It is an architecture problem. When player events are scattered across separate subsystems — each with its own data model, its own storage, its own query interface — no amount of UI polish can make the support experience coherent. The agent is doing the integration work that the platform should have done.

Multiply this by hundreds of support interactions per day, across multiple brands and jurisdictions, and the cost becomes structural. Longer handle times. More escalations. More cases where the agent misses a critical event because it lived in a screen they did not check. More compliance risk, because the audit trail is assembled manually rather than generated automatically.

The event feed

PAM takes a different approach. The platform's EventFeedListener captures every significant player action into a unified, chronological feed. Not a dashboard that queries six different tables and merges the results at display time — a single, normalized event stream that records every action as it happens.

The events captured include:

• Deposits and withdrawals — amount, method, status, provider reference
• Game rounds — wagers, payouts, game identifier, provider, round duration
• Bonus credits and expirations — bonus type, amount, wagering progress, trigger event
• KYC status changes — document uploads, verification results, status transitions
• Self-exclusion and responsible gaming events — limit changes, cooldown activations, exclusion triggers
• Communications sent — emails, SMS, push notifications, with template and delivery status
• Login and logout events — IP address, device fingerprint, session duration
• Back-office actions — manual adjustments, notes added by agents, account status changes

Every event carries the same metadata structure: a UTC timestamp, the player ID, the event type, the acting entity (player, system, or agent), and a context payload specific to the event type. This normalization is what makes the timeline queryable — not as a feature bolted on after the fact, but as a property of how events are stored.

Queryable by time, type, and context

A unified feed is only useful if you can find what you need in it. A player who has been active for two years might have tens of thousands of events on their timeline. Scrolling through them is not a solution.

PAM's timeline API supports filtering by event type, date range, and associated entity. A support agent can ask: "Show me all payment events for this player in the last 7 days." Or: "Show me everything that happened between 14:00 and 15:00 UTC on Tuesday." Or: "Show me all bonus events related to this specific campaign." The filters compose — type plus date range plus context — so agents can narrow down to exactly the events that matter for their investigation.

The API supports cursor-based pagination, which means it performs consistently whether the player has 50 events or 50,000. There is no page-number pagination that slows down as you go deeper into history. The cursor approach also means that new events arriving while an agent is reviewing the timeline do not shift the results — the view is stable.

For compliance teams, the same queryable timeline serves a different purpose. Instead of filtering by a single player, they can query across players: "Show me all self-exclusion events across all brands in the last 30 days." The same event model, the same query interface, the same consistent timestamps — just a different scope. This means compliance reporting draws from the same data that support agents use, eliminating the discrepancies that arise when reports are generated from a different data pipeline than the one agents interact with.

Retention policies

Not every event needs to live forever. A game round from three years ago has different retention requirements than a self-exclusion event from the same period. Storing everything at full fidelity indefinitely is not just expensive — it creates a liability. Data protection regulations in most jurisdictions require that personal data is not retained longer than necessary for its purpose.

PAM's DeleteOldEvents task enforces configurable retention policies per event type. The configuration is straightforward: each event type has a retention period, and events older than that period are either deleted or compressed, depending on the policy.

In practice, the retention tiers look like this:

• Compliance events (self-exclusion, KYC changes, responsible gaming interventions) — retained for 7 years, because most regulated markets require it
• Financial events (deposits, withdrawals) — retained for 5 years, aligned with anti-money laundering record-keeping requirements
• Game round details (individual wagers and payouts) — full detail retained for 90 days, then compressed to daily aggregates. The individual round data is purged, but the summary remains for trend analysis
• Session events (login, logout, page views) — retained for 12 months, then purged
• Communication events — retained for 24 months, covering the typical window for customer disputes

These retention periods are configurable per operator and per jurisdiction. A Swedish operator might need different retention windows than one licensed in Curacao. The configuration is managed in the back office by the compliance team — no deployment required to adjust a retention period when a regulator updates their requirements.

The result is a timeline that contains everything you need for operational and compliance purposes, without accumulating data that creates storage costs and regulatory exposure. The retention engine runs as a background task on a configurable schedule, processing deletions in batches to avoid impacting operational performance.

The principle

Player context is the product. Every feature in a gaming platform generates events — deposits, bets, bonuses, compliance actions, communications. If those events are not captured in a unified, queryable format, every support interaction starts from scratch. Every compliance audit requires manual assembly. Every investigation is a scavenger hunt across disconnected screens.

The timeline is what turns data into understanding. It is not a reporting feature or a nice-to-have dashboard. It is the infrastructure that makes support efficient, compliance auditable, and operations transparent. When a support agent can see a player's complete history in one place — filtered, paginated, with consistent timestamps and linked context — they can resolve issues faster, escalate less, and provide the kind of informed service that players notice.

The architectural decision is simple: capture events once, in a normalized format, at the time they occur. Everything else — the queries, the filters, the retention policies, the compliance reports — follows from that foundation. The alternative is to build those capabilities retroactively, stitching together data from subsystems that were never designed to be queried together. That path leads to the six-screen support experience. We chose the other one.