Overblik: Hvornår giver BigQuery mening for marketing og data teams?

BigQuery er relevant for din virksomhed, når I vil samle marketing- og salgsdata ét sted, analysere på tværs af kanaler og slippe for at være begrænset af regneark og enkeltværktøjers rapporter. Løsningen kan være meget billig i licens, men kræver, at du har styr på dataflow, governance og drift, hvis det ikke skal blive en dyr og uoverskuelig platform.

Hvis du i dag bruger Google Analytics 4 (GA4), Google Ads, sociale medier, webshop og CRM, men kæmper med at få et samlet billede af kunder, kampagner og omsætning, er det typisk dér, BigQuery begynder at give mening. Det er især interessant for virksomheder med:

• betydelige online-aktiviteter (e-handel, leadgenerering eller abonnementsforretning)
• flere marketingkanaler, som skal sammenlignes og styres ud fra ROAS, LTV og CAC
• et data- eller marketingteam, der kan arbejde (eller vil lære at arbejde) med SQL-forespørgsler.

Nedenfor går vi systematisk gennem, hvad BigQuery er, hvilke marketing-use cases der typisk giver mest værdi, hvad det koster i praksis, hvordan du kommer i gang på 30 dage, og hvad du skal have på plads omkring GDPR og governance.

Hvad er BigQuery?

BigQuery er et serverless cloud data warehouse, der samler og analyserer data fra flere kilder, så marketing- og data teams kan arbejde med ét fælles datagrundlag.

I praksis betyder det, at du ikke køber en server eller database, men bruger Googles infrastruktur til at lagre og analysere meget store datamængder. Du betaler typisk kun for pladsen (storage) og den datamængde, du analyserer (queries), uden selv at skulle drifte hardware.

BigQuery er særligt anvendeligt som centralt datalag til marketing, fordi det kan modtage data fra blandt andet:

• GA4 (standardintegration til event- og konverteringsdata)
• Google Ads, andre annonceplatforme og fx Search Console
• webshop og betalingsgateway
• CRM og kundesystemer
• offline-kilder som POS eller telefonisk salg (via batch- eller streaming-indlæsning).

Det afgørende er, at BigQuery ikke er et dashboard-værktøj og ikke et klassisk drifts- eller transaktionssystem. Det er en analysemotor og et datalager oven på dine kilder. Visualisering sker typisk i fx Looker Studio, Power BI eller et andet BI-værktøj, der kobles ovenpå.

En enkel måde at tænke på det er:

For danske virksomheder, der allerede er dybt i Googles økosystem (GA4, Google Ads, YouTube, Performance Max mv.), er BigQuery ofte det mest naturlige data warehouse-valg, fordi integrationerne er tætte og velunderstøttede.

Hvad kan BigQuery bruges til i marketing?

BigQuery bruges i marketing til at samle kampagne-, adfærds- og salgsdata, så teams kan lave bedre segmentering, attribution, rapportering og aktivering på tværs af kanaler.

I stedet for at trække enkeltstående rapporter ud af GA4, Google Ads, Facebook osv., giver BigQuery dig et samlet datagrundlag, hvor du kan stille spørgsmål på tværs: Hvilke kampagner skaffer kunder med høj livstidsværdi? Hvilke kanaler giver reelt overskud, når vi tager CAC med? Hvordan ser kunderejsen ud for de mest værdifulde segmenter?

Nedenfor er en forenklet matrix over typiske marketing-use cases, prioriteret efter værdi, datakrav og kompleksitet.

Use cases i “første bølge”: hurtig værdi med begrænset kompleksitet

I denne fase handler det typisk om at erstatte manuelle Excel-rapporter og inkonsistente tal med ét samlet billede. Det kræver primært, at GA4 er koblet rigtigt til BigQuery, og at du har en simpel datamodel, som BI-værktøjet kan læse.

Use cases i “anden bølge”: kundeværdi og profitabilitet

Her begynder du at kombinere adfærdsdata med rigtige salgstal og eventuelt dækningsbidrag. Det kræver typisk tættere samarbejde mellem marketing, økonomi og evt. data/IT. Til gengæld får du et væsentligt bedre grundlag for investeringsbeslutninger og kan se, hvilke kunder der reelt er værd at tiltrække og fastholde.

