Hvorfor WooCommerce-pluginen eller Shopify-appen din får installasjoner, men ingen betalende brukere, og go-to-market-prosedyren som løser det

Jeg lager egne WooCommerce-plugins under merket plogins, og jeg ser det samme mønsteret i min egen statistikk og i verktøyene byråer viser meg: antallet installasjoner øker, men den betalte varianten står stille. Oppføringen får folk til å klikke “Install”. Etter det vet ingen om brukeren fullførte oppsettet, så et resultat eller slettet pluginen samme ettermiddag.

Denne guiden er prosedyren jeg bruker for å finne ut hvor frafallet skjer og rette det. Den dekker plugins på WordPress.org og apper i Shopify App Store side om side, fordi problemene ligner hverandre selv om butikkene er ulike. Hver grense nedenfor kommer fra plattformens egen dokumentasjon, med lenke ved siden av faktaet. Der en plattform ikke dokumenterer noe, sier jeg det.

Driver du en plugin eller en app som produkt, eller et byrå med egne verktøy, er dette arbeidet en go-to-market-ingeniør gjør: oppføringer, måling av onboarding og innhold som følger utgivelsene.

#Hvorfor får WooCommerce-pluginen min installasjoner, men ingen betalende brukere?

Installasjoner måler oppføringen. Betalende brukere måler alt som skjer etterpå. Når de to tallene går fra hverandre, ligger gapet på ett av fire steder:

1. Oppføringen tiltrekker feil leser. Tagger, søkeord eller kortbeskrivelse treffer et søk med et ønske produktet ditt ikke dekker. Disse installasjonene faller fra fordi produktet svarer på et annet spørsmål.
2. Oppsettet er for langt eller for uklart. Brukeren aktiverer pluginen, havner på en innstillingsside med tjue felt og forsvinner. I Shopify skjer det samme på den innebygde admin-skjermen.
3. Det første resultatet kommer sent. En fraktplugin som først viser verdien sin når neste bestilling kommer inn, har et langt hull mellom installasjon og nytte. Mange avinstallerer i det hullet.
4. Oppgraderingen har ingen utløser. Gratisversjonen løser problemet godt nok, og ingenting i produktet forteller brukeren når den betalte versjonen ville hjulpet.

Du kan ikke skille disse fra hverandre ved å se på antall installasjoner. Du trenger en håndfull tall, målt på samme måte før og etter hver endring. Det er første trinn i prosedyren, og de fleste plugin-eiere hopper over det.

#Hva bør jeg måle før jeg endrer oppføringen til pluginen?

Skriv ned dagens tilstand før du redigerer et eneste felt. Uten en “før”-kolonne er enhver endring du gjør etterpå en mening. Jeg holder én tabell per produkt og fyller den ut med faste mellomrom, for eksempel de fire ukene før en endring i oppføringen og de fire ukene etter.

Her er malen. Kolonnene Før og Etter er tomme med vilje: fyll dem ut med dine egne data.

Tre regler holder tabellen ærlig:

• Bruk like lange perioder. Fire uker mot fire uker. Et kortere “etter”-vindu pynter på en endring.
• Endre én ting per periode. Skriver du om oppføringen og onboardingen i samme uke, vet du ikke hva som flyttet tallene.
• Skriv definisjonen før du leser tallet. “Oppsett fullført” betyr en bestemt lagret tilstand. Bestem hva den tilstanden er først, og tell deretter.

Delingen mellom betalende og gratis brukere i radene for funksjonsbruk kommer fra Mat De Sousa, grunnlegger av WideBundle. I et innlegg på X 2. november 2026 anbefalte han å spore funksjonsbruk hver for seg for de to gruppene, ved siden av avinstallasjoner samme dag, fullført onboarding og retensjon. Etter hans syn forteller funksjonene betalende brukere faktisk bruker hva den betalte planen selger. Jeg er enig i delingen og legger til én ting: hvis en funksjon brukes mye av gratisbrukere og sjelden av betalende, er den en kandidat til å bli oppgraderingens utløser.

#Hvordan fyller jeg ut oppføringen til en WordPress.org-plugin felt for felt?

En oppføring på WordPress.org genereres fra readme.txt. Reglene nedenfor kommer fra readme-dokumentasjonen. Kolonnen til høyre er det jeg sjekker i mine egne readme-filer før hver utgivelse.

