Quality problems are silent
The characteristic that makes data quality difficult is that most failures do not announce themselves.
A pipeline that stops running produces an obvious error. A pipeline that runs and delivers incomplete data produces a number that is plausible, that fits in the report, and that is wrong.
The failures that occur in practice are mostly of the second kind.
A supplier feed stops delivering for one game provider, and casino revenue appears to have declined for reasons nobody can identify.
An attribution link breaks after a platform change, and channel-level figures shift without anyone connecting the two events.
A currency conversion applies at the wrong point, and one market's figures are consistently understated by a proportion nobody notices.
A deduplication rule changes, and customer counts step by an amount that gets attributed to acquisition.
A timezone boundary shifts, and daily figures disagree with an external source at the margins.
In each case the number is plausible, the report renders, and the error persists until someone happens to look closely. That period is frequently months.
The consequence is that quality detection must be built rather than relied upon to emerge from use.
Building detection
The checks worth automating, in rough order of value.
Volume checks. Row counts and record volumes against expected ranges, per source, per day. A feed that delivers 60% of its usual volume has a problem, and this catches most silent failures.
Freshness checks. Whether each source has updated within its expected window, which catches stalled pipelines.
Completeness checks. Whether required fields are populated, and whether null rates have moved.
Range and distribution checks. Whether values fall within plausible bounds and whether distributions have shifted materially, which catches unit changes, precision changes and upstream logic changes.
Referential checks. Whether records link correctly, which catches identity resolution failures and orphaned rows.
Reconciliation. Whether derived figures agree with authoritative sources, particularly for revenue, which catches transformation errors.
Duplicate detection, both of records and of customers.
Anomaly detection on the outputs themselves, flagging when a reported figure moves outside its normal variation.
The design principle is that checks should fail loudly and to a named owner. A check that writes to a log nobody reads has not improved anything, and this is the most common way monitoring is implemented and ignored.
Lineage and ownership
The two properties that make an environment trustworthy over time.
Lineage means being able to trace a reported figure back through every transformation to its source. Without it, a discrepancy cannot be investigated and a definitional question cannot be answered.
Maintaining it requires transformation logic that is versioned and reviewable rather than existing as ad hoc queries, documented so that the reasoning is available, and discoverable so that anyone can follow the path without asking the person who built it.
Ownership means a named person accountable for each dataset and each core measure: its definition, its quality, its appropriate use and its continued relevance.
Without ownership, problems have no home. A quality check fails and nobody is responsible for investigating. A definition becomes outdated and nobody notices. A dataset becomes obsolete and nobody removes it.
Both properties decay without maintenance, and the decay is the analytical debt described in the first lesson.
Retention in analytical environments
A specific problem most operators have and few have addressed.
Data pulled into an analytical environment for a piece of work tends to stay. Extracts, intermediate tables, model training sets and one-off pulls accumulate over years.
Each of those carries the retention obligations of its source. Verification documents, financial evidence and transaction histories in an analytical copy are the same personal data subject to the same rules as in the operational system.
The consequences.
An environment full of undocumented extracts is holding personal data without a current basis, which is a data protection failure regardless of how it arose.
Retention schedules applied operationally may not reach analytical copies, so data deleted from the source persists in the warehouse.
Access controls are frequently looser in analytical environments than in operational ones, on the reasoning that analysts need broad access, which is difficult to justify for verification documents and financial evidence.
Breach exposure scales with what is held, and an analytical environment holding years of accumulated extracts is a larger target than the operational systems.
The remedies are ordinary. Catalogue what exists. Establish a basis and a retention period for each dataset. Apply deletion. Restrict access proportionately. And require that new extracts carry an owner and an expiry rather than being created and forgotten.
Data protection in analytical work
Extending the material in the Law and Compliance course to this function specifically.
Purpose limitation. Data collected under a legal obligation for verification was collected for that purpose. Using it for commercial analysis requires a basis, which may exist and should be established rather than assumed.
Minimisation. Analysis should use the data it needs, which frequently means aggregated or pseudonymised extracts rather than full records. An analyst working on channel performance does not need identity documents in their working environment.
Access proportionality. Who can see verification evidence, financial documents and risk inferences should reflect sensitivity rather than convenience.
Automated decisions. A model output that materially affects a customer engages specific obligations, including explainability and a route to contest. A model restricting an account or determining an affordability assessment falls here.
Inferred sensitive data. The most important point in this section. A model output indicating that a customer may be experiencing gambling harm is an inference about their health. Whether it is formally a special category depends on jurisdiction and specificity; the practical handling should be the same either way.
That handling: held securely, access-limited, used for the protective purpose that justified generating it, structurally prevented from becoming a commercial input, recorded factually rather than speculatively, and disclosable to the individual if they exercise access rights.
That last consideration is a useful discipline in itself. An inference nobody would want the customer to read is usually one that should not have been recorded in those terms.
Ethical questions specific to this work
Beyond legal obligation, and worth stating because analysts encounter them directly.
Optimisation targets. A model rewarded for engagement will find what increases engagement, which in this industry includes patterns the operator should not pursue. The constraints described in the Product Innovation course are analytical constraints as much as product ones, and the person building the model is frequently the only person who knows what features it is using.
Feature selection. A model given access to risk-relevant behaviour will use it if it predicts the target, whether or not anyone intended that. Checking what a model is actually using is part of building it responsibly.
Segmentation on inferred characteristics. Treating customers differently based on model outputs about them is defensible for protective purposes and requires examination when the purpose is commercial.
Analysis that would be uncomfortable to describe. The heuristic from earlier courses applies. If explaining a piece of analysis publicly would be awkward, that discomfort is information about the analysis.
Findings that will be misused. An analyst who produces a finding knowing how it will be applied bears some relationship to that application, and raising the concern is available even when the analysis was legitimately requested.
None of these has a procedural answer. They are judgements, they arise regularly, and the person best positioned to notice them is the analyst rather than anyone reviewing the output.
Governance that works
To close, the components of a functioning arrangement.
A metric dictionary, as described in the metrics lesson, maintained and enforced.
A data catalogue recording what exists, where it came from and what it can be used for.
Named ownership for datasets and measures.
Automated quality checks failing to owners.
Versioned transformation logic, reviewable and documented.
Retention schedules applied to analytical copies, with actual deletion.
Access controls proportionate to sensitivity.
Change control on definitions, with versioning and effective dates.
A route for raising concerns about how analysis is being used, which connects to the cultural conditions described in the Leadership course.
None of this is technically demanding. All of it competes against producing the next analysis, which is why it is deferred, and it is what separates an environment where answers can be trusted from one where every question begins with a reconciliation.
Closing the course
This course has argued that the constraint on analytical quality in gambling is rarely data availability, since operators hold unusually complete records of what their customers do.
The constraints are elsewhere. Definitions that disagree between teams. Attribution that broke silently. Identity that does not resolve. Averages quoted from distributions where the average describes nobody. Comparisons between groups that formed themselves. Reporting produced for nobody in particular. And accumulated debt that makes work built on it unreliable.
Each of those is addressable without sophisticated technique, and addressing them produces more value than any modelling capability built on top of them would.
The skills that matter, restated: understanding the business well enough to identify the questions that matter, thinking distributionally by default, knowing when a comparison supports a causal claim, being precise about definitions, being able to trace a number to its source, and communicating findings in a form that reaches a decision.
Technical capability matters and is further down that list than most analysts expect, because in this industry the ability to compute something is almost never what is missing.
Assessing an environment
For an analyst arriving at an operator, or reviewing one, the questions that establish whether the foundations can be trusted.
Can I trace a reported figure to its source? Pick one and try. The answer indicates the lineage position immediately.
Does each core metric have one definition? Or several, and does anyone know which is authoritative.
Who owns the customer table? And each other significant dataset. If the answer is nobody, problems have no home.
What quality checks run, and where do failures go? A check writing to an unread log is not a control.
When did a quality failure last get caught before it reached a report? If never, detection is not working.
What is in the analytical environment that nobody can justify? Almost always a substantial amount.
Who can see verification documents and financial evidence? And is that proportionate.
Are retention schedules applied to analytical copies? Usually not.
What models are in production, what do they affect, and can their outputs be explained?
Is there a route for raising concerns about how analysis is used? And has anyone used it.
An environment answering these well produces analysis that can be trusted. One that cannot is producing figures whose reliability nobody can establish, which is a worse position than having no figures, because the unreliable ones will be acted on.
The case for the unglamorous work
A closing argument, since everything in this lesson competes for attention against producing analysis.
The work described here has no output anyone requested. Nobody asks for a metric dictionary, a lineage record or a retention schedule. The requests are for answers, and the person building foundations is not delivering them.
The argument that wins is the one about capacity. An operator with reliable foundations answers a question in an afternoon. One without spends the afternoon reconciling two figures, discovers they used different definitions, resolves which is right, and then answers the question tomorrow.
Multiply that across every request and the foundational work has paid for itself several times over in analyst time alone, before considering the decisions that were taken on figures nobody had checked.
The related argument is about trust. An organisation that has been given conflicting numbers stops believing any of them, and an analytics function whose output is not believed has no influence regardless of how good the analysis is.
Both arguments are available and neither is as compelling as a request for a number, which is why the foundations are neglected almost everywhere and why the operators that invested in them have an advantage that is difficult to see from outside.
Quality problems by source
A practical catalogue of where each source in the data landscape typically fails.
Financial data is the most reliable and fails on timing: authorisation, capture and settlement occur at different moments, and combining them without accounting for it produces discrepancies that look like errors.
Gameplay data fails on completeness, usually when a supplier feed drops silently, and on identity linkage where content arrives through aggregators.
Account data fails on staleness, since declared circumstances are captured once and change afterwards.
Communication data fails on engagement measurement, which has become progressively less reliable, and on delivery attribution across channels.
Attribution data fails constantly and for the reasons set out in the Affiliate Marketing course.
Compliance data fails on outcome recording, since what an intervention achieved is frequently not captured even where the intervention itself is.
Third-party data fails on schedule, format and definition, and each supplier does so differently.
Derived data fails when the logic producing it changes without versioning, which makes historical comparison invalid in a way that is invisible.
Knowing where each source is weak directs checking effort and, more usefully, indicates which findings deserve scepticism before they are investigated.
A quality incident
To make the sequence concrete, a realistic case.
A weekly report shows casino revenue down 7% in one market. The commercial team begins investigating a competitor launch.
The first check compares the market's deposits, which are flat. Revenue down with deposits flat is unusual and points at something other than customer behaviour.
The second check examines revenue by game provider. One provider's contribution has dropped to near zero.
The third check confirms the provider's feed stopped delivering four days earlier, following a platform release.
The consequence is that the revenue was generated and not recorded, that the figure has been wrong for four days, that it appeared in a report, and that a team spent a day investigating a competitor.
What would have caught it is a volume check per source, per day, failing to a named owner, which is the first item on the detection list above and which takes an afternoon to build.
The general lesson is that the diagnostic sequence works from the implausible relationship, that quality failures frequently present as business findings, and that the cheapest intervention is upstream detection rather than downstream investigation.
Where to start
For an analyst or a function inheriting an environment with no governance, the sequence that produces the most improvement soonest.
Build volume and freshness checks on every source, failing to a named person. This is a day's work and it catches the majority of silent failures.
Write the metric dictionary for the ten measures that appear most often, with logic and authoritative source.
Trace one reported figure end to end and document the lineage, which reveals what is undocumented.
Catalogue the analytical environment and identify what nobody can justify holding.
Assign ownership for the core datasets, even provisionally, so problems have a home.
Check access to the sensitive categories against who actually needs it.
Six actions, none requiring a project, and between them they move an environment from one where nobody can establish whether a figure is right to one where the common failures are caught before they reach a report.
Everything more sophisticated builds on those, and attempting the sophisticated work first is the recognisable pattern of an analytics function producing impressive output on foundations that will not support it.