De alarmer, vi har sat op på alle Google Ads-konti

De dyreste fejl i en annoncekonto er sjældent dårlige bud eller svage annoncer. Det er de stille fejl: et tag, der forsvandt ved en deploy fredag eftermiddag, et betalingskort, der udløb, eller et feed, der blev suspenderet. Med Smart Bidding koster de mere end de tabte dage, fordi budstrategien lærer af forkerte data i mellemtiden.

Derfor kører vi det samme sæt alarmer på alle konti, vi har ansvaret for. De er bevidst få og bevidst binære. En alarm, der går for ofte, holder folk op med at læse.

Alarmerne går pr. e-mail. Rapporten er en tabel med én række pr. konto, hvor konti med 0 kr. forbrug ligger nederst.

Spend-stop er den simpleste alarm og den, der oftest fanger noget reelt. Hvis en konto, der skal køre, har brugt 0 kr. på 24 timer, er der sket noget: kampagnerne er sat på pause, budgettet er nulstillet, betalingen er afvist, annoncerne er afvist, eller kontoen er suspenderet.

Vi bruger nul og ikke et procentvist fald, fordi nul er utvetydigt. Et fald på 40 procent kan skyldes en helligdag, en ændret budstrategi eller at mål-ROAS blev strammet. Nul forbrug har ingen harmløse forklaringer på en konto, der er sat til at køre.

Forbrugsdata er hurtige. Google opgiver en servicegrænse på 1 time for klik, visninger og omkostninger, så et 24-timers vindue er reelt 23 timers data. Det er rigeligt til at skelne mellem en stille nat og en stoppet konto.

Den ene undtagelse er konti, der med vilje holder pause, fx sæsonvarer eller en kunde, der har stoppet annonceringen en måned. De skal på en undtagelsesliste med en slutdato, ellers sender alarmen samme mail hver dag, og så lærer folk at ignorere den.

Konverterings-stop fanger målingsfejl: forbruget kører, men der registreres ingen konverteringer. Det er næsten altid tracking og sjældent markedet.

For webshops bruger vi 24 timer, for leadgen 48 timer, af tre grunde.

• Volumen er lavere. En B2B-konto med 30 til 50 leads om måneden har rutinemæssigt døgn uden et eneste lead.
• Ugerytmen er skævere. Mange B2B-konti får næsten intet fra fredag aften til mandag morgen, og et 24-timers vindue ville gå hver lørdag.
• Konverteringerne kommer ofte senere. Leads, der kvalificeres i et CRM og importeres som offline-konverteringer, lander typisk med et døgns forsinkelse eller mere, afhængigt af hvor tit importen kører.

To tekniske detaljer afgør, om alarmen virker.

Den første er, hvilken kolonne I måler på. Google Ads rapporterer de primære konverteringskolonner på klikdatoen, ikke på datoen for konverteringen. Et køb i dag fra et klik i forgårs bliver skrevet på i forgårs. Hvis alarmen kigger på konverteringer for de seneste 24 timer i den almindelige kolonne, ser den kun konverteringer fra klik i samme vindue, og det tal er lavt for konti med en lang beslutningsproces. Brug i stedet konverteringer efter konverteringstidspunkt, i API og scripts metrics.conversions_by_conversion_date. Den svarer på det spørgsmål, alarmen faktisk stiller: er der registreret noget som helst det seneste døgn?

Den anden er forsinkelsen på selve dataene. Google angiver, at konverteringer fra Google Ads-tagget kan tage op til 3 timer om at dukke op ved sidste klik, og 15 timer ved andre attributionsmodeller. Importerer I konverteringer fra GA4, er tallene 12 og 24 timer. Kører kontoen på GA4-importerede konverteringer med datadrevet attribution, skal I enten måle på et længere vindue eller lade vinduet slutte et døgn tilbage. Ellers får I falske alarmer hver eneste morgen.

Valget mellem 24 og 48 timer er et valg mellem hurtig opdagelse og falske alarmer, og det kan regnes på.

Hvis en konto i gennemsnit får λ konverteringer pr. døgn, og de kommer nogenlunde tilfældigt, er sandsynligheden for et døgn helt uden konverteringer e^-λ. For en enkelt måling giver det:

En leadgen-konto med 1,5 leads om dagen ville få en falsk 24-timers alarm cirka hver femte dag, med 48 timer cirka hver tyvende. En webshop med 10 ordrer om dagen får stort set aldrig en falsk alarm, og dér er det spild at vente et døgn ekstra.

