En analysdashboard som rekommenderar, inte bara visar

Varje vecka skriver Claude min analys av affärsdatan. Den gör det inte från originalkällorna som ligger i BigQuery och hämtas från sju olika system (GA4, Meta Ads, Google Ads, App Store, Play Console, Supabase och RevenueCat). Men slutsatsen, vad jag bör göra härnäst utifrån vad som hänt den senaste veckan, det är det Claude skriver.

En dashboard ska göra två saker: visa vad som hänt, och hjälpa dig avgöra vad du ska göra åt det. De flesta verktyg gör det första bra och det andra mindre bra. Den här dashboarden försöker landa båda.

Vad jag vill uppnå

Att slippa fatta marknadsbeslut på magkänsla när jag har data som ger svaret. När en kampanj presterar fel, när en konverteringssiffra dippat, när installationerna sjunkit på iOS. Då vill jag veta inom timmar, inte två veckor senare när det är dags för månadsuppföljning. Och jag vill ha en konkret rekommendation, inte bara siffror.

Det betyder att dashboarden behöver tre saker. Aktuell data från alla källor på ett ställe. En tydlig vy som visar var jag tappar, växer eller stagnerar. Och en analys som föreslår vad jag ska göra åt det.

Den tredje delen är där Claude kommer in.

Hur jag tänker

Alternativen var färdiga verktyg som Looker Studio ⓘ eller GA4:s egna explore-vyer. Alla är bra på första delen, att visa data. Inget av dem skriver en svensk veckorapport med prioriterade åtgärder. Det kräver också manuellt och tidskrävande arbete som inte utförs från terminalen eller Claudes app.

Jag valde Streamlit för att AI ska kunna kontrollera allt. Vad som visas och hur data hämtas. Jag kan styra vad AI:n får se och vad den får svara på. Det är en utvecklarprodukt, men den gör presentation av data snabbt utan att jag behöver bygga ett frontend från grunden.

Det viktigaste arkitekturbeslutet handlade om hur Claude skulle integreras, och där fanns det två olika alternativ. Antingen får Claude direkt åtkomst till BigQuery och kan ställa egna frågor. Eller så får Claude strukturerad kontext som koden byggt åt den, med KPI:er, tratt, marknadsdata och status på datakällorna, färdigt att resonera kring.

Jag valde det andra av säkerhetsskäl. Jag vill inte att en AI ska kunna ställa frågor mot databasen utan kontroll. Men valet baserades också på att svaret förväntas bli bättre. Om Claude alltid får samma sammanfattning med samma rubriker kan jag skriva en systemprompt som vet exakt vad som finns i datan och vad som inte gör det. Det ger mer förutsägbara analyser.

Vad jag gör

Dashboarden består av fem sidor, var och en svarar på en specifik fråga. Veckovy med KPI:er och vecka-mot-vecka. Konverteringstratt från första besök till aktivt konto, marknadsprestanda per kanal, AI-insikter och datahälsa.

Bakom kulisserna tar dashboarden in data från sju källor, alla normaliserade till samma BigQuery-projekt:

• GA4 via daglig BQ-export
• Meta Ads via ett Node-script mot Meta Marketing API ⓘ
• Google Ads via BQ Data Transfer plus en Python-ETL som lägger data i samma schema som Meta
• App Store Connect via en Cloud Function ⓘ som synkar dagligen
• Google Play Console via BQ Data Transfer
• Supabase via Wrapper plus Cron, helt inifrån Supabase utan extern kod
• RevenueCat via en Cloud Function för historiska trender, plus direkt API-anrop från Streamlit för realtidsvärden i "Idag"-kort

När Claude ska analysera hämtar scriptet veckans data, bygger ett strukturerat kontext-objekt med KPI:er, trattgrader, marknadsprestanda och status per datakälla. Det skickas tillsammans med en systemprompt som beskriver hur Claude ska svara. Prompten har åtta principer som styr svaret:

