Stripe Revenue → Google Ads: importar conversões (tutorial) 2026

Para a maioria dos founders e equipas de growth SaaS a correr Google Ads em 2026, a lacuna entre o ROAS que o Google Ads reporta e a receita que a Stripe efectivamente cobrou está algures entre 20 % e 70 %. Conversões web pixel disparam em intenção de checkout (clique de botão, carregamento de página); não sabem sobre cartões falhados, bounces de dunning, reembolsos, disputas fraudulentas ou trials que nunca converteram. O Smart Bidding optimiza contra o sinal que lhe dá — e se esse sinal é intenção bruta de checkout em vez de receita líquida cobrada, o algoritmo escala gasto na direcção errada.

Este guia percorre a integração técnica e operacional completa: capturar o Google Click ID (GCLID) em cada página de checkout, armazená-lo em metadata de customer ou charge Stripe, subscrever os eventos webhook certos, chamar a Google Ads ConversionUploadService API com a acção de conversão e valor correctos, gerir contas Stripe multi-moeda e ligar reembolsos e disputas através da API de ajuste de conversão. Fechamos com um padrão middleware BigQuery para contas de alto volume e um rollout de implementação de 30 dias.

Por que a importação de conversões Stripe → Google Ads importa em 2026

Três tendências em 2026 tornam esta integração mais importante do que era em 2022:

1. O Smart Bidding agora consome essencialmente todo o gasto de conta. Segundo o reporting de transparência 2025 da Google, mais de 85 % do gasto Google Ads em contas activas em 2026 flui através de estratégias de licitação driven por sinal de conversão — Maximize Conversions, Maximize Conversion Value, Target CPA e Target ROAS. A estratégia de licitação é só tão precisa como os dados de conversão que recebe. Contas CPC manual podem tolerar sinal de conversão ruidoso porque humanos revêem cada licitação; o Smart Bidding não pode. Se os seus dados de conversão sobre-reportam em 30 %, o Smart Bidding gasta 30 % mais do que deveria em licitações que parecem lucrativas mas não são.

2. A depreciação dos cookies de terceiros de 2024 acelerou a importância do GCLID. À medida que o tracking browser-side se degrada, a importação de conversões server-side via GCLID torna-se a ponte mais fiável entre um clique de anúncio e uma conversão a jusante. A Stripe é a fonte natural da verdade para eventos de receita porque está na camada de settlement financeiro, pós-validação-de-método-de-pagamento. Atribuição pixel-based vai continuar a enfraquecer ao longo de 2026-2027; atribuição server-side baseada em Stripe mantém-se precisa.

3. Licitação baseada em ROAS exige input honesto de receita. A estratégia de licitação Target ROAS do Google Ads funciona prevendo valor de conversão por clique e licitando a um rácio alvo valor-para-custo. Se os valores que está a prever incluem receita reembolsada, receita de trial falhado e cobranças disputadas, as previsões são sistematicamente altas — e a licitação ultrapassa. Importação Stripe é o único mecanismo que dá ao Google Ads receita líquida ground-truth à granularidade de valor de conversão que o Target ROAS precisa.

A integração não é infraestrutura opcional para SaaS sérios em 2026; é o piso abaixo do qual o Smart Bidding não funciona correctamente.

O fluxo de dados em panorama: GCLID → Stripe → Google Ads

O fluxo de dados end-to-end é simples em conceito e cheio de casos limite em execução. Os cinco passos:

Passo 1 — Clique: Um utilizador clica no seu anúncio Google. O autotagging Google Ads acrescenta ?gclid=ABC123... ao URL de destino. O GCLID é um token único ligado a esse clique, válido por 90 dias para atribuição de conversão em campanhas Search/Display.

Passo 2 — Captura: A sua página de aterragem lê o parâmetro query gclid e persiste-o. Dois padrões de persistência: cookie (first_touch_gclid por 90 dias), ou armazenamento backend key-ed por session ID anónimo depois user ID após signup.

