Webbutik som redan är igång: vad du kontrollerar innan du köper

Säljaren öppnar laptopen, vrider skärmen mot dig, visar ett diagram med en stigande kurva och säger ett tal, som genast följs av de övriga talen och påståendena: butiken är igång, omsättningen är si, köparflödet är så, och priset är det här. Allt ser bra ut, och just därför är det värt att stanna upp, för nästan vart och ett av de här påståendena går att kontrollera, och nästan inget av dem kontrolleras medan avtalet ännu inte är underskrivet.

Den här artikeln handlar om den tekniska kontrollen innan du köper en webbutik som redan är igång, och den handlar inte om vad en sådan butik är värd, för värdering och skattefrågor är andra människors arbete, som vi medvetet inte rör här. Om hur du bygger en butik från grunden har vi skrivit separat, liksom om vad det kostar att skapa en webbutik. Här är det en helt annan situation: butiken finns redan, den har en historia, och frågan är vad av den historien som verkligen följer med till dig och vad som stannar hos säljaren.

Åtkomst till analytics visar mindre än det verkar

Det första varje förnuftig köpare begär är läsåtkomst till Google Analytics, och det är rätt, men det räcker inte, för den åtkomsten bevisar mindre än de flesta tror. Google Analytics 4 har fem roller, nämligen administratör, redigerare, marknadsförare, analytiker och läsbehörig, och det är just rollen Läsbehörig som köparen vanligtvis får: en läsbehörig ser inställningar och data och kan ändra vad som visas i rapporterna, men kan inte hantera användare och inte ändra egendomens inställningar.

Själva tilldelningen säger redan något, för bara en administratör kan lägga till en användare, och användare identifieras med e-postadressen till ett Google-konto, så en säljare som inte kan ge läsåtkomst är inte administratör för den aktuella egendomen, och det är en fråga som ska ställas genast. En skärmbild är inte åtkomst, och ett samtal där säljaren visar sin skärm är inte åtkomst heller, även om siffrorna ser övertygande ut.

Därefter kommer en detalj som få känner till och som kan vända slutsatsen helt, för Google Analytics låter en egendom lägga på databegränsningar, och två av dem rör just pengar: den ena döljer kostnadsmätvärden, den andra döljer intäktsmätvärden. De begränsade värdena syns inte i rapporterna, och användaren ser noll i stället. En köpare som ser nollor i intäktskolumnen har därför inte sett att butiken inte tjänar pengar, utan möjligen sett en begränsning, och det enda sättet att ta reda på det är att fråga om begränsningen är pålagd.

Det finns också en mer allmän gräns som är värd att ha i minnet under hela kontrollen, och den rör själva mätningen: analytics visar det som den inbyggda mätkoden registrerade, inte hur många människor som verkligen kom. En kod som bara sitter på tacksidan, en kod som körs två gånger, en kod på en utvecklingsmiljö eller en och samma kod som betjänar flera webbplatser ser i rapporten ut som besök. Ingen av de fallen är bedrägeri per definition, men var och en gör talet till något annat än det köparen tror.

Search Console är en annan sak och en annan kontroll

Google Search Console visar det som Google själv registrerade om webbplatsens synlighet i sökresultaten, så den är delvis oberoende av den mätkod säljaren har satt upp, och just det oberoendet gör den mer värdefull än analytics, även om siffrorna där är mindre och mindre smickrande. Rollerna där är andra än i analytics: ägare, fullständig användare, begränsad användare och partner, och en egendom måste ha minst en verifierad ägare, annars har ingen någon åtkomst.

En begränsad användare ser resultatrapporten, alltså sökfrågor, klick, exponeringar och genomsnittlig placering, men kan inte lägga till användare, skicka en webbplatskarta eller fullt ut granska en viss webbadress, så för köparen räcker det för att se sökflödet, men det räcker inte för att ta över egendomen. Det är en medveten skillnad som är värd att förstå före samtalet, för en säljare som bara erbjuder åtkomst som begränsad användare erbjuder siffror, inte möjligheten att ta över.

Det finns också frågan om hur gammal själva historiken är, och den brukar avgöra mer än siffrornas storlek, för Google börjar samla data om en egendom redan i det ögonblick någon lägger till den, ännu före verifieringen, så en nyligen skapad egendom kan inte visa flera års historik oavsett hur länge butiken har varit igång. Fråga när egendomen skapades, och jämför det med den ålder butiken påstår sig ha.

