Nettbutikk som allerede er i drift: hva du sjekker før du kjøper

Selgeren åpner laptopen, snur skjermen mot deg, viser en graf med en stigende kurve og sier et tall, som straks følges av de øvrige tallene og påstandene: butikken er i drift, omsetningen er sånn, kjøperstrømmen er slik, og prisen er denne. Alt ser bra ut, og nettopp derfor er det verd å stanse opp, for nesten hver av disse påstandene kan sjekkes, og nesten ingen av dem blir sjekket mens avtalen ennå ikke er underskrevet.

Denne artikkelen handler om den tekniske sjekken før du kjøper en nettbutikk som allerede er i drift, og den handler ikke om hva en slik butikk er verd, for verdsettelse og skattespørsmål er andre menneskers arbeid, som vi med vilje ikke rører her. Om hvordan du lager en butikk fra bunnen av har vi skrevet separat, likeså om hva det koster å lage en nettbutikk. Her er det en helt annen situasjon: butikken finnes allerede, den har en historie, og spørsmålet er hva av den historien som faktisk følger med til deg, og hva som blir igjen hos selgeren.

Tilgang til Analytics viser mindre enn det ser ut som

Det første hver fornuftig kjøper ber om, er lesetilgang til Google Analytics, og det er riktig, men det holder ikke, for den tilgangen beviser mindre enn de fleste tror. Google Analytics 4 har fem roller, nemlig administrator, redigerer, markedsfører, analytiker og seer, og det er nettopp seerrollen kjøperen vanligvis får: en seer ser innstillinger og data og kan endre det som vises i rapportene, men kan ikke administrere brukere og ikke endre områdets innstillinger.

Selve tildelingen sier allerede noe, for bare en administrator kan legge til en bruker, og brukere identifiseres med e-postadressen til en Google-konto, så en selger som ikke kan gi lesetilgang, er ikke administrator for det aktuelle området, og det er et spørsmål som skal stilles med en gang. Et skjermbilde er ikke tilgang, og en samtale der selgeren viser skjermen sin, er heller ikke tilgang, selv om tallene ser overbevisende ut.

Deretter kommer en detalj som få kjenner til, og som kan snu konklusjonen helt, for Google Analytics lar et område legge på databegrensninger, og to av dem gjelder nettopp penger: den ene skjuler kostnadsmålinger, den andre skjuler inntektsmålinger. De begrensede verdiene vises ikke i rapportene, og brukeren ser null i stedet. En kjøper som ser nuller i inntektskolonnen, har derfor ikke sett at butikken ikke tjener penger, men muligens sett en begrensning, og den eneste måten å avklare det på, er å spørre om begrensningen er lagt på.

Det finnes også en mer generell grense som er verd å ha i hodet gjennom hele sjekken, og den gjelder selve målingen: Analytics viser det den innebygde målekoden registrerte, ikke hvor mange mennesker som faktisk kom. En kode som bare sitter på takkesiden, en kode som kjører to ganger, en kode på et utviklingsmiljø eller én og samme kode som betjener flere nettsteder, ser i rapporten ut som besøk. Ingen av disse tilfellene er svindel per definisjon, men hver av dem gjør tallet til noe annet enn det kjøperen tror.

Search Console er et annet objekt og en annen sjekk

Google Search Console viser det Google selv registrerte om nettstedets synlighet i søkeresultatene, så den er delvis uavhengig av målekoden selgeren har satt opp, og nettopp den uavhengigheten gjør den mer verdifull enn Analytics, selv om tallene der er mindre og mindre smigrende. Rollene der er andre enn i Analytics: eier, full bruker, begrenset bruker og tilknyttet bruker, og et område må ha minst én verifisert eier, ellers har ingen noen tilgang.

