Si gestionas paid acquisition para un SaaS, freemium o trial-based business en 2026, el Stripe Dashboard te dice qué revenue generaste. Lo que no te dice es cuáles de los signups de tus $50.000 en Meta Ads del mes pasado realmente convirtieron de trial a paid, cuántos se quedaron atascados en dunning al segundo mes, y qué canales de adquisición recuperan failed payments frente a los que churnean silenciosamente. La mayoría de los marketers SaaS operan sobre signup counts porque el funnel trial-to-paid y el funnel de failed payment son invisibles dentro del reporting por defecto de Stripe.

Esta guía cubre tres métodos para llevar datos de Stripe a Looker Studio en 2026, los gotchas específicos de Stripe en cada capa, y los dos dashboards de marketing SaaS que cambian cómo se mide la adquisición: el funnel de conversión de trial por canal de adquisición y la recuperación de dunning por canal de adquisición. Ninguno es una vista por defecto del Stripe Dashboard, ambos requieren cruzar datos de Stripe con tu atribución de marketing, y ambos deciden si tu paid acquisition es genuinamente rentable o solo lo parece durante treinta días.

Para la capa de marketing reporting alrededor de esto, consulta nuestro playbook de KPIs de marketing dashboard, nuestra guía existente Stripe a Google Sheets para el path spreadsheet, y nuestra guía LinkedIn Ads a Google Sheets para la fuente de paid acquisition B2B que más empresas SaaS usan. Este post se centra específicamente en Looker Studio y en el ángulo del subscription funnel. Una nota rápida sobre nomenclatura: Google renombró Looker Studio de vuelta a Data Studio a principios de 2026, pero en search behavior y en uso diario la mayoría de marketers lo siguen llamando Looker Studio, así que ese es el nombre que usamos aquí. El producto, el ecosistema de connectors y el pricing no han cambiado.

Dónde vive el subscription funnel en Stripe

Antes de elegir un método, conviene saber qué expone Stripe y dónde se esconden los campos relevantes. El funnel trial-to-paid y el funnel de dunning se extienden por varios objetos de Stripe.

• Customer. El registro top-level. Lleva la fecha created (tu timestamp equivalente al signup), metadata (donde la mayoría de equipos almacena el canal de adquisición o UTM source), y enlaces a subscriptions, charges, invoices y payment methods.
• Subscription. El registro de suscripción. Lleva status (trialing, active, past_due, canceled, unpaid, incomplete), fechas trial_start y trial_end, start_date, canceled_at, y el objeto estructurado cancellation_details con campos reason y feedback poblados por tus surveys de churn.
• Invoice. El artefacto de facturación. Lleva attempt_count (cuántas veces Stripe reintentó un failed payment), next_payment_attempt, y status (draft, open, paid, void, uncollectible). El funnel de dunning vive dentro de invoice attempt counts y status transitions.
• PaymentIntent. El intento de pago. Lleva status (succeeded, requires_payment_method, canceled) y last_payment_error.code, que te dice si el fallo fue card declined, insufficient funds, expired card o fraud block. La recovery rate varía drásticamente por failure reason.
• Charge. El pago exitoso. Donde se registra el revenue real con currency, refund history e información de disputas.

Para la historia de marketing acquisition, la pieza crítica es el campo metadata en Customer (o Subscription) donde tu signup form estampa el canal de adquisición. Si tu signup form no escribe en metadata, estás volando a ciegas. Stripe no infiere el canal de marketing desde ningún otro lado.

Método 1: Export manual CSV desde el Stripe Dashboard

Para auditorías puntuales, snapshots mensuales para el board, o antes de tener un reporting setup real. Rápido, gratis, frágil en cuanto necesitas segmentación.

Setup: en Stripe Dashboard, ve a Customers, Subscriptions o Invoices. Click en Export. Elige CSV. Elige rango de fechas. Descarga. Abre en Sheets. Cruza manualmente entre exports si necesitas vista completa del funnel.

Gotchas específicos de Stripe en esta capa:

