Hvilken artikkel lukket avtalen?

Hvert selskap som skriver noe som helst, får til slutt den samme diskusjonen. Noen spør om bloggen er verdt det. Noen andre sier at trafikken er opp. En tredje påpeker at trafikk ikke er inntekt. Og så ser alle på to dashbord — ett som vet hvor mange som leste innlegget og ett som vet hvem som signerte — og oppdager at ingen av dem kan sette de to fakta i samme setning. Diskusjonen ender der den startet, og bloggen overlever på tro i enda et kvartal.

Kan du si hvilket blogginnlegg som førte til et salg?

Bare hvis to ting stemmer: at analysen din registrerer en reise per person framfor aggregerte tall, og at den reisen løser seg til den samme kundeposten avtalene dine bor på. De fleste stabler stryker på den andre testen framfor den første. Sidevisningene finnes, den vunne avtalen finnes, og koblingen mellom dem var en person ingen lagret.

Spørsmålet er verdt å formulere presist, fordi «attribusjon» brukes om flere ulike jobber. Dette er ikke siste-berøring-attribusjon på et annonseklikk, og det er ikke en markedsmiksmodell. Det er et mye mindre og mye mer besvarlig spørsmål: for denne navngitte kontakten som ble kunde, hva leste de, i hvilken rekkefølge, før de tok kontakt.

Hvorfor kan ikke Google Analytics svare på dette?

Den kan holde formen på svaret og så kaste det. GA4 er brukeravgrenset og hendelsesnivå, så en reise per person er arkitektonisk mulig. Problemet er oppbevaring: på en standard property kan data på bruker- og hendelsesnivå beholdes i 2 måneder eller 14 måneder — det er de eneste to valgene — og standarden er 2. Lengre vinduer på 26, 38 og 50 måneder er kun Analytics 360, og 360-prisene er ikke publisert noe sted på Googles egne sider.

Det betyr noe fordi B2B-salgssykluser er lengre enn oppbevaringsvinduet. Noen leser tre artikler i mars, kommer tilbake i oktober og signerer i november. På en standard GA4-property ble mars-lesingene slettet i mai. Oppbevaringskontrollen biter også hardere når du vokser: når en standard property blir «stor», reduseres oppbevaringen på hendelsesnivå automatisk til 2 måneder, og eldre data slettes permanent.

Og selv inne i vinduet kjenner ikke GA4 avtalefasene dine. Du eksporterer fra ett system og kobler i et tredje.

Hva med Plausible og Fathom?

De er utmerkede, og de kan ikke svare på dette spørsmålet — ikke som et hull, men som hele designet. Det er verdt å være presis på hvor tilsiktet det er, fordi det er den mest prinsippfaste ingeniørkunsten i kategorien.

Plausible teller en unik besøkende som hash(daglig_salt + nettstedsdomene + ip_adresse + user_agent), roterer og sletter saltet hver 24. time, og lagrer aldri rå IP eller user agent. Datapolicyen deres er utvetydig: «Alle data er isolert til én dag, ett nettsted og én enhet.» Fathom gjør det samme og går lenger, ved å runde tidsstempler opp til nærmeste time nettopp for at deres egne tilgangslogger ikke skal kunne kryssrefereres mot surfedatabasen deres. Begge er informasjonskapselfrie. Begge holder ingen data på personnivå overhodet — et bevisst omfangsvalg, og et annet enn Munins.

Plausible leverer riktignok en funksjon som heter User Journeys på Business-planen, og navnet er lett å mislese. Det er aggregert stiutforskning — velg en side, se hva folk gjorde ett og to steg senere, med sider automatisk gruppert etter katalog og frafallstall ved siden av. Ingen enkeltperson eksponeres på noe tidspunkt, fordi ingen enkeltperson finnes i dataene å eksponere.

Så den ærlige innrammingen er en gaffel, ikke en rangering. Er kravet ditt at analysen aldri skal holde data på personnivå i det hele tatt, kjøp en av disse to og slutt å lese; det er produktet for det kravet, og Munin er det ikke. Trenger du å vite hvilken artikkel en navngitt kunde leste før de signerte, kommer ingen mengde aggregert verktøy deg dit, og spørsmålet blir hvor den posten på personnivå bør bo. Hva hvert av de personvernvennlige verktøyene lagrer, og under hvilken lisens, er sammenliknet grundig for seg.

