En event-model er rygraden i produktanalyse: den beskriver, hvordan du navngiver og logger brugerhandlinger som events, hvilke properties der følger med, og hvordan du kobler dem til en bruger og en session. Når den er gennemtænkt, kan både product og udviklere svare på de samme spørgsmål uden at skændes om definitioner eller jagte data i forskellige værktøjer.

I denne guide får du en praktisk, dansk opskrift på naming conventions, properties, user/session mapping, GDPR og PII-håndtering samt de vigtigste metrics til activation, retention og feature adoption pr. segment. Du får også konkrete forslag til simple funnels, dashboards der fungerer i hverdagen, og hvordan du bygger minimum viable analytics uden en tung enterprise stack.

Hvad er en event-model, og hvorfor betyder den noget?

En event-model er en struktureret måde at beskrive produktadfærd på, hvor hver brugerhandling registreres som et event med et navn og et sæt properties. Det betyder noget, fordi en stabil event-model gør analyse billigere: mindre fejlsøgning, færre “hvad mente vi med det her?”-møder, og mere tid til at forbedre produktet.

Den typiske værdi er, at du kan gå fra mavefornemmelser til beslutninger baseret på data. Og du kan gøre det uden at bygge et data warehouse først, hvis du vælger en enkel standard og holder dig til den.

Naming conventions: gør events læsbare for både product og dev

Eventnavne er dit API til analyse. De skal være stabile, konsistente og forståelige uden kontekst. Vælg én stil og skriv den ned, så den overlever teamskift og refactors.

Anbefalet navnestruktur

En robust konvention er at bruge “substantiv + verbum” eller “objekt + handling”, fx “project_created” eller “invoice_sent”. Undgå at starte med “clicked” overalt; klik er ofte et UI-detaljeniveau, mens produktspørgsmålet handler om handlingen.

• Brug lowercase og underscores, fx “settings_saved”
• Undgå mellemrum, punktummer og tilfældig camelCase
• Hold navne handlingsorienterede: “report_exported” frem for “export_button_clicked”
• Versionér sjældent; brug hellere properties til variation
• Navngiv ud fra domæne, ikke UI: “trial_started” frem for “pricing_modal_opened”
• Reserver et prefix til system-events, fx “system_error”

Faldgruber ved navngivning

Den mest almindelige fejl er at lade events afspejle skærmbilleder, der ændrer sig. Så mister du historik og kan ikke sammenligne over tid. En anden klassiker er duplikerede navne med forskellig betydning på tværs af platforme.

Mini-konklusion: Hvis eventnavne kan læses som sætninger, kan de også diskuteres som produktadfærd i stedet for tracking-teknik.

Properties: få kontekst uden at drukne i felter

Et event uden properties er ofte for fattigt til at forklare hvorfor noget sker. Omvendt kan for mange properties blive en vedligeholdelsesbyrde og en GDPR-risiko. Målet er et lille, veldefineret sæt, der giver segmentering og debugging.

Core properties, du næsten altid bør have

Start med et basis-sæt på tværs af alle events, så dashboards ikke bliver et patchwork:

1. user_id (intern, stabil identifikator)
2. session_id (til at bygge simple funnels og session-analyse)
3. platform (web, ios, android, server)
4. app_version eller build
5. locale/timezone (til UX og support)
6. source/utm (til acquisition og aktivering)

Event-specifikke properties

Tilføj kun det, der svarer på et spørgsmål: “Hvilken feature?”, “Hvilken plan?”, “Hvor stor var filen?”, “Hvilken skabelon?”. Brug enums frem for fritekst, og dokumentér tilladte værdier.

Mini-konklusion: En god property er én, du faktisk bruger i segmenter eller fejlsøgning inden for to sprint.

User og session mapping: fra anonym til kendt uden huller

Mapping mellem anonym aktivitet og en kendt bruger er afgørende for activation og retention. Det er her mange teams mister data, fordi login, cookies og device-id’er blandes sammen uden klare regler.