• Cada export es un único tipo de objeto. Un funnel trial-to-paid necesita customers, subscriptions Y invoices cruzados. Eso son tres exports por snapshot, más gimnasia de VLOOKUP en Sheets para juntarlos.
• Metadata no está incluido en los exports por defecto. Tu campo custom de canal almacenado en metadata típicamente requiere o la capa Sigma SQL o la API. El export CSV por defecto de Stripe te da solo campos canónicos.
• Sin refresh incremental. Cada export es una descarga fresca desde cero. Construir una cadencia semanal significa acumular snapshots hacia adelante tú mismo en Sheets.
• Las cancellation reasons requieren survey activa. El campo cancellation_details.reason solo se rellena cuando has configurado el cancellation survey del Stripe Billing Portal. La mayoría de equipos lo configura una vez y se olvida; verifica que las respuestas del survey se están capturando antes de construir un dashboard de churn-by-reason.

Cuándo encaja este método: snapshot para el board, revisión trimestral, auditoría antes de invertir en tooling real.

Cuándo no: cualquier dashboard que refresque más que mensualmente, cualquier cosa que cruce Stripe con tu inversión en paid media, cualquier cosa que segmente por canal de adquisición.

Método 2: Apps Script con la API de Stripe

El path DIY para un equipo de marketing SaaS o RevOps cómodo con algo de código. El setup la primera vez son 45-90 minutos, luego 20-30 minutos por cada report adicional. El resultado aterriza en Sheets, que luego se conecta a Looker Studio como data source.

Paso 1. Genera una API key restringida de Stripe. En Stripe Dashboard: Developers, luego API keys, luego Create restricted key. Configura scope a read access en Customers, Subscriptions, Invoices, Charges y PaymentIntents únicamente. Nunca uses una secret key completa para workflows de lectura; las restricted keys están scoped y son revocables.

Paso 2. En tu Google Sheet, abre Extensions, luego Apps Script y pega un script con esta estructura:

function exportStripeSubscriptionsWithChannel() {
  const STRIPE_KEY = 'rk_live_YOUR_RESTRICTED_KEY';
  const baseUrl = 'https://api.stripe.com/v1/subscriptions';
  const headers = {
    'Authorization': 'Bearer ' + STRIPE_KEY,
    'Stripe-Version': '2024-09-30.acacia'
  };

  const sheet = SpreadsheetApp.getActiveSheet();
  sheet.clear();
  sheet.appendRow(['Subscription ID', 'Customer ID', 'Status', 'Trial Start', 'Trial End', 'Start Date', 'Canceled At', 'Cancellation Reason', 'Acquisition Channel']);

  let url = baseUrl + '?limit=100&expand[]=data.customer';
  while (url) {
    const response = UrlFetchApp.fetch(url, { headers: headers, muteHttpExceptions: true });
    const data = JSON.parse(response.getContentText());
    (data.data || []).forEach(sub => {
      const channel = (sub.customer && sub.customer.metadata) ? sub.customer.metadata.acquisition_channel : '';
      const reason = (sub.cancellation_details) ? sub.cancellation_details.reason : '';
      sheet.appendRow([sub.id, sub.customer.id, sub.status, sub.trial_start, sub.trial_end, sub.start_date, sub.canceled_at, reason, channel]);
    });
    url = data.has_more ? baseUrl + '?limit=100&starting_after=' + data.data[data.data.length - 1].id + '&expand[]=data.customer' : null;
  }
}

La API reference de Stripe documenta todos los endpoints, parámetros expand y patterns de paginación. Los docs de API versioning explican cómo funciona el header Stripe-Version. Para detalles de comportamiento de dunning, consulta la documentación de Smart Retries de Stripe.

Paso 3. Conecta el Sheet a Looker Studio. En Looker Studio: Create, luego Data source, luego Google Sheets connector, apunta a tu Stripe sheet, click Connect. El refresh schedule es configurable desde Looker Studio; el Apps Script trigger maneja el refresh subyacente desde Stripe.

Paso 4. Programa el Apps Script. Apps Script, Triggers, Add Trigger, ejecuta tu función diariamente antes del check-in del equipo.

