Hvilken artikel lukkede handlen?

Enhver virksomhed, der skriver noget som helst, får til sidst den samme diskussion. Nogen spørger, om bloggen er det værd. En anden siger, at trafikken er oppe. En tredje påpeger, at trafik ikke er omsætning. Og så kigger alle på to dashboards — ét der ved, hvor mange der læste indlægget, og ét der ved, hvem der skrev under — og opdager, at ingen af dem kan sætte de to kendsgerninger i samme sætning. Diskussionen slutter, hvor den begyndte, og bloggen overlever på tro endnu et kvartal.

Kan du sige, hvilket blogindlæg der førte til et salg?

Kun hvis to ting er sande: at din analyse registrerer en rejse per person frem for aggregerede tal, og at den rejse kobles til den samme kundepost, dine handler ligger på. De fleste stakke fejler på den anden test frem for den første. Sidevisningerne findes, den vundne handel findes, og koblingen mellem dem var en person, ingen gemte.

Spørgsmålet er værd at formulere præcist, fordi »attribution« bruges om flere forskellige job. Dette er ikke sidste-berøring-attribution på et annonceklik, og det er ikke en markedsmiksmodel. Det er et meget mindre og meget mere besvarligt spørgsmål: for denne navngivne kontakt, der blev kunde, hvad læste de, i hvilken rækkefølge, før de tog kontakt.

Hvorfor kan Google Analytics ikke svare på det?

Den kan holde formen på svaret og så smide det væk. GA4 er brugerafgrænset og på hændelsesniveau, så en rejse per person er arkitektonisk mulig. Problemet er opbevaringen: på en standardproperty kan data på bruger- og hændelsesniveau beholdes i 2 måneder eller 14 måneder — det er de eneste to muligheder — og standarden er 2. Længere vinduer på 26, 38 og 50 måneder findes kun i Analytics 360, og 360-priser er ikke publiceret nogen steder på Googles egne sider.

Det betyder noget, fordi B2B-salgscyklusser er længere end opbevaringsvinduet. Nogen læser tre artikler i marts, kommer tilbage i oktober og skriver under i november. På en standard-GA4-property blev marts-læsningerne slettet i maj. Opbevaringskontrollen bider også hårdere, når du vokser: når en standardproperty bliver »stor«, sænkes opbevaringen på hændelsesniveau automatisk til 2 måneder, og ældre data slettes permanent.

Og selv inde i vinduet kender GA4 ikke dine handelsfaser. Du eksporterer fra ét system og kobler i et tredje.

Hvad med Plausible og Fathom?

De er glimrende, og de kan ikke svare på dette spørgsmål — ikke som et hul, men som hele designet. Det er værd at være præcis om, hvor tilsigtet det er, fordi det er den mest principfaste ingeniørkunst i kategorien.

Plausible tæller en unik besøgende som hash(dagligt_salt + websteds_domæne + ip_adresse + user_agent), roterer og sletter saltet hver 24. time og gemmer aldrig rå IP eller user agent. Deres datapolitik er utvetydig: »Alle data er isoleret til én dag, ét websted og én enhed.« Fathom gør det samme og går videre ved at runde tidsstempler op til nærmeste time netop for, at deres egne adgangslogge ikke kan krydsrefereres mod deres browsingdatabase. Begge er cookiefri. Begge holder ingen data på personniveau overhovedet — et bevidst omfangsvalg, og et andet end Munins.

Plausible leverer ganske vist en funktion, der hedder User Journeys på Business-planen, og navnet er let at mislæse. Det er aggregeret stiudforskning — vælg en side, se hvad folk gjorde ét og to trin senere, med sider automatisk grupperet efter mappe og frafaldstal ved siden af. Ingen enkeltperson eksponeres på noget tidspunkt, fordi ingen enkeltperson findes i data at eksponere.

Så den ærlige indramning er et valg mellem to veje, ikke en rangordning. Er dit krav, at din analyse aldrig må holde data på personniveau overhovedet, så køb en af de to og stop med at læse; det er produktet til det krav, og Munin er det ikke. Har du brug for at vide, hvilken artikel en navngiven kunde læste, før de skrev under, bringer ingen mængde aggregeret værktøj dig derhen, og spørgsmålet bliver, hvor den post på personniveau bør bo. Hvad hvert af de privatlivsvenlige værktøjer gemmer, og under hvilken licens, er sammenlignet grundigt separat.