1. Identifiera drop-offs och föreslå åtgärder
2. Skilj alltid korrelation från kausalitet
3. Nämn alltid databegränsningar som påverkar analysen
4. Markera vilka metrics som är experimentella vs kanoniska
5. Ge prioriterade rekommendationer med motivering
6. Använd SEK för monetära värden
7. Var tydlig med vad som är hypotes och vad data faktiskt visar
8. Referera till specifika siffror från kontexten

Sista raden i prompten är att svaret alltid ska sluta med två till tre prioriterade åtgärder. Det är där analysen blir handlingsbar i stället för en text att läsa och lägga åt sidan.

En egen liten innovation är Datahälso-sidan. Den visar vilka datakällor som är aktuella, vilka som har lag, och vilka som har brutit. En source resolver i koden vet vilken tabell som har data idag och faller tillbaka på en sekundär om primärkällan är tom. Det betyder att en dag med trasig Meta-synk inte sänker hela dashboarden, den fortsätter visa det den har, med tydlig markering att marknadsdata är inaktuell.

Resultat och lärdomar

Veckorapporterna är användbara. De pekar på saker jag missat, prioriterar bland för många siffror, och tar hänsyn till begränsningar. Claude vet att Meta-attribution har upp till sju dagars lag, att GA4 underrapporterar på grund av Consent Mode v2 ⓘ, att Google Ads-konverteringar kan ha någon dags fördröjning. Det gör att analysen inte överreagerar på en plötslig dipp om datan ändå är osäker.

Den viktigaste lärdomen handlar om datakvalitet. Innan Datahälso-sidan fanns kunde dashboarden visa "0 events de senaste två dagarna" för en datakälla som tystnat. Claude kunde då skriva alarmistiska veckorapporter baserade på trasig data. Nu vet både jag och AI:n när en källa inte är aktuell, och rapporten justeras därefter. Status på datan ligger i kontexten Claude får, inte bara i tabellen.

En andra lärdom är att Claude blir dramatiskt bättre ju mer struktur kontexten har. I tidiga försök gav jag modellen mer rådata och hoppades på det bästa. Resultatet blev generiskt. När jag istället bygger kontexten som en sammanfattning med tydliga rubriker ("Nyckeltal", "Konverteringstratt", "Datakällstatus") får jag tightare och mer användbara svar. AI:n är inte bra på att gräva i tabeller, men bra på att resonera kring sammanfattningar. Den mappar bra mot människors arbetssätt också, jag tänker tydligare med en strukturerad föredragning än med en stor datadump.

Hur jag går vidare

Nästa steg är att integrera och korsköra datakällor, att förbättra analyser och att ta in fler produkter. Datakällor pluggas in i samma BigQuery-projekt, dashboarden använder source resolvern för att hitta rätt tabell, AI-insikterna byggs av samma kontext-mall. Att lägga till en andra produkt kostar inte mycket utveckling, mest konfiguration.

Parallellt pågår ett byte av själva dashboardlagret. Streamlit har varit en bra utvecklar- och prototypmiljö, men för standardrapporter där icke-utvecklare ska kunna utforska data passar Metabase bättre. Bytet är inte totalt, AI-insikterna stannar i Python eftersom de kräver custom logik som inte passar i ett färdigt verktyg. Det som möjliggör skiftet är ett event-definitionslager i BigQuery, en vy som joinar alla källor och definierar varje trattsteg (impressions, klick, nedladdningar, trials, betalande) på ett ställe. Både Streamlit och Metabase läser från samma definitioner, så ändras något i hur en konvertering räknas behöver det göras på ett ställe.

På längre sikt vill jag att AI:n inte bara analyserar utan föreslår experiment. Givet att vi just nu tappar mest mellan installation och första aktiva session, vad är värt att testa först utifrån vad vi redan provat? Det kräver mer kontext om historiska hypoteser och bättre struktur på annotationer. Men grunden är på plats.

Verktyg i den här processen