En begrenset bruker ser resultatrapporten, altså spørringer, klikk, visninger og gjennomsnittlig plassering, og kan ikke legge til brukere, sende inn et nettstedskart eller fullt ut undersøke en bestemt adresse, så for kjøperen holder det for å se søkestrømmen, men det holder ikke for å overta området. Det er en bevisst forskjell som er verd å forstå før samtalen, for en selger som bare tilbyr tilgang som begrenset bruker, tilbyr tall, ikke muligheten til å overta.

Det er også spørsmålet om hvor gammel selve historikken er, og det pleier å avgjøre mer enn tallenes størrelse, for Google begynner å samle data om et område allerede i det øyeblikket noen legger det til, ennå før verifiseringen, så et nylig opprettet område kan ikke vise flere års historikk uansett hvor lenge butikken har vært i drift. Spør når området ble opprettet, og sammenlign det med alderen butikken hevder å ha.

Nå til det dette verktøyet kan vise feil, og dette er ikke påstander om at selgere er uærlige, men rett og slett mekanikken: et område kan være av to slag, nemlig et område med URL-prefiks, som bare dekker én adresse med protokoll, og et domeneområde, som dekker hele domenet med alle underdomener. Et domeneområde kan derfor blande butikkens strøm og et helt separat bloggs strøm i ett tall, og den eneste måten å se det på, er å se hvilken type område som er åpent.

Det andre mekaniske spørsmålet er verifiseringen, og den skjer slik: eierskapet bekreftes med et bevis på nettstedet, og én av de tillatte måtene er nettopp Google Analytics-målekoden. Det betyr at begge verktøyene kan være verifisert med én og samme kode, som én og samme person styrer, så to tilsynelatende uavhengige sjekker kan handle om ett og samme, muligens feilaktige, nettsted. Ubrukte eierskapsbevis gjør det dessuten mulig for en tidligere fjernet eier å verifisere seg på nytt, så du, når du blir eier, må gå gjennom hvilke bevis som fortsatt ligger igjen på nettstedet.

Til slutt er det verd å kjenne grensen for det historiske vinduet, som her er streng: resultatdata lagres i seksten måneder, så en veksthistorie over tre år kan ikke trekkes ut av dette verktøyet, og en selger som lover det, må bevise det med noe annet. Og det siste: det er ikke riktig å vente at tallene i Analytics og i søkeverktøyet skal stemme overens, for de måler ulike ting, og ingen Google-dokument lover noe bestemt forhold mellom dem.

Eksporten er ikke butikken

Den andre store vanskeligheten ligger i ordet eksport, for kjøperen forstår det som en kopi av butikken, men i praksis er det et utdrag fra bestemte tabeller med bestemte grenser. WooCommerce har i bunnen et verktøy for import og eksport av produkter, og det virker faktisk, men det er et produktverktøy: kunder og ordrer dekker det ikke i det hele tatt, og for dem trengs enten en betalt utvidelse eller direkte tilgang til databasen.

Bilder er en separat småting med uforholdsmessig store følger, og årsaken sitter i eksportmekanikken: produkteksporten arbeider med bildenes adresser, ikke med selve filene, så bildene må være tilgjengelige i importøyeblikket, og grunnverktøyet flytter ikke bildenes alternative tekster. For en butikk med noen tusen produkter betyr det at en del bilder etter flyttingen rett og slett kan mangle, og det oppdages først når det allerede er for sent å forhandle om prisen.

På mer lukkede plattformer er grensene hardere, og de skal være kjent før samtalen om prisen, ikke etter den: hashverdier for passord følger vanligvis ikke med, og det betyr at alle eksisterende kunder etter flyttingen må tilbakestille passordet, noe som er et direkte kundefrafall og noe selgeren sjelden nevner. Lisensen til temaet blir ofte igjen hos selgerens konto, utvidelser er separate abonnementer med egne lisenser, og en del plattformer lar ikke ordrehistorikken importeres tilbake via administrasjonspanelet i det hele tatt.

