Data quality metrics zijn geen abstracte kwaliteitslabels. Ze maken zichtbaar of woningdata bruikbaar is voor een concrete beslissing, zoals een desktop taxatie, hypotheekacceptatie, portefeuillewaardering of verduurzamingsanalyse.
Nederland meet de kwaliteit van basisregistraties al jaren structureel. De meting over 2024 is de achtste opeenvolgende kwaliteitsmeting van CBS, basisregistraties en ICTU, met aandacht voor samenhang, consistentie en verbeterpunten tussen registraties. CBS beschrijft de kwaliteitsmeting van basisregistraties over 2024 als een terugkerende referentie voor datakwaliteit in het publieke domein.
Voor een productteam is de praktische vraag niet alleen of een record “goed” is. Je wilt weten welke foutmarge acceptabel is, voor welke toepassing, en welke actie volgt wanneer een grens wordt overschreden. In dit artikel vertalen we negen datakwaliteitsdimensies naar formules, voorbeelden uit Nederlandse woningdata, operationele drempels en een implementatiepatroon voor API-gebaseerde pipelines.
Wat data quality metrics zijn en waarom ze ertoe doen
Data quality metrics zijn meetbare indicatoren waarmee je objectief beoordeelt of data voldoet aan vooraf bepaalde eisen. Een metric bestaat meestal uit een formule, een teller, een noemer en een drempelwaarde. “De woningdata voelt betrouwbaar” is geen metric. “98 procent van de verplichte energielabelvelden is gevuld” wel.
Dat onderscheid helpt teams om technische kwaliteit te verbinden aan besluitvorming. Een hypotheekverstrekker kijkt bijvoorbeeld naar de bruikbaarheid van WOZ-, adres- en transactiedata. Een verzekeraar kan juist meer gewicht geven aan objectkenmerken, locatie en herleidbaarheid. Een modelteam bewaakt daarnaast de stabiliteit van definities en bronveranderingen.
Praktische regel: definieer eerst waarvoor de data wordt gebruikt. Pas daarna bepaal je welke metric en welke norm relevant zijn.
Slechte woningdata veroorzaakt verschillende soorten risico's:
- Waarderingsrisico: een woningwaardemodel krijgt een verouderde oppervlakte, een foutieve bouwjaarwaarde of een verkeerd gekoppeld referentieobject.
- Acceptatierisico: een hypotheekproces gebruikt een adresrecord dat niet goed aansluit op BAG, WOZ of Kadaster.
- Energierisico: een ontbrekend of verouderd energielabel beïnvloedt een analyse van verduurzamingspotentieel.
- Governancerisico: een team kan niet aantonen waar een waarde vandaan komt of welke bronversie is gebruikt.
CBS hanteert voor statistische kwaliteit onder meer validiteit, betrouwbaarheid, tijdigheid, volledigheid, internationale vergelijkbaarheid en interne consistentie door de tijd. Voor administratieve bronnen kijkt CBS bovendien naar bruikbaarheid voor statistische productie, samenhang met het statistische concept, koppelbaarheid en stabiliteit. Het CBS-raamwerk voor indicatoren laat daarmee zien waarom “juist” alleen onvoldoende is.

