Solflares datateam ser plånbokens liv utanför appen

Installationen är inte nödvändigtvis början på berättelsen. När en plånboksadress används i Solflare Wallet kan den redan ha en transaktionshistorik på blockkedjan Solana. Den historiken finns utanför appen och är offentlig. Datateamet behöver alltså inte börja med ett tomt blad när det försöker förstå användningen.

Det är en central förutsättning i det arbete som Mihael Alapić, data lead på Solflare, beskriver för den serbiska tekniksajten Startit. Teamet kombinerar händelser i den egna produkten med aktivitet på blockkedjan. Tillsammans ger uppgifterna en bredare bild än någon av datakällorna gör för sig.

Men bredare är inte samma sak som fullständig. En adress kan visa vad som har hänt med tillgångar utan att förklara varför. Appdata kan visa hur någon rör sig genom ett gränssnitt utan att avslöja vad personen försökte åstadkomma. Solflares dataarbete blir intressant just i skarven mellan dessa två perspektiv.

En adress är inte en person

Solflare Wallet är en kryptoplånbok för Solana. Här behöver ordet plånbok delas upp i två saker: appen som användaren möter och adressen på blockkedjan vars aktivitet går att följa. Adressens historia är inte begränsad till det som sker genom Solflares gränssnitt.

Alapić beskriver hur tidigare kryptoaktivitet används för att dela in användare i grupper. Det ger teamet möjlighet att skilja mellan att vara ny i produkten och att vara ny inför de handlingar produkten används till. Det är två olika utgångslägen för produktutveckling.

En person med tidigare aktivitet kan exempelvis behöva lära sig var en funktion finns, snarare än vad funktionen gör. Det är en möjlig produktfråga som historiken väcker, inte ett bevis för att varje aktiv adress tillhör en erfaren användare. Transaktioner är spår av handlingar, inte ett kunskapstest.

Det finns också en viktig gräns mellan adress och identitet. Samma person kan använda flera adresser. Att knyta aktivitet till en adress är därför inte detsamma som att veta hur många människor som står bakom ett beteende, vilka de är eller vilka avsikter de har.

I det beskrivna arbetssättet kopplas en publik plånboksadress samman med enhetsidentifierare och ett internt användar-ID. Därmed går det att relatera blockkedjeaktivitet till användning i appen. Kopplingen ger ett analysunderlag, men gör inte adressen till en säker biografi över en människa.

Två datakällor, olika slags svar

Appdata och blockkedjedata besvarar delvis olika frågor. Händelser i en app kan hjälpa ett produktteam att förstå vilka funktioner som används och hur användaren tar sig fram. Blockkedjan tillför transaktionernas perspektiv, även när aktiviteten ligger utanför den egna produkten.

I Solflares verktygslåda finns PostHog för produktanalys och dbt för att rensa, sammanfoga och modellera data. Den senare delen låter teknisk, men är avgörande för vad en rapport faktiskt säger. Uppgifter från olika håll måste få definitioner som fungerar tillsammans innan de kan ligga till grund för beslut.

Ta skillnaden mellan en apphändelse och en transaktion. Ett tryck på en knapp är inte automatiskt en genomförd handling på blockkedjan. Omvänt behöver en transaktion på en adress inte ha initierats i Solflare. En analys som blandar ihop dessa saker riskerar att tillskriva appen aktivitet som skett någon annanstans, eller att räkna en avsikt som ett resultat.

Leverantören Alchemy beskriver ett exempel där hämtningen av en plånboks historik tar under en minut. Det illustrerar en avgränsad del av arbetet: att få fram historiska uppgifter. Det säger däremot inget om hur lång tid Solflares hela analysflöde tar, hur uppgifterna kopplas ihop eller hur säkra slutsatserna blir.

Snabb åtkomst löser inte heller definitionsfrågorna. Vad ska räknas som en aktiv användare? När hör flera händelser till samma förlopp? Vilken aktivitet är relevant för den funktion som teamet vill förbättra? Det är sådana val som avgör om en tekniskt korrekt sammanställning också blir användbar.

När intäktsanalysen blir en produktfråga

Ett konkret exempel hos Alapić gäller högspenderande användares bidrag till intäkterna. Här flyttas uppmärksamheten från hur många som använder produkten till hur olika grupper bidrar till verksamheten.

Skillnaden spelar roll. En välanvänd funktion och en intäktsbringande funktion behöver inte vara samma sak. En grupp som märks tydligt i aktivitetsstatistiken behöver inte heller ha samma tyngd i intäkterna. För att förstå sambandet krävs både en tydlig gruppindelning och en genomtänkt definition av vad som räknas som intäkt.

I Alapićs beskrivning finns kopplingen till ett vip-program, exklusiva evenemang och möjligheten att lämna återkoppling på nya funktioner. Analysen blir därmed ett underlag för hur företaget utvecklar relationen med en viss användargrupp, inte bara en rapport över redan inträffade transaktioner.

Här tillför de två datakällorna olika saker. Appdata behövs för att förstå mötet med Solflares funktioner. Blockkedjehistoriken ger ett vidare sammanhang för adressens aktivitet. Tidigare kryptoaktivitet och bidrag till Solflares intäkter är däremot inte utbytbara mått: det ena kan inte utan vidare användas som bevis för det andra.

Det är också viktigt att hålla isär observation, tolkning och resultat. Att en grupp bidrar till intäkterna är en analytisk observation. Att den bör få ett särskilt erbjudande är ett affärsbeslut. Att erbjudandet sedan förbättrar lojaliteten eller produkten är ytterligare ett påstående, som behöver egen uppföljning. Det redovisade exemplet ger ingen grund för att sätta en siffra på en sådan effekt.

En nära dialog med högspenderande användare ger dessutom återkoppling från just den gruppen. Den ersätter inte förståelsen för dem som använder plånboken på andra sätt. Det är en avvägning för produktteamet, inte något som intäktsrapporten kan avgöra åt det.

AI kan skriva rapporten – inte ta ansvaret

Alapić beskriver också hur AI har förändrat analysarbetet. Claude Code ingår bland verktygen, och rapportarbete går snabbare. Samtidigt finns den manuella kvalitetsgranskningen kvar.

Det är lätt att se varför. En välformulerad rapport kan bygga på fel urval. En beräkning kan vara korrekt utförd men besvara en annan fråga än den produktteamet ställde. När data från både app och blockkedja används finns flera led där ett antagande kan bli fel utan att slutresultatet ser orimligt ut vid en snabb genomläsning.

Underlaget beskriver mänsklig granskning, men inte någon fullständig kontrollrutin hos Solflare. Det går därför inte att tillskriva teamet särskilda tester eller godkännandesteg. Däremot är kontrollfrågorna tydliga: håller kopplingarna mellan datakällorna, är grupperna rätt definierade och mäter rapporten verkligen det som beslutet gäller?

AI:s hastighet gör inte de frågorna mindre viktiga. Den flyttar snarare tyngdpunkten från att framställa en sammanställning till att bedöma om den håller. Ett snyggt diagram är fortfarande bara en presentation av de val som gjorts på vägen.

Solflares exempel visar ett dataarbete där produktens gräns inte är datans gräns. Teamet kan följa en adress bakåt och se aktivitet utanför den egna appen. Men steget från offentlig historik till ett välgrundat produktbeslut kräver fortfarande att någon skiljer det som går att observera från det som bara går att anta.