Passo 3 — Checkout: Quando o utilizador chega ao Stripe Checkout (ou ao formulário Stripe Elements na sua própria página), passe o GCLID armazenado como campo metadata na criação de Checkout Session, no PaymentIntent ou no objecto Customer. Isto liga o GCLID ao evento financeiro.

Passo 4 — Cobrança bem-sucedida: A Stripe processa o pagamento. Em settlement bem-sucedido (charge.succeeded), a Stripe dispara um webhook para o seu endpoint. O payload webhook contém o charge ID, montante, moeda, customer ID e metadata (incluindo o GCLID que armazenou).

Passo 5 — Upload para Google Ads: O seu handler webhook chama o endpoint Google Ads API ConversionUploadService.UploadClickConversions, passando GCLID, nome de recurso da acção de conversão, timestamp de conversão, valor de conversão e código de moeda. O Google Ads faz match do GCLID ao clique original, atribui a conversão e actualiza reporting e inputs de Smart Bidding.

Os erros mais comuns no passo 5 são: upload em checkout.session.completed em vez de charge.succeeded (falha falhas de pagamento), upload do montante bruto em vez de líquido de taxas Stripe (depende da sua preferência contabilística) e não gerir conversão de moeda quando cobranças Stripe e contas Google Ads estão em moedas diferentes.

Captar GCLID em metadata de customer ou charge Stripe

O primeiro passo técnico é capturar GCLID de forma fiável à data do clique e ligá-lo ao evento financeiro na Stripe. Três padrões de implementação por complexidade:

Padrão A — Metadata Stripe Checkout Session (mais simples):

Quando cria a Checkout Session server-side, passe o GCLID como 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",
});

Prós: zero armazenamento backend, metadata viaja com a sessão para sempre. Contras: valores metadata Stripe são limitados a 500 chars cada e o GCLID deve estar disponível no momento de criação da sessão (cookie definido na página de aterragem).

Padrão B — Metadata de objecto Customer (melhor para renovações de subscrição):

Armazene o GCLID no objecto Customer no primeiro signup. Todas as cobranças futuras desse customer herdam a atribuição:

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(),
  },
});

Prós: funciona para facturação recorrente (cada invoice.payment_succeeded herda o GCLID do customer). Contras: capta apenas first-touch GCLID, não last-touch — para SaaS com vários touchpoints de clique de anúncio ao longo de um ciclo de venda longo, pode querer actualizar o GCLID em cada novo clique.

Padrão C — A sua própria base de dados, junta à data do webhook:

Armazene GCLID na sua própria base de dados key-ed por user_id ou session_id. Quando o webhook Stripe dispara para charge.succeeded, procure o GCLID armazenado do utilizador e passe-o para Google Ads:

# No seu 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)

Prós: mais flexível, suporta atribuição last-touch, suporta janelas de atribuição multi-clique. Contras: exige infra-estrutura backend, mais modos de falha.

Boa prática — capture os três click IDs da era iOS:

Autotagging Google Ads moderno emite gclid para a maioria do tráfego, mais gbraid para campanhas iOS App e wbraid para tráfego iOS web quando ATT-restricted. Capte os três. A Google Ads upload API tem endpoints separados para cada um (UploadCallConversions, UploadClickConversions); use gclid onde presente, faça fallback para gbraid/wbraid para tráfego iOS.

Configurar a acção de conversão Google Ads para tracking de valor

Antes que qualquer código de upload possa ter sucesso, precisa de criar as acções de conversão em Google Ads que os uploads vão visar. Em Ferramentas > Conversões > Nova acção de conversão, escolha «Importação» como fonte, depois «Outras fontes de dados ou CRMs» > «Track conversões de cliques».

Três acções de conversão para criar para uma integração Stripe SaaS standard:

Acção 1 — Stripe Trial Start (opcional mas recomendada):