Nu till det den här tjänsten kan visa fel, och det här är inte påståenden om att säljare är ohederliga, utan helt enkelt mekaniken: en egendom kan vara av två slag, nämligen en egendom med webbadressprefix, som bara omfattar en adress med protokoll, och en domänegendom, som omfattar hela domänen med alla underdomäner. En domänegendom kan därför blanda ihop butikens flöde och ett helt separat bloggs flöde i en siffra, och det enda sättet att se det är att titta på vilken typ av egendom som är öppen.

Den andra mekaniska frågan är verifieringen, och den går till så här: ägandet verifieras med ett bevis på webbplatsen, och ett av de tillåtna sätten är just Google Analytics-mätkoden. Det betyder att båda verktygen kan vara verifierade med en och samma kod, som en och samma person styr, så två till synes oberoende kontroller kan handla om en och samma, möjligen felaktiga, webbplats. Oanvända äganderättstoken gör det dessutom möjligt för en tidigare borttagen ägare att verifiera sig på nytt, så köparen, när hen blir ägare, måste gå igenom vilka bevis som fortfarande ligger kvar på webbplatsen.

Slutligen är det värt att känna till gränsen för det historiska fönstret, som här är strikt: resultatdata sparas i sexton månader, så en tillväxthistoria över tre år går inte att dra ur det här verktyget, och en säljare som lovar det måste bevisa det med något annat. Och det sista: det är inte riktigt att vänta sig att siffrorna i analytics och i sökverktyget ska stämma överens, för de mäter olika saker, och inget Google-dokument utlovar något bestämt förhållande mellan dem.

Exporten är inte butiken

Den andra stora stötestenen ligger i ordet export, för köparen förstår det som en kopia av butiken, men i praktiken är det ett utdrag ur bestämda tabeller med bestämda gränser. WooCommerce innehåller i grunden ett verktyg för import och export av varor, och det fungerar verkligen, men det är ett varuverktyg: kunder och ordrar omfattas inte alls, och för dem behövs antingen ett betalt tillägg eller direkt åtkomst till databasen.

Bilder är en separat småsak med oproportionerligt stora följder, och skälet sitter i exportmekaniken: varexporten arbetar med bildernas adresser, inte med själva filerna, så bilderna måste vara nåbara i importögonblicket, och grundverktyget flyttar inte bildernas alternativa texter. För en butik med några tusen varor betyder det att en del bilder efter flytten helt enkelt kan saknas, och det upptäcks först när det redan är för sent att förhandla om priset.

På mer stängda plattformar är gränserna hårdare, och de ska vara kända före samtalet om priset, inte efter det: lösenordens hashvärden följer vanligtvis inte med, och det betyder att alla befintliga kunder efter flytten måste återställa lösenordet, vilket är ett direkt kundbortfall och något säljaren sällan nämner. Temalicensen stannar ofta hos säljarens konto, tillägg är separata abonnemang med egna licenser, och orderhistoriken låter en del plattformar inte importera tillbaka via administrationspanelen över huvud taget.

Till samma grupp hör tre småsaker som sällan kommer ihåg och som var och en för sig kostar pengar. Presentkort med saldo är förpliktelser mot kunderna, och de följer inte alltid med de övriga uppgifterna, så frågan om hur mycket outnyttjat saldo det finns i butiken hör till prissamtalet. Säkerhetscertifikatet flyttas inte som egendom, utan utfärdas på nytt i den nye innehavarens namn, och det är rutin bara om domänen redan är i dina händer, medan temalicensen ofta är knuten till säljarens konto, så efter flytten kan det visa sig att utseendet måste köpas en gång till.

Därav följer ett kontrollsteg som inte kostar något och som säger mycket. Be säljaren att göra en testexport redan före avtalet och öppna den själv, för där ser du genast om kunderna finns med, om ordrarna har varurader, om bilderna har adresser och om något av det som syns i butiken inte syns i filen över huvud taget.

Domänen övergår genom överlåtelse, inte genom att namnservrarna byts

Domändelen är den där köpare blandar ihop tre helt olika åtgärder, och den sammanblandningen brukar sluta med att domänen står kvar i säljarens namn. Byte av namnservrar är bara en anvisning om vem som sköter domänens poster, och med innehavet har det ingenting att göra; byte av registrar ändrar vem som administrerar domänen; och överlåtelse av domännamn är den åtgärd som ändrar på vems namn domänen är registrerad.