I virkeligheden er tallene lidt værre, fordi konverteringer klumper sig på bestemte ugedage og tidspunkter. Men tommelfingerreglen holder: vinduet skal være langt nok til, at kontoen normalt forventer mindst tre konverteringer i det. Så er risikoen for en falsk alarm omkring 5 procent eller lavere.

Det giver et filter, der er værd at tilføje: lad kun konverterings-stop gå, hvis forbruget i vinduet er mindst tre gange kontoens normale CPA. Så går alarmen ikke på en søndag, hvor kontoen kun har brugt 80 kr., men den går, når der er brugt 3.000 kr. uden en eneste ordre.

Konti under cirka én konvertering om dagen skal slet ikke have en konverterings-alarm på døgnbasis. Dér er en ugentlig kontrol og en løbende testkonvertering bedre.

Tre tilstande skal ikke vente på et vindue, fordi de stopper annonceringen helt eller er tæt på at gøre det.

Suspenderet konto. I API står kontoens status som SUSPENDED, og ifølge dokumentationen kan den kun aktiveres igen af Googles support. Google nævner blandt andet ubetalte beløb, mistænkelig betalingsaktivitet og grove politikovertrædelser som årsager. Genåbning kræver en klage, og Google genåbner kun i overbevisende tilfælde, så hver time tæller.

Afvist betaling. Ifølge Google kan annoncerne stoppe, indtil betalingen går igennem, selvom nogle konti kan køre en kort periode efter en afvisning. Typiske årsager er forkerte kortoplysninger, et udløbet kort, manglende dækning, en overskredet beløbsgrænse eller en bank, der blokerer internet- eller udenlandske transaktioner. Google anbefaler selv en backup-betalingsmetode, som kun trækkes, hvis den primære bliver afvist. Den er hurtigere at sætte op end at forklare en direktør, hvorfor shoppen var usynlig i fire dage.

Alle kampagner stoppet eller ikke-serverende. Her bruger vi kampagnernes primære status i stedet for den status, I selv har sat. En kampagne kan være aktiv og alligevel ikke kunne vise annoncer, fordi alle annoncer er afvist, slutdatoen er passeret, eller der ikke er nogen gyldige annoncegrupper. Google Ads API har en lang række årsagskoder til det, bl.a. HAS_ADS_DISAPPROVED, NO_AD_GROUP_ADS, CAMPAIGN_ENDED, BUDGET_MISCONFIGURED og NO_ASSET_GROUPS. Alarmen går, hvis ingen kampagner på kontoen har status som berettiget, begrænset eller under læring.

Alle tre ender også som spend-stop efter et døgn. Det er en bevidst sikring, hvis den hurtige alarm fejler.

Her er alarmerne set ud fra de fejl, de skal fange.

Samtykke er den fejl, der oftest slipper igennem. Et banner, der blokerer Googles tag fuldstændigt, giver nul konverteringer og fanges. Et banner, der sender forkerte standardværdier for ad_storage eller ad_user_data, giver i stedet færre og mere modellerede konverteringer, og det ligner et dårligt marked. Derfor tester vi samtykke efter hver ændring i banneret. Baggrunden står i vores artikel om Google Consent Mode.

Merchant Center er den anden. Ifølge Google bliver produkterne ved en suspendering fjernet fra Shopping-fladerne, både annoncer og gratis visninger, og ved alvorlige overtrædelser af politikken om vildledning kan det ske uden forudgående advarsel. En genbehandling tager typisk 3 til 7 hverdage. Har kontoen også søgekampagner, falder forbruget kun delvist, og spend-stop går ikke. Har I en webshop, hvor Shopping og PMax bærer omsætningen, bør feedet have sin egen overvågning. Det dækker vi i produktfeed og Merchant Center.

Alarmer fanger brud. Rapporten skal fange retning, og den går kl. 9.30 for både Google Ads og Meta.

Tidspunktet er valgt, fordi nattens data er landet, og fordi det er før dagens beslutninger bliver taget.

Rapporten har én række pr. konto og fire tal: forbrug måned-til-dato, forbrug i samme periode sidste år, ROAS måned-til-dato og ROAS i samme periode sidste år.

Vi sammenligner med sidste år og ikke med sidste måned, fordi sæson slår alt andet i e-handel.

Konti med 0 kr. i forbrug lægges nederst. De skal ikke skubbe aktive konti ned, men de skal heller ikke forsvinde. Står en konto dernede, som burde køre, er det et spørgsmål, man stiller samme formiddag.

Tre faldgruber i sammenligningen er værd at kende:

• Ugedagene forskyder sig. 1. oktober 2026 er en torsdag, 1. oktober 2025 var en onsdag.
• Kampagnedage flytter sig. Black Friday ligger 28. november i 2025 og 27. november i 2026. Sammenligner I de første 27 dage af november, er Black Friday kun med det ene år.
• Konverteringsforsinkelsen rammer kun i år. Sidste års tal er færdige. Årets seneste dage mangler konverteringer, der endnu ikke er kommet, fordi de primære kolonner skrives på klikdatoen. ROAS måned-til-dato ser derfor svagere ud tidligt i måneden, og mest ved lange beslutningsprocesser.

Den sidste kan løses med kolonnerne efter konverteringstidspunkt i begge år. Vælg én metode og hold fast i den. Mere om opbygningen af faste rapporter står under rapportering.

Der er tre måder at bygge det på, og de kan kombineres.

Automatiske regler er det hurtigste sted at starte. En daglig regel med handlingen send e-mail på kampagner med omkostning lig 0 i går giver en grov spend-stop-alarm på fem minutter.

Scripts er det, de fleste bør ende med. De kører under en Google-konto, og maildelen bruger Apps Scripts MailApp, hvor kvoten er 100 modtagere om dagen på en almindelig Gmail-konto og 1.500 på Google Workspace. Et MCC-script kan behandle op til 50 konti parallelt med executeInParallel.

Kernen i en rullende 24-timers kontrol ser sådan her ud:

function main() {
  var konto = AdsApp.currentAccount();
  var tz = konto.getTimeZone();
  var nu = new Date();
  var igaar = Utilities.formatDate(new Date(nu.getTime() - 864e5), tz, 'yyyy-MM-dd');
  var idag = Utilities.formatDate(nu, tz, 'yyyy-MM-dd');
  var time = parseInt(Utilities.formatDate(nu, tz, 'H'), 10);
  var rows = AdsApp.search(
    'SELECT segments.date, segments.hour, metrics.cost_micros, ' +
    'metrics.conversions_by_conversion_date FROM customer ' +
    'WHERE segments.date BETWEEN "' + igaar + '" AND "' + idag + '"');
  var kost = 0, konv = 0;
  while (rows.hasNext()) {
    var r = rows.next();
    if (r.segments.date === igaar && r.segments.hour < time) continue;
    kost += Number(r.metrics.costMicros) / 1e6;
    konv += Number(r.metrics.conversionsByConversionDate);
  }
  if (kost === 0) {
    MailApp.sendEmail('alarm@firma.dk', 'Spend-stop: ' + konto.getName(), '0 kr. forbrug de seneste 24 timer.');
  } else if (konv === 0) {
    MailApp.sendEmail('alarm@firma.dk', 'Konverterings-stop: ' + konto.getName(), kost.toFixed(0) + ' kr. brugt uden konverteringer.');
  }
}

I drift skal der mere til: undtagelseslisten, 48-timersvinduet for leadgen, CPA-filteret og en markering, så samme alarm ikke sendes hver time. Googles eget anomali-script sender kun én mail pr. alarmtype pr. dag.

API giver mest kontrol og er det rigtige valg, når I har mange konti, eller når alarmerne skal ind i et andet system end en indbakke. En Search-forespørgsel tæller som én operation uanset størrelse, så selv Explorer-adgangens 2.880 operationer om dagen rækker til en forespørgsel i timen på godt 100 konti. Kontostatus hentes fra customer.status, og kampagnernes tilstand fra campaign.primary_status og campaign.primary_status_reasons.

Afvist betaling er den sværeste at hente maskinelt. Den sikreste løsning er, at Googles egne betalingsnotifikationer går til en fælles adresse, der læses, og ikke kun til den person, der oprindeligt oprettede kontoen. Spend-stop er bagstopperen.

Alarmerne ovenfor går på nul. De ser ikke en konto, der langsomt bliver dårligere, og det er den fejltype, der koster mest over et kvartal.

Typiske eksempler: en ny version af samtykkebanneret, der halverer andelen af målte konverteringer. En stramning af mål-ROAS, der får forbruget til at falde 30 procent over to uger. En konkurrent, der går ind på jeres brandord. Et feed, hvor halvdelen af produkterne er afvist på grund af en prisafvigelse.

Det kræver anomali-regler, der sammenligner med en normal i stedet for med nul. Googles eget eksempel-script, Account Anomaly Detector, sammenligner dagens tal indtil nu med samme ugedag i de foregående 26 uger og anbefales kørt hver time.

En enklere version, der virker på de fleste konti:

• Forbrug i går mod gennemsnittet af samme ugedag de seneste fire uger. Alarm ved fald på over 40 procent.
• Konverteringer de seneste 7 dage mod de foregående 28 dage omregnet til 7 dage. Alarm ved fald på over 35 procent, men kun hvis den forventede værdi er mindst 10.
• Konverteringsrate på samme måde. Falder den, mens klik er stabile, er det oftest måling eller site og sjældent annoncerne.
• Antal godkendte produkter i Merchant Center mod i går. Alarm ved fald på over 10 procent.
• Andelen af konverteringer, der er modellerede, hvis I bruger avanceret samtykketilstand. Et pludseligt spring peger på banneret.

Tærsklerne er startværdier. Kommer der mere end en falsk alarm om ugen pr. konto, er reglen for følsom.

To ting fanger ingen alarm. Den første er, at konverteringerne bliver for mange, fx fordi et købstag fyrer to gange, og så ser ROAS fantastisk ud. Kontrollen er at holde konverteringer i Google Ads op mod ordrer i shoppen hver uge. Den anden er, at kontoen kører på et forkert mål. Den slags findes kun ved en gennemgang, og det er en del af vores arbejde med tracking og konverteringer.

Her er rækkefølgen, vi følger.

1. Bekræft i Google Ads, ikke kun i mailen. Se på samme vindue i grænsefladen, og tjek at problemet stadig er der.
2. Se ændringshistorikken for de seneste 48 timer.
3. Ved spend-stop: tjek kontostatus, betaling, kampagnestatus og budgetter i den rækkefølge. Afvist betaling og suspendering skal løses af den, der har adgang til betalingsprofilen, så find den person med det samme.
4. Ved konverterings-stop: tjek først om shoppen har fået ordrer i samme periode. Har den det, er det målingen. Har den ikke, er det sitet, checkout eller betalingen, og så er annoncerne det mindste problem.
5. Er det målingen, så lav en testkonvertering med Tag Assistant, og tjek hvornår der sidst blev publiceret en version i Tag Manager og en deploy på sitet. Tidspunktet for det sidste registrerede køb peger som regel på ændringen.
6. Tjek samtykkebanneret i et privat vindue: kommer banneret frem, sendes der samtykkesignaler, og fyrer tagget efter accept.
7. Når fejlen er rettet: læg en dataeksklusion ind for perioden med fejl, så Smart Bidding ikke lærer af den. Google anbefaler at gøre det så hurtigt som muligt, og at undgå at fjerne eksklusionen igen bagefter.
8. Lad være med at efterindlæse de manglende konverteringer bare for at få rapporten til at se pæn ud. Google fraråder det generelt, fordi det påvirker budgivningen, og skal det gøres alligevel, skal der gå mindst 5 dage efter eksklusionen.
9. Skriv kort ned, hvad der skete, hvornår det startede, og hvad der blev rettet. Går de samme fejl igen, er det deploy-processen, der skal ændres.

Punkt 7 er det, flest glemmer. Uden dataeksklusion har budstrategien set et døgn eller to med klik og ingen konverteringer, og den sænker buddene i dagene efter, selvom fejlen er væk. Google angiver, at lange udfald kan give udsving i 1 til 2 konverteringscyklusser.

Det gælder i endnu højere grad for kampagner med AI Max og PMax, som beskrevet i vores gennemgang af AI Max-opgraderingen. Vil I have alarmerne og rapporten sat op på jeres egen konto, er det en fast del af det, vi gør i Google Ads.

Alle kilder er tjekket 1. oktober 2026.

• Google Ads Help: datafriskhed og forsinkelser i rapporteringen
• Google Ads Help: forstå jeres konverteringsdata, klikdato og konverteringstidspunkt
• Google Ads Help: hvor lang tid det tager kunderne at konvertere
• Google Ads Help: almindelige måder at bruge automatiske regler på
• Google Ads Help: scripts til automatiske ændringer
• Google Ads Help: løs en afvist betaling
• Google Ads Help: genaktivér en afvist betalingsmetode
• Google Ads Help: overblik over kontosuspenderinger
• Google Ads Help: fejlfinding af konverteringssporingens status
• Google Ads Help: dataeksklusioner ved udfald i konverteringsdata
• Google Ads Help: samtykketilstand for brugere i EØS
• Merchant Center Help: advarsler og suspenderinger ved politikovertrædelser
• Merchant Center Help: vildledning
• Google Ads scripts: begrænsninger
• Google Ads scripts: MailApp
• Google Ads scripts: Account Anomaly Detector
• Apps Script: kvoter for Google-tjenester
• Google Ads API: adgangsniveauer for udviklertoken
• Google Ads API: kvoter og optælling af operationer
• Google Ads API: CustomerStatus
• Google Ads API: CampaignPrimaryStatusReason
• Google Ads API: felter i metrics, herunder conversions_by_conversion_date