Data hygiene is het doorlopende werk om je bedrijfsdata juist, volledig, consistent en actueel te houden in elk systeem waarin die staat. Je herstelt fouten, verwijdert dubbelingen, vult gaten, ruimt verouderde records op en zorgt dat gekoppelde tools elkaar niet tegenspreken.

De meeste teams zien het als een klus voor het CRM. De data van een go-to-market-team staat alleen op veel meer plekken dan het CRM: het marketingplatform, de sequencer, Clay-tabellen, enrichment-exports, advertentiedoelgroepen, het facturatiesysteem, een warehouse en een verrassend aantal spreadsheets. In elk ervan schrijven andere mensen en andere integraties, en elk ervan voedt beslissingen.

Daar gaat het meestal mis. Een team schoont het CRM grondig op, en de volgende sync vanuit een andere tool schrijft de oude waarden er meteen weer in. Of het CRM is brandschoon, terwijl de lijst die echt in een campagne gaat uit een export komt waar al een jaar niemand naar heeft gekeken.

TL;DR

• Data hygiene is de overkoepelende term. CRM hygiene gaat over één systeem, data decay is één oorzaak van vervuilde data en data normalization is één techniek. Data hygiene omvat ze allemaal, in elke tool.

• Tel je opslagplekken voor data voordat je iets opschoont. De sequencer, Clay-tabellen, CSV-exports en advertentiedoelgroepen bevatten meestal meer verouderde en dubbele data dan het CRM.

• Veel rommel ontstaat op de naden tussen tools. In de Salesforce-sync van HubSpot betekent een tweerichtingsveld dat de meest recente waarde altijd wint, ook als die waarde fout is.

• Geef elk belangrijk veld één system of record en één syncrichting, en leg die kaart vast.

• Slechte data is vaak al slecht bij de geboorte. In een studie van Harvard Business Review, waarin 75 leidinggevenden hun eigen records controleerden, had 47% van de nieuw aangemaakte records minstens één kritieke fout.

• Controleer data op de momenten dat die zich verplaatst (imports, nieuwe syncs, verzendingen, scoring- en AI-runs, het uitfaseren van tools) en verwijder wat je niet meer nodig hebt. Dat vraagt de Britse toezichthouder sowieso van je, in zijn uitleg bij de Britse versie van de AVG (GDPR).

• Nebor brengt in kaart waar de GTM-data van een klant staat, bepaalt samen met de klant welk systeem eigenaar is van elk veld, en bouwt de syncregels en checks in de eigen tools van de klant. Daarna dragen we de kaart over.

Data hygiene, CRM hygiene, decay en normalization: hoe ze samenhangen

Mensen wisselen deze vier termen vrij uit, terwijl elke term voor een ander soort werk staat. Welk werk je kiest, bepaalt waar je echt aan werkt.

• Data hygiene is de werkwijze als geheel, toegepast op elk systeem dat data over klanten, prospects en accounts opslaat.

• CRM hygiene is diezelfde werkwijze binnen één systeem, meestal het belangrijkste. Het gaat om dubbelingen samenvoegen, velden vullen en verouderde records archiveren in HubSpot of Salesforce.

• Data decay is de belangrijkste reden dat schone data niet schoon blijft. Mensen wisselen van baan en bedrijven veranderen van vorm, en niets in je tools werkt zichzelf bij.

• Data normalization is een van de technieken: zorgen dat de waarden in een veld één format volgen, zodat filters en regels ze kunnen matchen.

Twee andere werkwijzen liggen er vlak naast. Data enrichment vult aan wat ontbreekt, en contact verification en e-mailvalidatie bevestigen dat wat er staat nog werkt. Hygiëne grijpt naar die gereedschappen. Je hoeft er geen losse projecten van te maken.

Je hoort ook vaak datakwaliteit als naam voor dit alles. Datakwaliteit is het doel, de toestand waarin je data verkeert. Data hygiene is het werk dat je data daar brengt en houdt.

De GTM-data die nooit in een CRM-audit belandt