• PlausibleAGPL-3.0 community-udgave, sky fra 9 $/måned for 10.000 sidevisninger om måneden på Starter, EU-hostet i Tyskland af et estisk selskab. Kun aggregeret, med vilje. Værd at vide, før du driver selv: repoet har en extra/-mappe, der holder Enterprise Edition, og Plausibles egne udgivelsesnoter siger, at den er publiceret som kildetilgængelig, men »vi giver ikke andre ret til at bruge, distribuere eller på anden måde udnytte disse funktioner.«
• FathomProprietært, ingen offentlig kildekode. Fra 45 $/måned for 500.000 sidevisninger, alle planer inklusive mindst 50 websteder. EU Isolation dirigerer EU-besøgende gennem EU-servere, der fjerner IP'en, før den anonymiserede række gemmes på Fathoms amerikanske infrastruktur; trafik uden for EU går direkte til amerikanske servere. Hostet på AWS. Kun aggregeret, med vilje.
• MatomoGPL-3.0-kerne, og kernerepoet har reelt ingen proprietær mappe i sig — premium-plugins leveres separat under InnoCraft EULA frem for at gemme sig inde i det offentlige træ. Sky fra 29 €/måned eksklusive moms for 50.000 hits, ifølge Matomos prisside den 4. september 2026; On-Premise Community er gratis for altid med ubegrænsede hits og brugere. Gør personniveau ordentligt: Visitor Profile, Visitor Log og User ID findes på alle planer, og sessionsoptagelse afspiller en besøgendes sidevisninger efter hinanden. Skydata ligger i Frankfurt.
• Munins analysePå personniveau og samtykkestyret, på den samme Postgres-række som CRM-kontakten, supporttråden og CMS-posten. analytics_get_contact_journey returnerer én kontakts kronologiske tidslinje over sidevisninger og søgninger og opløser aktivitet fra før de identificerede sig. MIT hele vejen, EU-hostet i Cloud, 0 € at starte.

Hvordan hæftes rejsen på en person?

I tre trin, og det interessante er det tredje.

Sporeren er anonym først. analytics_create_tracker returnerer en offentlig trackerKey og en identityVerificationSecret, der vises én gang. Sidevisninger kommer ind med et uigennemsigtigt visitor_id og intet andet — intet navn, ingen e-mail, ingen kontakt.

Identitet signeres, den påstås ikke. Når nogen logger ind, læser browseren sit eget id med window.mn.getVisitorId(), din server signerer HMAC("${externalId}:${visitorId}") med sporerhemmeligheden, og browseren kalder window.mn.identify(externalId, userHash). Hashen er bundet til netop den browser, så en observeret hash kan ikke afspilles igen for at hæfte en anden besøgende på den identitet. Uoverensstemmelser droppes stille.

Og fortiden følger med. Det er den del, der overhovedet gør spørgsmålet besvarligt. At koble en besøgende udfylder end_user_id på den besøgendes visnings- og søgehændelser fra de sidste 30 dage, i den samme transaktion som koblingen — og analytics_get_contact_journey følger broen ved læsning, så selv ældre anonyme læsninger dukker op på tidslinjen. De tre artikler, nogen læste fjorten dage før de overhovedet gav dig deres e-mail, er ikke tabt; de hæfter sig i det øjeblik, der findes en person at hæfte dem på.

const go = () => {
  const visitorId = window.mn.getVisitorId();
  // POST { externalId, visitorId } til din server, få userHash tilbage, derefter:
  window.mn.identify(externalId, userHash);
};

// Sporeren indlæses asynkront. Brug flaget eller hændelsen, aldrig polling.
window.mn?.ready
  ? go()
  : document.addEventListener('munin:ready', go, { once: true });

Hvordan ved du, at det var den artikel og ikke den URL?

Fordi visningen er nøglet til posten, ikke til stien. Hvert CMS-leveringssvar sender et _tracking-blok med en signeret token bundet til ét post-id, og at rendere <article data-mn-entry-token={entry._tracking.token}> registrerer en læsning mod det id. Omdøb sluggen, flyt den under en ny rute, oversæt den til et andet sprog — analyselaget bemærker det aldrig, fordi det aldrig var nøglet på URL'en.

Kør URL-sporeren ved siden af, og du får to hændelser per visning: én subject_type='page' til tragtspørgsmål, én subject_type='cms_entry' til indholdsspørgsmål. De svarer på forskellige ting og forbliver adskillelige ved forespørgsel.

Én fælde er værd at navngive, fordi den stille ødelægger data, og ingen opdager det i månedsvis: sæt aldrig token på kort i en oversigt. Tagger du kortene på din journaloversigt, registrerer hver indlæsning af oversigten en læsning for hver eneste post på den, så din mest læste-liste bliver stille til det, der tilfældigvis ligger øverst på forsiden. Visninger af kort er et andet spørgsmål med en anden subjekttype.

Hvad kan du faktisk spørge om, når det er koblet op?

De nyttige spørgsmål viser sig ikke at være dem, et marketingdashboard er formet omkring.