Use cases i “tredje bølge”: avanceret attribution og aktivering

Disse use cases kræver en mere moden dataplatform, ofte med klare processer for datakvalitet, modellering og governance. Det kan være fornuftigt at overveje, om noget af aktiveringen skal ske via en egentlig Customer Data Platform, mens BigQuery er “motoren” i bunden.

En praktisk tommelfingerregel: Start altid med overblikket (første bølge), bevæg dig videre til kundeværdi og profit (anden bølge), og gem avanceret attribution og predictive modeller til du har styr på de grundlæggende data og processer.

Hvad koster BigQuery for marketingteams?

BigQuery kan være meget billigt for små teams, men den samlede pris afhænger af storage, data der scannes i queries, dataintegration og drift.

Det er vigtigt at skelne mellem selve BigQuery-prisen og den samlede løsning. Selve BigQuery-fakturaen kan i starten være tæt på nul, hvis du ligger under Googles gratisniveau (free tier). Men når du medregner data-connectors, eventuel ETL/ELT, dashboarding og løbende vedligeholdelse, ændrer billedet sig.

Grundlæggende prislogik: storage og queries

BigQuerys prismodel består grundlæggende af to hovedelementer:

• Storage: Hvad det koster at opbevare dine data pr. måned.
• Query processing: Hvad det koster, når BigQuery scanner data for at besvare dine SQL-forespørgsler.

Derudover findes to overordnede betalingsmodeller for query processing:

• On-demand pricing: Du betaler per terabyte (TiB) scannet data, efter et månedligt gratisniveau.
• Capacity/flat-rate (BigQuery Editions): Du betaler for en fast kapacitet (slots), hvilket giver mening ved større, mere stabile belastninger.

Free tier og vejledende on-demand priser

Googles officielle model (på publicerede priser) indeholder per måned:

• ca. 10 GiB gratis storage
• op til ca. 1 TiB gratis query processing
• derefter on-demand query pricing fra omkring 6,25 USD pr. TiB scannet data.

Priserne varierer efter region og kan ændre sig, så de skal altid tjekkes i den officielle prisdokumentation, før du laver egentlige budgetter. Valutaomregning til DKK skal betragtes som vejledende.

Eksempler på query-omkostninger (on-demand)

Nedenstående tabel illustrerer udelukkende selve BigQuery query-omkostningen ved on-demand pricing, hvis free tier allerede er opbrugt. Omregningen til DKK er kun et groft eksempel.

Selv relativt store datamængder kan altså være billige i ren BigQuery-licens, hvis dine queries er nogenlunde optimerede. Omvendt kan dårligt designede queries, der scanner enorme ubrugte datamængder, hurtigt fordyre driften unødigt.

TCO: Den samlede økonomi omkring BigQuery

For en virksomhed er den vigtige størrelse ikke kun BigQuery-linjen på kreditkortet, men den samlede TCO (Total Cost of Ownership) for dataplatformen. En simpel TCO-model for et marketing-setup kan se sådan ud:

En lille marketingafdeling kan ofte starte på et niveau, hvor:

• selve BigQuery-kontoen ligger på eller tæt ved free tier
• de største faste udgifter er connectors og evt. ekstern hjælp til opsætning
• den vigtigste “omkostning” er internt tidsforbrug.

Større teams med mange kampagner, flere lande og komplekse datamodeller får ofte en mere betydelig TCO, hvor det kan være oplagt at lave en egentlig business case. Her kan det give mening at inddrage viden fra fx kategorien om investeringer og business cases.

Hvornår giver capacity/flat-rate mening?

Hvis dit forbrugsmønster er stort og stabilt, kan kapacitetsbaserede BigQuery Editions være billigere og mere forudsigelige. Det kræver dog:

• rimelig god forståelse af dit nuværende og forventede query-forbrug
• et vist volumen, før besparelsen reelt opstår
• at du har nogen i huset eller hos leverandøren, der kan styre kapacitetsplanlægning.

De fleste danske marketingteams starter fornuftigt på on-demand og revurderer, hvis datamængden og brugen vokser markant.

Sådan kommer du i gang med BigQuery på 30 dage