Gotchas específicos de Stripe en la capa API:

• El versioning de la API importa más de lo que crees. El header Stripe-Version pinea qué versión de la API llamas. Pinea una versión (una revisión datada de 2025 o principios de 2026 es el estándar actual) y mantente en ella. Cuando Stripe deprecia una, te dan una ventana larga de migración, pero no es para siempre.
• Los rate limits existen pero son generosos. Stripe documenta aproximadamente 100 read operations por segundo en live mode y 25 por segundo en test mode. No los vas a tocar con workloads típicos de reporting. Implementa retry-on-429 igualmente por seguridad; los bursts raros pasan.
• La paginación es cursor-based con starting_after. Stripe no pagina por número de página; pasas el último ID de objeto de la página anterior. El campo has_more señala el final. Si omites la lógica de paginación solo obtienes los primeros 100 records.
• Usa expand para inlinear objetos relacionados. Por defecto, el campo customer en una subscription es solo un customer ID. Para obtener el metadata, pasa expand[]=data.customer. Cada nivel de expand añade latency; no expandas más de dos niveles de profundidad.
• Las restricted keys son scoped y revocables. Si tu script se compromete, revocas la restricted key en el Dashboard y nada más se rompe. Nunca uses la secret key sin restricciones (sk_live_ con full access) en spreadsheets, repositorios o endpoints no gestionados.
• Test mode versus live mode son separados. El prefijo rk_test_ consulta data de test; rk_live_ consulta producción. Confundirlos es el error pre-launch más común. El Stripe Dashboard tiene un toggle arriba a la derecha; el prefijo de la API key debe coincidir con el modo que pretendes.
• Límite de ejecución de Apps Script. Workspace Free: 6 minutos por ejecución. Workspace de pago: 30 minutos. Extraer un año de subscriptions más customer expansion más invoices puede pasar de los 6 minutos. Solución: procesa por chunks mensuales, o mueve el workflow a Cloud Functions si necesitas runs más largos.

Método 3: Conector no-code programado

El path para equipos de marketing SaaS que quieren datos de Stripe en Looker Studio de forma programada sin código, sin mantenimiento de API, y con el campo de canal de adquisición ya alineado. Setup en menos de 10 minutos.

Dataslayer conecta Stripe a Looker Studio vía el flujo de Stripe restricted API key. El conector consulta la misma API de Stripe que el script manual, pero expone subscription status, cancellation reasons, subscription metadata, trial dates e invoice status como dimensiones nativas consultables en tu data source de Looker Studio. Apuntas Looker Studio al conector Dataslayer, eliges los campos, y el dashboard se refresca en el schedule que configures.

Por qué importa un conector específicamente para reporting de marketing SaaS:

• Estados del subscription funnel como campos nativos. Status, trial_start, trial_end, canceled_at y cancellation_reason vienen como dimensiones que puedes pivotar directamente. Sin parsing de JSON, sin sintaxis de expand path.
• Subscription metadata expuesto como campos. Si estampas el canal de adquisición en subscription.metadata al signup (además de en customer.metadata), el conector lo expone como dimensión nativa que puedes pivotar directamente. Ese es el campo que te permite segmentar trial conversion por canal sin trabajo de extracción de JSON; la extracción nativa de customer metadata está en el roadmap del conector.
• Cruzado con paid media en un workbook. Una vez que Stripe y Meta Ads o LinkedIn Ads alimentan Looker Studio vía la misma capa de connector, el CAC blended por canal está a un campo calculado de distancia.
• Past invoice retrieval es opt-in. El conector expone un setting para extraer invoices históricos (con el coste de API que eso implica). Para dashboards continuos no lo necesitas; para hacer backfill de un año de data de dunning una vez, lo activas.

Costes: el plan gratis cubre un conector y un usuario; los planes de pago escalan a múltiples cuentas Stripe en un workspace. Precios actualizados aquí.