• 01Hvad læste denne kunde, før de skrev under? analytics_get_contact_journey med contactId, kronologisk, inklusive den anonyme strækning før de identificerede sig.
• 02Hvilke poster bliver faktisk læst? analytics_list_top_subjects med subjectType: "cms_entry" — nøglet på post-id, så en slugændring nulstiller ikke tællingen.
• 03Er der nogen, der læser denne færdig? analytics_get_subject_engagement returnerer opholdstid og læsedybde per post, hvilket er et mere ærligt signal end visninger på en lang artikel.
• 04Hvad søgte folk efter og fandt intet? analytics_list_zero_result_searches er den korteste vej fra analyse til en indholdsplan — det er en liste over artikler, dine læsere allerede har bedt dig skrive.
• 05Hvor sker frafaldet? analytics_get_funnel grupperer konverteringstrin per identificeret slutbruger, så en rejse, der krydser grænsen fra anonym til kendt, tæller som én person frem for to.

Hvad ændrer det ved, hvordan du skriver?

Mindre, end du ville håbe den første måned, og mere, end du ville vente dig ved den tredje.

Førsteordenseffekten er, at diskussionen om, hvorvidt bloggen virker, holder op med at være en diskussion. Du kan navngive de poster, der gik forud for vundne handler. Som regel er det ikke dem, nogen forudsagde, og som regel er de færre, end du kunne ønske — to eller tre tekster, der gør det meste af arbejdet, og en lang hale, der får trafik og lukker intet.

Andenordenseffekten er den, der akkumulerer. Søgninger uden resultat er en huskeliste skrevet af dem, du forsøger at nå, og de ligger i det samme system som videnbasen, der fylder sig selv fra løste supporttråde, og CRM'et, der fylder sig selv fra de samtaler, du allerede havde. Et spørgsmål stillet i support, søgt efter på sitet og aldrig besvaret nogen steder er et meget højt signal, når alle tre poster ligger én forespørgsel fra hinanden. Det er hele grunden til, at vi lagde seks moduler bag ét skema frem for at synkronisere fire produkter.

Og fordi det er et værktøjskatalog frem for et dashboard, behøver spørgsmålet ikke at være forudset af den, der tegnede skærmen. »Hvilke artikler læste vores vundne handler fra sidste kvartal, og hvilke af de artikler har ingen opdateret siden?« er ikke en rapport, nogen leverer. Det er to værktøjskald. Skrivesiden af den sløjfe — en agent, der skriver udkast ind i CMS'et og stopper ved gennemgangskøen — er beskrevet separat.

Ofte stillede spørgsmål

Hvordan finder jeg ud af, hvilket blogindlæg der førte til en kunde? Du har brug for rejsedata per person, der kobles til den samme post, dine handler sidder på. I Munin signerer du en identitetshash på serversiden, kalder window.mn.identify() én gang efter login, og læser derefter analytics_get_contact_journey med kontakt-id'et — den returnerer den persons kronologiske tidslinje over sidevisninger og søgninger, inklusive læsninger fra før de identificerede sig.

Lader Plausible eller Fathom mig se en enkelt besøgendes rejse? Nej, og det er tilsigtet frem for en begrænsning at arbejde uden om. Plausible isolerer alle data til én dag, ét websted og én enhed med et salt, de sletter hver 24. time; Fathom sletter sine besøgendehashes ved midnat og runder tidsstempler til timen. Plausibles »User Journeys«-funktion er aggregeret stiudforskning, ikke en navngiven persons spor.

Er Munins analyse cookiefri? Nej. Sporeren gemmer et uigennemsigtigt besøgende-id i localStorage under mn.vid, delt med chatwidgetten. Den vedvarende identifikator er det, der gør en rejse på tværs af sessioner mulig, og det er den handel, der indgås — det er derfor, Munin kan svare på et spørgsmål, Plausible og Fathom strukturelt ikke kan.

Hvor længe beholder Munin analysedata? Selvdrevet, så længe du beholder dem — hændelserne er rækker i din egen Postgres. Til sammenligning tilbyder GA4 på en standardproperty 2 eller 14 måneder for data på bruger- og hændelsesniveau, med 2 som standard, og 26/38/50 måneder kun i Analytics 360.

Kan jeg spore CMS-poster, hvis mit site er en statisk eksport? Ja. Hvert leveringssvar indeholder et _tracking-blok med en forsigneret pixel-URL, der ikke er tidsbegrænset, så et statisk build, der bager URL'en ind, bliver ved med at virke. Pixlen registrerer kun visninger — intet besøgende-id, altså ingen dubletfjernelse per person, ingen opholdstid og ingen læsedybde. Kan siden køre sporeren, så lad den.

Hvad er alternativet til Google Analytics med åben kildekode? Til aggregeret, privatlivsvenlig trafikstatistik er Plausible (AGPL-3.0) og Matomo (GPL-3.0) begge stærke, og Matomo kører selvdrevet gratis med ubegrænsede hits. Munin er MIT og svarer på et andet spørgsmål: ikke hvor mange der læste det, men hvilken navngiven kunde der gjorde.

Lav en sporer, læg posttokenet på din artikelskabelon, og bed om én kundes rejse — Munin Cloud er gratis til det, og analyseværktøjsreferencen har opkoblingen.

Trafik fortæller dig, at noget blev læst. Kun posten fortæller dig, at det betyder noget.