Vilken artikel stängde affären?

Varje företag som skriver något får till slut samma diskussion. Någon frågar om bloggen är värd det. Någon annan säger att trafiken är upp. En tredje påpekar att trafik inte är intäkt. Och sedan tittar alla på två dashboarder — en som vet hur många som läste inlägget och en som vet vem som skrev på — och upptäcker att ingen av dem kan sätta de två fakta i samma mening. Diskussionen slutar där den började, och bloggen överlever på tro ännu ett kvartal.

Kan du säga vilket blogginlägg som ledde till en affär?

Bara om två saker stämmer: att din analys registrerar en resa per person snarare än aggregerade siffror, och att den resan löser sig till samma kundpost som dina affärer bor på. De flesta stackar faller på det andra testet snarare än det första. Sidvisningarna finns, den vunna affären finns, och kopplingen mellan dem var en person ingen lagrade.

Frågan är värd att formulera exakt, eftersom ”attribution” används om flera olika jobb. Det här är inte sista-beröring-attribution på ett annonsklick, och det är inte en marknadsmixmodell. Det är en mycket mindre och mycket mer besvarbar fråga: för den här namngivna kontakten som blev kund, vad läste de, i vilken ordning, innan de hörde av sig.

Varför kan inte Google Analytics svara på det här?

Den kan hålla formen på svaret och sedan kasta det. GA4 är användaravgränsat och på händelsenivå, så en resa per person är arkitektoniskt möjlig. Problemet är lagringstiden: på en standardproperty kan data på användar- och händelsenivå behållas i 2 månader eller 14 månader — det är de enda två alternativen — och standard är 2. Längre fönster på 26, 38 och 50 månader finns bara i Analytics 360, och 360-priser publiceras inte någonstans på Googles egna sidor.

Det spelar roll eftersom B2B-säljcykler är längre än lagringsfönstret. Någon läser tre artiklar i mars, kommer tillbaka i oktober och skriver på i november. På en standard-GA4-property raderades mars-läsningarna i maj. Lagringskontrollen biter också hårdare när du växer: när en standardproperty blir ”stor” sänks lagringen på händelsenivå automatiskt till 2 månader, och äldre data raderas permanent.

Och även inuti fönstret känner GA4 inte till dina affärssteg. Du exporterar från ett system och kopplar i ett tredje.

Vad sägs om Plausible och Fathom?

De är utmärkta, och de kan inte svara på den här frågan — inte som en lucka, utan som hela designen. Det är värt att vara exakt om hur avsiktligt det är, eftersom det är den mest principfasta ingenjörskonsten i kategorin.

Plausible räknar en unik besökare som hash(dagligt_salt + webbplatsdomän + ip_adress + user_agent), roterar och raderar saltet var 24:e timme, och lagrar aldrig rå IP eller user agent. Deras datapolicy är otvetydig: ”All data är isolerad till en dag, en webbplats och en enhet.” Fathom gör samma sak och går längre, genom att avrunda tidsstämplar uppåt till närmaste timme just för att deras egna åtkomstloggar inte ska kunna korsrefereras mot deras surfdatabas. Båda är kakfria. Båda håller ingen data på personnivå överhuvudtaget — ett medvetet omfångsval, och ett annat än Munins.

Plausible levererar visserligen en funktion som heter User Journeys på Business-planen, och namnet är lätt att missläsa. Det är aggregerad stigutforskning — välj en sida, se vad folk gjorde ett och två steg senare, med sidor automatiskt grupperade per katalog och avhoppssiffror bredvid. Ingen enskild person exponeras vid något tillfälle, eftersom ingen enskild person finns i datan att exponera.

Så den ärliga inramningen är en gaffel, inte en rangordning. Är ditt krav att din analys aldrig får hålla data på personnivå överhuvudtaget, köp en av dessa två och sluta läsa; det är produkten för det kravet, och Munin är inte den. Behöver du veta vilken artikel en namngiven kund läste innan de skrev på, tar ingen mängd aggregerade verktyg dig dit, och frågan blir var den posten på personnivå bör bo. Vad vart och ett av de integritetsvänliga verktygen lagrar, och under vilken licens, jämförs utförligt separat.

