Stripe Revenue → Google Ads: importare le conversioni (tutorial) 2026

Per la maggior parte dei founder SaaS e team growth che fanno girare Google Ads nel 2026, il gap tra il ROAS che Google Ads riporta e il revenue che Stripe ha effettivamente incassato è da qualche parte tra il 20 % e il 70 %. Le conversioni web pixel si attivano sull'intent di checkout (click bottone, page load); non sanno nulla di carte fallite, bounce di dunning, rimborsi, dispute fraudolente o trial che non hanno mai convertito. Smart Bidding ottimizza rispetto al segnale che gli date — e se quel segnale è intent di checkout lordo piuttosto che revenue netto incassato, l'algoritmo scala lo spend nella direzione sbagliata.

Questa guida percorre l'integrazione tecnica e operativa completa: catturare il Google Click ID (GCLID) su ogni pagina di checkout, memorizzarlo nei metadata customer o charge Stripe, sottoscriversi agli eventi webhook giusti, chiamare l'API Google Ads ConversionUploadService con la conversion action e il valore corretti, gestire account Stripe multi-valuta e cablare rimborsi e dispute attraverso l'API conversion adjustment. Chiudiamo con un pattern middleware BigQuery per account ad alto volume e un rollout di implementazione di 30 giorni.

Perché l'import conversioni Stripe → Google Ads conta nel 2026

Tre trend nel 2026 rendono questa integrazione più importante di quanto fosse nel 2022:

1. Smart Bidding ora consuma essenzialmente tutto lo spend dell'account. Per il reporting di trasparenza Google 2025, più dell'85 % dello spend Google Ads sugli account attivi nel 2026 fluisce attraverso strategie di bid guidate da segnale di conversione — Maximize Conversions, Maximize Conversion Value, Target CPA e Target ROAS. La strategia di bid è accurata solo quanto i dati di conversione che riceve. Gli account Manual CPC possono tollerare segnale di conversione rumoroso perché gli umani rivedono ogni bid; Smart Bidding non può. Se i vostri dati di conversione sovra-riportano del 30 %, Smart Bidding spende il 30 % in più di quanto dovrebbe su bid che sembrano profittevoli ma non lo sono.

2. La deprecazione dei third-party cookie del 2024 ha accelerato l'importanza di GCLID. Mentre il tracking browser-side degrada, l'import server-side di conversioni via GCLID diventa il ponte più affidabile tra un click ad e una conversione downstream. Stripe è la fonte naturale di verità per gli eventi revenue perché si trova al layer di financial settlement, post-validazione del metodo di pagamento. L'attribuzione pixel-based continuerà a indebolirsi nel 2026-2027; l'attribuzione server-side basata su Stripe resta accurata.

3. Il bidding basato su ROAS richiede input di revenue onesti. La strategia di bid Target ROAS di Google Ads funziona predicendo il valore conversione per click e biddando a un ratio target valore-su-costo. Se i valori che sta predicendo includono revenue rimborsato, revenue di trial fallito e charge in dispute, le predizioni sono sistematicamente alte — e il bidding overshoot. L'import Stripe è l'unico meccanismo che dà a Google Ads il revenue netto ground-truth alla granularità di valore conversione di cui Target ROAS ha bisogno.

L'integrazione non è infrastruttura opzionale per SaaS seri nel 2026; è il floor sotto il quale Smart Bidding non funziona correttamente.

Il data flow a colpo d'occhio: GCLID → Stripe → Google Ads

Il flusso dati end-to-end è semplice nel concetto e pieno di edge case nell'esecuzione. I cinque passi:

Passo 1 — Click: Un utente clicca il vostro Google Ad. L'autotagging Google Ads appende ?gclid=ABC123... all'URL di destinazione. Il GCLID è un token unico legato a quel click, valido per 90 giorni per l'attribuzione conversioni su campagne Search/Display.

Passo 2 — Cattura: La vostra landing page legge il parametro query gclid e lo persiste. Due pattern di persistenza: cookie (first_touch_gclid per 90 giorni), o storage backend con chiave session ID anonima poi user ID dopo il signup.

Passo 3 — Checkout: Quando l'utente raggiunge Stripe Checkout (o il form Stripe Elements sulla vostra pagina), passate il GCLID memorizzato come campo metadata sulla creazione della Checkout Session, sul PaymentIntent o sull'oggetto Customer. Questo lega il GCLID all'evento finanziario.

