n8n Google Ads: 5 toků automatizace 2026

n8n překonal 100 000 aktivních self-hosted nasazení v roce 2025 (n8n.io) a 70 000 hvězd GitHub v Q1 2026, čímž se stal dominantní open-source alternativou k Zapieru a Make. Ekonomické kritérium je masivní: workflow Zapier spouštěný 10 000krát za měsíc stojí přibližně 89 EUR/měsíc v plánu Professional, stejný workflow na n8n self-hosted stojí 0 EUR nad 8 až 15 EUR/měsíc za VPS. Na účtech sledovaných ve veřejných benchmarcích Google Ads struktury přecházející na n8n získávají zpět 600 až 1 800 EUR/měsíc na položce automatizace, tedy nejrychlejší ROI celého tool stacku.

Zde je přesně nastavení self-hosted, credentials Google Ads a 6 workflow JSON připravených k importu pro automatizaci řízení Google Ads. Žádné obecnosti "n8n je skvělé" — konkrétní věci s docker-compose, JSON exporty, snippety transformací. Repozitář github.com/steerads/n8n-google-ads-flows obsahuje 6 zdokumentovaných workflow. Pokud stále srovnáváte se Zapierem a Make, přečtěte si paralelně náš srovnání Zapier vs Make Google Ads. Náš kalkulátor plýtvání rozpočtem odhaduje € spálené za měsíc broad výrazy bez negativů nebo nadměrným bounce rate LP.

n8n vs Zapier/Make: proč self-hosted pro Google Ads

n8n je nástroj pro automatizaci workflow low-code open-source spuštěný v roce 2019. Vizuální editor drag-drop podobný Zapieru nebo Make, ale se dvěma klíčovými rozdíly: (1) možnost self-hostingu pod licencí Sustainable Use License, (2) žádné ceny za spuštění na self-hosted verzi. Platíte svůj VPS, tečka.

Ekonomický výpočet na 12 měsíců pro účet provádějící 50 aktivních workflow (mix hourly + daily):

Kdy n8n self-hosted vítězí: vysoký objem spuštění (>5 000/měsíc), složité workflow s inline JavaScriptem, vlastní integrace nepokryté SaaS, požadavky na datovou rezidenci (přísné GDPR, citlivá data), technické týmy schopné udržovat Docker.

Kdy Zapier/Make zůstávají lepší: netechnické týmy (nulové ops infrastruktury), jednoduché workflow s nízkým objemem (<1 000 spuštění/měsíc), velmi rychlý start (15 minut Zapier vs 1 hodina n8n), potřeba exotických integrací (Zapier má 5 000+ nativních aplikací vs ~400 u n8n).

Pro specifické Google Ads má n8n klíčovou výhodu: žádná kvóta za spuštění, takže můžete provozovat hourly workflow monitorování CPC po dobu 1 roku bez platby 1 EUR navíc nad VPS. Na Zapieru vás stejný workflow stojí 8 760 spuštění x ~$0,02 = ~$175 minimálně ročně.

Tři vzory nasazení koexistují v roce 2026 podle profilu týmu a infrastrukturních omezení. Vzor 1 — Docker Compose na jediném VPS (nejrozšířenější): jediný VPS Hetzner nebo DigitalOcean za 5–12 EUR/měsíc, n8n + Postgres + Caddy v compose, automatické snapshoty každých 24 hodin na straně providera. Doporučeno pro 90 % případů použití SMB a mid-market. Vzor 2 — n8n Cloud managed (n8n.cloud): od 20 EUR/měsíc podle plánu, nulové ops infrastruktury ke správě, ideální pokud tým nechce vůbec sahat na Docker. Kompromis: žádná customizace prostředí runtime a data nezůstávají u vás. Vzor 3 — Kubernetes pro multi-tenant nebo velmi vysokou dostupnost: nasazení Helm chart officiální n8n na GKE/EKS/AKS, relevantní pouze pro agentury sdílející více klientů nebo interní SaaS nastavení s velmi vysokou zátěží. Počítejte s 80 až 250 EUR/měsíc podle velikosti clusteru.