El gotcha de Stripe que NINGÚN método arregla: si tu signup form no escribe el canal de adquisición en metadata en el momento de creación del customer, ningún dashboard puede recuperar el dato. Arregla el signup form primero. Estampa utm_source, utm_medium, utm_campaign y landing_page como campos separados en customer.metadata, y copia los mismos valores en subscription.metadata cuando se cree la subscription. La mayoría de conectores de reporting exponen el subscription metadata como dimensiones nativas consultables, mientras que el customer metadata vive típicamente dentro del objeto JSON del customer y requiere trabajo de extracción. Haz esto antes de construir cualquiera de los dashboards de este post.

Los 2 dashboards de marketing SaaS que merecen la pena

Una vez los datos de Stripe fluyen a Looker Studio con el campo de canal de adquisición alineado, estos dos reports cambian cómo los equipos de marketing SaaS miden paid acquisition. Ninguno es una vista por defecto del Stripe Dashboard, ambos requieren el metadata stamping de arriba, y ambos responden preguntas que el signup count solo esconde.

Dashboard 1: Funnel de trial conversion por canal de adquisición

La pregunta: de los 1.200 trial signups que Meta Ads trajo el mes pasado, ¿cuántos realmente convirtieron a paid en el día 14, y cómo se compara esa conversion rate con LinkedIn Ads u organic search? ¿Cuál es el verdadero CAC después de factorizar la conversión trial-to-paid, no solo el signup count?

Etapas del funnel a extraer de Stripe:

• Customers creados (día cero, por canal de adquisición)
• Subscriptions con status = trialing (trial activo)
• Subscriptions donde trial_end ya pasó y status transicionó a active (conversión trial-to-paid)
• Subscriptions donde trial_end pasó y status = canceled (drop-off del trial)

Columnas a extraer de Meta Ads, LinkedIn Ads o Google Ads:

• Campaign ID, daily spend, conversions reportadas por la plataforma
• UTM source/medium en la landing page que mapea al metadata.acquisition_channel de Stripe

Cálculos en Looker Studio (o en el Sheet que lo alimenta):

• Trial conversion rate por canal: COUNT(status = active AND trial_end < today) ÷ COUNT(trial_start <= today - 14)
• True CAC por canal: SUM(channel_spend) ÷ COUNT(active paid subscriptions desde ese canal)
• CAC payback period: CAC ÷ (MRR medio por customer para ese canal)

Layout de Looker Studio:

• Time-series chart: trial signups semanales, trial conversions y conversion rate por canal
• Bar chart: True CAC por canal (ordenado ascendente)
• Scorecard: CAC payback period blended en meses
• Filter controls: rango de fechas, multi-select de canal

Lo que este dashboard surfacea que los signup counts esconden:

• Canales con alto volumen de signups pero pobre conversión trial-to-paid (tu Meta Ads creative que convierte a free trial signup a buen coste pero donde casi nadie paga)
• Canales con bajo volumen de signups pero excelente conversión trial-to-paid (la fuente high-intent de referral o comparison-site que cuesta nada y convierte al 60%)
• El CAC real después de trial drop-off, no el CAC inflado de la marketing platform medido al signup

Dashboard 2: Recuperación de dunning por canal de adquisición

La pregunta: cuando la tarjeta de un paid customer falla, ¿los customers adquiridos por Meta Ads recuperan su pago a la misma tasa que los de LinkedIn u organic? ¿Estás perdiendo revenue recuperable silenciosamente en ciertos canales?

Datos a extraer de Stripe:

• Invoice id, customer, status, due_date, amount_due, created
• Transiciones de invoice: status que sigue en open pasada la due_date significa que el dunning de Stripe Smart Retries está iterando sobre el payment method del customer
• PaymentIntent last_payment_error.code adjunto a la invoice (card_declined, insufficient_funds, expired_card)
• Status final de la invoice: paid (recuperada), uncollectible (dunning fallido), o void (cancelada antes de recovery)
• metadata.acquisition_channel en la subscription padre (escribe esto al crear la subscription para acceso como dimensión nativa)

Cálculos en Looker Studio:

• Dunning recovery rate por canal: COUNT(invoices que transicionaron desde open pasada due_date a status final paid) ÷ COUNT(invoices que se quedaron en open pasada due_date al menos una vez)
• Lost revenue por canal: SUM(amount_due) donde status final = uncollectible, agrupado por canal
• Breakdown de failure reason: COUNT por last_payment_error.code