• Categoria: Sign-up
• Valor: Não usar valor
• Contagem: Uma
• Janela click-through: 90 dias
• Janela view-through: 1 dia
• Incluir em Conversões: Não (inicialmente — passe para Sim depois da primeira paid charge disparar para o mesmo utilizador)

Acção 2 — Stripe First Paid Charge (a acção primária):

• Categoria: Compra
• Valor: Usar valores diferentes para cada conversão
• Contagem: Uma (uma conversão por clique — a primeira paid charge)
• Janela click-through: 90 dias
• Janela view-through: 1 dia
• Incluir em Conversões: Sim (é para isto que o Smart Bidding optimiza)
• Modelo de atribuição: Data-driven (default em 2026)

Acção 3 — Stripe Expansion Revenue (para upsells, upgrades de plano, seats adicionais):

• Categoria: Compra
• Valor: Usar valores diferentes para cada conversão
• Contagem: Cada (múltiplas expansões por clique podem todas contar)
• Janela click-through: 90 dias
• Janela view-through: 1 dia
• Incluir em Conversões: Sim (aditivo a First Paid Charge em Smart Bidding)

Para cada acção de conversão, note o Conversion Action ID (um nome de recurso como customers/1234567890/conversionActions/9876543210). Vai passar isto à upload API como conversion_action.

Definir «Usar valores diferentes para cada conversão» é crítico para o caso de uso de receita Stripe. Sem ele, cada conversão é upload-ed com o mesmo valor fixo (o «valor por defeito» que definiu na acção). O Smart Bidding não consegue diferenciar um signup de plano básico 15 €/mês de um signup enterprise 1.500 €/mês se todas as conversões têm o mesmo valor. Seleccione sempre a opção «valores diferentes» para acções de receita Stripe-importadas.

Construir o listener webhook (exemplos Node.js + Python)

O listener webhook tem três responsabilidades: verificar a assinatura webhook Stripe (segurança), parsear o payload do evento e chamar o endpoint Google Ads API apropriado. Abaixo estão implementações mínimas em Node.js e Python — ambas production-ready em forma mas aparadas para clareza.

Implementação 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");
});

Implementação 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 crítico de produção a adicionar:

• Idempotência: faça cache de IDs de eventos Stripe processados por 24h, salte eventos duplicados
• Re-tentativa exponential backoff em erros Google Ads API 5xx (3 retries: 1s, 5s, 25s)
• Dead-letter queue para uploads permanentemente falhados (rever semanalmente)
• Logging estruturado de cada upload (charge_id, gclid, conversion_value, response_code)
• Alertas quando a taxa de erro excede 1 % numa janela rolling de 1 hora

Gestão de moedas, reembolsos e ajustes de conversão

As duas dores de cabeça operacionais que descarrilam a maioria das integrações Stripe-to-Google são normalização de moeda e gestão de reembolsos. Ambas devem ser resolvidas antes que o Smart Bidding funcione correctamente.

Normalização de moeda:

Contas Google Ads têm uma única moeda definida na criação. Todos os valores de conversão upload-ed devem ser nessa moeda. Contas Stripe podem cobrar em 135+ moedas. A lógica de reconciliação:

1. Se charge.currency Stripe corresponde à moeda de conta Google Ads → use charge.amount directamente (após dividir por 100 para a convenção cents-to-units)
2. Se charge.currency Stripe difere → use o amount e exchange_rate da BalanceTransaction Stripe para converter
3. Se BalanceTransaction ainda não está disponível (race condition logo após charge.succeeded) → consulte uma API de taxa FX externa no timestamp da cobrança

Pseudo-código para o caminho seguro:

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']

Gestão de reembolsos via UploadConversionAdjustments:

Quando a Stripe dispara charge.refunded, deve ajustar a conversão Google Ads correspondente. A API de ajuste aceita duas operações:

• RETRACT: remove a conversão original inteiramente (use para reembolsos completos)
• RESTATE: muda o valor de conversão (use para reembolsos parciais — passe o novo valor, mais baixo)