Til den samme gruppen hører tre småting som sjelden huskes, og som hver for seg koster penger. Gavekort med saldo er forpliktelser overfor kundene, og de følger ikke alltid med de øvrige dataene, så spørsmålet om hvor mye ubrukt saldo det er i butikken, hører til prissamtalen. Sikkerhetssertifikatet flyttes ikke som eiendom, men utstedes på nytt i den nye innehaverens navn, og det er rutine bare hvis domenet allerede er i hendene dine, mens temalisensen ofte er knyttet til selgerens konto, så etter flyttingen kan det vise seg at utseendet må kjøpes en gang til.

Derav følger et sjekksteg som ikke koster noe og som sier mye. Be selgeren om å lage en testeksport allerede før avtalen og åpne den selv, for der ser du med en gang om kundene er med, om ordrene har produktlinjer, om bildene har adresser, og om noe av det som er synlig i butikken, ikke vises i filen i det hele tatt.

Domenet går over med abonnentbytte, ikke med bytte av navnetjenere

Domenedelen er der kjøpere blander tre helt ulike handlinger, og den sammenblandingen pleier å ende med at domenet blir stående i selgerens navn. Bytte av navnetjenere er bare en anvisning om hvem som betjener domenets poster, og med bruksretten har det ingenting å gjøre; bytte av domeneforhandler endrer hvem som administrerer domenet; og abonnentbytte er den handlingen som endrer på hvem sitt navn domenet er registrert.

For .no-domener styres abonnentbyttet av Norids regelverk for norske domenenavn, og det gjøres gjennom en domeneforhandler, ikke ved at du skriver til registeret. Overføring mellom to abonnenter avvikler det eksisterende abonnementet og oppretter et nytt for den nye abonnenten; den nye abonnenten må oppfylle vilkårene for et nytt abonnement, det eksisterende abonnementet må ikke være utløpt, og den avgivende abonnenten må akseptere å gi fra seg navnet. Alle bestillinger og overføringer går gjennom en domeneforhandler, Norid tar ikke imot ordrer direkte fra abonnenter, og organisasjoner må være registrert i Enhetsregisteret og drive reell virksomhet.

To detaljer i den ordningen er viktigere enn de øvrige, og den første er at abonnentbyttet avvikler det gamle abonnementet og oppretter et nytt, med ny registreringsdato, så den som solgte, ikke lenger er abonnent; rekkefølgen skal gjøres riktig fra første gang. Den andre er at det ikke holder at en ansatt i selskapet sender inn en bestilling: den nye abonnenten må allerede oppfylle vilkårene, blant annet ha organisasjonsnummer i Enhetsregisteret, og den avgivende må akseptere å gi fra seg navnet.

Særskilt oppmerksomhet trengs når selgeren er et selskap som skal avvikles, for nettopp her kan kjøpet av butikken ende med at domenet går tapt. Norid kan slette et domenenavn hvis abonnenten ikke lenger finnes — for organisasjoner betyr det at de er slettet i Enhetsregisteret — og navnet blir deretter tilgjengelig for andre, med minst 30 dager der det er utilgjengelig for nyregistrering. En organisasjon som er ute av Enhetsregisteret, kan ikke beholde et .no. En kjøper som venter til selgeren har ryddet opp i sine saker, kan altså likevel miste butikkens adresse.

Betalingskontoen følger ikke med kjøpsavtalen

Forestillingen om at mottak av betaling også følger med butikken, er utbredt og feil, men det er like feil å si at en betalingskonto ikke kan flyttes i det hele tatt, for den riktige formuleringen ligger i midten: kjøpsavtalen i seg selv rører ikke kontoen, men betalingstjenesteyteren har sin egen ordning, og den kan også si nei.