Breng in kaart waar de data staat voordat je iets opschoont. Bij de meeste B2B-bedrijven waarmee we werken, is het CRM een van de vele plekken met contact- of accountrecords, en vaak de enige die ooit iemand heeft doorgelicht. Een typische inventaris ziet er zo uit:

• De sequencer of sales engagement tool. Die heeft een eigen kopie van elk contact dat je hebt gemaild, eigen registraties van bounces en uitschrijvingen, en vaak een andere functietitel dan het CRM, omdat hij uit een andere lijst is geïmporteerd.

• Clay-tabellen en andere enrichment-werkbladen. Ze worden gebouwd voor één campagne, één keer verrijkt en dan maandenlang laten staan, nog altijd gekoppeld aan een push naar het CRM.

• CSV-exports. Lijsten met webinardeelnemers, gescande badges van een event, de "topaccounts"-sheet van een rep, de lijst die een vorig bureau heeft overgedragen. Ze staan op gedeelde schijven en worden opnieuw geïmporteerd zodra iemand snel een lijst nodig heeft.

• Het marketing automation platform, als dat niet het CRM is, met een eigen abonnementsstatus en eigen lifecyclefases.

• Advertentiedoelgroepen, ooit geüpload vanuit een export en ververst zodra iemand eraan denkt.

• Facturatie- en productdata, die het eerlijkste antwoord hebben op de vraag wie klant is, en het daarover vaak oneens zijn met het CRM.

• Een warehouse of rapportagelaag die meerdere van de bovenstaande combineert en elke onenigheid ertussen erft.

Elk van deze plekken voedt een beslissing. De sequencer bepaalt wie wordt gemaild, de advertentiedoelgroep bepaalt wie je advertenties ziet, en de CSV bepaalt wie in de volgende ronde list building terechtkomt. Een schoon CRM helpt niets als de lijst die echt de deur uitgaat ergens anders vandaan kwam.

Als twee systemen het oneens zijn, welke heeft dan gelijk?

Dit patroon komen we constant tegen. Een rep hoort in een gesprek dat een contact van Head of Sales naar Chief Revenue Officer is gegaan, en past het CRM aan. Een week later duwt een Clay-tabel die hetzelfde contact maanden geleden verrijkte, zijn opgeslagen titel terug in het CRM, omdat die push nooit is uitgezet. De correctie van de rep is weg, en niemand weet dat het is gebeurd.

Of andersom. Een prospect schrijft zich uit voor een sequence. De sequencer legt het vast, maar de uitschrijving bereikt het CRM nooit, dus marketing zet dezelfde persoon de maand erna op een nieuwsbrief. Dat is meer dan slordig. Het is een complianceprobleem en een klachtrisico voor je verzenddomein.

Geen van beide is een invoerfout. Het zijn syncbeslissingen die niemand bewust heeft genomen. De documentatie van HubSpot voor de Salesforce-integratie laat zien hoe grof die beslissingen zijn. Bij een tweerichtingsveld overschrijft de meest recente waarde altijd alle bestaande waarden, en een waarde die je aan de ene kant verwijdert, verdwijnt ook aan de andere kant. Zelfs de veiligere regel "Prefer Salesforce unless blank" neemt bij de eerste sync van een contact de huidige waarde in Salesforce als uitgangspunt, en die kan een recentere waarde in HubSpot overschrijven.

Veel synctools werken volgens een vergelijkbaar principe: de laatste schrijfactie wint, tenzij je ze iets anders opdraagt. Een hygiëneprobleem in één tool wordt zo een hygiëneprobleem in elke tool die eraan hangt. Wie één systeem opschoont terwijl de syncs ongewijzigd doorlopen, heeft daar plezier van tot de volgende sync.

Geef elk veld één thuis

Systemen die het oneens zijn, los je op met een beslissing. Een opschoonronde helpt daar weinig. Kies voor elk veld dat ertoe doet het ene systeem dat er eigenaar van is, en stel elke sync zo in dat de waarde uit dat systeem wegstroomt en er nooit naar terugkomt.