• PlausibleAGPL-3.0 community-utgave, sky fra 9 $/måned for 10 000 sidevisninger i måneden på Starter, driftet i EU i Tyskland av et estisk selskap. Kun aggregert, ved design. Verdt å vite før du selvdrifter: repoet har en extra/-katalog som holder Enterprise Edition, og Plausibles egne utgivelsesnotater sier at den er publisert som kildetilgjengelig, men «vi gir ingen andre rettigheter til å bruke, distribuere eller på annen måte utnytte disse funksjonene.»
• FathomProprietær, ingen offentlig kildekode. Fra 45 $/måned for 500 000 sidevisninger, alle planer inkluderer minst 50 nettsteder. EU Isolation ruter EU-besøkende gjennom EU-servere som stripper IP-en før den anonymiserte raden lagres på Fathoms amerikanske infrastruktur; trafikk utenfor EU går direkte til amerikanske servere. Driftet på AWS. Kun aggregert, ved design.
• MatomoGPL-3.0-kjerne, og kjerne-repoet har genuint ingen proprietær katalog i seg — premium-plugins leveres separat under InnoCraft EULA framfor å gjemme seg inne i det offentlige treet. Sky fra 29 €/måned eks. mva for 50 000 treff, ifølge Matomos prisside 4. september 2026; On-Premise Community er gratis for alltid med ubegrenset antall treff og brukere. Gjør personnivå ordentlig: Visitor Profile, Visitor Log og User ID er på alle planer, og sesjonsopptak spiller av en besøkendes sidevisninger etter hverandre. Skydata ligger i Frankfurt.
• Munins analysePå personnivå og samtykkestyrt, på den samme Postgres-raden som CRM-kontakten, supporttråden og CMS-oppføringen. analytics_get_contact_journey returnerer én kontakts kronologiske tidslinje over sidevisninger og søk, og løser aktivitet fra før de identifiserte seg. MIT hele veien, driftet i EU på Cloud, 0 € å starte.

Hvordan festes reisen til en person?

I tre steg, og det interessante er det tredje.

Sporeren er anonym først. analytics_create_tracker returnerer en offentlig trackerKey og en identityVerificationSecret som vises én gang. Sidevisninger kommer inn med en ugjennomsiktig visitor_id og ingenting annet — intet navn, ingen e-post, ingen kontakt.

Identitet signeres, den påstås ikke. Når noen logger inn, leser nettleseren sin egen id med window.mn.getVisitorId(), serveren din signerer HMAC("${externalId}:${visitorId}") med sporerhemmeligheten, og nettleseren kaller window.mn.identify(externalId, userHash). Hashen er bundet til den ene nettleseren, så en observert hash kan ikke spilles av på nytt for å feste en annen besøkende til den identiteten. Avvik forkastes stille.

Og fortiden følger med. Det er delen som gjør spørsmålet besvarlig i det hele tatt. Å koble en besøkende etterfyller end_user_id på den besøkendes visnings- og søkehendelser fra de siste 30 dagene, i den samme transaksjonen som koblingen — og analytics_get_contact_journey løser broen ved lesetidspunkt, så selv eldre anonyme lesinger dukker opp på tidslinjen. De tre artiklene noen leste fjorten dager før de i det hele tatt ga deg e-posten sin, er ikke tapt; de fester seg i det øyeblikket det finnes en person å feste dem til.

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

// Sporeren lastes asynkront. Bruk flagget eller hendelsen, aldri polling.
window.mn?.ready
  ? go()
  : document.addEventListener('munin:ready', go, { once: true });

Hvordan vet du at det var den artikkelen og ikke den URL-en?

Fordi visningen er nøklet til oppføringen, ikke til stien. Hvert CMS-leveringssvar sender med en _tracking-blokk som inneholder et signert token bundet til én oppførings-id, og å tegne <article data-mn-entry-token={entry._tracking.token}> registrerer en lesing mot den id-en. Døp om sluggen, flytt den under en ny rute, oversett den til et annet språk — analyselaget merker det aldri, fordi det aldri var nøklet på URL-en.

Kjør URL-sporeren ved siden av, og du får to hendelser per visning: én subject_type='page' for traktspørsmål, én subject_type='cms_entry' for innholdsspørsmål. De svarer på ulike ting og forblir atskillbare ved spørring.

Én felle er verdt å navngi, fordi den stille ødelegger dataene og ingen oppdager det på måneder: legg aldri tokenet på kort i en oversikt. Merker du kortene på journaloversikten, registrerer hver lasting av oversikten en lesing for hver eneste oppføring på den, så mest-lest-lista di blir stille til hva som tilfeldigvis ligger øverst på forsida. Visninger av kort er et annet spørsmål med en annen subjekttype.

Hva kan du faktisk spørre om når det er koblet opp?

De nyttige spørsmålene viser seg ikke å være de et markedsføringsdashbord er formet rundt.

• 01Hva leste denne kunden før de signerte? analytics_get_contact_journey med contactId, kronologisk, inkludert den anonyme strekningen før de identifiserte seg.
• 02Hvilke oppføringer blir faktisk lest? analytics_list_top_subjects med subjectType: "cms_entry" — nøklet på oppførings-id, så en slug-omdøping nullstiller ikke tellingen.
• 03Er det noen som fullfører denne? analytics_get_subject_engagement returnerer oppholdstid og lesedybde per oppføring, som er et ærligere signal enn visninger på en lang artikkel.
• 04Hva søkte folk etter og fant ingenting? analytics_list_zero_result_searches er den korteste veien fra analyse til en innholdsplan — det er en liste over artikler leserne dine allerede har bedt deg skrive.
• 05Hvor skjer frafallet? analytics_get_funnel grupperer konverteringssteg etter identifisert sluttbruker, så en reise som krysser grensen fra anonym til kjent teller som én person framfor to.