Identitetsflow i praksis

En simpel model er: du har en “anonymous_id” ved første besøg, og når brugeren opretter sig eller logger ind, binder du den aktivitet til din interne user_id. Hvis brugeren logger ud, fortsætter sessioner stadig, men events bør stadig bære den anonymes identitet.

Som tommelfingerregel: log altid user_id når du kan, og ellers anonymous_id. Undgå at bruge email som id, selv internt.

Sessioner der giver mening

Session_id kan være en UUID pr. app-start eller pr. 30 minutters inaktivitet, men beslutningen skal være ensartet. Sessioner bruges til simple funnels og til at se, om en bruger “nåede noget” i én sammenhængende oplevelse.

Mini-konklusion: Identitet er ikke bare tracking; det er fundamentet for at kunne måle brugerrejser uden at forvride tallene.

GDPR og PII: sådan logger du nyttigt uden at gemme for meget

GDPR handler ikke om at undgå analytics, men om at håndtere data ansvarligt. PII (personhenførbare oplysninger) som navn, email, telefon, præcise adresser og fritekst kan hurtigt snige sig ind i event-streams via formularfelter og URL’er.

Lav en enkel politik: Events må ikke indeholde PII i navne eller properties. Hvis du har et legitimt behov for at genkende en bruger, så brug en intern, pseudonymiseret user_id og gem de personlige data i dit primære system, ikke i trackinglaget.

• Maskér eller strip querystrings fra URLs, hvis de kan indeholde tokens
• Log kun sidste 2-3 cifre af en postnummer-zone, hvis du skal bruge geografi
• Brug allowlists for properties, ikke “log alt”-SDK defaults
• Sæt retention på rå events, fx 90-180 dage, afhængigt af formål
• Dokumentér behandlingsgrundlag og samtykke-flow, hvor det er påkrævet

Midt i arbejdet med adoption kan det være nyttigt at standardisere, hvordan du følger usage uden at opsamle unødvendige detaljer; en pragmatisk tilgang er at fokusere på feature-koder og plan-niveau og lade UI-tekst og fritekst blive udenfor. Et eksempel på en konkret tilgang er at track feature usage med stabile feature-identifikatorer og tydelige segmenter, så du kan analysere adfærd uden at gemme persondata.

Mini-konklusion: Privacy-by-design gør din analytics mere robust, fordi du undgår data, du senere skal slette, filtrere eller forklare.

Activation og retention: metrics der faktisk kan styre et produkt

De fleste teams måler enten alt for lidt (kun signups) eller alt for meget (hundrede grafer uden ejerskab). Start med metrics, der knytter sig til værdiskabelse: activation er “første gang brugeren oplever værdi”, retention er “kommer de tilbage og gør det igen”.

Definér activation som et adfærdskriterie

Activation bør være et event eller en kort sekvens, fx “workspace_created” + “first_item_added”. Sæt en tidsramme, fx inden for 24 timer fra signup. Hvis du kun måler “konto oprettet”, får du falsk optimisme.

Retention uden enterprise-setup

Retention kan måles som “returning users” pr. uge eller måned, baseret på et kerne-event. Vælg én primary metric, fx “items_completed”, og mål hvor mange brugere der gør det i uge 1, 2, 3 efter deres første uge. Det behøver ikke være mere kompliceret for at være nyttigt.

Mini-konklusion: Når activation og retention er bundet til konkrete events, bliver roadmap prioritering en diskussion om adfærd, ikke om holdninger.

Feature adoption pr. segment: lær hvem der får værdi, og hvem der sidder fast

Feature adoption er ikke bare “hvor mange klikker”; det er “hvilke brugere bruger funktionen som en del af deres workflow”. Du får mest ud af at segmentere efter rolle, plan, branche, teamstørrelse eller use case.

Segmenter med få, stabile dimensioner