Kortbeskrivelsen bærer mest vekt, fordi den vises der brukerne sammenligner plugins. Jeg skriver den som én setning: hva pluginen gjør for en WooCommerce-butikk, med butikkeierens egne ord. For plogins-customs betyr det toll, tolldokumenter og fraktbrev, begrepene en nettbutikk som sender utenfor EU bruker, i stedet for navnet på en forordning. For en norsk nettbutikk, som driver fra et EØS-land utenfor EU, er det nettopp slike ord som havner i søkefeltet.

Langbeskrivelsen og FAQ-delen i readme-filen er stedet der du svarer på spørsmålene som stopper oppsettet. Jeg flytter hvert spørsmål som dukket opp i støtteforumet over i readme-FAQen, formulert slik brukeren stilte det. Da blir støttetråder til innhold i oppføringen, og neste brukers vei til en fungerende konfigurasjon blir kortere.

Vil du vite mer om å bygge pluginsiden for WooCommerce-butikker, se siden min om WooCommerce-utvikler.

#Hvordan fyller jeg ut oppføringen til en Shopify-app felt for felt?

Shopify dokumenterer langt mer av oppføringen enn WordPress.org gjør. Alle tallene i denne tabellen kommer fra Shopify App Store best practices.

To punkter til fra samme side endrer hvordan jeg planlegger oppføringen:

• Oversettelser. Shopify oppgir at oversatte oppføringer “konverterer opptil 4 ganger bedre i markeder utenfor engelsk” (egen oversettelse), og at engelske hovedoppføringer oversettes automatisk til 8 språk: brasiliansk portugisisk, dansk, nederlandsk, fransk, tysk, forenklet kinesisk, spansk og svensk. Norsk står ikke på listen. Selger du til norske butikkeiere, må den norske teksten skrives og legges inn for hånd, mens dansk og svensk følger med uten ekstra innsats. Jeg skriver den engelske hovedoppføringen i korte, bokstavelige setninger, slik at den automatiske oversettelsen har mindre å gjøre feil, og jeg kontrollerer den tyske og spanske versjonen for hånd.
• Ytelse i nettbutikken. Shopify ber om at apper ikke senker Lighthouse-ytelsesscoren med mer enn 10 poeng. Scoren er vektet Home 17 %, Product details 40 %, Collection 43 %. Hvis appen legger inn noe som helst i butikkfronten, måler jeg disse tre sidetypene med og uten appen før jeg sender inn.

Skjermbildene og videoen er stedet der onboarding-problemet fra første seksjon blir synlig. Klarer jeg ikke å lage en skjermbildeserie som går fra installasjon til første resultat på tre til seks bilder, er oppsettet for langt, og å rette skjermbildene retter ikke produktet.

Bygger du selve appen, dekker siden min om Shopify-utvikler implementeringssiden.

#Hva endrer Built for Shopify-merket for en app?

Built for Shopify er det eneste stedet der Shopify oppgir at noe påvirker søket. Ifølge den siden gir statusen:

• et merke på appkortet og en fremheving i oppføringen,
• et søkefilter og et løft i rangeringen i App Store-søk,
• prioritert gjennomgang og målretting i annonseplanen,
• kvalifisering for førstesamlingen på forsiden og i kategorier og for “Picked for you”, som Shopify beskriver som personalisert og uten garanti.

Kriteriene dekker sikkerhet, trygghet og pålitelighet; ytelse i admin, og i butikkfronten eller kassen for apper som berører dem; brukervennlighet; dokumentert nytte målt på installasjoner; antall omtaler og vurdering over et rullerende vindu; og en komplett oppføring. Appen må være innebygd i Shopify admin.

Prosessen har tenner. Å feile på samme kriterium tre ganger på rad suspenderer søknaden i tre måneder. Statusen vurderes hvert år, og en app som faller under et kriterium får 60 dager på å rette det.

I planleggingen behandler jeg kriteriene som en sjekkliste som nesten helt overlapper med onboarding-arbeidet nedenfor. “Brukervennlighet” og “dokumentert nytte” er vanskelige å vise uten hendelsene for oppsett og første resultat, så jeg instrumenterer først og søker etterpå. Søker du tidlig og feiler på samme kriterium gjentatte ganger, koster det tre måneder.

#Hvordan instrumenterer jeg onboarding i en plugin for å se hvor brukerne faller fra?

Butikkenes dashbord stopper ved installasjon og avinstallasjon. Alt mellom de to hendelsene må komme fra ditt eget produkt. Jeg sender fem hendelser, og navnene nedenfor er mine anbefalte navn, ingen standard fra noen plattform eller analyseverktøy:

Definisjonen av first_result er den viktigste designbeslutningen. For plogins-customs er et første resultat et tolldokument generert fra en ekte bestilling. For en bundle-app i Shopify kan det være den første pakken vist på en produktside. Skriv den ned per produkt, for hendelsen er bare så god som definisjonen.