Ambas as operações exigem: GCLID original, nome de recurso da acção de conversão, data-tempo de conversão original (deve corresponder exactamente) e o timestamp de ajuste.

// 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(),
          },
    },
  ],
});

A janela de ajuste de 55 dias: o Google Ads apenas aceita ajustes dentro de 55 dias do timestamp de conversão original. Reembolsos para além de 55 dias não podem ser reflectidos em Google Ads. Para SaaS com janelas de reembolso longas (garantias money-back de 90 dias, reembolsos de subscrição anual a meio do ano), esta é uma lacuna estrutural — vai precisar de reconciliar manualmente em reporting Looker / GA4 e aceitar que o Smart Bidding está a operar com números ligeiramente obsoletos numa pequena percentagem de conversões.

Disputas e chargebacks: subscreva charge.dispute.created. Se reason é «fraudulent» ou «credit_not_processed», trate como reembolso completo (RETRACT). Se «duplicate» ou «subscription_canceled», siga as suas próprias regras de negócio — geralmente também trate como reembolso completo para efeitos de atribuição de anúncios.

Opção de middleware BigQuery para contas de alto volume

Para SaaS a fazer mais de 10.000 conversões/mês ou a correr contas Google Ads multi-produto, multi-região, o padrão direct-webhook começa a esforçar-se. O padrão middleware BigQuery adiciona 5 minutos de latência mas resolve vários problemas de uma só vez.

A arquitectura:

1. Webhooks Stripe → Cloud Function (Node.js ou Python) → tabela BigQuery de eventos crus
2. Query agendada BigQuery (a cada 5 minutos) → lê novos eventos, calcula records de conversão, chama Google Ads API
3. Vistas materializadas BigQuery → dashboards de reconciliação, tracking de reembolsos, debugging de atribuição

A Cloud Function não faz quase nada — apenas valida a assinatura Stripe e escreve o evento cru para BigQuery. A query agendada detém toda a lógica de conversão, o que significa que pode actualizar lógica editando SQL em vez de fazer deploy de código.

Schema para a tabela de eventos crus:

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;

A query agendada corre a cada 5 minutos:

-- 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

Por que o padrão middleware BigQuery vence a escala:

• Capacidade de replay: se a Google Ads API tem uma queda, eventos crus ficam em BigQuery e podem ser re-uploaded mais tarde
• Ledger auditável: o estado, timestamp e resposta de cada upload são consultáveis
• Mais barato a escala: chamadas API em batch custam menos do que chamadas per-event (Google Ads API tem rate limits e quotas)
• Routing multi-conta: encaminhe conversões para a conta Google Ads certa baseado no produto ou região Stripe — fácil em SQL, complexo em código webhook
• Dashboards de reconciliação: BigQuery → dashboards Looker a mostrar receita Stripe vs receita importada Google Ads, atraso de reembolso, mismatches de moeda

A desvantagem: 5 minutos de latência vs sub-segundo para webhooks directos. Para o loop de aprendizagem do Smart Bidding, latência de 5 minutos é invisível — o Smart Bidding actualiza diariamente, não em tempo real.

Para padrões mais profundos de pipeline BigQuery específicos para dados de anúncios, veja o nosso tutorial pipeline de dados BigQuery Google Ads.

Plano de implementação de 30 dias com checkpoints de rollout

O schema HowTo acima é o dia-a-dia. Enquadramento estratégico para o rollout de 30 dias:

Semana 1 — Auditoria e design (Dias 1-7). Documente o estado actual: como as conversões disparam actualmente, qual o ROAS reportado, qual a receita Stripe real para a mesma janela. A lacuna é o que está prestes a corrigir. Defina a taxonomia de conversão (Trial Start, First Paid, Expansion). Crie as acções de conversão Google Ads mas não as inclua em Conversões ainda — estão inactivas até os dados fluírem.