Passo 4 — Charge riesce: Stripe processa il pagamento. Al settlement riuscito (charge.succeeded), Stripe attiva un webhook al vostro endpoint. Il payload webhook contiene charge ID, importo, valuta, customer ID e metadata (incluso il GCLID che avete memorizzato).

Passo 5 — Upload a Google Ads: Il vostro handler webhook chiama l'endpoint API Google Ads ConversionUploadService.UploadClickConversions, passando GCLID, conversion action resource name, timestamp conversione, valore conversione e currency code. Google Ads matcha il GCLID al click originale, attribuisce la conversione e aggiorna reporting e input Smart Bidding.

Gli errori più comuni nel passo 5 sono: caricare a checkout.session.completed invece di charge.succeeded (manca i fallimenti di pagamento), caricare l'importo lordo invece del netto delle fee Stripe (dipende dalla vostra preferenza contabile), e non gestire la conversione valuta quando charge Stripe e account Google Ads sono in valute diverse.

Catturare GCLID nei metadata customer o charge di Stripe

Il primo passo tecnico è catturare in modo affidabile il GCLID al momento del click e legarlo all'evento finanziario in Stripe. Tre pattern di implementazione per complessità:

Pattern A — Metadata Checkout Session Stripe (il più semplice):

Quando create la Checkout Session server-side, passate il GCLID come campo metadata:

const session = await stripe.checkout.sessions.create({
  mode: "subscription",
  line_items: [{ price: "price_xyz", quantity: 1 }],
  metadata: {
    gclid: req.cookies.gclid || "",
    gbraid: req.cookies.gbraid || "",
    wbraid: req.cookies.wbraid || "",
    click_timestamp: req.cookies.click_ts || "",
  },
  success_url: "https://yoursaas.com/thanks",
  cancel_url: "https://yoursaas.com/pricing",
});

Pro: zero storage backend, i metadata viaggiano con la sessione per sempre. Contro: i valori metadata Stripe sono limitati a 500 char ciascuno e il GCLID deve essere disponibile al momento della creazione sessione (cookie impostato sulla landing page).

Pattern B — Metadata oggetto Customer (migliore per rinnovi subscription):

Memorizzate il GCLID sull'oggetto Customer al primo signup. Tutti i charge futuri da quel customer ereditano l'attribuzione:

const customer = await stripe.customers.create({
  email: req.body.email,
  metadata: {
    gclid: req.cookies.gclid || "",
    first_touch_campaign: req.cookies.utm_campaign || "",
    signup_date: new Date().toISOString(),
  },
});

Pro: funziona per billing ricorrente (ogni invoice.payment_succeeded eredita il GCLID del customer). Contro: cattura solo il GCLID first-touch, non last-touch — per SaaS con touchpoint multipli di ad-click attraverso un ciclo di vendita lungo, potreste voler aggiornare il GCLID a ogni nuovo click.

Pattern C — Il vostro database, joined al momento del webhook:

Memorizzate GCLID nel vostro database con chiave user_id o session_id. Quando il webhook Stripe si attiva per charge.succeeded, cercate il GCLID memorizzato dell'utente e passatelo a Google Ads:

# Nel vostro handler webhook charge.succeeded:
user_id = stripe_customer.metadata.get('user_id')
gclid = db.query("SELECT gclid FROM users WHERE id = %s", [user_id])
if gclid:
    upload_to_google_ads(gclid, charge.amount, charge.currency, charge.created)

Pro: il più flessibile, supporta attribuzione last-touch, supporta finestre di attribuzione multi-click. Contro: richiede infrastruttura backend, più modalità di failure.

Best practice — catturare tutti e tre i click ID dell'era iOS:

L'autotagging moderno di Google Ads emette gclid per la maggior parte del traffico, più gbraid per campagne iOS App e wbraid per traffico web iOS quando ATT-restricted. Catturate tutti e tre. L'API upload Google Ads ha endpoint separati per ciascuno (UploadCallConversions, UploadClickConversions); usate gclid dove presente, fallback a gbraid/wbraid per traffico iOS.

Configurare la conversion action Google Ads per il value tracking

Prima che qualsiasi codice di upload possa riuscire, dovete creare le conversion action in Google Ads che gli upload targetteranno. In Tools > Conversions > New conversion action, scegliete «Import» come fonte, poi «Other data sources or CRMs» > «Track conversions from clicks».

Tre conversion action da creare per una standard integrazione Stripe SaaS:

Action 1 — Stripe Trial Start (opzionale ma raccomandato):

• Category: Sign-up
• Value: Don't use a value
• Count: One
• Click-through window: 90 giorni
• View-through window: 1 giorno
• Include in Conversions: No (inizialmente — flippate a Yes dopo che il primo paid charge si attiva per lo stesso utente)

Action 2 — Stripe First Paid Charge (l'action primaria):

• Category: Purchase
• Value: Use different values for each conversion
• Count: One (una conversione per click — il primo paid charge)
• Click-through window: 90 giorni
• View-through window: 1 giorno
• Include in Conversions: Yes (questo è ciò verso cui Smart Bidding ottimizza)
• Attribution model: Data-driven (default nel 2026)

Action 3 — Stripe Expansion Revenue (per upsell, upgrade piano, seat aggiuntivi):

• Category: Purchase
• Value: Use different values for each conversion
• Count: Every (expansion multipli per click possono tutti contare)
• Click-through window: 90 giorni
• View-through window: 1 giorno
• Include in Conversions: Yes (additivo a First Paid Charge in Smart Bidding)

Per ogni conversion action, notate l'ID Conversion Action (un resource name come customers/1234567890/conversionActions/9876543210). Passerete questo all'API upload come conversion_action.

Impostare «Use different values for each conversion» è critico per il use case revenue Stripe. Senza di esso, ogni conversione si carica con lo stesso valore fisso (il «default value» che impostate sulla action). Smart Bidding non può differenziare un signup piano base 15 €/mese da un signup enterprise 1.500 €/mese se tutte le conversioni hanno lo stesso valore. Selezionate sempre l'opzione «different values» per le action di revenue importate da Stripe.

Costruire il listener webhook (esempi Node.js + Python)

Il listener webhook ha tre responsabilità: verificare la firma webhook Stripe (sicurezza), parsare il payload evento e chiamare l'endpoint API Google Ads appropriato. Qui sotto implementazioni minimali in Node.js e Python — entrambi production-ready nella forma ma tagliati per chiarezza.

Implementazione Node.js / Express:

import express from "express";
import Stripe from "stripe";
import { GoogleAdsApi } from "google-ads-api";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const googleAds = new GoogleAdsApi({
  client_id: process.env.GOOGLE_ADS_CLIENT_ID,
  client_secret: process.env.GOOGLE_ADS_CLIENT_SECRET,
  developer_token: process.env.GOOGLE_ADS_DEVELOPER_TOKEN,
});
const customer = googleAds.Customer({
  customer_id: process.env.GOOGLE_ADS_CUSTOMER_ID,
  refresh_token: process.env.GOOGLE_ADS_REFRESH_TOKEN,
});

app.post("/webhooks/stripe", express.raw({ type: "application/json" }), async (req, res) => {
  const sig = req.headers["stripe-signature"];
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, sig, process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  if (event.type === "charge.succeeded") {
    const charge = event.data.object;
    const gclid = charge.metadata.gclid;
    if (!gclid) return res.status(200).send("No GCLID — skipping");

    const conversionValue = charge.amount / 100; // Stripe amounts are in cents
    const conversionTime = new Date(charge.created * 1000).toISOString();

    await customer.conversionUploads.uploadClickConversions({
      conversions: [
        {
          gclid,
          conversion_action: process.env.GOOGLE_ADS_CONVERSION_ACTION_RN,
          conversion_date_time: conversionTime,
          conversion_value: conversionValue,
          currency_code: charge.currency.toUpperCase(),
        },
      ],
      partial_failure: true,
    });
  }
  res.status(200).send("OK");
});

Implementazione Python / FastAPI:

from fastapi import FastAPI, Request, HTTPException
import stripe
from google.ads.googleads.client import GoogleAdsClient

stripe.api_key = os.environ['STRIPE_SECRET_KEY']
client = GoogleAdsClient.load_from_storage('google-ads.yaml')

@app.post('/webhooks/stripe')
async def stripe_webhook(request: Request):
    payload = await request.body()
    sig = request.headers.get('stripe-signature')
    try:
        event = stripe.Webhook.construct_event(payload, sig, os.environ['STRIPE_WEBHOOK_SECRET'])
    except Exception:
        raise HTTPException(status_code=400, detail='Invalid signature')

    if event['type'] == 'charge.succeeded':
        charge = event['data']['object']
        gclid = charge['metadata'].get('gclid')
        if not gclid:
            return {'status': 'no gclid'}

        upload_service = client.get_service('ConversionUploadService')
        click_conversion = client.get_type('ClickConversion')
        click_conversion.gclid = gclid
        click_conversion.conversion_action = os.environ['GOOGLE_ADS_CONVERSION_ACTION_RN']
        click_conversion.conversion_date_time = (
            datetime.fromtimestamp(charge['created']).strftime('%Y-%m-%d %H:%M:%S+00:00')
        )
        click_conversion.conversion_value = charge['amount'] / 100
        click_conversion.currency_code = charge['currency'].upper()
        upload_service.upload_click_conversions(
            customer_id=os.environ['GOOGLE_ADS_CUSTOMER_ID'],
            conversions=[click_conversion],
            partial_failure=True,
        )
    return {'status': 'ok'}

Hardening critico di produzione da aggiungere:

• Idempotenza: cache degli event ID Stripe processati per 24h, skip eventi duplicati
• Retry con backoff esponenziale su errori 5xx dell'API Google Ads (3 retry: 1s, 5s, 25s)
• Coda dead-letter per upload permanentemente falliti (revisione settimanale)
• Logging strutturato di ogni upload (charge_id, gclid, conversion_value, response_code)
• Alerting quando il tasso di errore supera l'1 % su una finestra rolling di 1 ora

Gestione valuta, rimborsi e aggiustamenti conversioni

I due mal di testa operativi che fanno deragliare la maggior parte delle integrazioni Stripe-to-Google sono la normalizzazione valuta e la gestione rimborsi. Entrambi devono essere risolti prima che Smart Bidding funzioni correttamente.

Normalizzazione valuta:

Gli account Google Ads hanno una valuta singola impostata alla creazione. Tutti i valori conversione caricati devono essere in quella valuta. Gli account Stripe possono addebitare in 135+ valute. La logica di riconciliazione:

1. Se Stripe charge.currency matcha la valuta dell'account Google Ads → usate charge.amount direttamente (dopo aver diviso per 100 per la convenzione centesimi-su-unità)
2. Se Stripe charge.currency differisce → usate Stripe BalanceTransaction amount ed exchange_rate per convertire
3. Se BalanceTransaction non è ancora disponibile (race condition subito dopo charge.succeeded) → interrogate un'API FX esterna al timestamp del charge

Pseudocodice per il path sicuro:

def normalize_currency(charge, target_currency):
    if charge['currency'].upper() == target_currency:
        return charge['amount'] / 100
    # Fetch balance transaction (settled in your Stripe payout currency)
    bt = stripe.BalanceTransaction.retrieve(charge['balance_transaction'])
    if bt['currency'].upper() == target_currency:
        return bt['amount'] / 100
    # Both differ — convert via Stripe's exchange rate
    return (bt['amount'] / 100) * bt['exchange_rate']

Gestione rimborsi via UploadConversionAdjustments:

Quando Stripe attiva charge.refunded, dovete aggiustare la conversione Google Ads corrispondente. L'API adjustment accetta due operazioni:

• RETRACT: rimuove interamente la conversione originale (usare per rimborsi completi)
• RESTATE: cambia il valore conversione (usare per rimborsi parziali — passate il nuovo, più basso valore)

Entrambe le operazioni richiedono: GCLID originale, conversion action resource name, data-tempo conversione originale (deve matchare esattamente) e timestamp adjustment.

// charge.refunded handler
const refund = event.data.object;
const isFullRefund = refund.amount_refunded === refund.amount;

await customer.conversionAdjustmentUploads.uploadConversionAdjustments({
  conversionAdjustments: [
    {
      gclid_date_time_pair: {
        gclid: refund.metadata.gclid,
        conversion_date_time: originalConversionTime, // must match original exactly
      },
      conversion_action: process.env.GOOGLE_ADS_CONVERSION_ACTION_RN,
      adjustment_type: isFullRefund ? "RETRACTION" : "RESTATEMENT",
      adjustment_date_time: new Date().toISOString(),
      restatement_value: isFullRefund
        ? undefined
        : {
            adjusted_value: (refund.amount - refund.amount_refunded) / 100,
            currency_code: refund.currency.toUpperCase(),
          },
    },
  ],
});

La finestra di adjustment di 55 giorni: Google Ads accetta adjustment solo entro 55 giorni dal timestamp di conversione originale. I rimborsi oltre i 55 giorni non possono essere riflessi in Google Ads. Per SaaS con finestre di rimborso lunghe (garanzie soddisfatti o rimborsati di 90 giorni, rimborsi subscription annuali a metà anno), questo è un gap strutturale — dovrete riconciliare manualmente in Looker / GA4 reporting, e accettare che Smart Bidding sta operando con numeri leggermente obsoleti su una piccola percentuale di conversioni.

Dispute e chargeback: sottoscrivetevi a charge.dispute.created. Se reason è «fraudulent» o «credit_not_processed», trattate come rimborso completo (RETRACT). Se «duplicate» o «subscription_canceled», seguite le vostre regole di business — generalmente trattate anche come rimborso completo per scopi di attribuzione ad.

Opzione middleware BigQuery per account ad alto volume

Per SaaS che fanno più di 10.000 conversioni/mese o gestiscono account Google Ads multi-prodotto, multi-regione, il pattern direct-webhook inizia a stressare. Il pattern middleware BigQuery aggiunge 5 minuti di latenza ma risolve diversi problemi insieme.

L'architettura:

1. Webhook Stripe → Cloud Function (Node.js o Python) → tabella eventi raw BigQuery
2. Query schedulata BigQuery (ogni 5 minuti) → legge nuovi eventi, calcola record conversione, chiama API Google Ads
3. Viste materializzate BigQuery → dashboard di riconciliazione, tracking rimborsi, debug di attribuzione

La Cloud Function fa quasi nulla — solo valida la firma Stripe e scrive l'evento raw in BigQuery. La query schedulata tiene tutta la logica di conversione, il che significa che potete aggiornare la logica editando SQL piuttosto che deployando codice.

Schema per la tabella eventi raw:

CREATE TABLE stripe_events (
  event_id STRING NOT NULL,
  event_type STRING NOT NULL,
  charge_id STRING,
  customer_id STRING,
  gclid STRING,
  gbraid STRING,
  wbraid STRING,
  amount_cents INT64,
  currency STRING,
  occurred_at TIMESTAMP NOT NULL,
  processed_at TIMESTAMP,
  google_ads_upload_status STRING, -- pending / success / failed
  google_ads_upload_response JSON,
  raw_payload JSON
)
PARTITION BY DATE(occurred_at)
CLUSTER BY event_type, gclid;

La query schedulata gira ogni 5 minuti:

-- Pseudocode — actual implementation uses Cloud Function callable from BQ
INSERT INTO conversion_uploads (event_id, gclid, conversion_value, status)
SELECT
  event_id,
  gclid,
  amount_cents / 100.0 AS value,
  upload_to_google_ads(gclid, conversion_action_rn, occurred_at, amount_cents / 100.0, currency) AS status
FROM stripe_events
WHERE event_type = 'charge.succeeded'
  AND google_ads_upload_status = 'pending'
  AND gclid IS NOT NULL
  AND occurred_at > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 80 DAY); -- within GCLID window