Layout de Looker Studio:

• Heat map: filas = canal de adquisición, columnas = failure reason, celdas = recovery rate
• Bar chart: revenue total uncollectible perdido por canal (últimos 90 días)
• Scorecard: dunning recovery rate blended, con tendencia vs periodo anterior

Lo que este dashboard surfacea que los reports por defecto de Stripe no muestran:

• Canales donde customers churnean por silent payment failure (tu Meta retargeting audience que se signupea con entusiasmo, nunca actualiza una tarjeta, y se cancela silenciosamente en el primer failed renewal)
• Concentración de failure reason por canal (canales sesgados hacia expired cards vs insufficient funds cuentan historias distintas sobre audience quality)
• El revenue recuperable que estás dejando sobre la mesa porque tus dunning emails no están tuneados por canal

Comparando los tres métodos

La decisión suele bajar a si tu canal de adquisición ya está estampado en customer.metadata y a cada cuánto refresca el dashboard. Estampado y refresh semanal: el manual funciona. Estampado y refresh diario: Apps Script. Estampado, cruce multi-channel, y quieres recuperar tiempo: conector programado.

Particularidades de Stripe que conviene conocer

Cinco comportamientos que afectan a cada método y a cada dashboard construido sobre datos de Stripe subscription:

• Las transiciones de status no son siempre lineales. Una subscription puede ir de trialing a active a past_due de vuelta a active (recuperación de dunning), y luego a canceled. Para medir la conversión trial-to-paid correctamente, consulta el status en el momento en que pasó trial_end, no el status actual. Usa un snapshot o el events log; el estado actual solo esconde el funnel.
• La proration cambia la matemática del MRR. Los cambios de plan mid-cycle disparan invoices prorrateadas. Si computas MRR sumando todas las invoices en un mes, los upgrades o downgrades mid-cycle doble-cuentan o doble-descuentan. Usa subscription.plan.amount en el límite del periodo en vez de sumas de invoices.
• Las trial extensions mueven trial_end silenciosamente. Customer support concediendo una extensión de trial de una semana cambia la fecha trial_end en el objeto subscription. Tu query "¿este customer convirtió en el día 14?" necesita anclarse en trial_start más un offset fijo, no en lo que sea trial_end ahora mismo.
• Las subscriptions en test mode se ven idénticas a las live. Si tu reporting apunta accidentalmente a la API key de test, los datos parecen plausibles y tu dashboard reporta silenciosamente subscriptions de test. Audita qué prefijo de key usa tu conector al setup inicial; muchas autopsias terminan aquí.
• Customer.metadata es no estructurado. Stripe no valida las keys o values que escribes en metadata. Si tu signup form escribe source en algunos flows y acquisition_channel en otros, tu dashboard los ve como campos distintos. Estandariza los nombres de keys de metadata en la capa del signup form primero.

Errores comunes y cómo leerlos

401 unauthorized: la restricted API key es inválida, revocada o le falta el prefijo Bearer en el header Authorization. También dispara si usaste una rk_test_ key contra live data o viceversa.

403 forbidden: la restricted key se creó sin el scope requerido sobre el objeto que estás pidiendo. Edita la key en Dashboard, expande scopes (read access en los object types relevantes), guarda, reintenta.

429 too many requests: rate limit alcanzado. Stripe devuelve un 429 sin header Retry-After por defecto; implementa exponential backoff empezando en 1 segundo y doblando hasta 32 segundos. Raro para workflows de lectura; común si accidentalmente entras en loop sin paginación.

400 bad request con error de parámetro: usualmente un parámetro desconocido o un path expand[] malformado. El mensaje de error de Stripe te dice qué parámetro; consulta la API reference para la forma correcta.

Array data vacío en subscriptions: causa común es filtrar por un status que no existe (typos como active_status en vez de active), o tirar de test mode donde no tienes data real. Verifica el prefijo de la key y el spelling del status.

FAQ