Een bruikbaar meetkader behandelt dus niet alleen volledigheid en nauwkeurigheid, maar ook tijdigheid, consistentie, uniciteit, validiteit, herleidbaarheid, versheid en bias. De werkwijze voor data quality management sluit daarop aan door kwaliteit te koppelen aan bronbeheer, meetregels en operationele opvolging.
De negen kerndimensies voor woningdata
Een datakwaliteitsdimensie beschrijft welk aspect van kwaliteit je beoordeelt. De metric maakt die dimensie meetbaar. Voor woningdata zijn negen dimensies bijzonder bruikbaar, omdat ze samen zowel bronkwaliteit als geschiktheid voor modellen en processen afdekken.
| Dimensie | Definitie | Voorbeeld in woningdata |
|---|---|---|
| Completeness | De mate waarin verplichte gegevens aanwezig zijn. | Het percentage woningen met een gevuld energielabel, bouwjaar en BAG-verblijfsobject-ID. |
| Accuracy | De mate waarin een waarde overeenkomt met een betrouwbare referentie. | Een WOZ-waarde vergelijken met een gezaghebbende bron of een gevalideerde referentie. |
| Timeliness | De vertraging tussen een mutatie en de beschikbaarheid ervan. | De tijd tussen een Kadaster-publicatie en verwerking in een hypotheekpipeline. |
| Consistency | De mate waarin dezelfde betekenis en waarde in systemen behouden blijft. | Controleren of adres-, object- en WOZ-gegevens logisch op elkaar aansluiten. |
| Uniqueness | De mate waarin elk record slechts één keer voorkomt. | Duplicaatdetectie op BAG-verblijfsobject-ID en adrescombinatie. |
| Validity | De mate waarin data aan structuur, formaat en toegestane waarden voldoet. | Een postcode, bouwjaar of objecttype toetsen aan het verwachte schema. |
| Lineage | De herleidbaarheid van een uitkomst naar bronnen en bewerkingen. | Een modelwaarde terugbrengen naar brontransacties, kenmerken en versie-informatie. |
| Freshness | De leeftijd van de laatste relevante update. | De ouderdom van een transactiedatum, energielabel of objectkenmerk meten. |
| Bias | Een systematische afwijking tussen groepen. | Nagaan of een woningwaardemodel structureel anders uitvalt per regio of woningtype. |
NORA omschrijft juistheid als de mate waarin gegevens de echte waarde weergeven, compleetheid als de aanwezigheid van gegevens, actualiteit als de mate waarin gegevens recent genoeg zijn en validiteit als conformiteit aan de verwachte structuur. De tabel met kwaliteitsdimensies van NORA geeft daarvoor een bruikbare Nederlandse begrippenbasis.
De gewichten verschillen per proces. Een bank kan accuracy, lineage en consistency zwaarder laten wegen bij hypotheekacceptatie. Een gemeente kan completeness en timeliness prioriteren voor dienstverlening. Een makelaar kan vooral letten op actuele, unieke en complete advertentiegegevens. Voor verduurzamingsanalyses is een combinatie nodig van volledigheid, geldigheid en versheid van energie- en objectkenmerken. Ook informatie over zonnepanelen voor woningcorporaties is pas bruikbaar wanneer bron, actualiteit en objectkoppeling duidelijk zijn.
Formules en voorbeelden om metrics te meten
Een metric wordt operationeel zodra je exact vastlegt hoe je haar berekent. Gebruik bij voorkeur één formule per dimensie, documenteer de bron en leg vast of de uitkomst een percentage, ratio, afwijking of tijdsduur is.
| Metric | Formule | Fictief voorbeeld |
|---|---|---|
| Completeness | (1 - ontbrekende_velden / totaal_velden) × 100 |
(1 - 20 / 1000) × 100 = 98,0% energielabel-coverage. |
| Accuracy | 1 - |gemeten - referentie| / referentie |
1 - |245.000 - 250.000| / 250.000 = 98,0%, dus 2,0% afwijking. |
| Timeliness | verwerkingstijd - publicatietijd |
Een transactie is 18 uur na publicatie beschikbaar. |
| Consistency | 1 - afwijkende_koppelingen / totaal_koppelingen |
985 van 1000 koppelingen zijn gelijk, dus 98,5% consistentie. |
| Uniqueness | 1 - duplicaten / totaal_records |
5 duplicaten op 1000 records geeft 99,5% uniciteit. |
| Validity | records_die_aan_schema_voldoen / totaal_records |
970 van 1000 records voldoen aan het schema, dus 97,0%. |
| Lineage | records_met_volledige_bronketen / totaal_records |
940 van 1000 records zijn volledig herleidbaar, dus 94,0%. |
| Freshness | mediaan(leeftijd_van_update) |
De mediane leeftijd van een transactiedatum is 12 dagen. |
| Bias | (gemiddelde_regio - gemiddelde_totaal) / gemiddelde_totaal |
Een regionale gemiddelde waarde wijkt 3,0% af van het totaal. |
Gebruik fictieve voorbeelden om de rekenlogica te testen, maar gebruik voor productie altijd een referentie die past bij de use case. Een verschil tussen WOZ-waarde en modelwaarde is bijvoorbeeld niet automatisch een fout. De waarden kunnen verschillende doelen, peildata of methoden hebben. Meet daarom zowel de afwijking als de betekenis van die afwijking.