Du kommer bedst i gang ved først at definere et konkret forretningsmål, derefter forbinde de vigtigste datakilder og til sidst bygge en simpel datamodel og et første dashboard.

Det er fristende at starte i Google Cloud Console og klikke løs, men erfaringen er, at du får en mere bæredygtig løsning, hvis du tænker business først og teknik bagefter. Her er en realistisk 30-dages plan, som både marketing og data/IT kan samles om.

Uge 1: Forretningsmål og datakilder

I første uge skal du beslutte, hvorfor I overhovedet vil bruge BigQuery.

• Definer mål: Vælg 1-2 konkrete formål, fx “fælles marketing-dashboard til ledelsen” eller “bedre ROAS-styring på tværs af kanaler”.
• Identificer KPI’er: Fx omsætning, dækningsbidrag, ROAS, CAC, LTV, konverteringsrate.
• Kortlæg datakilder: Hvilke systemer skal med i første iteration (GA4, Ads, webshop, CRM, email)?
• Aftal roller: Hvem har ansvar for data, for den tekniske opsætning og for rapporteringen?

Det er ofte her, marketingchefen, økonomiansvarlig og eventuel dataansvarlig mødes og aftaler succeskriterier. En del af dette hænger naturligt sammen med generelle overvejelser om valg af systemer og integrationer.

Uge 2: Opret Google Cloud-projekt og BigQuery

Nu kan du sætte det tekniske fundament.

• Opret eller brug en eksisterende Google Cloud-konto.
• Opret et nyt projekt til marketing-data (så drift og test evt. kan adskilles).
• Tilknyt en billing account og sæt budget alerts op.
• Aktiver BigQuery API i projektet.
• Vælg region for datalagring (typisk EU-region for danske virksomheder).
• Opret en service account til dataindsamling og definér adgangsroller via Cloud IAM.

Her er det en god idé at tænke over, hvem der skal have læse- og skriveadgang, og hvem der alene skal kunne se rapporter. Det handler både om sikkerhed og om at reducere risikoen for dyre, fejlagtige queries.

Uge 3: Forbind GA4 og de første datakilder

Med projektet på plads er næste skridt at få data ind.

• Konfigurér GA4 BigQuery-export (daglig eller streaming afhængig af behov).
• Opret datasets i BigQuery til henholdsvis rådata og modellerede data (fx raw og analytics).
• Vælg metode til andre kilder: native connectors, tredjeparts ETL/ELT-værktøjer eller egne scripts.
• Sørg for, at mindst én vigtig ikke-GA4 kilde (fx webshop eller Ads) også er koblet på.

Når de første data ligger i BigQuery, kan du begynde at skrive simple queries for at kontrollere volumener og datakvalitet. Her er det en fordel, hvis én i teamet har grundlæggende SQL-kompetencer, eller I får hjælp udefra.

Uge 4: Byg første datamodel og dashboard

Den sidste uge handler om at omsætte data til noget, virksomheden faktisk bruger.

• Definér en enkel datamodel, der samler relevante tabeller i overskuelige views (fx sessions, konverteringer, kampagner, omsætning).
• Byg en første rapport i et BI-værktøj, fx Looker Studio eller et andet, I allerede bruger.
• Fokuser på få, vigtige KPI’er og visuelle elementer frem for 25 detaljerede faner.
• Test rapporten sammen med marketing- og ledelsesteamet og justér.
• Dokumentér kort, hvilke datakilder, tabeller og views rapporten bygger på.

Målet efter 30 dage bør ikke være en perfekt dataplatform, men et velfungerende første use case, der beviser værdien og giver erfaring med BigQuery i jeres organisation. Derefter kan du bygge ud i bølger med flere use cases, som beskrevet tidligere.

Hvordan sikrer du governance og GDPR i BigQuery?

BigQuery kan bruges sikkert i danske setups, men GDPR, databehandleraftaler, adgangsstyring og dataplacering skal være på plads, før løsningen går i drift.

Det er vigtigt at understrege, at BigQuery i sig selv ikke gør dine data GDPR-kompatible. Værktøjet giver tekniske muligheder som kryptering og adgangsstyring, men ansvaret for lovlig behandling, formål, samtykke og sletning ligger stadig hos virksomheden.

