PPC-automatisering var altid mulig. Den betalte sig bare aldrig — indtil nu.

Hele argumentet i én sætning

At automatisere PPC rigtigt var altid muligt — det betalte sig bare aldrig, så næsten ingen gjorde det. AI gav os ingen nye superkræfter; den fik omkostningerne ved at bruge de gamle til at falde sammen, og netop dén ene økonomiske forskydning lægger et årti fuldt af „det ville vi gerne, men det ville aldrig betale sig” tilbage på bordet. Alt nedenfor er beviset — fortalt indefra de værktøjer, jeg faktisk bygger med, ikke fra en leverandørs keynote.

Her er, hvad du konkret tager med fra dette stykke: de tre æraer, der gjorde PPC-automatisering for dyr til at gide, det præcise øjeblik i år, hvor regnestykket vendte, og ét rigtigt job — at rydde skrald-søgeforespørgsler med en lokal open source-model — brudt ned trin for trin, med det mellemresultat, du ville stå og kigge på i hver fase. Til sidst kan du kende forskel på „AI gav os nye evner” (for det meste forkert) og „AI ændrede, hvem der har råd til de gamle” (det, der faktisk betyder noget) — og du har et flow, du kan kopiere.

Mellem 2015 og 2017 drev jeg en lille blog om Google Ads Scripts, og så holdt jeg op med at skrive. Ikke fordi idéerne tørrede ud — men fordi kløften mellem „det er muligt” og „det er værd at gøre for en kunde” forblev stædigt bred i et årti. Næsten alt, hvad du har læst om, at AI slår PPC-specialisten ihjel, vender mekanismen på hovedet. AI ændrede ikke, hvad du kan gøre i paid search. Det meste var altid muligt. Det, der ændrede sig, er hvem der kan gøre det, og til hvilke omkostninger — og det vejer langt tungere end endnu en auto-bidding-knap. Lad mig vise dig, hvorfra jeg ved det.

Scripts-æraen: et par dage for et „enkelt” script

Hvorfor jeg begynder her: for at vise dig, at loftet aldrig var teknologien. Det var arbejdskraften, fra det allerførste værktøj, jeg rørte ved.

Google Ads Scripts føltes som magi, da de kom. JavaScript, direkte i kontoen, der løber gennem kampagner. I praksis var et „enkelt” script — sæt søgeord over en CPA-tærskel på pause, markér ødelagte final-URL’er — et par dages skrivning og debugging, så snart du havde styr på særtilfældene, kvoterne og de tavse fejl.

Så kom den del, ingen budgetterede med: at køre det på tværs af konti. Ét script pr. konto, kopieret ind, der gled længere og længere fra hinanden og brød stille, så snart én kundes navnekonvention ikke matchede de andres. Skalering og distribution var et job for sig. Så de fleste scripts ude i virkeligheden kom aldrig længere end reporting — trække nogle tal ind i et Sheet efter en plan. Alt, der faktisk ændrede kontoen, var for skørt og for dyrt at vedligeholde til at være det værd for de fleste bureauer.

Erkendelsen, du tager med dig: selv det „nemme” automatiseringslag var begrænset af vedligeholdelsesomkostninger, ikke af evne.

API-æraen: to dage til første query, to år til et værktøj

Hvorfor netop denne tæller: her blev tilbagebetalingskløften så bred, at den blev en forretningsbeslutning, ikke et engineering-spørgsmål.

Google Ads API — dengang AdWords API — var den ægte magt og den ægte mur. Jeg så vores systemarkitekt, en mand med over 25 års engineering bag sig, bruge to hele dage på at læse dokumentation, før en eneste query returnerede data. Det er ikke en kritik af ham. Det er den kompleksitet, du melder dig til.

Vi gik all in alligevel og byggede PPC Robot: et dybt tilpasseligt reporting- og operations-værktøj, teknisk smukt, ægte kraftfuldt. Det kostede også to udviklere, på fuld tid, i to år. Den videreudvikling, det krævede for at holde liv, lå et sted omkring 100.000 € om året — groft, størrelsesorden — og det betalte sig aldrig selv. Det dækkede kun en brøkdel af det, vores PPC-specialister faktisk havde brug for, så til sidst parkerede vi det i en begrænset intern tilstand. Ikke fordi det var dårligt. Fordi regnestykket aldrig gik op.

Og vi leverede stadig rigtige ting oven på den API — for fire, fem år siden:

Kig på den liste og bemærk én ting: intet af det er eksotisk efter nutidens målestok. Det var alt sammen muligt. Det kostede bare en formue at bygge og en formue at holde i live. Hver eneste nævneværdig feature — et keyword research-værktøj, et ekspansionsværktøj, annonceoversættelse, en Shopping-generator — blev målt i måneder. Det er hele æraens lektie i én sætning: loftet var aldrig teknologien. Det var tilbagebetalingstiden.

