Stripe Revenue → Google Ads: importar conversiones (tutorial) 2026

Para la mayoría de fundadores SaaS y equipos de growth ejecutando Google Ads en 2026, la brecha entre el ROAS que Google Ads reporta y los ingresos que Stripe realmente cobró está en algún punto entre el 20 % y el 70 %. Las conversiones de web pixel se disparan en la intención de checkout (clic de botón, page load); no saben sobre tarjetas fallidas, rebotes de dunning, reembolsos, disputas fraudulentas, o trials que nunca convirtieron. Smart Bidding optimiza contra la señal que le das — y si esa señal es intención bruta de checkout en vez de ingresos netos cobrados, el algoritmo escala inversión en la dirección equivocada.

Esta guía recorre la integración técnica y operativa completa: capturar el Google Click ID (GCLID) en cada página de checkout, almacenarlo en metadata customer o charge de Stripe, suscribirse a los eventos webhook correctos, llamar la API Google Ads ConversionUploadService con la conversion action y valor correctos, manejar cuentas Stripe multi-divisa, y conectar reembolsos y disputas vía la API de conversion adjustment. Cerramos con un patrón middleware BigQuery para cuentas de alto volumen y un despliegue de implementación de 30 días.

Por qué la importación de conversiones Stripe → Google Ads importa en 2026

Tres tendencias en 2026 hacen esta integración más importante de lo que era en 2022:

1. Smart Bidding ahora consume esencialmente toda la inversión de la cuenta. Según los informes de transparencia 2025 de Google, más del 85 % de la inversión Google Ads en cuentas activas en 2026 fluye a través de estrategias de puja impulsadas por señal de conversión — Maximize Conversions, Maximize Conversion Value, Target CPA, y Target ROAS. La estrategia de puja es solo tan precisa como los datos de conversión que recibe. Las cuentas Manual CPC pueden tolerar señal de conversión ruidosa porque humanos revisan cada puja; Smart Bidding no puede. Si sus datos de conversión sobreinforman un 30 %, Smart Bidding invierte un 30 % más de lo que debería en pujas que parecen rentables pero no lo son.

2. La depreciación de cookies de terceros de 2024 aceleró la importancia del GCLID. A medida que el tracking del lado navegador se degrada, la importación server-side de conversiones vía GCLID se convierte en el puente más fiable entre un clic publicitario y una conversión downstream. Stripe es la fuente natural de verdad para eventos de ingreso porque se sitúa en la capa de settlement financiero, post-validación del método de pago. La atribución basada en pixel seguirá debilitándose a lo largo de 2026-2027; la atribución server-side basada en Stripe permanece precisa.

3. La puja basada en ROAS requiere input honesto de ingresos. La estrategia de puja Target ROAS de Google Ads funciona prediciendo el valor de conversión por clic y pujando hacia un ratio target valor-a-coste. Si los valores que está prediciendo incluyen ingresos reembolsados, ingresos de trials fallidos, y cargos disputados, las predicciones son sistemáticamente altas — y la puja se pasa de largo. La importación Stripe es el único mecanismo que da a Google Ads ingresos netos ground-truth a la granularidad de conversion-value que Target ROAS necesita.

La integración no es infraestructura opcional para SaaS serios en 2026; es el piso por debajo del cual Smart Bidding no funciona apropiadamente.

El flujo de datos de un vistazo: GCLID → Stripe → Google Ads

El flujo de datos end-to-end es directo en concepto y lleno de casos límite en ejecución. Los cinco pasos:

Paso 1 — Clic: Un usuario hace clic en su Google Ad. El autotagging de Google Ads añade ?gclid=ABC123... a la URL de destino. El GCLID es un token único atado a ese clic, válido por 90 días para atribución de conversión en campañas Search/Display.

Paso 2 — Capture: Su landing page lee el query parameter gclid y lo persiste. Dos patrones de persistencia: cookie (first_touch_gclid por 90 días), o almacenamiento backend con clave de session ID anónimo y luego user ID tras signup.