Hva endrer det ved hvordan du skriver?

Mindre enn du skulle håpe den første måneden, og mer enn du ville ventet innen den tredje.

Førsteordenseffekten er at diskusjonen om hvorvidt bloggen virker, slutter å være en diskusjon. Du kan navngi oppføringene som gikk forut for vunne avtaler. Som regel er det ikke dem noen forutsa, og som regel er de færre enn du skulle ønske — to eller tre tekster som gjør mesteparten av jobben, og en lang hale som får trafikk og lukker ingenting.

Andreordenseffekten er den som akkumulerer. Søk uten treff er en gjøremålsliste skrevet av dem du prøver å nå, og de ligger i det samme systemet som kunnskapsbasen som fyller seg selv fra løste supporttråder og CRM-et som fyller seg selv fra samtalene du allerede hadde. Et spørsmål stilt i support, søkt etter på nettstedet, og aldri besvart noe sted, er et veldig høyt signal når alle tre postene ligger én spørring fra hverandre. Det er hele grunnen til at vi la seks moduler bak ett skjema framfor å synkronisere fire produkter.

Og fordi det er en verktøykatalog framfor et dashbord, trenger ikke spørsmålet å ha blitt forutsett av den som tegnet skjermen. «Hvilke artikler leste de vunne avtalene våre fra forrige kvartal, og hvilke av de artiklene har ingen oppdatert siden?» er ikke en rapport noen leverer. Det er to verktøykall. Skrivesiden av den sløyfen — en agent som skriver utkast inn i CMS-et og stopper ved gjennomgangskøen — er skrevet opp for seg.

Ofte stilte spørsmål

Hvordan finner jeg ut hvilket blogginnlegg som førte til en kunde? Du trenger reisedata per person som løser seg til den samme posten avtalene dine ligger på. I Munin signerer du en identitetshash på serversiden, kaller window.mn.identify() én gang etter innlogging, og leser så analytics_get_contact_journey med kontakt-id-en — den returnerer den personens kronologiske tidslinje over sidevisninger og søk, inkludert lesinger fra før de identifiserte seg.

Lar Plausible eller Fathom meg se en enkelt besøkendes reise? Nei, og det er tilsiktet framfor en begrensning å komme rundt. Plausible isolerer alle data til én dag, ett nettsted og én enhet ved hjelp av et salt de sletter hver 24. time; Fathom sletter besøkendehashene sine ved midnatt og runder tidsstempler til nærmeste time. Plausibles «User Journeys»-funksjon er aggregert stiutforskning, ikke en navngitt persons spor.

Er Munins analyse informasjonskapselfri? Nei. Sporeren lagrer en ugjennomsiktig besøkende-id i localStorage under mn.vid, delt med chat-widgeten. Den vedvarende identifikatoren er det som gjør en reise på tvers av økter mulig, og det er byttehandelen som gjøres — det er derfor Munin kan svare på et spørsmål Plausible og Fathom strukturelt ikke kan.

Hvor lenge beholder Munin analysedata? Selvdriftet, så lenge du beholder dem — hendelsene er rader i din egen Postgres. Til sammenlikning tilbyr GA4 på en standard property 2 eller 14 måneder for data på bruker- og hendelsesnivå, med 2 som standard, og 26/38/50 måneder bare på Analytics 360.

Kan jeg spore CMS-oppføringer om nettstedet mitt er en statisk eksport? Ja. Hvert leveringssvar inkluderer en _tracking-blokk med en forhåndssignert piksel-URL som ikke er tidsbegrenset, så et statisk bygg som baker inn URL-en fortsetter å virke. Pikselen registrerer bare visninger — ingen besøkende-id, altså ingen deduplisering per person, ingen oppholdstid og ingen lesedybde. Kan siden kjøre sporeren, så la den gjøre det.

Hva er alternativet til Google Analytics med åpen kildekode? For aggregert, personvernvennlig trafikkstatistikk er Plausible (AGPL-3.0) og Matomo (GPL-3.0) begge sterke, og Matomo selvdriftes gratis med ubegrenset antall treff. Munin er MIT og svarer på et annet spørsmål: ikke hvor mange som leste det, men hvilken navngitt kunde som gjorde det.

Lag en sporer, legg oppføringstokenet på artikkelmalen din, og be om én kundes reise — Munin Cloud er gratis til det, og analyseverktøyreferansen har oppkoblingen.

Trafikk forteller deg at noe ble lest. Bare posten forteller deg at det betydde noe.