En minimal skisse på WordPress-siden ser slik ut. Endepunktet og alternativnavnet er plassholdere, og ingenting sendes før nettstedseieren har sagt ja:

// Example only: endpoint and option name are placeholders.
function myplugin_track( string $event, array $props = [] ): void {
    if ( get_option( 'myplugin_telemetry_optin' ) !== 'yes' ) {
        return;
    }
    wp_remote_post( 'https://analytics.example.com/api/event', [
        'blocking' => false,
        'timeout'  => 2,
        'body'     => wp_json_encode( [
            'event'   => $event,
            'product' => 'myplugin',
            'version' => MYPLUGIN_VERSION,
            'props'   => $props,
        ] ),
        'headers'  => [ 'Content-Type' => 'application/json' ],
    ] );
}

add_action( 'myplugin_setup_saved', function () {
    myplugin_track( 'setup_completed', [ 'seconds_since_install' => time() - (int) get_option( 'myplugin_installed_at' ) ] );
} );

I en gratis plugin ber jeg om samtykke på oppsettskjermen, forklarer hva som sendes og holder dataene fri for personopplysninger: ingen e-postadresser, ingen butikk-URL-er med mindre brukeren har sagt ja til det. I Shopify kjenner app-backenden allerede butikken, så hendelsene sendes fra serversiden i appen selv.

Umami, PostHog og GA4 tar alle imot egendefinerte hendelser. Jeg velger ett verktøy per produkt og holder meg til det, for å bytte verktøy midt i en før/etter-sammenligning ødelegger sammenligningen. Når de fem hendelsene flyter, fyller måletabellen fra andre seksjon seg selv, og traktdiagrammet viser hvilket av de fire svikt-punktene fra første seksjon som gjelder.

Mat De Sousa legger til ett argument til for dette arbeidet i samme innlegg: etter hans erfaring installerer butikkeiere konkurrerende apper side om side og beholder den som er raskest å sette opp. Passer det med kategorien din, er seconds_since_install på setup_completed tallet å følge med på.

#Hvordan gjør jeg utgivelser av pluginen om til innhold som gir nye brukere?

De fleste plugin-eiere skriver en endringslogg og stopper der. Endringsloggen er nøyaktig, kort og lest av nesten ingen. Funksjonene i den er det beste materialet til innhold, fordi hver av dem løser et konkret problem en butikkeier søker etter.

For plogins publiserer jeg en maskinlesbar funksjonsfeed på plogins.com/features.json. Filen pakker oppføringene inn i et objekt med vendor, count og releases. Hver utgivelse har plugin, name, edition, version, released, url, changelog, wpOrg og en features-liste der hvert element har en kind (new, added eller changed) og en text. Rettelser og sikkerhetsnotater er utelatt med vilje: de betyr noe for brukerne og hører hjemme i endringsloggen, men de beskriver ingen ny egenskap noen søker etter.

Dette er den ekte oppføringen for plogins-customs 1.3.0, utgitt 1. november 2026, kortet ned til to av de fem funksjonene:

{
  "plugin": "plogins-customs",
  "name": "Customs",
  "edition": "free",
  "version": "1.3.0",
  "released": "2026-11-01",
  "url": "https://plogins.com/plogins-customs/",
  "changelog": "https://plogins.com/plogins-customs/changelog/",
  "wpOrg": "https://wordpress.org/plugins/plogins-customs/",
  "features": [
    {
      "kind": "added",
      "text": "Customs Paperwork. Generate printable Commercial Invoice and Customs Declaration (CN22/CN23) slips directly from the WooCommerce order edit screen and order list."
    },
    {
      "kind": "added",
      "text": "Store EORI number setting under WooCommerce > EU Import Duty (Union Customs Code, Reg. (EU) No 952/2013, Art. 9), automatically printed on declarations and carrier export documents."
    }
  ]
}

Prosedyren som gjør en slik oppføring til innhold:

1. Les feeden etter hver utgivelse. Pressearbeidsflyten min henter nye oppføringer og lister funksjoner som ikke er brukt i en artikkel ennå.
2. Koble hver funksjon til et problem. “Customs Paperwork” svarer til butikkeierens spørsmål om hvilke dokumenter en pakke som forlater EU trenger. EORI-innstillingen svarer til spørsmålet om hvor EORI-nummeret må stå.
3. Finn artikkelen som allerede dekker problemet. Finnes den, kommer funksjonen inn i den artikkelen som et avsnitt med lenke til pluginen. Finnes ingen, blir problemet en ny artikkel.
4. Skriv den på hvert språk nettstedet betjener. Jeg publiserer på seks språk, så funksjonen havner i seks artikler, hver skrevet for leserne og reglene i landene som snakker språket.
5. Lenk tilbake fra pluginen. Pluginens egen side og readme-FAQ lenker til artikkelen som forklarer problemet, slik at leseren som kommer fra søk og brukeren som kommer fra pluginen møter den samme forklaringen.