Stripe beskriver nettopp dette tilfellet i dokumentasjonen sin og angir at den eksisterende kontoeieren som vil overlate kontoen til noen andre, for eksempel ved salg av virksomheten, først skal kontakte brukerstøtten for å avklare hvilken informasjon som må oppdateres. Deretter skal opplysningene om bankkontoen for utbetalinger, selskapets juridiske navn, skattemessig identifikasjonsnummer og representantens data endres, og selskapet advarer uttrykkelig mot å sende den nye eierens opplysninger på e-post, mens ordningen er en annen hvis selskapet er overtatt av en juridisk person i et annet land.

Det finnes ytterligere en detalj som nettopp gjelder dataene, og som kjøpere får vite sent: hvis overgangen ikke skjer ved at den samme kontoen overtas, men ved flytting til en ny, da kan kunder og betalingsmetoder kopieres mellom de to kontoene, men enkeltbetalinger, fakturaer, planer og abonnementer, kuponger, hendelser og logger kopieres ikke. For en butikk med abonnementer er det kritisk, for avbrutte abonnementer betyr avbrutte inntekter, og det spørsmålet skal stilles før avtalen, ikke etter den.

Vilkårene i norske bankers og lokale betalingsformidleres oppkjøpsavtaler bruker vi ikke her, for dem har vi ikke lest for denne sjekken, og det er ærligere å si enn å fylle hullet med et gjett, så det er et bevisst hull, ikke en forglemmelse. Hvis butikken tar imot betalinger via en norsk bank eller en lokal betalingsformidler, skal spørsmålet om avtalen kan overdras, stilles nettopp til den tjenesteyteren, og Stripes ordning må ikke flyttes over dit.

Kundelisten er den juridisk skarpeste delen

Her er stedet der kjøperen kan erverve ikke et aktivum, men en plikt, og nettopp derfor er dette avsnittet skrevet som en advarsel, ikke som en instruksjon. Begynnelsen sitter i avtalens struktur: hvis du kjøper aksjene i selskapet (aksjesalg), da forblir behandlingsansvarlig det samme rettssubjektet og databasen bytter ikke eier; hvis du kjøper butikken som innmat fra et annet rettssubjekt (innmatsalg), da havner personopplysningene hos en ny behandlingsansvarlig, og det er et helt annet tilfelle.

Personvernforordningen lover ingenting om kjøp av butikker, og i den finnes det ingen artikkel som sier at kundedatabasen følger med automatisk. Det må finnes et behandlingsgrunnlag etter artikkel 6, og det finnes en opplysningsplikt: artikkel 13 krever at den behandlingsansvarliges identitet oppgis når opplysningene samles inn, mens artikkel 14, som nettopp gjelder tilfellet der opplysningene ikke er samlet inn fra personen selv, krever at den nye behandlingsansvarlige opplyser om sin identitet, sine formål, det rettslige grunnlaget, kategoriene av personopplysninger og kilden, og at det gjøres senest innen en måned eller ved den første henvendelsen.

I Norge kommer det for e-postmarkedsføring ytterligere en lov, og nettopp den er kjernen i dette avsnittet. Markedsføringsloven § 15 forbyr, uten mottakerens forutgående samtykke, å rette markedsføringshenvendelser til fysiske personer ved elektroniske kommunikasjonsmetoder som tillater individuell kommunikasjon, og unntaket i tredje ledd krever at det foreligger et eksisterende kundeforhold der den næringsdrivende avtaleparten har mottatt kundens elektroniske adresse i forbindelse med salg, at markedsføringen bare gjelder den næringsdrivendes egne varer, tjenester eller andre ytelser tilsvarende dem kundeforholdet bygger på, og at kunden enkelt og gebyrfritt gis anledning til å reservere seg når adressen samles inn og ved hver senere henvendelse. Datatilsynet gjentar de samme vilkårene og peker på § 15 tredje ledd; Forbrukertilsynet håndhever markedsføringsloven.