Een veldkaart hoeft niet ingewikkeld te zijn. Een gedeelde sheet met vijf kolommen volstaat: het veld, het system of record, welke tools het lezen, de syncrichting en wie beslist als de regel verandert. De antwoorden liggen meestal voor de hand zodra iemand de vraag stelt:

• Klantstatus en contractwaarde horen bij de facturatie. Het CRM is daar geen eigenaar van.

• Uitschrijvingen en bounces horen bij de tool die de e-mail verstuurt, en ze moeten doorstromen naar elke andere tool die kan versturen.

• Functietitel en senioriteit horen bij het CRM. Enrichment mag een leeg veld vullen, maar nooit een waarde overschrijven die een rep heeft ingevoerd.

• Productgebruik hoort bij de productdatabase en gaat volgens schema naar het CRM.

Iemand moet eigenaar zijn van de kaart zelf. Bij de meeste bedrijven is dat revenue operations, omdat dat team de tools aan elkaar koppelt. De eigenaar schoont niet elk record op. Die persoon zegt nee als een nieuwe integratie tweerichtingstoegang wil tot een veld waar ze niet aan hoort te komen.

Slechte data is vaak al slecht bij de geboorte

Het is verleidelijk om vervuilde data te zien als schone data die is verouderd. Veel ervan komt al kapot binnen. Harvard Business Review publiceerde een studie waarin 75 leidinggevenden 100 recente records van hun eigen afdeling controleerden. Gemiddeld had 47% van de nieuw aangemaakte records minstens één kritieke fout, en maar 3% van de scores haalde zelfs de ruimste norm die de auteurs acceptabel zouden noemen.

In GTM-systemen komen de fouten steeds van dezelfde plekken: formulieren die alles accepteren, imports die haastig zijn gekoppeld, enrichment-providers die hun eigen formats wegschrijven en integraties die een nieuw record aanmaken omdat ze geen bestaand record konden matchen. Daarom is de methode uit de studie het kopiëren waard. Neem de laatste 100 records die elk systeem heeft aangemaakt, controleer ze met de hand tegen de werkelijkheid en tel hoeveel er helemaal kloppen. Records van vorige week vertellen je iets over je invoerpunten, en dat is een andere vraag dan hoe snel oude records verouderen.

Data hygiene meten over systemen heen

Het Data Quality Framework van de Britse overheid gebruikt zes dimensies die DAMA UK heeft gedefinieerd: volledigheid, uniciteit, consistentie, actualiteit, geldigheid en juistheid. De meeste kun je binnen één tool meten, en CRM hygiene doet dat al. Twee ervan hebben alleen betekenis over tools heen, en die moet een overkoepelende blik toevoegen.

Consistentie is de eerste. Het framework zegt het zonder omwegen: data is consistent als die niet in strijd is met data in een andere dataset. In GTM-termen moeten het CRM en de facturatie het eens zijn over hoeveel klanten je hebt, en moeten de sequencer en het CRM het eens zijn over wie zich heeft uitgeschreven.

Uniciteit is de tweede. Een contact kan in het CRM één schoon record zijn en toch vier keer voorkomen in de sequencer, twee Clay-tabellen en een advertentiedoelgroep, waarbij elke kopie op zichzelf veroudert. Die kopieën herkennen als één persoon of één bedrijf is het werk van identity resolution.

Een paar checks over systemen heen dekken allebei, en ze zijn snel gedaan:

• Het aantal klanten in het CRM tegenover de actieve abonnementen in de facturatie.

• Uitschrijvingen en hard bounces in de verzendtools die ontbreken in de suppressievelden van het CRM.

• Contacten in je actieve sequences die helemaal niet in het CRM staan.

• Het aantal plekken waar één testcontact opduikt als je er overal naar zoekt.

Lopen die cijfers uit elkaar, dan is er een sync kapot of ontbreekt er een. Die sync repareren doet er dan meer toe dan de records opschonen die hij steeds weer kapotmaakt.

Controleer de data op de momenten dat die zich verplaatst

Opschonen volgens de kalender werkt voor één systeem. Over veel systemen heen werkt het beter om checks te koppelen aan de momenten dat data van hand wisselt, want dan verspreiden slechte waarden zich.