Feedformatet har to fordeler. Et skript kan lese det, så veien fra utgivelse til utkast avhenger ikke av at noen husker det. Og fordi hver funksjon er én setning med en kind, ser jeg med et blikk hvilke utgivelser som la til noe det er verdt å skrive om, og hvilke som bare endret oppførsel.

Vil du ha denne rørledningen koblet inn i din egen utgivelsesprosess og ditt eget innholdssystem, er det en del av det jeg setter opp som go-to-market-ingeniør. Automatiseringssiden, utgivelseskroker og planlagte jobber, ligger tett opp til arbeidet på siden min om automatisering av forretningsprosesser.

#Kan en konkurrent kopiere Shopify-appen eller WooCommerce-pluginen min?

Mat De Sousas syn, fra samme innlegg, er at apper som bare er et visuelt lag oppå butikken er enkle å kopiere. Han foreslår to tillegg som er vanskeligere å kopiere: et tjenestelag, der leverandøren setter opp appen for butikkeieren, og et datalag, for eksempel A/B-tester og analyse som viser butikkeieren hva appen endret.

Mitt eget arbeid støtter datalag-halvdelen av argumentet fra kundesiden. Siden 2019 har jeg kjørt A/B-tester, anbefalinger og dynamisk innhold i Dynamic Yield for e-handelskunder. Butikkeiere som ser et testresultat knyttet til sine egne omsetningsspørsmål ber om neste test. En butikkeier som bare ser en widget, spør om det finnes en billigere widget.

For en plugin- eller app-eier er den praktiske versjonen liten:

• Tjenestelag. Tilby en oppsettsøkt eller ferdig konfigurasjon til den betalte planen, og gjør det synlig i oppføringen og på oppsettskjermen. For plogins-customs er tilsvarende ferdig utfylte tariff- og opprinnelsesinnstillinger for butikkeierens katalog.
• Datalag. Vis butikkeieren ett tall inne i produktet som beviser at pluginen virket: genererte dokumenter, tillagte tolllinjer, leverte e-poster. Det tallet er også first_result-hendelsen fra forrige seksjon.

Mat De Sousa anbefaler også å ta i bruk nye Shopify-funksjoner raskt. Jeg leser det som et argument for oppføringen også: en ny plattformfunksjon som appen din støtter fra dag én er et nytt søkeord, et nytt skjermbilde og en ny funksjonslinje.

#Anbefaler Shopify Sidekick apper fra App Store?

Shopifys hjelpeside om Sidekick dokumenterer at Sidekick kan generere egne apper, bygge Shopify Flow-arbeidsflyter og utføre oppgaver med flere trinn. Siden sier ikke at Sidekick anbefaler apper fra App Store.

Mat De Sousa beskriver det annerledes, ut fra egen bruk: etter hans fremstilling gjør Sidekick et spørsmål fra en butikkeier om til søkeord og returnerer 3 til 5 apper på toppen av rangeringen. Det er hans observasjon, og Shopify har ikke dokumentert det.

To konklusjoner gjelder uansett hvilken lesning som stemmer. Hvis beskrivelsen hans er riktig, er appene som rangerer godt i vanlig App Store-søk de Sidekick viser, så oppføringsarbeidet ovenfor gjelder to ganger. Hvis Sidekick genererer en egen app for et enkelt behov, konkurrerer en app som bare dekker det enkle behovet med et gratis generert alternativ, noe som tar deg tilbake til tjeneste- og datalagene. Inntil Shopify dokumenterer hvordan anbefalingene fungerer, planlegger jeg ingen lansering rundt dem.

#Hva dokumenterer ikke WordPress.org og Shopify App Store om rangering?

Ingen av plattformene publiserer vektene i søkerangeringen sin. Readme-siden på WordPress.org forklarer hvordan tagger og beskrivelser vises og filtreres. Shopifys best practices forklarer hvordan hvert felt skal fylles ut, og siden om Built for Shopify sier at statusen gir et løft i søk. Ingen av disse sidene sier hvor mye et felt, en omtale eller et installasjonstall veier.