Volba Docker Compose vs n8n Cloud si zaslouží být rozhodnuta na začátku. Docker Compose dává 100% kontrolu (data u vás, vlastní prostředí, minimální síťová latence k Postgresu), ale vyžaduje minimální ops disciplínu: aktualizace Dockeru každých 1–2 měsíce, monitorování místa na disku (tabulka spuštění rychle roste), správa certifikátu Let's Encrypt pokud Caddy havaruje. n8n Cloud odstraňuje veškerou tuto zátěž, ale přidává externí závislost a pevné náklady, které rostou lineárně s počtem aktivních workflow. Pro datový tým s 1 DevOps na částečný úvazek zůstává Docker Compose správnou výchozí volbou. Pro čistě marketingový tým bez technických operací n8n Cloud zabraňuje týdnům technického dluhu.

Nastavení n8n: Docker, credentials, první workflow

Nejrychlejší nastavení pro hostování n8n v produkci: Docker Compose na VPS Ubuntu s Caddy jako reverse proxy (automatické HTTPS přes Let's Encrypt). Zde je přesně docker-compose.yml k vložení:

# docker-compose.yml — n8n self-hosted production-ready
version: "3.8"

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - n8n-network

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n-network

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.votredomaine.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.votredomaine.com/
      - GENERIC_TIMEZONE=Europe/Paris
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
    networks:
      - n8n-network

volumes:
  postgres_data:
  n8n_data:
  caddy_data:
  caddy_config:

networks:
  n8n-network:

Odpovídající Caddyfile pro automatický HTTPS reverse proxy:

n8n.votredomaine.com {
    reverse_proxy n8n:5678
    encode gzip
}

Soubor .env k umístění vedle (NIKDY necommitovat):

POSTGRES_PASSWORD=un_password_fort_minimum_32_chars_xxxxxx
N8N_ENCRYPTION_KEY=encryption_key_32_chars_strict_yyyyyyyy

Vygenerujte N8N_ENCRYPTION_KEY pomocí openssl rand -hex 32. Tento klíč šifruje všechny credentials uložené n8n (OAuth tokeny, API klíče) — pokud ho ztratíte, všechny credentials jsou neobnovitelné.

Spuštění:

# DNS prerekvizita: nasměrovat n8n.vasedomena.com na IP VPS
docker-compose up -d
docker-compose logs -f n8n  # ověřit spuštění

n8n je přístupný na https://n8n.vasedomena.com po ~2 minutách (prodleva Caddy pro vygenerování certifikátu Let's Encrypt). První přístup: vytvoření adminského účtu, nastavení časového pásma a hotovo.

Strategie zálohování credentials a workflow

Jakmile je n8n v produkci, ztráta šifrovaných credentials nebo databáze Postgres může stát týdny rekonfigurace. Tři osy zálohování k zavedení bezpodmínečně před migrací kritických workflow. Osa 1 — Snímek disku na straně providera. Aktivujte automatické denní snapshoty na VPS (1–2 EUR/měsíc navíc u Hetzneru nebo DigitalOcean). V případě korupce nebo špatné manipulace obnovení za méně než 10 minut do historického bodu. To je nejlevnější a nejúčinnější záchranná síť, která nevyžaduje žádnou aplikační logiku.

Osa 2 — Pravidelný šifrovaný dump Postgresu. Denní cron provádějící pg_dump n8n, poté šifrující dump pomocí age nebo GPG, poté pushující na S3-kompatibilní bucket (R2 Cloudflare, Backblaze B2, Wasabi) s retencí 30 dní. Logika šifrování je zásadní: dump obsahuje všechny workflow, ale také credentials Google Ads šifrované vaším encryption_key. Pokud dump unikne v čistém textu bez šifrování, kdokoli s encryption_key může přistoupit k vašim credentials. Ukládejte encryption_key odděleně od dumpu (ideálně v password manageru sdíleném se správcem zálohy týmu).

Osa 3 — JSON export kritických workflow v source control. Pro každý produkční workflow exportujte JSON přes "Download" v UI n8n a commitujte do dedikovaného privátního Git repozitáře. To přináší dva přínosy: verzování a code review změn workflow a okamžité obnovení pokud je databáze Postgres ztracena. Encryption_key je stále potřebný pro reimport s credentials, ale struktura workflow je zachována. Na účtech sledovaných ve veřejných benchmarcích Google Ads týmy kombinující tři osy nikdy neztrácejí více než 24 hodin konfigurace v případě incidentu, oproti týdnům pro ty, kteří mají pouze jednu osu.

Konfigurace credentials Google Ads

V Credentials > Add Credential > Google Ads OAuth2 API. Zadejte:

• Client ID: z vašeho projektu GCP (viz náš průvodce nastavením Python API pro postup generování).
• Client Secret: totéž.
• Scope: https://www.googleapis.com/auth/adwords.
• Authorization URL: předvyplněno n8n.
• Token URL: předvyplněno.
• Redirect URL: zkopírujte hodnotu poskytnutou n8n a přidejte ji do Authorized redirect URIs vašeho OAuth klienta v GCP Console.

Klikněte Connect my account, ověřte v okně OAuth, n8n automaticky získá refresh_token a uloží ho šifrovaný.

Pro developer_token (který není v OAuth), přidejte samostatný Credential Header Auth s Header Name: developer-token a Header Value: YOUR_DEVELOPER_TOKEN. Nody HTTP Request volající Google Ads API budou tento header konzumovat.

Flow 1–2: monitoring CPC + upozornění Slack

První 2 flows pokrývají denní monitoring: detekci anomálií CPC a upozornění Slacku. To je nejvýnosnější případ použití na začátku.

Flow 1 — Monitoring CPC s upozorněními Slack

Trigger: Cron, každou hodinu. Logika: pull průměrných CPC aktivních kampaní za posledních 24 klouzavých hodin, porovnání s průměrným CPC za 7 dní, upozornění Slack pokud variace > +25 %.

Exportovaný JSON workflow (minimalizovaný výňatek pro čtení):

{
  "name": "GoogleAds — CPC Monitoring + Slack Alerts",
  "nodes": [
    {
      "name": "Cron Hourly",
      "type": "n8n-nodes-base.cron",
      "parameters": {
        "triggerTimes": { "item": [{ "mode": "everyHour" }] }
      }
    },
    {
      "name": "Pull GAQL CPC",
      "type": "n8n-nodes-base.httpRequest",
      "parameters": {
        "method": "POST",
        "url": "https://googleads.googleapis.com/v17/customers/{{$env.CUSTOMER_ID}}/googleAds:search",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "googleAdsOAuth2Api",
        "headerParameters": {
          "parameters": [
            { "name": "developer-token", "value": "{{$env.DEV_TOKEN}}" },
            { "name": "login-customer-id", "value": "{{$env.LOGIN_CID}}" }
          ]
        },
        "bodyParameters": {
          "parameters": [
            {
              "name": "query",
              "value": "SELECT campaign.id, campaign.name, metrics.average_cpc FROM campaign WHERE campaign.status = 'ENABLED' AND segments.date DURING LAST_7_DAYS"
            }
          ]
        }
      }
    },
    {
      "name": "Compute Variations",
      "type": "n8n-nodes-base.code",
      "parameters": {
        "language": "javaScript",
        "jsCode": "const items = $input.all();\nconst alerts = [];\nfor (const i of items) {\n  const c = i.json;\n  // Calcul variation CPC vs baseline\n  const cpcNow = c.metrics.average_cpc / 1000000;\n  const cpcAvg7d = c.baseline_cpc;\n  const variation = (cpcNow - cpcAvg7d) / cpcAvg7d;\n  if (variation > 0.25) {\n    alerts.push({\n      campaign: c.campaign.name,\n      cpc_now: cpcNow.toFixed(2),\n      cpc_baseline: cpcAvg7d.toFixed(2),\n      variation_pct: (variation * 100).toFixed(1)\n    });\n  }\n}\nreturn alerts.map(a => ({ json: a }));"
      }
    },
    {
      "name": "Slack Alert",
      "type": "n8n-nodes-base.slack",
      "parameters": {
        "channel": "#google-ads-alerts",
        "text": "[CPC ALERT] {{$json.campaign}} - CPC +{{$json.variation_pct}}% ({{$json.cpc_baseline}} EUR -> {{$json.cpc_now}} EUR)"
      }
    }
  ]
}

Proměnné k přizpůsobení po importu: CUSTOMER_ID (10místné číslo klientského účtu), DEV_TOKEN (developer token Google Ads), LOGIN_CID (nadřazený MCC), kanál Slack.

Frekvence triggeru: každou hodinu během pracovní doby, denně v noci (aby se předešlo falešně pozitivním výsledkům na nízkém objemu). Výstup: zpráva Slack na každou kampaň, jejíž CPC překračuje +25 % baseline.

Flow 2 — Detekce anomálií výdajů (>2× průměr za 7 dní)

Trigger: Cron, každé 4 hodiny. Logika: pull celkových výdajů účtu za klouzavé období, porovnání s průměrem za 7 dní × faktor. Pokud variace překračuje 2×, upozornění na Slack s rozpisem podle kampaně.

Vzor n8n je podobný Flow 1 se 4 nody:

1. Cron každé 4 hodiny.
2. HTTP Request GAQL: pull celkových výdajů + rozpad podle kampaně.
3. Code: výpočet variace vs baseline za 7 dní, identifikace příčinných kampaní.
4. Slack: odeslání strukturované zprávy při anomálii.

Proměnné k vyladění: SPEND_VARIATION_THRESHOLD (2,0 = +100 % = dvojnásobek), MIN_SPEND_BASELINE (filtrovat kampaně s nízkým objemem pro předcházení falešně pozitivním výsledkům), ALERT_CHANNEL.

Flow 3–4: synchronizace konverzí CRM do Google Ads

Flows 3–4 pokrývají push offline konverzí z CRM do Google Ads (Offline Conversion Imports + Customer Match). To je jeden z nejvýnosnějších případů použití pro SaaS B2B a lead gen s dlouhým prodejním cyklem.

Flow 3 — Push HubSpot deals won do offline konverzí Google Ads

Trigger: webhook HubSpot (fáze dealu = closed-won). Logika: přijmout webhook, získat gclid z dealu (uložený ve vlastní property), naformátovat payload podle specifikace Google Ads UploadClickConversion, push přes API.

Architektura flow:

[Webhook HubSpot] -> [Extract GCLID + value] -> [Format payload Google Ads]
                                              -> [HTTP POST UploadClickConversion]
                                              -> [Log success/error in PostgreSQL]
                                              -> [Slack notify if error]

Node HTTP Request do Google Ads Offline Conversion:

// Code node : format payload
const dealData = $input.first().json;
const gclid = dealData.properties.hs_gclid;
const dealValue = parseFloat(dealData.properties.amount);
const closeDate = dealData.properties.closedate;

if (!gclid) {
  // Pas de GCLID = pas trackable (deal organique ou source non-Google)
  return [{ json: { skip: true, reason: "no_gclid" } }];
}

// Format ISO requis par Google Ads
const conversionDateTime = new Date(closeDate)
  .toISOString()
  .replace("T", " ")
  .substring(0, 19) + "+00:00";

return [{
  json: {
    conversions: [{
      gclid,
      conversion_action: `customers/${$env.CUSTOMER_ID}/conversionActions/${$env.CONV_ACTION_ID}`,
      conversion_date_time: conversionDateTime,
      conversion_value: dealValue,
      currency_code: "EUR"
    }],
    partial_failure: true,
    validate_only: false
  }
}];

Proměnné k přizpůsobení: CUSTOMER_ID, CONV_ACTION_ID (ID konverzní akce "Closed Deal" vytvořené předem v Google Ads UI). Viz náš průvodce conversion tracking Google Ads pro vytvoření konverzní akce a funkční rámec offline importů.

Kritické pasti:

• GCLID vyprší 90 dní po kliknutí. Pokud váš prodejní cyklus překračuje 90 dní, push musí být proveden před vypršením nebo použijte GBRAID/WBRAID pro iOS.
• Hodnota dealu musí být v nativní měně účtu (EUR, USD, GBP). Žádné míchání.
• partial_failure: true umožňuje Google přijmout platné konverze i pokud je jedna z dávky neplatná. Bez tohoto příznaku chyba způsobí odmítnutí celé dávky.

Flow 4 — Synchronizace publik GA4 do Customer Match

Trigger: Cron denně ve 3:00. Logika: dotaz na publikum GA4 (např. "uživatelé, kteří navštívili stránku ceníku bez nákupu"), získání emailů, hash v SHA-256, push do seznamu Google Ads Customer Match.

Flow řetězí 4 hlavní nody: pull GA4 Data API -> node SHA-256 hash (vlastní Code) -> Google Ads OfflineUserDataJobService -> potvrzení Slack. Viz náš průvodce Customer Match first-party data pro kompletní strategii publik.

Flow 5–6: týdenní emailový reporting + Looker Studio

Poslední 2 flows pokrývají opakující se reporting: týdenní email s přehledem KPI a push BigQuery + obnovení Looker Studio pro dashboardy.

Flow 5 — Týdenní HTML email report výkonu

Trigger: Cron, každé pondělí v 8:00. Logika: pull klíčových KPI za posledních 7 dní (výdaje, kliknutí, konverze, CPA, ROAS) podle kampaně, naformátování HTML emailu, odeslání přes SMTP na distribuční seznam. Náš kalkulátor CPA ve 2 vstupech vrací hodnotu + medián Francie pro vaši vertikálu.

Centrální node Code formátující HTML:

// Format HTML weekly report
const campaigns = $input.all().map(i => i.json);

let html = `
<h2 style="font-family: Arial; color: #1a202c;" data-speakable>
  Google Ads Weekly Report - Week ${getWeekNumber()}
</h2>
<p>Period: ${getDateRangeLabel()}</p>
<table border="1" cellpadding="10" style="border-collapse:collapse; font-family:Arial; font-size:13px;">
  <tr style="background:#f5f5f5;">
    <th>Campaign</th><th>Spend</th><th>Clicks</th><th>Conv</th><th>CPA</th><th>ROAS</th>
  </tr>
`;

let totalSpend = 0, totalConv = 0;
for (const c of campaigns) {
  const cpa = c.conversions > 0 ? (c.cost_eur / c.conversions).toFixed(2) : "N/A";
  const roas = c.cost_eur > 0 ? (c.conversions_value / c.cost_eur).toFixed(2) : "N/A";
  html += `
    <tr>
      <td>${c.name}</td>
      <td>${c.cost_eur.toFixed(2)} EUR</td>
      <td>${c.clicks}</td>
      <td>${c.conversions.toFixed(1)}</td>
      <td>${cpa} EUR</td>
      <td>${roas}</td>
    </tr>
  `;
  totalSpend += c.cost_eur;
  totalConv += c.conversions;
}

html += `
</table>
<p><strong>Total Spend:</strong> ${totalSpend.toFixed(2)} EUR</p>
<p><strong>Total Conversions:</strong> ${totalConv.toFixed(1)}</p>
<p><strong>Avg CPA:</strong> ${(totalSpend / totalConv).toFixed(2)} EUR</p>
`;

function getWeekNumber() {
  const now = new Date();
  const start = new Date(now.getFullYear(), 0, 1);
  const days = Math.floor((now - start) / 86400000);
  return Math.ceil((days + start.getDay() + 1) / 7);
}

function getDateRangeLabel() {
  const end = new Date();
  const start = new Date();
  start.setDate(end.getDate() - 7);
  return `${start.toISOString().split("T")[0]} -> ${end.toISOString().split("T")[0]}`;
}

return [{ json: { html_body: html, subject: `Google Ads Report W${getWeekNumber()}` } }];

Proměnné: EMAIL_RECIPIENTS (seznam oddělený čárkami), SMTP_* (host, port, user, pass — credentials n8n SMTP).

Flow 6 — Denní push do BigQuery + obnovení Looker Studio

Trigger: Cron denně ve 4:00. Logika: pull všech granulárních KPI (podle kampaně, klíčového slova, zařízení, geo) za posledních 24 hodin, push v append módu do tabulky BigQuery, spuštění obnovení dashboardu Looker Studio přes webhook.

To je klasický vzor data warehousing: BigQuery jako single source of truth, Looker Studio (dříve Data Studio) jako vizualizační vrstva, n8n jako orchestrátor ETL. Výhoda oproti skriptu Python: žádná infrastruktura scheduleru k údržbě, nativní pozorovatelnost v n8n.

Osvědčené postupy: error handling, retry, logging

Workflow n8n běžící 24/7 bez error handlingu selže tiše a problém zjistíte o 3 týdny později, když se zákazník ptá, proč report již nepřichází. 4 kritické vzory.

Vzor 1 — Dedikovaný error workflow. V Settings > Error Workflow navrhněte specifický workflow, který se spustí, když jakýkoli jiný workflow selže. Error workflow přijímá payload chyby (název workflow, node, chybová zpráva, časové razítko) a odešle upozornění Slack. Všechny produkční workflow musí ukazovat na tento error workflow.

Vzor 2 — Retry on failure. Na každém kritickém nodu (zejména HTTP Request) aktivujte Retry On Fail s 3 pokusy a prodlevou 30 sekund. Pro přechodné chyby (rate limit, timeout sítě) retry stačí. Pro permanentní chyby (vypršení auth, neplatný argument) node selže po 3 pokusech a aktivuje se error workflow.

Vzor 3 — Continue On Fail strategicky. Pro workflow zpracovávající N položek paralelně (např. push 100 konverzí HubSpot do Google Ads) aktivujte Continue On Fail na node mutace. Workflow pokračuje i pokud 5 položek z 100 selže. Přidejte node IF za to pro oddělení úspěchů od chyb a logování chyb do dedikovaného Postgres nodu.

Vzor 4 — Prunování historických spuštění. V Docker .env nakonfigurujte EXECUTIONS_DATA_MAX_AGE=336 (336 hodin = 14 dní) pro automatické mazání historických spuštění. Jinak DB n8n roste donekonečna. Pro 50 aktivních workflow se 100 spuštěními denně každý počítejte ~150k řádků za 14 dní.

// Code node : log structure pour observability
const ts = new Date().toISOString();
const workflowName = $workflow.name;
const executionId = $execution.id;
const nodeOutput = $input.first().json;

return [{
  json: {
    log_level: "INFO",
    timestamp: ts,
    workflow: workflowName,
    execution_id: executionId,
    event: "workflow_completed",
    items_processed: $input.all().length,
    metadata: nodeOutput
  }
}];

Limity n8n vs přímé API

n8n je vynikající low-code kompromis, ale má svá omezení. 4 případy, kdy přechod na samostatný Python nebo Node.js skript (viz náš průvodce nastavením Google Ads API Python) zůstává lepší.

Limit 1 — Velmi vysoký objem (>500k operací/den). n8n vyniká na středních objemech (1 000 až 100 000 ops/den). Nad tím latence na node + overhead zápisu do DB zpomaluje. Skript Python s nativními dávkovými operacemi zpracuje 1M ops za 1 hodinu, oproti 4–6 hodinám u n8n.

Limit 2 — Složitá algoritmická logika. Pro workflow vyžadující ML inferenci, statistické regrese, clustering — node Code n8n umožňuje JS, ale s omezeným prostředím. Skript Python se scikit-learn / XGBoost zůstává praktičtější.

Limit 3 — Integrace produktu. Pokud začleňujete Google Ads do interního produktu (dashboard, SaaS aplikace), n8n je příliš „interní nástroj" a příliš těžkopádný. Přímé API přes SDK zůstává správnou volbou.

Limit 4 — Debugging za provozu na produkci. n8n nabízí správnou, ale ne optimální pozorovatelnost (žádný kompletní stacktrace na Code nodech, omezené logy). Pro vyspělý stack Python s nastavením logging + Sentry překonává n8n v UX debuggingu.

Pro 80 % případů použití Google Ads SMB nebo mid-market (monitoring, synchronizace CRM, reporting, alerting) je n8n zcela dostačující a poměr náklady/údržba zůstává nepřekonatelný. Pro účty, které chtějí industrializovat bez ops infrastruktury, náš modul Auto-optimalizace pokrývá 6 výše uvedených flows v řízeném režimu (žádný VPS k údržbě, žádný refresh_token k obnovení), s nativním dashboardem a alertingem. Viz také náš checklist auditu Google Ads, náš průvodce 10 skripty Google Ads, naše srovnání Zapier vs Make pro no-code možnosti a náš průvodce MCP Google Ads Claude Desktop pro konverzační vrstvu.

Časté chyby v produkčním n8n

Pět chyb se opakovaně vyskytuje v self-hosted n8n nastaveních pozorovaných při auditu. Každá může stát několik dní tichého incidentu nebo špatných rozhodnutí Google Ads na základě neúplných dat. Zde jsou pasti a jak se jim vyhnout.

1. Žádný monitoring na samotném workflow. Diagnóza: workflow selže po aktualizaci Google Ads API nebo odvolání refresh_token, ale nikdo si toho nevšimne, dokud zákazník nezeptá, proč týdenní report již nepřichází. Oprava: nakonfigurujte globální Error Workflow, který posílá na Slack #ops-alerts při každém selhání, a cron heartbeat (triviální workflow posílající denní OK), pro detekci případů, kdy je samotný scheduler n8n down. Kritický workflow bez heartbeatu je monitorovací díra, která může trvat týdny.

2. Ukládání encryption_key ve stejném Git repozitáři jako compose. Diagnóza: .env s N8N_ENCRYPTION_KEY je omylem commitován, útočník klonující repozitář může dešifrovat všechny credentials Google Ads. Oprava: NIKDY necommitujte .env. Použijte secret manager (Doppler, Vault, AWS SM, GCP Secret Manager) nebo minimálně uložte klíč do password manageru sdíleného s auditovaným přístupem. Pokud byl klíč veřejně commitován, okamžitě ho obnovte a překonfigurujte všechny credentials.

3. Aktivní workflow na testovacím účtu s login_customer_id produkce. Diagnóza: vývojář zkopíruje workflow z testovacího účtu do produkce bez změny login_customer_id, workflow upravuje rozpočty na špatném účtu. Oprava: používejte odlišné proměnné prostředí pro každé prostředí (CUSTOMER_ID_TEST, CUSTOMER_ID_PROD) a přísnou konvenci pojmenování (workflow označený [PROD] nebo [TEST] v názvu). Systematicky testujte v režimu "Execute Workflow" na testovacím účtu před aktivací v produkci.

4. Postgres databáze, která se sytí bez mazání spuštění. Diagnóza: po 6 měsících v produkci databáze Postgres dosáhne 50+ GB, workflow se zpomalují, zálohy trvají hodiny. Oprava: nakonfigurujte EXECUTIONS_DATA_PRUNE=true a EXECUTIONS_DATA_MAX_AGE=336 (14 dní) od samotného nastavení. Pro kritické workflow, jejichž logy chcete uchovávat déle, exportujte do BigQuery nebo samostatného datového úložiště v okamžiku spuštění, místo nafukování DB n8n.

5. Smyčka bez throttlingu na dávkách mutací Google Ads. Diagnóza: workflow synchronizující 5 000 Customer Match emailů selže s RESOURCE_EXHAUSTED, protože volá API paralelně na všechny položky. Oprava: přidejte node "SplitInBatches" s batch_size 100 a node "Wait" 2 sekundy mezi dávkami. Celková propustnost je mírně snížena, ale míra chyb klesá z 30–40 % na méně než 1 %. Tato logika platí pro všechny batch operace vůči Google Ads, HubSpot, Salesforce a dalším API s rate limitem.

Pro oficiální zdroje viz dokumentaci n8n (výborná úroveň detailu) a oficiální repozitář GitHub n8n pro sledování vydání.

Zdroje

Oficiální zdroje použité v tomto průvodci:

• modelcontextprotocol.io
• schema.org
• blog.google
• anthropic.com

FAQ