• Voor een import. Match tegen bestaande records, koppel elke kolom bewust en weiger rijen die niet door de validatie komen, in plaats van ze te herstellen nadat ze zijn binnengekomen.

• Voordat je een nieuwe sync aanzet. Bepaal de richting per veld en test die op een handvol records, gezien wat een eerste sync kan overschrijven.

• Voor een verzending. Check de lijst tegen de suppressiedata van elke tool die verstuurt, ook van de tools die je deze keer niet gebruikt, en haal adressen eruit die elders al bouncten. Elk dood adres jaagt je bounce rate omhoog en kost sender reputation.

• Voordat een model de data leest. Elk model voor lead scoring, elke AI-agent en elke Clay-workflow handelt op volume op wat het krijgt. Dat is een veelvoorkomende reden dat implementaties van Clay en vergelijkbare tools mislukken. Een rep ziet een duidelijk fout record. Een geautomatiseerde stap mailt ernaar.

• Als je een tool uitfaseert. Exporteer wat je nodig hebt naar het system of record en verwijder de rest, in plaats van een slapende kopie te laten staan.

De meeste van deze checks kunnen als geautomatiseerde stappen draaien in dezelfde koppelingen die de data verplaatsen, als onderdeel van je workflow orchestration. Het is hetzelfde leidingwerk dat je bouwt om sales prospecting te automatiseren, met bij elke overdracht een controlepunt erbij. Je coverage rate bepaalt hoe ver enrichment de gaten kan vullen, dus het controlepunt moet ook beslissen wat er gebeurt met een record dat niet compleet te krijgen is.

Verwijderen hoort ook bij data hygiene

De meest onderschatte hygiënetaak is dingen weggooien. Oude exports, eenmalige Clay-tabellen, de eventlijsten van vorig jaar en de contacten in een markt waar je niet meer aan verkoopt, verouderen allemaal door. Zolang ze bestaan, importeert iemand ze vroeg of laat opnieuw.

Er is naast een praktische ook een juridische reden. De uitleg van de Britse toezichthouder over opslagbeperking zegt dat je persoonsgegevens niet langer mag bewaren dan je ze nodig hebt, en dat je periodiek moet nakijken wat je hebt en het moet wissen of anonimiseren als je het niet meer nodig hebt. De AVG in de EU kent hetzelfde beginsel. Een prospectlijst die je drie jaar geleden kocht en nooit gebruikte, is een hygiëneprobleem en een complianceprobleem tegelijk.

De uitzondering is je suppressiedata. Uitschrijvingen en do-not-contact-vlaggen zijn het enige wat je overal wilt hebben, actueel in elke tool die kan versturen. Het zijn de gegevens die voorkomen dat je iemand benadert die heeft gevraagd dat niet te doen.

Tot slot

De kern van data hygiene is weten waar je data staat en hoe die beweegt. Records schrobben is maar een klein deel van het werk. Kun je elke opslagplek benoemen, het systeem dat eigenaar is van elk veld en de richting van elke sync, dan wordt het opschonen zelf routinewerk voor automatisering en een korte lijst checks.

De teams die dit fout doen, zijn meestal niet slordig. Ze schoonden het systeem op dat ze konden zien en lieten de syncs, de exports en de bijtabellen draaien zoals eerst, dus de oude waarden kwamen terug. De teams die het goed doen, zien de verbindingen tussen tools als onderdeel van de data, en ze verwijderen wat ze niet meer nodig hebben.

Dat fundament telt elk jaar zwaarder, omdat steeds meer van een modern go-to-market-systeem is geautomatiseerd, en in een geautomatiseerde stap staat niets stil bij de vraag of een record er verkeerd uitziet.

Als we dit voor een klant doen, brengen we eerst elke plek in kaart waar hun GTM-data staat, spreken we de veldeigenaren af met hun team en bouwen we daarna de syncregels en checks in de tools die ze al gebruiken. De kaart laten we achter bij de persoon die hem actueel houdt.

Veelgestelde vragen