• PlausibleAGPL-3.0 community-utgåva, moln från 9 $/månad för 10 000 sidvisningar i månaden på Starter, EU-driftat i Tyskland av ett estniskt företag. Endast aggregerat, medvetet. Värt att veta innan du driftar själv: repot har en extra/-katalog som håller Enterprise Edition, och Plausibles egna releasenoteringar säger att den publiceras som källtillgänglig men ”vi ger inte andra rätt att använda, distribuera eller på annat sätt utnyttja dessa funktioner.”
• FathomProprietärt, ingen publik källkod. Från 45 $/månad för 500 000 sidvisningar, alla planer inklusive minst 50 webbplatser. EU Isolation dirigerar EU-besökare genom EU-servrar som tar bort IP:n innan den anonymiserade raden lagras på Fathoms amerikanska infrastruktur; trafik utanför EU går direkt till amerikanska servrar. Driftat på AWS. Endast aggregerat, medvetet.
• MatomoGPL-3.0-kärna, och kärnrepot har genuint ingen proprietär katalog i sig — premiumplugins levereras separat under InnoCraft EULA i stället för att gömma sig inne i det publika trädet. Moln från 29 €/månad exklusive moms för 50 000 träffar, enligt Matomos prissida den 4 september 2026; On-Premise Community är gratis för alltid med obegränsat antal träffar och användare. Gör personnivå ordentligt: Visitor Profile, Visitor Log och User ID finns på alla planer, och sessionsinspelning spelar upp en besökares sidvisningar efter varandra. Molndata ligger i Frankfurt.
• Munins analysPå personnivå och samtyckesstyrd, på samma Postgres-rad som CRM-kontakten, supporttråden och CMS-posten. analytics_get_contact_journey returnerar en kontakts kronologiska tidslinje över sidvisningar och sökningar, och löser aktivitet från innan de identifierade sig. MIT hela vägen, EU-driftat i Cloud, 0 € att börja.

Hur fästs resan vid en person?

I tre steg, och det intressanta är det tredje.

Spåraren är anonym först. analytics_create_tracker returnerar en publik trackerKey och en identityVerificationSecret som visas en gång. Sidvisningar kommer in med ett ogenomskinligt visitor_id och inget annat — inget namn, ingen e-post, ingen kontakt.

Identitet signeras, den påstås inte. När någon loggar in läser webbläsaren sitt eget id med window.mn.getVisitorId(), din server signerar HMAC("${externalId}:${visitorId}") med spårarhemligheten, och webbläsaren anropar window.mn.identify(externalId, userHash). Hashen är bunden till just den webbläsaren, så en observerad hash kan inte spelas upp igen för att fästa en annan besökare vid den identiteten. Avvikelser släpps tyst.

Och det förflutna följer med. Det är den del som gör frågan besvarbar överhuvudtaget. Att koppla en besökare fyller i end_user_id på den besökarens visnings- och sökhändelser från de senaste 30 dagarna, i samma transaktion som kopplingen — och analytics_get_contact_journey löser bryggan vid läsning, så att även äldre anonyma läsningar syns på tidslinjen. De tre artiklar någon läste fjorton dagar innan de överhuvudtaget gav dig sin e-post är inte förlorade; de fäster sig i det ögonblick det finns en person att fästa dem vid.

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

// Spåraren laddas asynkront. Använd flaggan eller händelsen, aldrig polling.
window.mn?.ready
  ? go()
  : document.addEventListener('munin:ready', go, { once: true });

Hur vet du att det var den artikeln och inte den URL:en?

För att visningen är nycklad till posten, inte till sökvägen. Varje CMS-leveranssvar skickar med ett _tracking-block som innehåller en signerad token bunden till ett post-id, och att rendera <article data-mn-entry-token={entry._tracking.token}> registrerar en läsning mot det id:t. Döp om sluggen, flytta den under en ny rutt, översätt den till ett andra språk — analyslagret märker det aldrig, eftersom det aldrig var nycklat på URL:en.

Kör URL-spåraren bredvid och du får två händelser per visning: en subject_type='page' för trattfrågor, en subject_type='cms_entry' för innehållsfrågor. De svarar på olika saker och förblir åtskiljbara vid frågetillfället.

En fälla är värd att namnge, eftersom den tyst förstör datan och ingen upptäcker det på månader: sätt aldrig token på kort i en översikt. Taggar du korten på din journalöversikt registrerar varje sidladdning en läsning för varenda post på den, så din mest-lästa-lista blir tyst det som råkar ligga högst upp på startsidan. Visningar av kort är en annan fråga med en annan subjekttyp.

Vad kan du faktiskt fråga när det är kopplat?

De användbara frågorna visar sig inte vara de som en marknadsdashboard är formad kring.