To ting, der brød op i år

Hvorfor jeg bliver konkret nu: „AI ændrede alt” er en påstand, du bør nægte at acceptere på tro og love. Så her er to job, der før ikke betalte sig og nu gør — begge ting, jeg kører, ikke hypoteser — og ved det første viser jeg dig præcis, hvad hvert trin producerer.

1. At udelukke de forkerte søgeforespørgsler

At rense irrelevante søgetermer ud af en konto er værdifuldt og dødssygt kedeligt. Den gamle måde var en halvmanuel gennemtravlning af tusindvis af forespørgsler, hvor man spottede mønstre og tilføjede negative søgeord i hånden. Forestil dig situationen: en løbeskobutik betaler for klik på „running shoes repair”, „nike air max history” og „free running shoes” — intet af det sælger eller servicerer den. Gang det med tusindvis af rækker, hver uge, på tværs af hver konto. Det er det job, ingen vil have, og alle har brug for.

Handlingen, der ændrede sig: et Python-script trækker forespørgslerne fra Google Ads API og overleverer dem til en open source-model — Googles Gemma 4 — med ordentlige instruktioner og, afgørende, kontekst om sitet: sitemappet, site-/DB-strukturen, breadcrumb-taksonomien, produkt-feedet. Resultatet: modellen flagger ikke kun enkelte skrald-forespørgsler; den blotlægger mønstrene bag dem, hurtigere og billigere end et menneskeligt overblik. Her er det flow i fem konkrete trin.

Den stille overskrift her er ikke „AI er smart”. Den er, at en lokalt kørende open source-model er nok — du behøver ikke engang en frontier-API for at få det til at betale sig. Det er økonomien i bevægelse, ikke evnen.

Se det køre: hvad hvert trin faktisk spytter ud

De fem trin er opskriften; det her er maden. Nedenfor står det konkrete artefakt, hvert trin overleverer dig for vores løbeskobutik — det, du bogstaveligt talt kigger på, før du går videre. Formerne er præcis det, værktøjerne returnerer; rækkerne er illustrative, ikke en rigtig kunde. (Gennemgående illustrative eksempler.)

TRÆK → de rå søgetermer, med penge koblet på. Hvert term, kontoen betalte for, sorteret så spildet er synligt:

Search term                Clicks  Cost   Conv
running shoes                420    €310    12
free running shoes            88    €61      0
running shoes repair          54    €40      0
nike air max history          31    €24      0
running shoes wikipedia       19    €14      0

Fire af disse fem rækker er rent forbrug med nul konverteringer — 139 €, kontoen aldrig havde behøvet betale. Problemet er åbenlyst i fem rækker og usynligt i fem tusind.

FORANKR → kontekstpakken, modellen ræsonnerer imod. Ikke prosa — et kompakt kort over, hvad sitet i virkeligheden er:

sitemap.xml      → 1,010 URLs (categories, products, blog)
breadcrumb tax.  → Footwear > Running > Road / Trail
product feed     → 1,205 SKUs (id, title, category, price)
DB structure     → no "repair", "rental" or "history" nodes exist

Den sidste linje er den, der gør arbejdet: modellen ved nu, at „repair” ikke er noget, denne butik tilbyder, i stedet for at gætte.

SPØRG → domme, og mønstrene ovenover. Modellen returnerer en dom pr. forespørgsel — men gevinsten er blokken nederst:

Query                     Verdict      Why
free running shoes        irrelevant   freebie intent, no purchase
running shoes repair      irrelevant   service we don't offer
nike air max history      irrelevant   informational, no buy intent
running shoes wikipedia   irrelevant   reference-seeker

→ PATTERN: tokens "free", "repair", "history", "wikipedia"
  = non-commercial modifiers absent from our taxonomy.
  Recommend excluding as a shared negative list.

Fire rækker blev til én regel. Den regel fanger skrald af typen „running shoes free shipping returns”, som du ikke har set endnu — hvilket er hele pointen.

GENNEMGÅ → et menneske godkender reglen. Du læser én linje — „non-commercial modifiers absent from our taxonomy” — er enig i, at den passer, og du er færdig. Ingen scrollning gennem 5.000 rækker. Dommen falder én gang.

PUSH → de negative lander på det rigtige niveau. Fordi mønsteret er site-bredt, ryger det på en delt liste over negative søgeord, ikke i én annoncegruppe:

Shared negative list: "non-commercial modifiers"
  free · repair · history · wikipedia · manual · pdf
Applied to: all Search campaigns