För .se-domäner styrs överlåtelsen av Internetstiftelsens registreringsvillkor, och den görs genom en registrar, inte genom ett brev till registret. Endast innehavaren kan begära överlåtelse, och registraren ska kontrollera att den som begär den verkligen är innehavaren, till exempel med BankID eller mot Bolagsverket. Den nya innehavaren ska ha godkänt registreringsvillkoren och lämnat de uppgifter som behövs, och registraren ska flytta över registreringen snarast, dock senast inom fem arbetsdagar från det att förutsättningarna är uppfyllda. Begäran går alltså genom registraren, inte direkt till Internetstiftelsen.

Två detaljer i den ordningen är viktigare än de övriga, och den första är att när överlåtelsen har beviljats ersätter den nya innehavaren den tidigare, så att den som sålde inte längre är den registrerade innehavaren; ordningen ska göras rätt från första gången. Den andra är att det inte räcker att någon anställd hos bolaget skickar in en begäran: registraren ska försäkra sig om att den som begär överlåtelsen har rätt att företräda innehavaren.

Särskild uppmärksamhet krävs när säljaren är ett bolag som ska likvideras, för just här kan köpet av butiken sluta med att domänen går förlorad. Det finns ingen svensk regel som säger att överlåtelsen måste göras innan likvidationen är avslutad, att vilande näringsverksamhet blockerar bytet, eller att namnet efter en kort övergång blir fritt att registrera för vem som helst. Överlåtelsen går fortfarande genom registraren, och den som begär den måste ha rätt att företräda innehavaren; är bolaget redan upplöst är det en annan procedur, inte en automatisk övergång. En köpare som väntar tills säljaren har städat undan sina affärer kan alltså fortfarande förlora butikens adress.

Betalningskontot följer inte med köpeavtalet

Föreställningen att också mottagandet av betalningar följer med butiken är utbredd och felaktig, men det är lika fel att säga att ett betalningskonto inte går att flytta alls, för den rätta formuleringen ligger i mitten: köpeavtalet i sig rubbar inte kontot, men betaltjänstleverantören har sin egen ordning, och den kan också säga nej.

Stripe beskriver just det här fallet i sin dokumentation och anger att den befintliga kontoinnehavaren som vill lämna över kontot till någon annan, till exempel vid försäljning av företaget, först ska kontakta supporten för att ta reda på vilken information som måste uppdateras. Därefter ska uppgifterna om bankkontot för utbetalningar, företagets juridiska namn, skatteregistreringsnummer och företrädarens uppgifter ändras, och företaget varnar uttryckligen för att skicka den nye ägarens uppgifter via e-post, medan ordningen är en annan om företaget har tagits över av en juridisk person i ett annat land.

Det finns ytterligare en detalj som just rör uppgifterna och som köpare får veta sent: om övergången inte sker genom att samma konto tas över, utan genom flytt till ett nytt, då kan kunder och betalningsmetoder kopieras mellan de två kontona, men enskilda betalningar, fakturor, planer och abonnemang, kuponger, händelser och loggar kopieras inte. För en butik med abonnemang är det kritiskt, för avbrutna abonnemang betyder avbrutna intäkter, och den frågan ska ställas före avtalet, inte efter det.

Svenska bankers och lokala betaltjänsters villkor vid förvärv använder vi inte här, för dem har vi inte läst för den här kontrollen, och det är ärligare att säga än att fylla luckan med en gissning, så det är ett medvetet hål, inte ett förbiseende. Om butiken tar emot betalningar via en svensk bank eller en lokal betaltjänst ska frågan om avtalet får överlåtas ställas just till den leverantören, och Stripes ordning får inte flyttas över dit.

Kundlistan är den juridiskt vassaste delen

Här är platsen där köparen kan förvärva inte en tillgång utan en skyldighet, och just därför är det här avsnittet skrivet som en varning, inte som en instruktion. Början sitter i avtalets struktur: om du köper bolagets aktier (aktieöverlåtelse), då förblir personuppgiftsansvarig samma juridiska person och databasen byter inte ägare; om du köper butiken som inkråm från ett annat rättssubjekt (inkråmsöverlåtelse), då hamnar personuppgifterna hos en ny personuppgiftsansvarig, och det är ett helt annat fall.