Paso 3 — Checkout: Cuando el usuario llega a Stripe Checkout (o al formulario Stripe Elements en su propia página), pase el GCLID almacenado como un campo metadata en la creación del Checkout Session, el PaymentIntent, o el Customer object. Esto vincula el GCLID al evento financiero.

Paso 4 — Charge succeeds: Stripe procesa el pago. En settlement exitoso (charge.succeeded), Stripe dispara un webhook a su endpoint. El payload del webhook contiene el charge ID, importe, divisa, customer ID, y metadata (incluyendo el GCLID que almacenó).

Paso 5 — Upload a Google Ads: Su webhook handler llama el endpoint Google Ads API ConversionUploadService.UploadClickConversions, pasando GCLID, conversion action resource name, conversion timestamp, conversion value, y currency code. Google Ads hace match del GCLID con el clic original, atribuye la conversión, y actualiza informes y inputs de Smart Bidding.

Los errores más comunes en el paso 5 son: hacer upload en checkout.session.completed en vez de charge.succeeded (pierde fallos de pago), hacer upload del importe bruto en vez del neto de fees Stripe (depende de su preferencia contable), y no manejar conversión de divisa cuando los charges Stripe y las cuentas Google Ads están en divisas diferentes.

Capturar GCLID en metadata de customer o charge de Stripe

El primer paso técnico es capturar GCLID de forma fiable al momento del clic y vincularlo al evento financiero en Stripe. Tres patrones de implementación por complejidad:

Patrón A — Metadata de Stripe Checkout Session (más simple):

Cuando crea el Checkout Session server-side, pase el GCLID como un 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",
});

Pros: cero almacenamiento backend, la metadata viaja con la sesión para siempre. Cons: los valores metadata Stripe están limitados a 500 caracteres cada uno y el GCLID debe estar disponible al momento de creación de sesión (cookie configurada en landing page).

Patrón B — Metadata del Customer object (mejor para renovaciones de suscripción):

Almacene el GCLID en el Customer object en el primer signup. Todos los charges futuros de ese customer heredan la atribución:

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

Pros: funciona para facturación recurrente (cada invoice.payment_succeeded hereda el GCLID del customer). Cons: solo captura GCLID first-touch, no last-touch — para SaaS con múltiples touchpoints de ad-click a través de un ciclo de venta largo, podría querer actualizar el GCLID en cada nuevo clic.

Patrón C — Su propia base de datos, joined al momento del webhook:

Almacene GCLID en su propia base de datos con clave user_id o session_id. Cuando el webhook Stripe se dispare para charge.succeeded, busque el GCLID almacenado del usuario y páselo a Google Ads:

# In your charge.succeeded webhook handler:
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)

Pros: el más flexible, soporta atribución last-touch, soporta ventanas de atribución multi-clic. Cons: requiere infraestructura backend, más modos de fallo.

Buena práctica — capturar los tres click IDs de la era iOS:

El autotagging moderno de Google Ads emite gclid para la mayoría del tráfico, más gbraid para campañas iOS App y wbraid para tráfico web iOS cuando ATT-restringido. Capture los tres. La API de upload Google Ads tiene endpoints separados para cada uno (UploadCallConversions, UploadClickConversions); use gclid donde esté presente, fallback a gbraid/wbraid para tráfico iOS.

Configurar la acción de conversión de Google Ads para tracking de valor

Antes de que ningún código de upload pueda tener éxito, necesita crear las conversion actions en Google Ads a las que apuntarán los uploads. En Tools > Conversions > New conversion action, elija «Import» como source, luego «Other data sources or CRMs» > «Track conversions from clicks.»

Tres conversion actions a crear para una integración Stripe SaaS estándar:

Action 1 — Stripe Trial Start (opcional pero recomendado):