Een eenvoudige controle kan er conceptueel zo uitzien:
completeness = populated_fields / required_fieldsfreshness = today - last_updateaccuracy_gap = abs(model_value - reference_value) / reference_valuealert = metric < threshold
De formule is slechts het begin. Leg ook vast wie eigenaar is van de bron, welke records worden uitgesloten, hoe null-waarden worden behandeld en welke actie volgt bij een overschrijding.
Thresholds en SLA's per doelgroep
Een threshold is een inhoudelijke kwaliteitsgrens. Een SLA maakt die grens afdwingbaar in een proces of contract. De juiste norm hangt af van het risico van een fout, niet alleen van de technische mogelijkheden van een databron.
De normen hieronder zijn praktische voorbeeldwaarden voor ontwerp en bespreking binnen een organisatie. Ze zijn geen universele wettelijke normen. Voor basisregistraties bestaan wel specifieke Nederlandse kwaliteitsregels. Zo moet volgens Digitale Overheid 100 procent van de postcodes in de BAG overeenkomen met het postcodebestand, moet 98 procent van aangeboden bedrijfsgegevens binnen 36 uur zijn verwerkt en moet eind februari 95 procent van de WOZ-waarden van het betreffende kalenderjaar beschikbaar zijn.
| Doelgroep | Completeness | Accuracy | Timeliness | Uniqueness |
|---|---|---|---|---|
| Banken | ≥98% voor kritieke taxatie-input | Binnen ±2% op afgesproken WOZ-referentie | Binnen één werkdag | ≥99,5% op BAG-ID |
| Verzekeraars | ≥95% voor object- en risicokenmerken | Afwijking volgens risicomodel | Binnen afgesproken risicovenster | ≥99,5% op object-ID |
| Gemeenten | ≥98% voor verplichte registratieve velden | Volgens bron- en normenkader | Volgens wettelijke of ketenafspraak | ≥99,5% op sleutelvelden |
| Makelaars | ≥90% voor marketingdata | Referentiecontrole per bron | Binnen enkele werkdagen | ≥99,0% op advertentie-object |
Een hypotheekverstrekker kan een kleine afwijking in een waarde kritisch vinden, terwijl een makelaar een ontbrekende secundaire woningkenmerk nog kan herstellen vóór publicatie. Dat verschil moet zichtbaar zijn in de SLA, met minimaal een meetfrequentie, eigenaar, escalatiepad, hersteltermijn en rapportagevorm.
Beslisregel: koppel iedere threshold aan een concrete schadepost. Een grens zonder beschreven gevolg wordt al snel een administratieve score.
Maak onderscheid tussen blocking rules en warning rules. Een ontbrekend BAG-ID kan een uitkomst blokkeren. Een oudere buurtvariabele kan een waarschuwing opleveren, zolang het productteam de beperking zichtbaar maakt.
Praktijkmetingen met WOZ transactie en locatie
Praktijkmeting begint met een stabiele sleutel. Voor Nederlandse woningdata is het BAG-verblijfsobject-ID vaak het startpunt voor koppeling tussen objectkenmerken, WOZ, locatie en afgeleide modeluitkomsten. Daarna meet je per bron wat aanwezig is, hoe betrouwbaar de koppeling is en hoe recent het record is.
De Nederlandse kwaliteitsmeting maakt duidelijk dat volledigheid en juistheid van koppelingen verschillende zaken zijn. Volledigheid kijkt of koppelsleutels gevuld zijn voor onder meer personen, verblijfsobjecten, WOZ-objecten, percelen, panden en vestigingen. Juistheid beoordeelt of de koppeling logisch klopt, maar een logische koppeling hoeft niet automatisch de feitelijke werkelijkheid volledig te beschrijven. Het CBS-dashboard over de kwaliteitsmeting onderbouwt dat onderscheid.
Een werkbare meetroute
- Bepaal de populatie. Selecteer bijvoorbeeld alle woningen binnen een postcodegebied en leg de peildatum vast.
- Meet completeness. Deel het aantal records met een geldig BAG-ID, WOZ-waarde en relevante locatievelden door het totale aantal records.
- Controleer accuracy. Vergelijk WOZ- of modelwaarden met passende referentietransacties. Gebruik geen transactie als directe waarheid wanneer peildatum, woningtype of marktcontext verschillen.
- Meet timeliness en freshness. Bereken de tijd tussen bronmutatie en API-beschikbaarheid, plus de leeftijd van het laatste record.
- Test consistency. Controleer of gemeentegegevens, Kadaster-koppelingen en objectkenmerken elkaar niet logisch tegenspreken.
- Documenteer lineage. Sla bron, versie, verwerkingstijdstip, transformatie en endpoint-output op.
Een fictief Amsterdams adres kan een gevuld BAG-ID hebben, maar een ontbrekende WOZ-waarde. Een fictief Utrechts adres kan alle velden bevatten, maar een ouder transactierecord hebben. Beide records zijn dus “compleet” op een andere manier, afhankelijk van de verplichte velden en de use case.
Checklist voor productie
- Zijn verplichte velden per use case vastgelegd?
- Is de sleutel uniek en stabiel?
- Heeft iedere output een bron- en timestamp?
- Zijn afwijkingen tussen WOZ en modelwaarde verklaarbaar?
- Zijn freshness-regels gekoppeld aan alerts?
- Kunnen productmanagers een fout terugbrengen naar bron en bewerking?
Monitoring dashboards en alertpatronen
Een dashboard maakt datakwaliteit bestuurbaar door trends, uitzonderingen en SLA-breuken zichtbaar te maken. Een momentopname zegt of een dataset vandaag voldoet. Een trend laat zien of de kwaliteit verslechtert, verbetert of structureel fluctueert.
Zet per dimensie minimaal de actuele score, de afgesproken grens, de ontwikkeling en het aantal betrokken records in beeld. Voor woningdata zijn bijvoorbeeld deze panelen nuttig:
- Completeness: dagelijkse dekking van energielabel, bouwjaar, BAG-ID en WOZ-velden.
- Accuracy: afwijking tussen modelwaarde en gekozen referentie, uitgesplitst naar regio en woningtype.
- Timeliness: verwerkingstijd per bron en aandeel records binnen de SLA.
- Lineage: records zonder bronversie, transformatie of koppelinformatie.
- Freshness: leeftijd van de laatste update per dataset en endpoint.
- Bias: afwijkingen tussen regio's, woningtypen of segmenten.
Richt severity-niveaus in op basis van impact. Een informatieve melding kan een lichte verschuiving signaleren. Een waarschuwing past bij een naderende SLA-breuk. Een kritieke alert blokkeert bijvoorbeeld een batch wanneer de objectkoppeling ontbreekt of de accuracy-afwijking buiten de afgesproken tolerantie valt.
De door het productteam opgegeven patronen zijn bruikbaar als startpunt, maar moeten worden gevalideerd tegen historische productdata. Een alert bij meer dan 5 procent accuracy-afwijking op dagbasis of een freshness-overschrijding van 30 dagen kan in een specifieke pipeline relevant zijn, maar zulke grenzen zijn geen algemene Nederlandse norm.
Voor operations: toon vandaag wat stuk is. Voor data-eigenaren: toon welke bron structureel afwijkt. Voor stakeholders: toon welke SLA's geraakt worden.
Gebruik dagelijkse snapshots voor operations, wekelijkse trendrapporten voor data-eigenaren en maandelijkse SLA-rapportages voor stakeholders. De monitoringaanpak voor datakwaliteit kan daarbij als referentie dienen voor de koppeling tussen metrics, alerts en opvolging.
Implementatie via Altum AI API met pseudo-code
Een API-implementatie werkt wanneer iedere uitkomst een bron, tijdstip, identifier en meetregel behoudt. Begin met een afgescheiden testomgeving, definieer de verplichte velden en leg vast welke endpointrespons als referentie dient.
De opgegeven basis-URL is Authenticatie loopt conceptueel via een API-key in deAuthorization`-header. Voor de gewenste meetopzet kun je de volgende endpoints als functionele onderdelen modelleren:
/woningen/{id}/woningwaardevoor vergelijking met een woningwaardemodel./woningen/{id}/wozvoor WOZ-validatie./transactiesvoor verwerking en tijdigheid./kadaster/postcode/{pc}/transactiesvoor transactie-completeness./metadata/freshnessvoor versheid en lineage-informatie.
De exacte request- en responsevelden moeten jullie afstemmen op de actuele API-documentatie. De uitleg over API's en hun werking helpt ontwikkelaars om de integratiegrenzen correct te ontwerpen.
Pseudo-code voor een batchmeting
import json
import requests
from datetime import date
BASE_URL = "https://api.altumai.nl/v1/"
HEADERS = {"Authorization": "Bearer API_KEY"}
def get(path, params=None):
response = requests.get(
BASE_URL + path,
headers=HEADERS,
params=params,
timeout=20
)
response.raise_for_status()
return response.json()
def measure_record(woning_id, postcode):
woningwaarde = get(f"woningen/{woning_id}/woningwaarde")
woz = get(f"woningen/{woning_id}/woz")
transacties = get(f"kadaster/postcode/{postcode}/transacties")
freshness = get("metadata/freshness", {"woning_id": woning_id})
required = [woningwaarde, woz, transacties, freshness]
completeness = sum(value is not None for value in required) / len(required)
model_value = woningwaarde.get("waarde")
reference_value = woz.get("waarde")
accuracy_gap = None
if model_value and reference_value:
accuracy_gap = abs(model_value - reference_value) / reference_value
return {
"woning_id": woning_id,
"postcode": postcode,
"completeness": completeness,
"accuracy_gap": accuracy_gap,
"freshness": freshness,
"transaction_count": len(transacties.get("items", []))
}
records = [
{"woning_id": "voorbeeld-id-1", "postcode": "1234AB"},
{"woning_id": "voorbeeld-id-2", "postcode": "2345CD"}
]
report = {
"measured_on": str(date.today()),
"metrics": [measure_record(r["woning_id"], r["postcode"]) for r in records]
}
with open("data-quality-report.json", "w", encoding="utf-8") as file:
json.dump(report, file, ensure_ascii=False, indent=2)
Gebruik retries met gecontroleerde back-off voor tijdelijke fouten, rate limiting om de bron en jullie eigen infrastructuur te beschermen, en correlation IDs voor logging. Registreer statuscodes, latency, requestcontext en foutcategorieën. Stuur de JSON-uitkomst vervolgens naar het dashboard, waar thresholds, trends en escalaties samenkomen.
Altum AI biedt woningdata via API's voor onder meer woningwaarde, WOZ, Kadastertransacties, locatiekenmerken en energie. De Woningwaarde API kan in een kwaliteitsproces worden gebruikt wanneer jullie modeluitkomsten naast een bronwaarde, metadata en toepassingsspecifieke tolerantie willen beoordelen.
Veelgestelde vragen over data quality metrics
Wat is het verschil tussen een dimensie en een metric?
Een dimensie is het kwaliteitsbegrip, zoals accuracy of completeness. Een metric is de concrete berekening, bijvoorbeeld het percentage records met een gevuld BAG-ID.
Welke metrics zijn het belangrijkst voor woningwaardering?
Voor woningwaardering zijn accuracy, completeness, timeliness, consistency en lineage doorgaans essentieel. De prioriteit hangt af van het beslisrisico, de bron en de manier waarop het woningwaardemodel wordt gebruikt.
Is een verschil tussen WOZ en modelwaarde automatisch een datakwaliteitsfout?
Nee. WOZ en een modelwaarde kunnen verschillende peildata, definities en doelen hebben. Meet de afwijking, documenteer de referentie en bepaal vooraf welke bandbreedte voor jullie toepassing aanvaardbaar is.
Hoe begin je met monitoring?
Start met één kritieke keten, bijvoorbeeld BAG naar WOZ naar woningwaarde. Definieer verplichte velden, een unieke sleutel, een freshness-regel, een accuracy-referentie en een eigenaar voor incidenten. Breid daarna uit naar andere bronnen en use cases.
Laatst bijgewerkt: 8 september 2026
Altum AI werkt aan woningdata voor banken, hypotheekverstrekkers, verzekeraars, taxateurs, gemeenten, vastgoedinvesteerders en softwareteams. Het platform combineert API's en datasets voor woningwaarde, WOZ, Kadastertransacties, locatie, energie en verduurzaming, zodat jullie datakwaliteit niet alleen beoordelen, maar ook direct in productprocessen kunnen verwerken.
Koppel jullie kwaliteitsregels aan actuele woningdata via de API's van Altum AI. Start met een testaccount, controleer de beschikbare endpoints in de documentatie en bespreek met het team welke thresholds, bronketens en alerts bij jullie hypotheek-, taxatie- of vastgoedproces passen.