Og nå det som gjør dette til en felle: det nevnte unntaket er skrevet for den næringsdrivende som har mottatt adressene i sine egne salg, altså den samme som betjente kundene. En kjøper som ikke har mottatt adressene, er ikke den næringsdrivende, så den tidligere eierens unntak følger ikke med filen; taushet fra en tilsynsmyndighet er ikke en tillatelse.

Utenfor Norge er dette spørsmålet løst ulikt, og den forskjellen er det ærligere å vise enn å skjule. Den tyske konferansen for personvernmyndigheter inntok i 2024 en streng holdning og mente at salg av en kundedatabase som et frittstående aktivum i regelen krever forhåndssamtykke, mens Spanias nasjonale lov inneholder en bestemmelse som ved overgang av virksomhet presumerer behandlingen som lovlig hvis den trengs for virksomhetens kontinuitet. Norge har ikke regulert spørsmålet med noen slik egen presumsjon, så kjøperen har forordningen, den nevnte § 15 og en juridisk vurdering av den konkrete avtalen.

Sjekker som ikke avhenger av selgeren

Alle de foregående sjekkene avhenger av det selgeren gir og det selgerens innstillinger viser, så ved siden av dem er det verd å legge minst én der kilden er en annen, og den enkleste av slike sjekker er serverloggene, for de skriver ned forespørsler uavhengig av om siden i det hele tatt har en målekode, og av om besøkende samtykket til informasjonskapsler.

Dette er ikke en Google-metode, og ingen Google-dokument anbefaler den, så vi presenterer den heller ikke som et offisielt råd, men som en praksis der man, når man sammenligner volumet av forespørsler i loggene med Analytics-øktene for samme periode, vanligvis ser enten et rimelig forhold eller en slik forskjell at det er verd å spørre. Webhotellets kontrollpanel gir vanligvis tilgang til loggene, så denne sjekken krever tilgang til webhotellet, og nettopp derfor er den verd å be om samtidig med det øvrige.

Den andre uavhengige kilden er betalingstjenesteyterens oversikt, og det er den eneste av alle som viser penger, ikke besøk. Her er én forskjell viktig: oversikten selgeren sender som et dokument, er ikke den samme som oversikten du ser i selve tjenesteyterens panel, for den første kan hvem som helst lage, den andre ikke, så be om tilgang til panelet eller i det minste om en felles skjerm med det åpent.

Det finnes ytterligere en sjekk som tar fem minutter, og som nesten alle hopper over: å se hvordan butikken ser ut i søkemotoren i dag, ved å skrive inn butikkens navn og noen fraser fra produktnavnene. Hvis butikken påstår en stabil søkestrøm, men selv ikke vises på sitt eget navn eller vises bak markedsplasser der den selv selger, da kommer strømmen et annet sted fra, og det er verd å finne ut hvorfra, for betalt reklame kan etter avtalen rett og slett stoppe.

Den tredje er regnskapssiden, som vi ikke rører i sak, men hvis eksistens er verd å nevne, for den er den eneste som knytter alt det øvrige til deklarerte tall, og hvis Analytics, betalingspanelet og regnskapet forteller tre ulike historier, da er problemet ikke målingens presisjon, og deretter er det ikke lenger en teknisk samtale.

Kodens og plattformens tilstand kan sjekkes billig

Sjekken av den tekniske tilstanden høres ut som en dyr revisjon, men merparten av svaret kan fås på noen timer og med offentlige opplysninger. Det første steget er å finne ut plattformens og språkets versjon og sammenligne den med produsentens publiserte støttekalender, for når støtten er opphørt, får nye sårbarheter ikke lenger oppdateringer, selv om butikken fortsetter å kjøre akkurat som før.

Det andre steget er listen over utvidelser sammen med oppdateringshistorikken deres, for en forlatt utvidelse er samtidig en sikkerhetsrisiko og en skjult kostnad: før eller senere må den erstattes, og å erstatte den i en butikk som allerede er i drift, betyr vanligvis at også alt som er bygd rundt den, må skrives om. Det tredje er spørsmålet om butikken noen gang har vært hacket, og hva som ble gjort etterpå, og det spørsmålet er verd å stille rett ut, for et unnvikende svar er her like opplysende som et bekreftende.