Dataplacering og EU-datalagring

Som udgangspunkt bør danske virksomheder vælge en EU-region til deres BigQuery-datasets. Det reducerer juridisk kompleksitet i forhold til dataplacering. Du skal dog stadig have styr på, om der indgår overførsel til tredjelande, leverandøraftaler og tekniske/organisatoriske sikkerhedsforanstaltninger.

Databehandleraftaler og roller

Når du bruger BigQuery, optræder Google som databehandler for de personoplysninger, du lægger i platformen. Der skal derfor være en databehandleraftale på plads, typisk via Googles standardvilkår, og du skal internt have afklaret:

• Hvem er dataansvarlig (ofte virksomheden selv)?
• Hvilke formål behandles persondata til (marketinganalyse, rapportering mv.)?
• Hvilke behandlingshjemler bruger I (samtykke, interesseafvejning, kontrakt)?

Hvis der behandles følsomme data eller større mængder persondata, kan en vurdering af konsekvenser for databeskyttelse (DPIA) være relevant. Her kan materiale om persondata og informationssikkerhed give et godt udgangspunkt.

Adgangsstyring og Cloud IAM

Adgangsstyring er både et sikkerheds- og governance-argument. Ved hjælp af Cloud IAM kan du:

• begrænse hvem der kan oprette og ændre datasets og tabeller
• styre hvem der kan køre queries, og hvem der blot kan læse resultater via dashboards
• logge og revidere, hvem der har tilgået hvilke data (audit logs).

En robust governance-model deler ofte rollerne op i fx:

• platform-ejer (IT/data), der styrer struktur, rettigheder og omkostninger
• data steward for marketingdata, der har ansvar for datakvalitet og dokumentation
• forretningsbrugere (marketing, ledelse), der primært ser dashboards og kører simple analyser.

Dataminimering, retention og sletning

For at leve op til GDPR-principperne om dataminimering og opbevaringsbegrænsning bør du:

• undgå at indsamle og lagre flere persondata, end du har brug for til definerede formål
• sætte klare retention-politikker (fx hvor længe rå events fra GA4 skal ligge i BigQuery)
• have procedurer for sletning eller pseudonymisering, når formålet ikke længere er aktuelt.

Samtidig skal tracking og datagrundlag hænge sammen med jeres cookie- og samtykkepraksis, fx via consent mode eller alternativer som beskrevet i guiden om GDPR-venlig tracking.

Hvornår skal du vælge BigQuery frem for alternativer?

BigQuery er stærkest, når du allerede arbejder i Google-økosystemet, vil samle flere datakilder og har brug for fleksibel analyse snarere end et simpelt BI-lag.

Der findes andre data warehouse-løsninger som fx Snowflake, Amazon Redshift og Azure-baserede platforme. De kan være bedre valg i nogle situationer. Beslutningen bør ikke handle om mærkeloyalitet, men om konkrete kriterier.

Hvis I primært køber BigQuery for at få pænere dashboards, kan det være tegn på, at problemet i virkeligheden er jeres BI-opsætning og ikke datalageret. Omvendt, hvis I mærker klare begrænsninger i Excel og standardrapporter, og I mangler et fælles datagrundlag, er BigQuery eller et tilsvarende warehouse typisk næste skridt. Her kan det være nyttigt at se på indhold om dataanalyse og BI generelt.

Hvilke fejl og faldgruber skal du undgå?

De største fejl er næsten altid manglende datastyring, ukontrollerede queries, dårlig datakvalitet og et uklart ansvar for drift og vedligeholdelse.

Teknisk set er det nemt at komme i gang med BigQuery. Udfordringen opstår ofte 6-18 måneder senere, når ingen helt kan forklare, hvad der ligger hvor, og hvorfor fakturaen og kompleksiteten er vokset. Her er nogle typiske faldgruber og måder at forebygge dem på.

1. Ukontrollerede queries og unødige omkostninger

Faldgrube: Brugere kører brede SELECT *-queries på store, uparitionerede tabeller uden filtre. Det scanner enorme datamængder og kan gøre on-demand-regningen unødigt høj.

Modtræk:

• indfør en simpel query-standard (filtrer på dato, brug kun relevante kolonner)
• brug partitionering og eventuelt clustering på større tabeller
• sæt budget alerts og cost dashboards op.

2. Råtabeller uden struktur og dokumentation

Faldgrube: Alt data lander i én stor bunke af råtabeller, som ingen har navngivet eller dokumenteret. Efter noget tid ved ingen, hvilke tabeller der er “de rigtige”.

Modtræk:

• adskil raw og analytics-datasets fra start
• lav simple views med meningsfulde navne til brug i rapporter
• dokumentér i et kort notat eller wiki, hvad de vigtigste tabeller og views indeholder.

3. Manglende datakvalitet og uafklarede definitioner

Faldgrube: To dashboards viser forskellige omsætningstal, fordi de bygger på forskellige kilder eller definitioner. Tilliden til rapportering falder.

Modtræk:

• bliv enige om, hvilke kilder og definitioner der gælder for centrale KPI’er
• byg fælles, dokumenterede views til disse KPI’er i BigQuery
• lad BI-rapporterne bruge de samme views i stedet for egne udtræk.

4. Governance og ansvar kommer for sent

Faldgrube: BigQuery starter som et eksperiment og ender som kritisk infrastruktur, uden at der er afsat tid eller ansvar til drift, sikkerhed og compliance.

Modtræk:

• udpeg en platform-ejer og en data steward for marketingdata tidligt
• aftal minimumsniveau for dokumentation, adgangsstyring og datapolitikker
• tænk BigQuery ind i jeres generelle compliance- og governance-arbejde.

Hvad kan BigQuery ML bruges til?

BigQuery ML er nyttigt til forecasting og klassifikation, men det er sjældent første skridt for et marketingteam, der stadig bygger sin datamodel og governance op.

BigQuery ML gør det muligt at træne og køre maskinlæringsmodeller direkte på dine data i BigQuery, uden at flytte dem til andre systemer. Typiske marketingrelevante anvendelser kan være:

• forecasts for omsætning, trafik eller konverteringer (regressionsmodeller)
• churn-prediktioner, hvor kunder klassificeres efter risiko for at forlade dig
• segmentering via clustering, fx til mere målrettede kampagner.

Det giver bedst mening at tage BigQuery ML i brug når:

• dine grunddata er relativt stabile og veldokumenterede
• du har konkrete spørgsmål, som simple rapporter ikke kan besvare (fx “hvem er mest tilbøjelige til at købe igen?”)
• teamet har adgang til datafolk eller eksterne partnere med ML-erfaring.

Hvis du stadig kæmper med grundlæggende tracking, simple dashboards og datakvalitet, er det normalt bedre at investere tiden dér først. Når fundamentet er på plads, kan BigQuery ML være en naturlig del af en bredere indsats for automatisering og AI, som også behandles i vores tekster om automatisering og AI i praksis.

Konkrete næste skridt for din virksomhed

Hvis du står med beslutningen om BigQuery til marketing og data, kan du bruge denne korte tjekliste som næste skridt:

• Afklar behovet: Hvilke 1-2 use cases skal BigQuery løse først (fx samlet marketing-dashboard, bedre ROAS-styring, RFM-segmentering)?
• Vurdér økonomien: Estimér forbrug (storage, queries) og læg connectors, dashboards, implementering og drift oveni. Brug gerne principperne fra business case-arbejde til at se, om gevinsterne realistisk overstiger udgifterne.
• Beslut arkitektur: Skal BigQuery være jeres centrale marketing data warehouse, eller skal det indgå sammen med en CDP eller andre systemer?
• Planlæg opstart: Lav en 30-dages plan med klare roller og leverancer, så I får første værdi hurtigt.
• Sikre governance og GDPR: Vælg EU-region, få databehandleraftale og adgangsstyring på plads, og dokumentér jeres databehandling.

For mange danske virksomheder bliver BigQuery et vigtigt element i den samlede marketing- og data-strategi, men kun når det kobles tæt til forretningsmål, økonomi og governance. Hvis du har brug for at drøfte netop jeres situation og organisering, kan det også være relevant at se på viden om IT-ledelse og drift eller kontakte en rådgiver, der både forstår data og bundlinje.