Har bygget egen analytics i PostgreSQL

Situation. Produktbeslutninger kræver tal, og den almindelige måde at få dem på er at sætte et tag fra en tredjepart på hver side og lade andres servere holde øje med brugerne. Det er hurtigt, det er gratis ved små mængder, og det betyder, at besøgendes adfærd på en professionel netværksplatform — hvem der kiggede på hvilken virksomhed, hvem der søgte efter hvad — bliver et aktiv, en annoncevirksomhed sidder på. For en platform, hvis brugere er maritime fagfolk, der kan identificeres, er det en dårlig handel.

Opgave. Produktteamet havde brug for funnels, retention og hændelsesdata, indsamlet på en måde, som platformen kunne stå inde for, og som en bruger kunne sige nej til.

Handling. Analytics kom til at ligge i PostgreSQL, i et skema på 7 tabeller og 47 funktioner. Hændelsestabellerne er partitionerede — 22 partitionsdefinitioner — og rydder automatisk op i sig selv efter en fast plan, for prisen ved first‑party analytics ligger ikke i at indsamle hændelserne, men i at gemme dem for evigt. Identitet er pseudonymiseret bag et salt, der roterer, så en besøgende ikke kan følges hen over rotationsgrænsen, ikke engang inde fra databasen; det er et bevidst loft over, hvad dataene kan svare på. Klienten tager højde for samtykke og sender intet, før samtykket er givet, i stedet for at sende og filtrere bagefter. Konverteringsfunnels beregnes i databasen, ved siden af dataene, i stedet for at blive eksporteret et andet sted hen for at blive joinet tilbage.

Resultat. Spørgsmål om, hvordan produktet bruges, besvares fra platformens egne tabeller, uden at noget forlader den, og uden et tag i siden. Begrænsningerne er den ærlige del: at rotere saltet koster muligheden for kohorteanalyser over lang tid, og intet af det her kommer med de dashboards, man får gratis med et hostet værktøj. Begge dele blev accepteret med åbne øjne.