¿Puede Looker Studio conectar a Stripe nativamente en 2026?
Looker Studio no tiene conector nativo first-party para Stripe. La Looker Studio Connector Gallery contiene Partner Connectors construidos por terceros (típicamente con precios entre $5-25 por usuario al mes) que hacen el puente entre Stripe y Looker Studio. La alternativa es aterrizar datos de Stripe en Google Sheets o BigQuery primero, luego apuntar Looker Studio a esa data source.

¿Cómo trackeo el canal de adquisición de un Stripe customer?
Escribe utm_source, utm_medium, utm_campaign y un campo normalizado acquisition_channel en customer.metadata al crear el customer, y copia los mismos valores en subscription.metadata cuando se cree la subscription. Stripe preserva ambos para siempre. La mayoría de conectores de reporting exponen el subscription metadata como dimensiones nativas consultables, mientras que el customer metadata vive dentro del objeto JSON del customer. Escribir en ambos te da acceso como dimensión nativa en el dashboard sin extracción de JSON. Este es el fix más importante para atribución de marketing SaaS.

¿Cuál es la diferencia entre subscription status e invoice status?
El subscription status describe la relación de billing recurrente (trialing, active, past_due, canceled, unpaid, incomplete). El invoice status describe un único billing event dentro de esa relación (draft, open, paid, void, uncollectible). Una subscription puede estar active mientras su invoice actual está open (unpaid pero no aún fallida); una subscription pasa a past_due solo después de intentos de dunning.

¿Cómo puedo cruzar datos de Stripe con inversión de Meta Ads en Looker Studio?
Trae ambos a la misma capa de data source (Looker Studio con un partner connector, o Google Sheets/BigQuery con un conector aterrizando ambos). Luego crea un calculated field en Looker Studio que cruce sobre la dimensión de canal (típicamente el acquisition_channel normalizado estampado en metadata de Stripe, matched contra utm_source en Meta Ads). Para datasets pequeños, un blend en Looker Studio funciona; para volúmenes mayores, pre-agrega en la capa de data source.

¿Cómo trackeo trial-to-paid conversion en Stripe?
Para cada subscription creada en un mes dado, haz snapshot del status en el momento en que pasa trial_end. Una subscription con status active en ese punto convirtió; una con canceled o incomplete no. El Stripe Events log preserva esas transiciones; el estado actual del objeto subscription no. La mayoría de equipos consulta events o mantiene un snapshot diario del estado de subscription.

¿Por qué mi dunning recovery rate está por debajo del benchmark publicado por Stripe?
Stripe publica benchmarks de recovery blended entre todos los merchants. Tu rate varía drásticamente por audience quality (que es lo que el canal de adquisición revela), card mix (tarjetas corporativas recuperan a tasas más altas que personales), geografía (US/EU recuperan distinto), y si tienes Smart Retries habilitado en Billing settings. Segmentar recovery por canal revela dónde se está fugando tu audience quality.

Conclusión

Los tres métodos para llevar Stripe a Looker Studio en 2026 están en un espectro: CSV manual para auditorías puntuales, Apps Script para automatización gratis si tu equipo puede mantener código y los campos de metadata, conector programado para dashboards de marketing SaaS hands-off entre múltiples canales pagos. El método correcto depende de si tu signup form ya está estampando el canal de adquisición en customer.metadata y de cada cuánto necesita refrescar el funnel.

Pero los métodos son el medio, no el fin. Los dos dashboards (funnel de trial conversion por canal y dunning recovery por canal) son el trabajo que cambia cómo los marketers SaaS miden paid acquisition. Ambos requieren que el metadata stamping esté en su lugar en el signup form, ambos requieren datos de Stripe cruzados con tu inversión en paid media, y ambos responden la pregunta que el signup count solo nunca podría en 2026: qué canales realmente pagan back, y en qué timeline.

Arregla el metadata stamping. Lleva los datos de Stripe a Looker Studio. Construye los dos dashboards. Empieza tu trial gratis de Dataslayer si quieres saltarte el mantenimiento de API y el trabajo de extracción de metadata, e ir directamente a los dashboards.