De fleste større organisationer kæmper ikke med mangel på data. De kæmper med, at data ligger spredt i siloer. Salg, marketing, finans, BI og indkøb arbejder ofte i hver deres domæne med egne tools, KPI’er og datastrukturer, som ikke nødvendigvis understøtter virksomhedens samlede datastrategi.
Det bliver særligt tydeligt i marketing. Her er det ofte svært at dokumentere den faktiske effekt på bundlinjen, når kunderejsen går gennem flere systemer, og når konvertering ikke kun sker som et simpelt impulskøb. Samtidig bliver lokale teknologivalg og separate datamodeller hurtigt en strukturel barriere for samarbejde på tværs. For hvem ejer faktisk data definationerne og kan de genskabes når vi bevæger os fra værktøj x til z?
Den klassiske silo-tilgang er også en barriere for at realisere AI i praksis. En ambitiøs (MarTech) AI-strategi bliver hurtigt udfordret af API rate limits, udokumenterede processer, manglende datakvalitet og uklare definitioner. Hvis AI-agenter skal skabe reel værdi, kræver det et centraliseret, velstruktureret og compliant datagrundlag.
I dette indlæg viser jeg et koncept for en composable tracking-arkitektur, hvor Google Tag Manager, Stape, server-side tagging på Azure og Databricks Zerobus Ingest arbejder sammen. Målet er at flytte online adfærdsdata direkte ind i det sted, hvor virksomhedens øvrige data allerede lever – og gøre dem anvendelige til BI, AI, aktivering og bedre beslutninger.
Løsningen: en first-party, composable arkitektur
En umiddelbar påstand er, at løsningen er særligt attraktiv i regulerede industrier f.eks. finans, som er underlagt krav fra eksempelvis GDPR, DORA og AI Act. I disse brancher er det afgørende at have fuld kontrol over sine data, herunder hvordan de opbevares, behandles og anvendes.
Netop derfor kan løsningen være attraktiv, da den giver mulighed for en høj grad af styring, sporbarhed og governance omkring data anvendelsen.
Setuppet er enkelt i princippet: event-streaming starter i klienten og ender direkte i data warehouset. Konkret sender Google Tag Manager Client-side data via Stape Data Tag til Google Tag Manager Server-side (hostet på Azure), som streamer direkte videre til Azure Databricks via Zerobus Ingest.
Hvad skal der bruges for at bygge setuppet?
Komponenterne nedenfor er dem, jeg bruger i demoen. Flere af dem kan udskiftes med alternativer, men principperne er de samme: en rig datalayer, client-side tracking, en server-side gateway, en sikker ingestion-mekanisme og et analytisk lag i Databricks.
- En rig datalayer med forretningskritiske events.
- Google Tag Manager Client-side.
- Stape Data Tag.
- Stape Unique Event ID Variable.
- GTM Server-side provisioneret på Azure.
- Stape Data Client.
- Custom GTM Server-side tag template til streaming mod Databricks.
- OAuth token management i SGTM (En del af min PoC) eller et internt ingestion endpoint i Azure (Anbefalet).
- Azure Databricks Zerobus Ingest.
- Databricks Genie til conversational analytics.
- Databricks Dashboards til standardiseret rapportering.
- Databricks Agentic AI til næste lag af analyse og aktivering.
- Instruction files: system prompts og kontekstdokumenter, der giver Genie og agenter domæneviden om schema, KPI’er og forretningsdefinitioner.
Med dette setup får du:
- 100% kontrol og ejerskab: data bliver i jeres Azure-tenant.
- Egen datamodel: definér egne identifiers og byg forretningsnære begreber som household conversion-rate.
- Thin og thick events: opsaml sikre basis-events før samtykke og berigede events efter samtykke.
- Aktiveringspotentiale: brug adfærd til triggers, segmentering, e-mail, outbound eller agent-baserede flows.
- Real-time data: hvert event kan lande i Databricks med meget lav latency.
- Ingen datasilo: adfærdsdata bliver et dataprodukt, som kan bruges på tværs af BI, marketing, service og AI.
- Ingen sampling eller blackbox-modellering: data er reel, rå og kontrollerbar.
- Composable setup: komponenter kan udskiftes, uden at hele arkitekturen skal bygges om.
Hvad er Databricks Zerobus Ingest?
At ingeste real-time streaming data til Databricks har tidligere krævet en del opsætning: Change Data Capture (CDC), en mellemliggende service bus som Kafka, og tung orkestrering. Det har gjort tærsklen høj – også for MarTech-teams, der ellers har al den nødvendige infrastruktur til rådighed.
Zerobus Ingest fjerner den barriere. Det er en push-baseret, serverless ingestion-API, der skriver data direkte ind i Delta-tabeller styret af Unity Catalog – uden mellemliggende message broker, uden manuel partition-konfiguration og uden broker-management.
Sådan fungerer det i praksis:
- GTM Server-side modtager et event fra browseren via Stape Data Tag og Data Client.
- Et custom server-side tag mapper payloadet til de kolonner, Databricks-tabellen forventer.
- Tagget henter eller genbruger et OAuth access token.
- Eventet bygges som en JSON-række og sendes til Zerobus Ingest endpointet.
- Zerobus validerer schemaet, appender data til Delta-tabellen og returnerer acknowledgment.
For MarTech betyder det, at GTM Server-side kan sende clickstream-events direkte til Databricks i realtid. Online adfærdsdata lander i det samme miljø som jeres øvrige forretningsdata – klar til at blive kombineret, beriget og aktiveret.
Det er præcis her, data-siloen brydes: adfærdsdata er ikke længere isoleret i et tredjeparts-tool, men tilgængeligt i BI og AI-lag sammen med resten af virksomhedens data.
En vigtig forudsætning er dog, at I har styr på jeres digitale dataopsamling og identifiers på tværs af kanaler – fx et konsistent user-id – så data kan forbindes meningsfuldt på tværs af systemer.
Conversational Analytics med Databricks Genie
Når data flyder compliant og i realtid fra browseren til Delta-tabellerne, åbner vi for det mest værdiskabende lag: Conversational Analytics.
I stedet for at forretningen skal oprette en IT-ticket for at få et nyt dashboard, kan man benytte Databricks Genie – en AI-drevet, naturlig sprog-grænseflade direkte oven på jeres Delta-tabeller. Med de rigtige instruktioner og forretningskontekst forstår Genie jeres datamodel og lader forretningsbrugere stille spørgsmål som:
Thin event-spørgsmål (aggregeret – uden samtykke):
- Hvor mange page views fik vi på bilforsikringssiden fra mobilbrugere i sidste uge?
Thick event-spørgsmål (identificerbare/profilerede med samtykke):
- Hvor mange kunder, der ikke har en bilforsikring, har beregnet en pris på en bilforsikring online inden for de seneste 12 måneder, og hvem er de?
- Hvad er konverteringsraten for husstande i København sammenlignet med Aarhus i løbet af de seneste
Det afgørende er ikke kun, at man kan stille spørgsmål i naturligt sprog. Det afgørende er, at Genie kan arbejde oven på de samme Delta-tabeller, som resten af organisationen bruger. Med instruction files kan man beskrive schema, KPI-definitioner, forretningslogik, datakvalitetsregler og begreber som “household”, “conversion” og “qualified lead”. Resultatet er færre BI-tickets, mindre ventetid og hurtigere vej fra spørgsmål til svar.
Se også Databricks’ egen introduktion til Genie One, Genie Agents og Genie Ontology.
Consent og privacy tilgang!
Et vigtigt princip i arkitekturen er, at consent håndteres før data kommer ind i pipelinen – ikke inde i den. Det betyder, at vi kan skelne klart mellem thin events og thick events.
- Thin events: Basis-events, såsom page_view, uden PII og uden bruger-id. Her ved vi typisk ikke, hvem brugeren er, eller kan entydigt identificere den enkelte bruger.
Vi registrerer alene, hvad der er sket. Thin events kan anvendes til sikker og aggregeret måling før samtykke. De kan eksempelvis bruges til at besvare spørgsmål som:Hvor mange beregninger blev der foretaget på bilforsikring i denne måned?Hvor mange sidevisninger havde bilforsikringssiderne?
Thin events understøtter anonym tracking, hvor browseren eller brugeren ikke profileres. Dette er relevant i situationer, hvor brugeren ikke giver samtykke via CMP’en, aktivt afviser cookies eller blokerer dem via browserindstillinger, extensions eller lignende. - Thick events: Profilerede og berigede events (kan f.eks., ske serverside), som vi kender dem i dag. Disse indsamles kun, hvis brugeren giver samtykke via CMP’en. Thick events kan indeholde identifikatorer, segmenter og andre berigende attributter, som gør det muligt at koble adfærd til en specifik bruger eller kundeprofil. Dette giver grundlag for mere avanceret analyse, personalisering, målgruppedannelse og aktivering på tværs af kanaler.
Der er ingen Consent Mode, ingen modellerede huller og ingen blackbox-estimater. Data er enten reel og indsamlet korrekt – eller også eksisterer den ikke. Identifiers kan sættes som server-side first-party cookies på et Azure-subdomæne, og data kan holdes inden for organisationens Azure-tenant. Det gør consent rate-analyse og datakvalitet langt mere transparent.
Hvad kan det bruges til?
Når clickstream-data lander direkte i Databricks, bliver conversion metrics og kundeadfærd tilgængelige for hele organisationen. Det kan bruges til personalisering, A/B-testanalyse, funnel-analyse, household-level metrics, aktivering og agent-understøttede workflows – uden at bygge endnu en isoleret marketing-silo.
Konklusion
Ved at bygge en composable tracker fra GTM Client-side over Stape og GTM Server-side til Azure Databricks via Zerobus Ingest får vi mere end et teknisk tracking-setup. Vi får et first-party fundament, hvor dataopsamling, governance, BI og AI kan hænge sammen på organisationens egne præmisser.
Silo-problemet løses ikke ved at købe endnu et tool. Det løses ved at lade adfærdsdata lande der, hvor resten af virksomhedens data allerede er. Og med Zerobus Ingest er den tekniske barriere væk.