Det fjerde steget gjelder koden, hvis butikken er tilpasset, og det ligger nær det spørsmålet vi har behandlet separat i artikkelen om hva du eier når systemet er ferdig. Her holder den praktiske siden: hvor kodelageret ligger, hvem som kan nå det, og om det følger med til deg sammen med butikken, for et kodelager på selgerens personlige konto blir etter avtalen liggende på selgerens personlige konto, hvis det ikke flyttes særskilt.

Ved siden av kodelageret finnes tilganger og nøkler, og de pleier å være spredt på steder som ingen har skrevet opp: webhotellets panel, domenekontoen, betalingspanelet, e-posttjenesten, nøkler til eksterne tjenester og Analytics. Listen over dem er verd å be om skriftlig før avtalen og å sjekke etter den, for en nøkkel som ingen overleverte, pleier å vise seg først når noe slutter å virke, og da er selgeren allerede gått.

Det femte er listen over løpende kostnader som følger med butikken, og den pleier å være lenger enn kjøperen venter, for der inngår plattformabonnementet, separate utvidelsesabonnementer, temaet, betalingstjenesteyterens provisjoner, webhotell, domene og sertifikater, og hver av dem har sin fornyelsesdato og sin pris etter den første perioden. Den listen er verd å sette i én tabell før prissamtalen, for nettopp den viser hva butikkens reelle månedskostnad er.

Hva du skal be om før du skriver under

Alt det foregående lander i et knippe krav som ikke tar mye tid, og som en ærlig selger ikke har vanskelig for å oppfylle: på Analytics-siden er det lesertilgang til selve området, ikke skjermbilder, sammen med et svar på om begrensningen av inntektsmålinger er lagt på, og på Search Console-siden tilgang som begrenset bruker sammen med opplysning om hvilken type område som er åpent.

På datasiden er det en testeksport før avtalen, et svar på om hashverdier for passord følger med, og klarhet om hva som skjer med ordrehistorikken. På domenesiden er det dokumentasjon på hvem som står som abonnent i dag, og en avtale om at abonnentbyttet skjer før betalingen eller samtidig med den, ikke etter, og at den nye abonnenten allerede har organisasjonsnummer.

På betalingssiden er det et spørsmål til betalingstjenesteyteren, ikke til selgeren, for bare den kan si om kontoen følger med og på hvilke vilkår, og selgerens overbevisning i det spørsmålet er ikke et bevis. Finnes det abonnementer i butikken, skal det samme spørsmålet stilles en gang til, særskilt om nettopp dem, for abonnementer er den delen som oftest brekker ved en flytting. På personvernsiden er det klarhet om hvordan listen ble samlet inn og hva kundene da fikk vite, og en skriftlig avtale om at den nye behandlingsansvarlige etter avtalen skal oppfylle opplysningsplikten sin.

Dette knippet krav ser langt ut, men det er kortere enn den uken som går med til å etter avtalen prøve å få tilbake et domene eller gjenopprette abonnementer, og merparten av det tar en ærlig selger fram på et par timer. En selger som innvender mot disse kravene, har med det svaret allerede besvart det viktigste spørsmålet, og det er den billigste måten som finnes å finne det ut på.

Og til slutt er det to ting denne artikkelen med vilje ikke gjør, for de er ikke vårt arbeid, og å late som om vi er et annet yrke ville være det dårligste vi kunne gjøre her. Vi uttaler oss ikke om hva butikken er verd, og vi erstatter ikke en jurist i spørsmålet om hvordan en konkret kundeliste kan brukes, for begge deler er andre menneskers arbeid. Vil du at vi sjekker den tekniske delen før du skriver under, skriv til oss, så gjør vi det sammen med teamet for utvikling av nettbutikker.