Perché il pattern middleware BigQuery vince alla scala:

• Capacità di replay: se l'API Google Ads ha un'interruzione, gli eventi raw restano in BigQuery e possono essere ricaricati dopo
• Ledger auditabile: lo status, timestamp e risposta di ogni upload sono interrogabili
• Più economico alla scala: le chiamate API batched costano meno delle chiamate per-evento (l'API Google Ads ha rate limit e quota)
• Routing multi-account: instradare conversioni al giusto account Google Ads basandosi su prodotto Stripe o regione — facile in SQL, complesso nel codice webhook
• Dashboard di riconciliazione: BigQuery → dashboard Looker che mostrano revenue Stripe vs revenue importato Google Ads, lag rimborsi, mismatch valuta

Lo svantaggio: 5 minuti di latenza vs sub-secondo per webhook diretti. Per il learning loop di Smart Bidding, 5 minuti di latenza sono invisibili — Smart Bidding aggiorna quotidianamente, non in tempo reale.

Per pattern pipeline BigQuery più profondi specifici per dati ads, vedi il nostro tutorial BigQuery Google Ads data pipeline.

Piano di implementazione a 30 giorni con checkpoint di rollout

Lo schema HowTo sopra è il giorno-per-giorno. Framing strategico per il rollout di 30 giorni:

Settimana 1 — Audit e design (Giorni 1-7). Documentate lo stato attuale: come si attivano attualmente le conversioni, qual è il ROAS riportato, qual è il revenue Stripe effettivo per la stessa finestra. Il gap è ciò che state per fixare. Definite la tassonomia conversioni (Trial Start, First Paid, Expansion). Create le conversion action Google Ads ma non includetele ancora in Conversions — sono inattive finché non fluiscono dati.

Settimana 2 — Implementazione (Giorni 8-15). Aggiungete cattura GCLID alle landing page. Cablate Stripe Checkout per passare GCLID come metadata. Costruite il listener webhook per charge.succeeded. Testate contro un account test Google Ads con GCLID sintetici. Validate che le conversioni test appaiano nel tab Google Ads Uploads entro 5 minuti.

Settimana 3 — Hardening (Giorni 16-22). Aggiungete normalizzazione valuta. Cablate webhook charge.refunded e charge.dispute.created a UploadConversionAdjustments. Aggiungete idempotenza, logica retry e coda dead-letter. Mettete in piedi la dashboard di riconciliazione Stripe-vs-Google. Fatela girare per 7 giorni contro dati live senza ancora cambiare Smart Bidding alla nuova conversion action.

Settimana 4 — Switchover e tuning (Giorni 23-30). Flippate «Include in Conversions» sulla action Stripe First Paid Charge. Flippatela off sulla vecchia action web pixel. Passate la conversione primaria di Smart Bidding a Stripe First Paid Charge. Aspettatevi 14-30 giorni di volatilità bid mentre l'algoritmo ricostruisce il suo modello. Non cambiate il ROAS target durante questo periodo; lasciatelo stabilizzare, poi ricalibrate.

Checkpoint di rollout da monitorare:

• Fine settimana 1: conversion action esistono in Google Ads, tassonomia documentata, ROAS baseline misurato
• Fine settimana 2: conversioni test visibili nel tab Google Ads Uploads, nessun errore nei log webhook
• Fine settimana 3: conversioni live in flusso, dashboard di riconciliazione entro tolleranza 5 %, rimborsi processati come RETRACT/RESTATE correttamente
• Fine settimana 4: Smart Bidding cambiato, periodo learning iniziato, team formato sulle nuove dashboard

Oltre il giorno 30 — operazioni in corso:

Eseguite un audit di attribuzione trimestrale. Confrontate il revenue riportato Google Ads con il revenue incassato Stripe per la stessa finestra. I due dovrebbero concordare entro il 5 %; un gap più grande indica fallimenti di cattura GCLID, bug di gestione rimborsi o scadenze di finestra di attribuzione. Per account sotto 50 k€/mese, questo può essere un task di 1 ora ogni trimestre. Per account sopra 100 k€/mese, costruitelo nel middleware BigQuery come report di riconciliazione settimanali automatizzati.

Se state gestendo Google Ads alla scala e volete ottimizzazione AI-driven stratificata sopra dati di conversione importati Stripe puliti, SteerAds esegue un audit gratuito di 14 giorni sui vostri account Google Ads + Microsoft Ads inclusi un check della salute del vostro import conversioni.

Per contesto più ampio su attribuzione e misurazione conversioni, vedi la nostra guida attribuzione data-driven vs last-click 2026 e la guida Google Ads conversion tracking server-side 2026 per pattern di implementazione adiacenti.

Fonti

Fonti ufficiali e di terze parti consultate per questa guida:

• developers.google.com/google-ads/api

  — documentazione API Google Ads ConversionUploadService

• docs.stripe.com/webhooks

  — riferimento webhook Stripe e tipi evento

• support.google.com/google-ads

  — help import conversioni offline e documentazione finestra 90 giorni

• developers.google.com/google-ads/api/conversions/upload-adjustments

  — API conversion adjustment per rimborsi

• docs.stripe.com/api/balance_transactions

  — riferimento BalanceTransaction per tassi di cambio valuta

Letture correlate: Generazione di immagini AI per Google Ads 2026: Midjourney, DALL-E e creatività pubblicitarie · BigQuery + Google Ads data pipeline 2026: costruire il proprio data warehouse di reporting · Consent Mode v2 implementazione 2026: configurazione obbligatoria SEE per Google Ads + GA4 · Dynamic Creative Optimization in Google Ads 2026: setup e strategia DCO · Enhanced Conversions per Google Ads 2026: recuperare il 5–15% di attribuzione persa · GA4 + Google Ads conversion import setup 2026: guida completa di implementazione in 30 giorni

FAQ