Ét mønster, én liste, hver kampagne beskyttet — og det tjener sin plads i næste uge, uden endnu en menneskelig gennemgang. Det er øjeblikket, hvor en dødssyg ugentlig pligt bliver til en ti-minutters gennemgang.

2. Keyword research

Det andet job er det, der før var en budgetpost for sig. Ægte keyword research — den slags, der kortlægger efterspørgsel mod dine landingssider og fortæller dig, hvad der mangler på sitet — betød før snesevis af timers datatræk (AdWords API, suggest-bokse, OpenRefine), halvmanuel oprydning, klassificering efter landingsside og oven i det trend-/søgevolumen-/gap-reporting.

Det er ikke bare billigere. Det er bedre — mere præcist, med timer brugt på validering og dømmekraft i stedet for på rørlæggerarbejde. Netop den kombination, billigere og bedre, er præcis det, der egentlig skulle være umuligt. Jeg har brudt den moderne version ned fra ende til anden i markedsudvidelses-blueprintet og i content-gap-analysen — begge med det rigtige mellemresultat vist ved hvert trin.

Økonomien, før og efter

Det er hele tesen i én tabel. Samme job, samme kvalitetslægte — kun omkostningen ved at udføre dem flyttede sig. Dokumenterede tal, hvor jeg har dem; resten er størrelsesorden fra ét bureaus to årtier med netop det.

Læs tabellen fra top til bund, og mønsteret er det samme i hver række: evne-kolonnen ændrede sig ikke — vi kunne alt dette allerede i 2019. Pris-kolonnen faldt gennem gulvet. Det er ikke en teknologihistorie. Det er en historie om tilbagebetalingstid, og tilbagebetalingstiden er det, der afgør, om en klog idé nogensinde bliver bygget.

Hvad det her faktisk betyder for branchen

Hvorfor jeg planter et flag her: den populære udlægning — „AI gør det af med PPC-specialisten” — er doven, og at vende den på hovedet har reelle karrierekonsekvenser for de folk, der læser med.

„PPC-specialisternes æra er ved at slutte” er nonsens. Det modsatte sker. Gode specialister brugte år frustrerede over, at den kloge ting — den ting, de tydeligt kunne se — „ikke var værd at bygge”. Nu får de lov til at bygge den. Automatisk, profitabelt, i stor skala. En hel hylde fuld af PPC-strategier, der før ikke betalte sig eller var direkte absurde at forsøge, ligger pludselig på bordet.

Det, der faktisk sker, er en skarpere splittelse inde i håndværket. På den ene side juniorer uden fantasi, vision eller greb om værktøjerne — folk, der opfatter platformens UI som hele jobbet. På den anden side super-seniorer, der mestrer værktøjerne, opfinder workflowene, tænker uden for platformens kasser, kobler datakilder, ingen andre kobler, og bygger sig selv specialiserede dashboards i stedet for at vente på, at en leverandør leverer en feature.

Og for at slå den åbenlyse misforståelse ihjel: det her er ikke et argument for billigere service. Værktøjer, compute og udvikling koster stadig penge. Pointen er, at et projekt, der før var seks måneders udvikling, nu er to uger — så investeringen endelig giver mening. Kunden får en dramatisk bedre service til en lignende pris, ikke en ringere for mindre.

Hvorfor jeg skriver igen

Jeg holdt op med at blogge for år tilbage, fordi kløften mellem idé og økonomisk fornuftig eksekvering var for bred til at være interessant. Den kløft lukkede sig lige. Så denne blog er tilbage, og den bliver konkret: use cases med rigtige tal, de præcise flow, de faktiske resultater — inklusive de rodede dele og grænserne. De første deep dives er allerede online; flere er på vej.

Hvis din reaktion på det hele er „endelig kunne vi gøre netop det, vi altid ville” — godt. Det er hele pointen med denne æra. Lad os bygge det.

1. TRÆK    Google Ads API → søgetermsrapport (query, klik, omkostning, konv.)
2. FORANKR Byg en kontekstpakke, modellen kan ræsonnere imod:
            - sitemap.xml (hvad sitet faktisk sælger)
            - site- / DB-struktur + breadcrumb-taksonomi
            - produkt-feed (id, title, category)
3. SPØRG   Prompt til Gemma 4: "Klassificér med denne site-kontekst hver query
            som relevant / irrelevant for det, vi sælger. Returnér de
            irrelevante OG MØNSTRENE bag dem (token, intention,
            kategori-mismatch)."
4. GENNEMGÅ Menneske validerer de ~10 mønstre, ikke 5.000 rækker enkeltvis.
5. PUSH    Send negative tilbage via API'et på det rigtige niveau (delt liste
            for site-brede skrald-tokens; annoncegruppe for lokal støj).

FAQ