• Category: Sign-up
• Value: Don't use a value
• Count: One
• Click-through window: 90 días
• View-through window: 1 día
• Include in Conversions: No (inicialmente — flip a Yes después de que el primer paid charge se dispare para el mismo usuario)

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

• Category: Purchase
• Value: Use different values for each conversion
• Count: One (una conversión por clic — el primer paid charge)
• Click-through window: 90 días
• View-through window: 1 día
• Include in Conversions: Yes (esto es hacia lo que Smart Bidding optimiza)
• Attribution model: Data-driven (por defecto en 2026)

Action 3 — Stripe Expansion Revenue (para upsells, upgrades de plan, asientos adicionales):

• Category: Purchase
• Value: Use different values for each conversion
• Count: Every (múltiples expansiones por clic pueden todas contar)
• Click-through window: 90 días
• View-through window: 1 día
• Include in Conversions: Yes (aditivo a First Paid Charge en Smart Bidding)

Para cada conversion action, anote el Conversion Action ID (un resource name como customers/1234567890/conversionActions/9876543210). Pasará esto a la API de upload como conversion_action.

Configurar «Use different values for each conversion» es crítico para el caso de uso de ingresos Stripe. Sin esto, cada conversión hace upload con el mismo valor fijo (el «default value» que configura en la action). Smart Bidding no puede diferenciar un signup de plan basic de 15 €/mes de un signup enterprise de 1500 €/mes si todas las conversiones tienen el mismo valor. Siempre seleccione la opción «different values» para actions de ingresos importados de Stripe.

Construir el listener de webhook (ejemplos Node.js + Python)

El listener de webhook tiene tres responsabilidades: verificar la firma webhook de Stripe (seguridad), parsear el event payload, y llamar el endpoint Google Ads API apropiado. Debajo hay implementaciones mínimas en Node.js y Python — ambas production-ready en forma pero recortadas para claridad.

Implementación 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");
});

Implementación 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'}

Endurecimiento de producción crítico a añadir:

• Idempotencia: cachee event IDs procesados de Stripe durante 24 h, salte eventos duplicados
• Reintento con backoff exponencial en errores Google Ads API 5xx (3 reintentos: 1s, 5s, 25s)
• Dead-letter queue para uploads permanentemente fallidos (revisar semanalmente)
• Logging estructurado de cada upload (charge_id, gclid, conversion_value, response_code)
• Alertas cuando la tasa de error exceda el 1 % en una ventana móvil de 1 hora

Manejo de divisas, reembolsos y ajustes de conversión

Los dos dolores de cabeza operativos que descarrilan la mayoría de integraciones Stripe-a-Google son la normalización de divisas y el manejo de reembolsos. Ambos deben resolverse antes de que Smart Bidding funcione correctamente.

Normalización de divisas:

Las cuentas Google Ads tienen una sola divisa configurada en la creación. Todos los valores de conversión uploaded deben estar en esa divisa. Las cuentas Stripe pueden cobrar en 135+ divisas. La lógica de conciliación:

1. Si Stripe charge.currency coincide con la divisa de cuenta Google Ads → use charge.amount directamente (después de dividir por 100 para la convención cents-a-units)
2. Si Stripe charge.currency difiere → use el amount y exchange_rate del Stripe BalanceTransaction para convertir
3. Si BalanceTransaction no está aún disponible (race condition justo después de charge.succeeded) → consulte una API FX externa al timestamp del charge

Pseudocódigo para el path 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']

Manejo de reembolsos vía UploadConversionAdjustments:

Cuando Stripe dispara charge.refunded, debe ajustar la conversión Google Ads correspondiente. La API de ajuste acepta dos operaciones:

• RETRACT: elimina la conversión original por completo (úselo para reembolsos completos)
• RESTATE: cambia el valor de conversión (úselo para reembolsos parciales — pase el nuevo valor, más bajo)