Vælg 3-6 segment-properties, der er lette at holde korrekte. Eksempler: plan_type, seat_count_bucket, role, onboarding_source og industry. Undgå at segmentere på for mange ting på én gang; så får du små tal og tilfældige konklusioner.

Mål adoption som rate og som tid-til-adoption

To gode KPI’er er “% af aktive brugere der bruger feature X pr. uge” og “median tid fra signup til first_use af feature X”. Kombinér dem, så du ser både udbredelse og hastighed.

Mini-konklusion: Segmenteret adoption viser, om problemet er produktet generelt eller kun for bestemte brugertyper.

Simple funnels: nok til at finde lækager uden at bygge et BI-projekt

Funnels behøver ikke være fancy. En enkel funnel kan afsløre, om brugere falder fra ved invitation, import, betaling eller første succes. Det vigtige er, at hvert step har en klar event-definition og at rækkefølgen giver mening.

Et godt startpunkt er 3-5 steps, fx: signup_completed → onboarding_finished → first_value_event → second_value_event → subscription_started. Hold hvert step så tæt på værdiskabelse som muligt, ellers optimerer du på kosmetik.

1. Definér hvert step med præcist eventnavn og evt. filter på property
2. Vælg tidsvindue, fx 7 dage fra signup
3. Split på segmenter: plan_type eller source
4. Undersøg top 2 frafaldspunkter, ikke alle
5. Tilføj kun nye steps, hvis de ændrer beslutninger

Mini-konklusion: Den bedste funnel er den, der fører til én konkret ændring i produkt eller onboarding inden for en uge.

Dashboards for product og dev: fælles sandhed, hurtig fejlfinding

Dashboards fejler ofte, fordi de enten er for højt niveau til udviklere eller for tekniske til product. Løsningen er at lave to lag: et product-dashboard med de få styrende metrics og et dev-dashboard med datakvalitet og tracking-sundhed.

Product-dashboard: 6-10 grafer der styrer beslutninger

Hold det simpelt: activation rate, retention curve, DAU/WAU, funnel conversion, top features pr. segment og error-impact på kernerejser. Tilføj annotationer ved releases, så man kan se, hvornår noget ændrede sig.

Dev-dashboard: datakvalitet som first-class

Udviklere har brug for at se: event-volume pr. platform, andel events uden user_id, nye/ukendte eventnavne, property-null rates, og spikes i “system_error”. Hvis tracking kan bryde uden alarm, vil den bryde.

Mini-konklusion: Når product og dev deler definitioner, kan I løse både adfærdsproblemer og instrumentation hurtigt.

Minimum viable analytics: sådan kommer du i gang uden enterprise stack

Hvad koster det? Det afhænger af volumen og behov, men du kan komme langt med et lille setup: en event-spec (i et dokument), et tracking-bibliotek, og et enkelt analyseværktøj eller en letvægts pipeline til et databasebord. Den dyreste del er typisk ikke licensen, men tiden brugt på uklare krav og efterfølgende oprydning.

Start med en “MVA”-pakke: 10-20 events, et standard property-sæt, og tre dashboards. Instrumentér de vigtigste flows først, og udvid kun, når der er et beslutningsbehov. Vær bevidst om scope: du bygger et beslutningssystem, ikke et datamuseum.

• Lav en event-katalogside med navn, beskrivelse, properties, ejerskab
• Gennemfør en ugentlig tracking-review i 20 minutter
• Test events i staging med faste scenarier
• Sæt alerts på pludselige fald i nøgle-events
• Planlæg oprydning: deprecate events i stedet for at lade dem leve evigt

De klassiske fejl er at tracke alt fra dag ét, at bruge ustabile navne, at gemme PII i properties, og at mangle ejerskab. Bedste praksis er at holde standarder små, dokumentere dem, og iterere med fokus på de spørgsmål, der driver produktet frem.

Mini-konklusion: Minimum viable analytics handler om at skabe en pålidelig feedback-loop med få events, klare definitioner og lav vedligeholdelse.