• 01Vad läste den här kunden innan de skrev på? analytics_get_contact_journey med contactId, kronologiskt, inklusive den anonyma sträckan innan de identifierade sig.
• 02Vilka poster blir faktiskt lästa? analytics_list_top_subjects med subjectType: "cms_entry" — nycklat på post-id, så en slugändring nollställer inte räkningen.
• 03Är det någon som läser klart den här? analytics_get_subject_engagement returnerar vistelsetid och läsdjup per post, vilket är en ärligare signal än visningar på en lång artikel.
• 04Vad sökte folk efter och hittade inget? analytics_list_zero_result_searches är den kortaste vägen från analys till en innehållsplan — det är en lista över artiklar dina läsare redan bett dig skriva.
• 05Var sker avhoppet? analytics_get_funnel grupperar konverteringssteg per identifierad slutanvändare, så en resa som korsar gränsen från anonym till känd räknas som en person snarare än två.

Vad ändrar det i hur du skriver?

Mindre än du skulle hoppas den första månaden, och mer än du skulle vänta dig till den tredje.

Första ordningens effekt är att diskussionen om huruvida bloggen fungerar slutar vara en diskussion. Du kan namnge de poster som föregick vunna affärer. Oftast är det inte de någon förutspådde, och oftast är de färre än du skulle vilja — två eller tre texter som gör det mesta av jobbet, och en lång svans som får trafik och stänger inget.

Andra ordningens effekt är den som ackumuleras. Sökningar utan träff är en att-göra-lista skriven av dem du försöker nå, och de ligger i samma system som kunskapsbasen som fyller sig själv från lösta supporttrådar och CRM:et som fyller sig självt från samtalen du redan hade. En fråga ställd i support, sökt efter på webbplatsen, och aldrig besvarad någonstans är en mycket hög signal när alla tre posterna ligger en fråga från varandra. Det är hela skälet till att vi lade sex moduler bakom ett schema i stället för att synka fyra produkter.

Och eftersom det är en verktygskatalog snarare än en dashboard behöver frågan inte ha förutsetts av den som ritade skärmen. ”Vilka artiklar läste våra vunna affärer från förra kvartalet, och vilka av de artiklarna har ingen uppdaterat sedan dess?” är ingen rapport någon levererar. Det är två verktygsanrop. Skrivsidan av den slingan — en agent som skriver utkast in i CMS:et och stannar vid granskningskön — är beskriven separat.

Vanliga frågor

Hur tar jag reda på vilket blogginlägg som ledde till en kund? Du behöver resedata per person som löser sig till samma post som dina affärer sitter på. I Munin signerar du en identitetshash på serversidan, anropar window.mn.identify() en gång efter inloggning, och läser sedan analytics_get_contact_journey med kontakt-id:t — den returnerar den personens kronologiska tidslinje över sidvisningar och sökningar, inklusive läsningar från innan de identifierade sig.

Låter Plausible eller Fathom mig se en enskild besökares resa? Nej, och det är avsiktligt snarare än en begränsning att arbeta runt. Plausible isolerar all data till en dag, en webbplats och en enhet med ett salt de raderar var 24:e timme; Fathom raderar sina besökarhashar vid midnatt och avrundar tidsstämplar till timmen. Plausibles ”User Journeys”-funktion är aggregerad stigutforskning, inte en namngiven persons spår.

Är Munins analys kakfri? Nej. Spåraren lagrar ett ogenomskinligt besökar-id i localStorage under mn.vid, delat med chattwidgeten. Den beständiga identifieraren är det som gör en resa över sessioner möjlig, och det är avvägningen som görs — det är därför Munin kan svara på en fråga Plausible och Fathom strukturellt inte kan.

Hur länge behåller Munin analysdata? Självdriftat, så länge du behåller dem — händelserna är rader i din egen Postgres. Som jämförelse erbjuder GA4 på en standardproperty 2 eller 14 månader för data på användar- och händelsenivå, med 2 som standard, och 26/38/50 månader bara i Analytics 360.

Kan jag spåra CMS-poster om min webbplats är en statisk export? Ja. Varje leveranssvar innehåller ett _tracking-block med en försignerad pixel-URL som inte är tidsbegränsad, så ett statiskt bygge som bakar in URL:en fortsätter fungera. Pixeln registrerar bara visningar — inget besökar-id, alltså ingen deduplicering per person, ingen vistelsetid och inget läsdjup. Kan sidan köra spåraren, låt den göra det.

Vad är alternativet till Google Analytics med öppen källkod? För aggregerad, integritetsvänlig trafikstatistik är Plausible (AGPL-3.0) och Matomo (GPL-3.0) båda starka, och Matomo driftas själv gratis med obegränsat antal träffar. Munin är MIT och svarar på en annan fråga: inte hur många som läste det, utan vilken namngiven kund som gjorde det.

Skapa en spårare, lägg posttoken på din artikelmall, och be om en kunds resa — Munin Cloud är gratis för det, och analysverktygsreferensen har kopplingen.

Trafik berättar att något lästes. Bara posten berättar att det spelade roll.