Ambas operaciones requieren: GCLID original, conversion action resource name, original conversion date-time (debe coincidir exactamente), y el 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(),
          },
    },
  ],
});

La ventana de ajuste de 55 días: Google Ads solo acepta ajustes dentro de 55 días del timestamp original de conversión. Reembolsos más allá de 55 días no pueden reflejarse en Google Ads. Para SaaS con ventanas de reembolso largas (garantías money-back de 90 días, reembolsos mid-year de suscripción anual), esta es una brecha estructural — necesitará conciliar manualmente en informes Looker / GA4, y aceptar que Smart Bidding está operando con números ligeramente obsoletos en un pequeño porcentaje de conversiones.

Disputas y chargebacks: suscríbase a charge.dispute.created. Si la razón es «fraudulent» o «credit_not_processed», tratar como reembolso completo (RETRACT). Si «duplicate» o «subscription_canceled», siga sus propias reglas de negocio — generalmente también tratar como reembolso completo para propósitos de atribución publicitaria.

Opción middleware BigQuery para cuentas de alto volumen

Para SaaS haciendo más de 10 000 conversiones/mes o ejecutando cuentas Google Ads multiproducto, multirregión, el patrón direct-webhook empieza a tensionarse. El patrón middleware BigQuery añade 5 minutos de latencia pero resuelve varios problemas a la vez.

La arquitectura:

1. Webhooks Stripe → Cloud Function (Node.js o Python) → tabla raw events BigQuery
2. Scheduled query BigQuery (cada 5 minutos) → lee nuevos eventos, computa registros de conversión, llama Google Ads API
3. Vistas materializadas BigQuery → dashboards de conciliación, tracking de reembolsos, debugging de atribución

La Cloud Function hace casi nada — solo valida la firma Stripe y escribe el evento raw en BigQuery. La scheduled query mantiene toda la lógica de conversión, lo cual significa que puede actualizar lógica editando SQL en vez de desplegar código.

Schema para la tabla de eventos 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 scheduled query se ejecuta 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 qué el patrón middleware BigQuery gana a escala:

• Capacidad de replay: si la Google Ads API tiene una caída, los eventos raw permanecen en BigQuery y pueden ser re-uploaded después
• Ledger auditable: el estado, timestamp y respuesta de cada upload es consultable
• Más barato a escala: las llamadas API por lotes cuestan menos que las llamadas por evento (Google Ads API tiene rate limits y quotas)
• Routing multi-cuenta: dirija conversiones a la cuenta Google Ads correcta basándose en producto o región Stripe — fácil en SQL, complejo en código webhook
• Dashboards de conciliación: BigQuery → dashboards Looker mostrando ingresos Stripe vs ingresos importados Google Ads, retraso de reembolsos, desajustes de divisa

El downside: 5 minutos de latencia vs sub-second para webhooks directos. Para el loop de aprendizaje de Smart Bidding, 5 minutos de latencia es invisible — Smart Bidding actualiza diariamente, no en tiempo real.

Para patrones de pipeline BigQuery más profundos específicos a datos publicitarios, vea nuestro tutorial pipeline de datos BigQuery Google Ads.

Plan de implementación de 30 días con checkpoints de despliegue

El schema HowTo anterior es el día a día. Encuadre estratégico para el despliegue de 30 días:

Semana 1 — Auditoría y diseño (Días 1-7). Documente el estado actual: cómo se disparan actualmente las conversiones, cuál es el ROAS reportado, cuáles son los ingresos reales Stripe para la misma ventana. La brecha es lo que está a punto de arreglar. Defina la taxonomía de conversión (Trial Start, First Paid, Expansion). Cree las conversion actions Google Ads pero no las incluya en Conversions todavía — están inactivas hasta que los datos fluyan.