Semana 2 — Implementação (Dias 8-15). Adicione captura GCLID a páginas de aterragem. Ligue Stripe Checkout para passar GCLID como metadata. Construa o listener webhook para charge.succeeded. Teste contra uma conta de teste Google Ads com GCLIDs sintéticos. Valide que conversões de teste aparecem no tab Uploads do Google Ads dentro de 5 minutos.

Semana 3 — Hardening (Dias 16-22). Adicione normalização de moeda. Ligue webhooks charge.refunded e charge.dispute.created a UploadConversionAdjustments. Adicione idempotência, lógica de retry e dead-letter queue. Suba o dashboard de reconciliação Stripe-vs-Google. Corra-o por 7 dias contra dados live sem ainda mudar o Smart Bidding para a nova acção de conversão.

Semana 4 — Switchover e tuning (Dias 23-30). Passe «Incluir em Conversões» na acção Stripe First Paid Charge. Desligue-o na acção web pixel antiga. Mude a conversão primária do Smart Bidding para Stripe First Paid Charge. Espere 14-30 dias de volatilidade de licitação à medida que o algoritmo reconstrói o seu modelo. Não mude ROAS alvo durante este período; deixe-o estabilizar, depois recalibre.

Checkpoints de rollout a monitorizar:

• Fim da semana 1: acções de conversão existem em Google Ads, taxonomia documentada, ROAS baseline medido
• Fim da semana 2: conversões de teste visíveis no tab Uploads do Google Ads, sem erros em logs de webhook
• Fim da semana 3: conversões live a fluir, dashboard de reconciliação dentro de 5 % de tolerância, reembolsos a processar como RETRACT/RESTATE correctamente
• Fim da semana 4: Smart Bidding mudado, período de aprendizagem iniciado, equipa treinada nos novos dashboards

Para além do dia 30 — operações em curso:

Corra uma auditoria de atribuição trimestral. Compare a receita Google Ads reportada com a receita Stripe cobrada para a mesma janela. As duas devem concordar dentro de 5 %; uma lacuna maior indica falhas de captura GCLID, bugs de gestão de reembolso ou expirações de janela de atribuição. Para contas abaixo de 50 k€/mês, isto pode ser uma tarefa de 1 hora a cada trimestre. Para contas acima de 100 k€/mês, construa-a no middleware BigQuery como relatórios de reconciliação semanais automatizados.

Se está a gerir Google Ads a escala e quer optimização AI-driven sobreposta a dados de conversão Stripe-importados limpos, a SteerAds executa uma auditoria gratuita de 14 dias às suas contas Google Ads + Microsoft Ads incluindo uma verificação da saúde da sua importação de conversões.

Para contexto mais amplo sobre atribuição e medição de conversão, veja o nosso guia de atribuição data-driven vs last-click 2026 e o guia de tracking de conversão Google Ads server-side 2026 para padrões de implementação adjacentes.

Fontes

Fontes oficiais e de terceiros consultadas para este guia:

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

  — documentação Google Ads API ConversionUploadService

• docs.stripe.com/webhooks

  — referência de webhook Stripe e tipos de eventos

• support.google.com/google-ads

  — ajuda de importação de conversões offline e documentação da janela de 90 dias

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

  — API de ajuste de conversão para reembolsos

• docs.stripe.com/api/balance_transactions

  — referência BalanceTransaction para taxas de câmbio

Leituras relacionadas: Geração de imagens com IA para Google Ads 2026: Midjourney, DALL-E e criativos · BigQuery + Google Ads data pipeline 2026: construa o seu data warehouse de reporting · Implementação do Consent Mode v2 2026: configuração obrigatória no EEE para Google Ads + GA4 · Dynamic Creative Optimization no Google Ads 2026: configuração e estratégia DCO · Enhanced Conversions para Google Ads 2026: recupere 5–15 % de atribuição perdida · GA4 + Google Ads conversion import setup 2026: guia completo de implementação em 30 dias

FAQ