Support Universe
Hvad er Change Data Capture (CDC)?
Change Data Capture (CDC) er en metode til at opdage og overføre ændringer i data fra et kildesystem (typisk en database) til andre systemer, næsten i realtid. I stedet for at kopiere hele databaser igen og igen, sender CDC kun de rækker, der er blevet oprettet, opdateret eller slettet, så dine dataforbrugere altid arbejder på friske data.
Hvad består Change Data Capture (CDC) af?
CDC er ikke ét enkelt værktøj, men et mønster for, hvordan du fanger og distribuerer dataændringer sikkert og effektivt. I praksis består en CDC-løsning typisk af flere byggesten:
- Datakilde: Ofte en relationsdatabase (f.eks. Postgres, MySQL, SQL Server) eller et ERP/CRM-lag, hvor “sandheden” ligger.
- Ændringsdetektor: Mekanismen der registrerer inserts, updates og deletes. Det kan ske via transaktionslog (log-baseret), triggers eller tidsstempler/versionering (polling).
- Event/ændringsformat: En struktur for, hvordan ændringen beskrives, fx “før/efter”-værdier, operationstype (I/U/D), tabellen, primærnøgle, tidspunkt og eventuelt transaktions-ID.
- Transportlag: Kø/stream eller API-lag der leverer ændringer videre, fx til en dataplatform, et marketing automation-system eller et CRM.
- Mål/forbrugere: Data warehouse/lake, BI, reverse ETL, søgeindeks, CDP, marketing automation eller interne services.
- Styring og kvalitet: Overvågning, fejlhåndtering, retry, deduplikering og “exactly-once/at-least-once”-strategier samt datavalidering.
Det vigtigste at forstå som B2B-virksomhed er, at CDC handler om kontrolleret datafriskhed: du vælger, hvor tæt på realtid du vil være, og hvilke data der skal bevæge sig hvorhen.
Hvordan fungerer Change Data Capture (CDC)?
CDC fungerer ved at identificere ændringer i kildedata og gøre dem tilgængelige som en strøm af hændelser, som andre systemer kan abonnere på eller hente. Der er tre udbredte måder:
1) Log-baseret CDC
Databaser skriver alle ændringer til en transaktionslog. En CDC-komponent “læser” loggen og omsætter ændringer til events. Fordelen er lav påvirkning af databasen og høj nøjagtighed, fordi du fanger ændringerne der, hvor de faktisk sker.
2) Trigger-baseret CDC
Du opretter database-triggers, der ved ændringer skriver til en “ændringstabel” eller sender beskeder videre. Det kan være relativt enkelt at forstå, men kan belaste databasen, være sværere at versionere og kræver stram governance.
3) Polling (tidsstempler/versionering)
Et job kører med faste intervaller og henter rækker ændret siden sidst (via “updated_at”, versionskolonner eller vandmærker). Det er ofte lettest at komme i gang med, men kan give højere latency, risiko for manglende ændringer (hvis felter ikke opdateres korrekt) og unødvendig belastning.
Uanset metode ender CDC typisk med en pipeline, hvor ændringer:
- identificeres i kilden,
- serialiseres til et standardformat,
- leveres til mål,
- og behandles idempotent (så samme event ikke skaber dobbeltdata).
En vigtig teknisk detalje er, at du bør designe for eventual consistency: der kan forekomme kort forsinkelse, og mål kan være få sekunder/minutter bagud. For mange B2B-processer (rapportering, lead scoring, segmenter) er det mere end tilstrækkeligt.
Hvorfor er Change Data Capture (CDC) vigtigt for B2B-virksomheder?
CDC er især relevant, hvis du arbejder med B2B-leadgenerering, account-based marketing eller datadrevne salgsprocesser, hvor timing og datakvalitet påvirker pipeline direkte.
- Hurtigere reaktion på købssignaler: Når firmadata, adfærd eller CRM-status ændrer sig, kan dine flows reagere samme dag i stedet for efter næste natlige sync.
- Bedre datakvalitet i go-to-market: Mindre risiko for at sælgere og marketing arbejder på forældede kontodata (branche, størrelse, tech stack, status, ejerforhold osv.).
- Lavere omkostninger end fulde genindlæsninger: Du flytter kun ændringer, ikke hele datamængder. Det kan reducere compute, netværk og driftskompleksitet.
- Mere pålidelig rapportering: Når dine BI- og pipeline-rapporter bygger på friske ændringer, bliver attribution, forecast og funnel-analyser mere troværdige.
- Skalerbar arkitektur: CDC gør det nemmere at koble flere systemer på den samme “ændringsstrøm” uden at lave mange skrøbelige punkt-til-punkt-integrationer.
Hvis du arbejder med en tydelig ideel kundeprofil, bliver CDC ekstra værdifuldt: når en virksomhedsprofil eller relation ændrer sig, kan dine segmenter, scoringmodeller og outreach opdateres løbende. Læs mere om at definere og operationalisere din ICP på Cohertas side om ideel kundeprofil.
Hvordan bruges Change Data Capture (CDC) i praksis?
CDC bliver ofte implementeret som en del af din data stack, men værdien opstår først, når du kobler ændringer til konkrete forretningsprocesser. Her er typiske B2B-cases:
Opdatering af CRM og marketing automation med “friske” kontodata
Når du enrich’er konti eller modtager nye virksomhedsdata, kan CDC sikre, at ændringer automatisk slår igennem i dine downstream-systemer. Det kan være alt fra segmenter til personaliserede kampagner og salgsopgaver. Hvis du eksempelvis vil aktivere leads direkte i dine automations, kan du se mulighederne for leads til ActiveCampaign.
Near real-time rapportering og pipeline-overvågning
I stedet for at vente på et natligt ETL-job kan CDC sende ændringer til dit warehouse/lake løbende. Det gør dashboards mere brugbare til daglige beslutninger, især når salg og marketing arbejder i korte cyklusser.
Automatiseret lead routing og prioritering
Når et lead skifter status, en konto får nye signaler, eller en kontakt opdateres, kan du trigge handlinger med det samme: oprette tasks, opdatere ejer, starte en nurtureserie eller eskalere til outbound.
Dataaktivering i leadmotor og søgning efter virksomheder
CDC kan bruges til at holde dine interne datasæt ajour, så søgning og filtrering på virksomheder altid bygger på seneste ændringer. Hvis du arbejder med at aktivere firmadata og finde nye prospects systematisk, kan du læse om Cohertas leadmotor og sådan fungerer Coherta.
Eksport/import flows, hvor du vil undgå manuelle “fuld dump”
Mange B2B-teams starter med CSV-eksporter og manuelle imports. CDC er ofte næste modenhedstrin, hvor du går fra batch til løbende opdateringer. Hvis du stadig bruger filer i dele af din proces, kan du standardisere arbejdsgange via import og export.
Fordele og ulemper
- Fordel: Lavere belastning og hurtigere opdateringer
Du flytter kun ændringer, hvilket typisk giver lavere omkostninger og bedre performance end fulde reloads. - Fordel: Bedre datakonsistens på tværs af systemer
Når ændringer distribueres systematisk, reducerer du “hvilket system har ret?”-diskussioner og manuelle rettelser. - Fordel: Stærkt fundament for automatisering
CDC gør det nemmere at bygge hændelsesdrevne flows (routing, scoring, segmentopdatering, alerts). - Ulempe: Højere krav til drift og governance
Du skal have styr på overvågning, retries, dead-letter håndtering og datavalidering for at undgå stille fejl. - Ulempe: Skemaændringer og versionering kan være komplekst
Når tabeller ændrer struktur, skal dine downstream-forbrugere kunne håndtere nye felter, ændrede datatyper eller fjernede kolonner. - Ulempe: “Næsten realtid” er ikke det samme som realtid
Der vil ofte være latency, og du skal designe processer, der tåler kortvarig forsinkelse og evt. reprocessing.
Typiske misforståelser
- “CDC er kun til data warehousing”
CDC er mindst lige så relevant til operationelle systemer: CRM-opdateringer, marketing automation, alerts og søgeindekser. - “CDC betyder, at vi aldrig behøver en fuld load”
De fleste løsninger kræver en initial fuld indlæsning (snapshot) og derefter ændringer. Du bør også kunne reprocess’e ved fejl. - “Polling er også CDC, så det er det samme”
Polling kan være en CDC-tilgang, men den har andre tradeoffs end log-baseret CDC. I mange miljøer giver log-baseret bedre nøjagtighed og lavere belastning. - “CDC løser datakvalitet af sig selv”
CDC flytter ændringer hurtigt, men hvis kildedata er inkonsistente, flytter du bare problemerne hurtigere. Du skal stadig arbejde med datastandarder, validering og ownership. - “Vi kan bare sende events og så er alt synkroniseret”
Uden idempotens, deduplikering og klar håndtering af deletes kan du skabe datadrift mellem systemer.
FAQ
Hvornår giver CDC mening frem for en daglig batch-eksport?
CDC giver mening, når timing påvirker forretningen: fx lead routing, segmenter, scoring, pipeline-rapportering eller når flere teams arbejder på de samme kontodata. Hvis du kun bruger data til månedlig rapportering, kan batch stadig være fint og billigere at drifte.
Hvilke dataændringer bør du typisk fange?
Start med ændringer, der udløser handling: statusfelter, ejerfelter, segment-/tagfelter, firmografiske nøglefelter og relationer (fx konto-kontakt). Hvis du ikke kan knytte en ændring til en beslutning eller proces, er den ofte lav prioritet i første iteration.
Skal CDC være “real time” for at være værdifuldt?
Nej. For mange B2B-setup er 5–30 minutters latency rigeligt. Det vigtigste er stabilitet, datakonsistens og at dine forbrugere (CRM, automations, BI) kan stole på, at opdateringer kommer løbende.
Hvordan håndterer du sletninger (deletes) i CDC?
Du bør eksplicit modellere deletes i dit ændringsformat og beslutte, om downstream skal hard-delete, soft-delete eller markere data som inaktiv. Mange fejl i CDC-projekter opstår, fordi deletes ignoreres og gamle rækker “lever videre” i mål.
Hvordan hænger CDC sammen med API-integrationer?
CDC beskriver, hvordan ændringer opdages og sendes videre; API’er er ofte transport- eller aktiveringslaget. Hvis du vil integrere virksomhedsdata mere direkte i dine systemer, kan du se mulighederne via Coherta API og guiden til integration af Cohertas API til virksomhedssøgning.
Få dataændringer til at blive til pipeline – ikke bare flere tabeller
CDC skaber først værdi, når du kobler ændringer til din go-to-market: bedre segmenter, hurtigere opfølgning og mere præcis prioritering af konti. Hvis du vil gøre firmadata operationelle i salg og marketing, så du løbende aktiverer de rigtige virksomheder og kontakter, kan du se hvordan Coherta fungerer eller gå direkte til vores leadmotor og vurdere, hvordan den passer til din ICP og dine workflows.