Dataskyddsförordningen lovar ingenting om köp av butiker, och i den finns ingen artikel som säger att kunddatabasen följer med automatiskt. Det måste finnas en rättslig grund enligt artikel 6, och det finns en informationsplikt: artikel 13 kräver att den personuppgiftsansvariges identitet anges när uppgifterna samlas in, medan artikel 14, som just rör fallet där uppgifterna inte har samlats in från personen själv, kräver att den nye personuppgiftsansvarige upplyser om sin identitet, sina ändamål, den rättsliga grunden, kategorierna av personuppgifter och källan, och att det görs senast inom en månad eller vid den första kommunikationen.

I Sverige kommer det för e-postmarknadsföring ytterligare en lag, och just den är kärnan i det här avsnittet. 19 § marknadsföringslagen (2008:486) förbjuder en näringsidkare att vid marknadsföring till en fysisk person använda elektronisk post om personen inte har samtyckt till det på förhand, och det enda undantaget kräver tre villkor samtidigt: marknadsföringen avser näringsidkarens egna likartade produkter, personen har inte motsatt sig att adressen används, och personen ges vid insamlingen och i varje senare meddelande en klar, tydlig, kostnadsfri och enkel möjlighet att motsätta sig. Dataskyddsförordningen kräver fortfarande en rättslig grund enligt artikel 6; marknadsföringslagen ersätter inte den.

Och nu det som gör det här till en fälla: det nämnda undantaget är skrivet för den näringsidkare som har fått adresserna i sina egna affärer, alltså samma näringsidkare som betjänade kunderna. En köpare som inte har fått adresserna är inte den näringsidkaren, så den tidigare ägarens undantag följer inte med filen; tystnad från en myndighet är inte ett tillstånd.

Frågan är löst olika i olika länder, och den skillnaden är det ärligare att visa än att dölja. Tysklands dataskyddskonferens intog 2024 en sträng hållning och menade att försäljning av en kunddatabas som en fristående tillgång i regel kräver förhandssamtycke, medan Spaniens nationella lag innehåller en bestämmelse som vid övergång av verksamhet presumerar behandlingen som laglig om den behövs för verksamhetens kontinuitet. Sverige har inte reglerat frågan med någon egen presumtion av det slaget, så köparen har förordningen, den nämnda 19 § och en juridisk bedömning av det konkreta avtalet.

Kontroller som inte beror på säljaren

Alla föregående kontroller beror på vad säljaren ger och vad hens inställningar visar, så vid sidan av dem är det värt att lägga minst en vars källa är en annan, och den enklaste av sådana kontroller är serverloggarna, för de skriver ner förfrågningar oberoende av om sidan över huvud taget har någon mätkod och av om besökaren samtyckte till kakor.

Det här är inte en Google-metod och inget Google-dokument rekommenderar den, så vi presenterar den inte heller som ett officiellt råd, utan som en praxis där man, när man jämför volymen förfrågningar i loggarna med analytics-sessionerna för samma period, vanligtvis ser antingen ett rimligt förhållande eller en sådan skillnad att det är värt att fråga. Åtkomst till loggarna ger vanligtvis webbhotellets kontrollpanel, så den här kontrollen kräver åtkomst till webbhotellet, och just därför är den värd att begära samtidigt med det övriga.

Den andra oberoende källan är betaltjänstleverantörens översikt, och det är den enda av alla som visar pengar, inte besök. Här är en skillnad viktig: den översikt säljaren skickar som ett dokument är inte densamma som den översikt du ser i själva leverantörens panel, för den första kan vem som helst ta fram, den andra inte, så be om åtkomst till panelen eller åtminstone om en gemensam skärm med den öppen.

Det finns ytterligare en kontroll som tar fem minuter och som nästan alla hoppar över: att titta på hur butiken ser ut i sökmotorn i dag, genom att skriva in dess namn och några fraser ur varunamnen. Om butiken påstår ett stabilt sökflöde, men själv inte syns på sitt eget namn eller syns bakom marknadsplatser där den själv säljer, då kommer flödet någon annanstans ifrån, och det är värt att ta reda på varifrån, för betald reklam kan efter avtalet helt enkelt stanna av.

Den tredje är bokföringssidan, som vi inte rör i sak, men vars existens är värd att nämna, för den är den enda som knyter allt det övriga till deklarerade siffror, och om analytics, betalningspanelen och bokföringen berättar tre olika historier, då är problemet inte mätningens precision, och sedan är det inte längre ett tekniskt samtal.

Kodens och plattformens skick går att kontrollera billigt