Semana 2 — Implementación (Días 8-15). Añada captura GCLID a las landing pages. Conecte Stripe Checkout para pasar GCLID como metadata. Construya el listener webhook para charge.succeeded. Pruebe contra una cuenta de test Google Ads con GCLIDs sintéticos. Valide que las conversiones de test aparecen en la pestaña Uploads de Google Ads en 5 minutos.

Semana 3 — Endurecimiento (Días 16-22). Añada normalización de divisas. Conecte webhooks charge.refunded y charge.dispute.created a UploadConversionAdjustments. Añada idempotencia, lógica de reintento, y dead-letter queue. Levante el dashboard de conciliación Stripe-vs-Google. Ejecútelo durante 7 días contra datos en vivo sin cambiar todavía Smart Bidding a la nueva conversion action.

Semana 4 — Switchover y tuning (Días 23-30). Active «Include in Conversions» en la action Stripe First Paid Charge. Desactívelo en la action antigua web pixel. Cambie la conversión primaria de Smart Bidding a Stripe First Paid Charge. Espere 14-30 días de volatilidad de pujas mientras el algoritmo reconstruye su modelo. No cambie target ROAS durante este período; déjelo estabilizarse, luego recalibre.

Checkpoints de despliegue a monitorear:

• Fin de semana 1: conversion actions existen en Google Ads, taxonomía documentada, ROAS baseline medido
• Fin de semana 2: conversiones de test visibles en pestaña Uploads de Google Ads, sin errores en logs de webhook
• Fin de semana 3: conversiones en vivo fluyendo, dashboard de conciliación dentro del 5 % de tolerancia, reembolsos procesando como RETRACT/RESTATE correctamente
• Fin de semana 4: Smart Bidding cambiado, período de aprendizaje comenzado, equipo entrenado en los nuevos dashboards

Más allá del día 30 — operaciones continuas:

Ejecute una auditoría trimestral de atribución. Compare ingresos reportados Google Ads vs ingresos cobrados Stripe para la misma ventana. Los dos deberían concordar dentro del 5 %; una brecha mayor indica fallos de captura GCLID, bugs de manejo de reembolsos, o expiraciones de ventana de atribución. Para cuentas bajo 50 k€/mes, esto puede ser una tarea de 1 hora cada trimestre. Para cuentas sobre 100 k€/mes, constrúyala dentro del middleware BigQuery como informes semanales automatizados de conciliación.

Si está gestionando Google Ads a escala y quiere optimización impulsada por IA superpuesta sobre datos de conversión Stripe-imported limpios, SteerAds ejecuta una auditoría gratuita de 14 días sobre sus cuentas Google Ads + Microsoft Ads incluyendo una revisión de la salud de su importación de conversiones.

Para contexto más amplio sobre atribución y medición de conversión, vea nuestra guía atribución data-driven vs last-click 2026 y la guía Google Ads conversion tracking server-side 2026 para patrones de implementación adyacentes.

Sources

Fuentes oficiales y de terceros consultadas para esta guía:

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

  — Documentación Google Ads API ConversionUploadService

• docs.stripe.com/webhooks

  — Referencia webhook Stripe y tipos de eventos

• support.google.com/google-ads

  — Ayuda de importación de conversiones offline y documentación de ventana de 90 días

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

  — API de ajuste de conversión para reembolsos

• docs.stripe.com/api/balance_transactions

  — Referencia BalanceTransaction para tipos de cambio

Lecturas relacionadas: Generación de imágenes con IA para Google Ads 2026: Midjourney, DALL-E y creatividades · BigQuery + Google Ads data pipeline 2026: construye tu data warehouse de reporting · Implementación de Consent Mode v2 2026: configuración obligatoria en el EEE para Google Ads + GA4 · Dynamic Creative Optimization en Google Ads 2026: configuración y estrategia de DCO · Enhanced Conversions para Google Ads 2026: recupera entre el 5 % y el 15 % de atribución perdida · GA4 + Google Ads conversion import setup 2026: guía de implementación completa en 30 días

FAQ