Jeg er Mariusz Szatkowski og har utviklet i WordPress og WooCommerce siden 2006. Under merket plogins bygger og utgir jeg egne WooCommerce-plugins, så jeg kjenner begge sider av en plugin-oppføring: jeg skriver koden, og jeg ser hva som skjer etter at noen har installert den.
Som go-to-market-ingeniør bygger jeg det som ligger mellom et fungerende produkt og en betalende bruker: oppføringen i katalogen eller App Store, en utgivelsesfeed som mater artiklene dine, onboarding du kan måle, og Mautic- eller CRM-automatisering som følger opp.
Hvorfor funksjoner ikke lenger er nok i 2026
Å kopiere en funksjon tar nå noen dager. Byråer bygger egne små verktøy for kundene sine, og de visuelle delene av en plugin eller app er lettest å kopiere. Det som fortsatt er vanskelig å kopiere, er distribusjonen: en oppføring som svarer på kjøperens spørsmål, onboarding som raskt gir det første resultatet, data som viser hvilken funksjon betalende brukere trenger, og oppfølging som ikke avhenger av at noen husker å skrive en e-post.
Mat De Sousa, som driver Shopify-appen WideBundle, beskriver det samme skiftet ut fra samtaler med Shopify-byråer. Rent visuelle apper får det tøft, mens de som vokser, legger til et tjenestelag (å sette opp appen for forhandleren) og et datalag (A/B-tester og analyse som byrået ikke kan bygge selv). Jeg ser det samme på WooCommerce-siden: siden 2019 har jeg kjørt A/B-tester, anbefalinger og dynamisk innhold i Dynamic Yield for netthandelskunder, og datalaget er det kundene oftest spør etter.
Hvem go-to-market-ingeniørarbeid passer for
Tre typer kunder ber om dette arbeidet, og hver av dem starter et annet sted.
- Utviklere av plugins og apper. Du har en WooCommerce-plugin på WordPress.org eller en Shopify-app i App Store, en gratis og en betalt versjon, og installasjoner som ikke blir til inntekt. Arbeidet starter med oppføringen og veien fra installasjon til første resultat.
- Nettbutikker der markedsføringsverktøyene har vokst frem tilfeldig. GA4, Google Tag Manager, et nyhetsbrevverktøy, et CRM og noen scenarioer i Zapier eller Make.com, satt opp av forskjellige folk. Ingen kan si hvilken kanal som gir betalende kunder. Arbeidet starter med målingen og dataflyten mellom verktøyene.
- B2B-tjenesteselskaper og byråer. Henvendelser kommer inn via skjemaer og e-post, og oppfølgingen avhenger av hvem som har tid. Arbeidet starter med Mautic eller CRM-et: ett sted der kontakten, samtykket og historikken ligger, og automatisering som tar seg av oppfølgingen.
Passer ingen av de tre, ligger problemet trolig i selve produktet eller nettstedet. Da er WooCommerce-utvikling eller automatisering av forretningsprosesser et bedre sted å begynne.
Hva du får i de første ukene
Hvert oppdrag gir filer du beholder, uansett hvem som jobber videre med dem.
| Leveranse | Innhold | Hvorfor det betyr noe |
|---|---|---|
| Utgangstabell | Installasjoner eller besøk, avinstalleringer samme dag eller fluktfrekvens, gjennomført onboarding, første resultat, overgang fra prøve til betalt, henvendelser per kanal, hver med kilde og definisjon | Uten den kan ingen si i ettertid om en endring virket |
| Hendelsesplan | Hendelsene produktet eller nettstedet sender (installasjon, oppsett startet, oppsett fullført, første resultat, oppgradering), egenskapene deres og hvor de havner | Analyseverktøyet viser bare det du har instrumentert |
| Ny oppføringstekst | WordPress.org-readme eller App Store-felt innenfor de dokumenterte grensene, skjermbilder av det ekte grensesnittet | Oppføringen er det første svaret kjøperen leser |
| Funksjonsliste | En maskinlesbar liste over utgitte funksjoner fra changelogen din, i samme format som plogins.com/features.json | Utgivelsene forsvinner ikke lenger i en changelog ingen leser |
| Kart over kontaktdata | Hvilket system som har kontakter, samtykke, kilde og historikk, og hvordan postene flyttes mellom systemene | Automatisert oppfølging blir aldri bedre enn dataene under den |
| Andre måling | Utgangstabellen på nytt, med de samme definisjonene | Avgjør hva som blir, hva som gjøres om og hva som fjernes |
Fremgangsmåten bak filene, med måletabellen, feltene i oppføringen og hendelsesnavnene, står i artikkelen min om vekst for en WooCommerce-plugin eller Shopify-app.
Verktøy jeg bruker i produksjon
Jeg lister bare verktøy jeg har brukt i ekte prosjekter. Har du noe annet i oppsettet ditt, sier jeg fra før jeg gir et tilbud.
| Område | Verktøy |
|---|---|
| Måling | Google Tag Manager, GA4, Search Console, BigQuery, Umami, PostHog |
| Eksperimenter og personalisering | Dynamic Yield (A/B-tester, anbefalinger og dynamisk innhold siden 2019) |
| Markedsføringsautomatisering og CRM | Mautic, CleverReach, HubSpot |
| Automatisering uten kode | Make.com, Zapier |
| Kode og integrasjoner | PHP, Python, JavaScript og TypeScript, Kotlin med Spring Boot, WordPress REST API, webhooks, OAuth |
| Netthandel | WooCommerce, Shopify, Stripe, Klarna, PayPal |
| AI-agenter | MCP-servere (forfatter av woocommerce-mcp), lokale modeller via Ollama for klassifisering på kundens egen infrastruktur |
Hva jeg trenger fra deg
- Lesetilgang til analyseverktøyet, statistikken i katalogen eller Partner Dashboard, og CRM-et eller Mautic-installasjonen.
- Changelogen eller utgivelsesnotatene for de siste versjonene.
- Din egen setning om hva kjøperen installerer produktet eller kontakter deg for. Jeg sjekker den mot dataene og finner ikke på noe selv.
- Én person som bestemmer når to mål kolliderer, for eksempel flere installasjoner mot færre supporthenvendelser.
- Grafisk design, hvis oppføringen eller landingssidene trenger nye visuelle elementer. Designet kommer fra deg, jeg implementerer og måler det.
Slik rapporterer jeg
Skriftlig, i repositoriet eller i et delt dokument, aldri bare muntlig i en samtale. Hver rapport har samme tabell som utgangspunktet, hva som er endret siden forrige rapport, og hva jeg anbefaler å fjerne. Har en endring ikke flyttet tallet sitt, står det i rapporten. Jeg lover ingen rangeringer, installasjoner eller inntekter, fordi verken plugin-katalogen eller App Store publiserer hvordan de rangerer, og resultatene dine avhenger like mye av produktet som av distribusjonen.
Det som oftest svikter først, også på mitt eget nettsted
Den første revisjonen avdekker som regel et verktøy som kjører uten å registrere noe nyttig. Her er tre eksempler fra dette nettstedet, alle funnet og rettet i 2026:
- Kampanjeparametere forsvant ved omdirigering. En regel som skulle fjerne dupliserte URL-er, sendte hver adresse med
utm_*,gclidellerfbclidvidere til den rene URL-en med en 301. Canonical-taggen håndterte allerede duplikatene, så regelen gjorde bare skade: fra juli til oktober sto de skjulte UTM-feltene i kontaktskjemaet tomme, og kilden til de henvendelsene er ukjent. Løsningen var å la sporingsparametere være i fred og la canonical-taggen og headerenNo-Vary-Searchgjøre jobben sin. Testen er én forespørsel: en adresse med en nyutm_sourceskal svare med 200, ikke 301. - En samtykkebryter som ikke styrte noe. Cookie-banneret hadde en kategori for funksjonelle informasjonskapsler, avkrysset som standard, og ingen kode lyttet til brukerens valg. YouTube-innbygginger lastet uansett, mens beskrivelsen lovet at de ble blokkert når kategorien var slått av. Å bare fjerne avkryssingen ville gjort det verre, for da ville banneret spørre og samtidig gi feil opplysning om virkningen. Rekkefølgen er alltid mekanismen først, deretter standardvalget.
- Et nyhetsbrevskjema uten bekreftelse og uten mulighet til å melde seg av. Skjemaet sendte adressen rett til en e-posttjeneste. Det fantes ingen double opt-in, ingen avmeldingslenke, og personvernerklæringen nevnte ikke nyhetsbrevet. Løsningen ble en signert bekreftelseslenke som gjelder i sju dager, og en permanent avmeldingslenke. Adressen kommer på listen først etter bekreftelsen, som er det første tidspunktet den lovlig kan legges til.
Hver av de tre så ut som en fungerende funksjon, og hver av dem ville gjort enhver rapport bygget oppå den feil. Derfor går de første ukene til utgangstabellen og hendelsesplanen, før noen kampanje eller automatisering settes i gang.
Hva jeg gjør som go-to-market-ingeniør
Slik forløper et go-to-market-oppdrag
Utgangspunkt
Jeg samler det du allerede har: statistikk fra katalogen eller App Store, analyse, data fra Mautic eller CRM, supportsaker. Installasjoner, avinstalleringer samme dag, gjennomført onboarding og betalende brukere per funksjon havner i én tabell før noe endres.
Oppføring
WordPress.org-readme eller Shopify App Store-felt skrevet om innenfor grensene: 1 til 5 tagger og en kort beskrivelse på 150 tegn på WordPress.org, et navn på 30 tegn og opptil fem søkeord på Shopify. Skjermbilder av det ekte grensesnittet, ikke mockups.
Onboarding
Veien fra installasjon til første resultat, kortet ned og instrumentert. Hvis et oppsettstrinn kan løses med kode eller en fornuftig standardverdi, gjør jeg det.
Fra utgivelse til innhold
Changelog-linjer som gir ny funksjonalitet, går inn i en maskinlesbar funksjonsfeed og derfra inn i artikkelen eller siden om problemet funksjonen løser, på hvert språk du selger på.
Oppfølging
Mautic- eller CRM-segmenter for prøveperioder, stoppet onboarding, fornyelser og signaler om frafall, med samtykke registrert slik kjøperens land krever.
Andre måling
Den samme tabellen som i første trinn, noen uker senere. Det som ikke flyttet seg, fjernes eller gjøres om.
Hvor jeg har gjort dette arbeidet
Alt nedenfor er arbeid jeg har gjort selv, beskrevet uten kundenavn.
Mautic matet fra et ERP, et nyhetsbrevverktøy og adressedata
Siden oktober 2025 jobber jeg som full-stack engineer på en abonnementsplattform for medier og handel, for et programvarebyrå i Wien. Jeg bygde en tjeneste i Kotlin og Spring Boot som slår sammen abonnent-, firma-, adresse- og kampanjedata fra et eldre forlags-ERP, CleverReach og adressekilder inn i Mautic via OAuth. Det meste av arbeidet er identitetsmatching: å koble firmaer, normalisere e-postadresser og telefonnumre, fjerne duplikater, respektere flagg for kontaktforbud og holde kilden til hver post sporbar. Importene går i en asynkron kø over millioner av kontaktrader og egendefinerte objekter. En lokal språkmodell (Ollama via Spring AI) klassifiserer postene i køen med strukturert utdata, på kundens egen infrastruktur, slik at kontaktdata aldri forlater den.
Hvorfor første betalinger feiler
På samme plattform kjørte jeg en skrivebeskyttet analyse av forlatte første betalinger på tvers av Stripe, Klarna, PayPal og faktura. Den skilte SCA- og 3D Secure-feil fra brukere som avbryter eller bytter mellom betalingsmetoder, og ble til en repeterbar månedlig eksport som erstattet manuell gjennomgang. For en abonnementsvirksomhet er dette steget mellom “en prøveperiode startet” og “inntekten kom inn”, og det er akkurat her go-to-market-arbeid lønner seg.
Eksperimenter, sporing og CRM-automatisering
- Eksperimenter: A/B-tester, anbefalinger og dynamisk innhold i Dynamic Yield for nettbutikkunder siden 2019.
- Sporing: Google Tag Manager, GA4, Search Console og BigQuery, satt opp slik at kampanjer og konverteringer faktisk lar seg lese.
- CRM: kontraktsarbeid siden januar 2021 for en kunde i Berlin på WordPress, WooCommerce, HubSpot og Shopify, med automatiseringer i Make.com og Zapier mellom nettsidene, CRM-et og andre verktøy.
Mine egne plugins som testbenk
- plogins: mine WooCommerce-plugins, gratisversjoner på WordPress.org og Pro-versjoner solgt direkte, med PHPStan, PHPCS og automatiserte utgivelser. Konverteringsfunksjonene omfatter order bumps, gjenoppretting av forlatte handlekurver, oppfølgings-e-poster, ventelister for varer som er tilbake på lager og trappetrinnspriser. EU-etterlevelsen omfatter angreknappen som kreves av direktiv (EU) 2023/2673, og Polski for WooCommerce (GPSR, Omnibus).
- Utgivelsesfeed: hver utgivelse skriver sine nye funksjoner til en offentlig feed på plogins.com/features.json, og nyhetsarbeidsflyten min henter dem derfra inn i artiklene om problemene de løser.
- AI-agenter: jeg skrev en åpen kildekode MCP-server, woocommerce-mcp, som gir AI-agenter tilgang til WooCommerce-produkter, ordrer og salgsdata.
Relaterte tjenester: Shopify-utvikler, WooCommerce ERP-integrasjon og automatisering av forretningsprosesser.
Hva App Store og plugin-katalogen faktisk belønner
Shopify dokumenterer en del av det. Apper med Built for Shopify-status får et merke, et søkefilter og et løft i rangeringen i App Store-søket, og statusen avhenger av ytelse, brukervennlighet og dokumentert nytteverdi målt i installasjoner, antall anmeldelser og vurdering (Shopify, Built for Shopify). Veiledningen for oppføringer tillater opptil fem søkeord av hele ord og sier at apper ikke bør senke butikkens Lighthouse-poengsum for ytelse med mer enn 10 poeng (Shopify, App Store best practices).
WordPress.org dokumenterer readme-formatet: 1 til 5 tagger, tagger som bare din plugin bruker, vises ikke, og den korte beskrivelsen bør holde seg under 150 tegn (Plugin Handbook, readme). Ingen av plattformene publiserer rangeringsvektene sine, så jeg lover ingen plasseringer. Jeg retter opp det som er dokumentert og måler resten.
Samtykkeregler for oppfølgingen
Automatisk e-post til folk som har installert en gratis plugin eller startet en prøveperiode, er i de fleste tilfeller markedsføring, og den trenger et rettslig grunnlag. I Norge krever markedsføringsloven § 15 forhåndssamtykke når en fysisk person skal få markedsføring med elektroniske metoder som muliggjør individuell kommunikasjon, for eksempel e-post. Forbrukertilsynet fører tilsyn med bestemmelsen. Jeg setter opp Mautic slik at samtykket, kilden og datoen lagres per kontakt, og kampanjene sjekker det feltet i stedet for å forutsette samtykke.
Omfang
Inkludert
- Arbeid med oppføring i katalog og App Store innenfor de dokumenterte grensene
- Funksjonsfeed fra changelogger og bruken av den i artikler og sider
- Instrumentering av onboarding (Umami, PostHog eller GA4) og tabellen før og etter
- Segmenter, skjemaer, kampanjer og integrasjoner i Mautic eller CRM
- Landingssider og sporing som overlever omdirigeringer
Ikke inkludert
- Betalte annonsekampanjer og annonsebudsjetter
- Publisering på LinkedIn eller andre sosiale medier på dine vegne
- Salgssamtaler i ditt navn
- Grafisk design og wireframes (du leverer dem)
- Garanterte rangeringer, installasjoner eller inntekter
Hvor du bør starte
Du har installasjoner, men få betalende brukere
Start med utgangspunktet og onboardingen: gapet ligger vanligvis mellom installasjon og første resultat.
Ingen finner pluginen eller appen
Start med oppføringen og artiklene om problemene produktet løser.
Henvendelser kommer inn, men ingen følger dem opp
Selve produktet trenger arbeid først
Send en kort skriftlig beskrivelse via kontaktsiden: produktet, hvor det selges, hvilke data du allerede har, og det ene tallet du vil flytte.