Kontrollen av det tekniska skicket låter som en dyr granskning, men merparten av svaret går att få på några timmar och med offentliga uppgifter. Det första steget är att ta reda på plattformens och språkets version och jämföra den med tillverkarens publicerade stödkalender, för när stödet har upphört patchas inte nya sårbarheter längre, även om butiken fortsätter att köra precis som förut.

Det andra steget är listan över tillägg tillsammans med deras uppdateringshistorik, för ett övergivet tillägg är samtidigt en säkerhetsrisk och en dold kostnad: någon gång måste det ersättas, och att ersätta det i en butik som redan är igång betyder vanligtvis att också allt som har byggts runt tillägget måste skrivas om. Det tredje är frågan om butiken någon gång har blivit hackad och vad som gjordes därefter, och den frågan är värd att ställa rakt, för ett undvikande svar är här lika upplysande som ett jakande.

Det fjärde steget rör koden, om butiken är anpassad, och det ligger nära den fråga vi har behandlat separat i artikeln om vad du äger när systemet är klart. Här räcker den praktiska sidan: var kodförrådet ligger, vem som kan komma åt det och om det följer med till dig tillsammans med butiken, för ett kodförråd på säljarens personliga konto stannar efter avtalet på säljarens personliga konto, om det inte flyttas särskilt.

Vid sidan av kodförrådet finns åtkomster och nycklar, och de brukar vara utspridda på ställen som ingen har skrivit upp: webbhotellets panel, domänkontot, betalningspanelen, e-posttjänsten, nycklar till externa tjänster och analytics. Listan över dem är värd att begära skriftligt före avtalet och att kontrollera efter det, för en nyckel som ingen lämnade över brukar visa sig först när något slutar fungera, och då har säljaren redan gått.

Det femte är listan över löpande kostnader som följer med butiken, och den brukar vara längre än köparen väntar sig, för där ryms plattformens abonnemang, separata tilläggsabonnemang, temat, betaltjänstens provisioner, webbhotell, domän och certifikat, och var och en av dem har sitt förnyelsedatum och sitt pris efter den första perioden. Den listan är värd att sätta i en tabell före prissamtalet, för just den visar vad butikens verkliga månadskostnad är.

Vad du ska begära innan du skriver under

Allt det föregående landar i ett knippe krav som inte tar mycket tid och som en hederlig säljare inte har svårt att uppfylla: på analytics-sidan är det åtkomst som läsbehörig till själva egendomen, inte skärmbilder, tillsammans med ett svar på om begränsningen av intäktsmätvärden är pålagd, och på Search Console-sidan åtkomst som begränsad användare tillsammans med uppgift om vilken typ av egendom som är öppen.

På datasidan är det en testexport före avtalet, ett svar på om lösenordens hashvärden följer med, och klarhet om vad som händer med orderhistoriken. På domänsidan är det ett belägg för på vems namn domänen är registrerad i dag, och en överenskommelse om att överlåtelsen sker före betalningen eller samtidigt med den, inte efter.

På betalningssidan är det en fråga till betaltjänstleverantören, inte till säljaren, för bara den kan säga om kontot följer med och på vilka villkor, och säljarens övertygelse i den frågan är inte ett bevis. Finns det abonnemang i butiken ska samma fråga ställas en gång till, särskilt om just dem, för abonnemang är den del som oftast brister vid en flytt. På dataskyddssidan är det klarhet om hur listan samlades in och vad kunderna då fick veta, och en skriftlig överenskommelse om att den nye personuppgiftsansvarige efter avtalet ska uppfylla sin informationsplikt.

Det här knippet krav ser långt ut, men det är kortare än den vecka som går åt till att efter avtalet försöka få tillbaka en domän eller återställa abonnemang, och merparten av det tar en hederlig säljare fram på ett par timmar. En säljare som invänder mot de här kraven har med det svaret redan besvarat den viktigaste frågan, och det är det billigaste sättet som finns att ta reda på det.

Och till sist är det två saker som den här artikeln medvetet inte gör, för de är inte vårt arbete och att låtsas vara ett annat yrke vore det sämsta vi kunde göra här. Vi uttalar oss inte om vad butiken är värd, och vi ersätter inte en jurist i frågan om hur en konkret kundlista får användas, för båda är andra människors arbete. Vill du att vi kontrollerar den tekniska delen innan du skriver under, hör av dig, så gör vi det tillsammans med teamet för utveckling av webbutiker.