Lighthouse-vektingen på Shopifys best practices-side (Home 17 %, Product details 40 %, Collection 43 %) beskriver hvordan Shopify slår sammen ytelsesscoren på tvers av sidetyper. Det er et ytelsesmål, og ingen av de tre dokumentene knytter det til plassering i søk.

Det får konsekvenser for hvordan jeg snakker om resultater:

• Jeg lover ingen rangeringsposisjon til noen, meg selv inkludert.
• Jeg måler det jeg kan definere: visninger av oppføringen, installasjoner, fullført oppsett, første resultat, oppgraderinger.
• Når en endring i oppføringen følges av flere installasjoner, rapporterer jeg det som en endring i samme periode, med verdiene før og etter, og jeg holder periodelengdene like.

#Kan jeg sende oppfølgings-e-post til brukere som har installert pluginen min?

Meldinger som hører til tjenesten, som en lisensnøkkel, en bekreftelse på oppsett eller et sikkerhetsvarsel om pluginen, er en del av driften. Markedsføring overfor en person er et annet tilfelle, og det er regulert.

I Norge er det markedsføringsloven § 15 som gjelder. Den krever forhåndssamtykke for markedsføring rettet mot fysiske personer med elektronisk post. Tilsynet er Forbrukertilsynet. Loven har et snevert unntak for eksisterende kundeforhold; les ordlyden i paragrafen før du bygger på det, siden det avhenger av hva kunden kjøpte og hvordan reservasjonsmuligheten ble gitt. Bak ligger ePrivacy-direktivet 2002/58/EF, som setter samme samtykkeregel i EU-retten.

I praksis ber jeg en gratisbruker som aldri har kjøpt noe om samtykke ved registrering, med en avkrysningsboks som ikke er forhåndsvalgt og en enkel beskrivelse av hva vedkommende får. Jeg bygger ikke utsendelser på at noen har installert en gratis plugin.

Jeg kjører Mautic hver dag på en abonnementsplattform, og oppsettet som virker er enkelt: ett segment per produkt og plan, bygget på de samme hendelsene install, setup_completed og upgrade, og e-post utløst av det brukeren gjorde eller ikke gjorde. En bruker som installerte, men aldri utløste setup_completed, får en melding om den ene innstillingen som blokkerer oppsettet. En bruker som nådde first_result, får ingenting om oppsett i det hele tatt. Det holder e-postene korte og relevante, og det betyr at segmentene og måletabellen leser fra én hendelsesstrøm.

#Hva er rekkefølgen på arbeidet for en plugin eller app som stopper opp etter installasjon?

Dette er sekvensen jeg følger på mine egne produkter og anbefaler for enhver plugin eller app med installasjoner og ingen betalende brukere:

1. Uke 1: mål. Definer de fem hendelsene og betingelsen for first_result, send sporingen ut med samtykke, og fyll kolonnen Før i måletabellen fra butikkens dashbord og din analyse.
2. Uke 2: oppføringen. Gå gjennom sjekklisten felt for felt for plattformen din. Rett tagger, kortbeskrivelse, søkeord, skjermbilder og funksjonsliste mot de dokumenterte grensene. Endre ingenting i produktet ennå.
3. Uke 3 til 6: les traktdiagrammet. La hendelsene samle seg gjennom en full periode. Finn trinnet med det største frafallet: oppsett påbegynt, oppsett fullført eller første resultat.
4. Uke 7: rett det største frafallet. Forkort oppsettet, forhåndsutfyll standardverdier eller flytt første resultat nærmere installasjonen. Én endring.
5. Uke 7 til 10: mål på nytt. Fyll kolonnen Etter med en periode av samme lengde.
6. Ved hver utgivelse: innhold. Legg utgivelsen inn i funksjonsfeeden, koble hver ny funksjon til et problem og en artikkel, og oppdater funksjonslinjene i oppføringen.
7. Når trakten er stabil: oppfølging. Bygg e-postsekvensene med samtykke på de samme hendelsene.

I Shopify søker du om Built for Shopify etter trinn 5, når du kan vise tall for oppsett og nytte i stedet for å håpe at gjennomgangen finner dem.

#Hva gjør jeg nå?

Ta måletabellen fra denne artikkelen, fyll ut kolonnen Før for pluginen eller appen din med de siste fire ukenes data, og send den til meg sammen med lenken til oppføringen din på WordPress.org eller i Shopify App Store via siden for go-to-market-ingeniør. Jeg sender tilbake en gjennomgang av oppføringen felt for felt mot de dokumenterte grensene, og det ene onboarding-trinnet jeg ville instrumentert først.