Atribución de ingresos

Conecte los pedidos verificados con el tráfico y las campañas que hay detrás.

Los pedidos llegan a Seean de dos maneras: un conector nativo recibe los webhooks firmados de un proveedor de pago, o su servidor envía pedidos y reembolsos verificados a la API de pedidos de Seean. Cada sitio web informa en una moneda que usted elige. Cuando un pedido nombra a un visitante que Seean conoce, la atribución (contactos, primera y última fuente, página de destino, tiempo hasta la compra) se deriva en el servidor a partir de las visitas registradas de ese visitante en los 90 días anteriores al pedido. Los campos que suministra su integración se usan solo para los visitantes sin visitas registradas.

Conectar un proveedor de pago

Abra Settings → Integrations → Payment providers (Configuración → Integraciones → Proveedores de pago) en su propio sitio web y seleccione Enable (Activar) bajo Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall o Whop. El panel lista los pasos de configuración, la URL de webhook del sitio web para ese proveedor (https://events.seean.io/api/connect/<provider>/<site ID>) y los eventos a activar; pegue el secreto de firma del proveedor y Seean verifica cada entrega antes de almacenarla. Para Stripe, Polar y Paddle, Quick connect (Conexión rápida) crea el webhook a partir de una clave de API que pega una sola vez; la clave no se almacena. Tras Save secret (Guardar secreto) el campo se vacía por seguridad y la línea de abajo indica Secret saved (ends in …) (Secreto guardado, termina en …) con los cuatro últimos caracteres, para que pueda confirmar que se almacenó el secreto correcto; pegue un valor nuevo solo para sustituirlo. Los pedidos pagados y los reembolsos llegan entonces automáticamente, y la línea de estado muestra el último evento y cualquier error. Una conexión o desconexión fallida muestra el motivo del servidor, incluidos los segundos de espera cuando la solicitud se limitó por frecuencia. Las guías de proveedores de abajo dan los pasos de cada proveedor, el fragmento de atribución, el comportamiento de reembolsos y moneda y los límites.

Stripe ofrece además, tras la conexión, una sección separada Optional Stripe payment reads (Lecturas opcionales de pagos de Stripe) solo para el propietario. Un control de consentimiento, inicialmente sin marcar, autoriza explícitamente la retención de una clave de lectura restringida para la factura, los pagos y los reembolsos exactos del Checkout inicial, no para renovaciones ni para una carga retroactiva. La clave nunca se rellena previamente ni se devuelve; solo el propietario ve el estado de activación, el modo de prueba o en vivo, la cuenta y el sufijo. Sustituirla requiere un nuevo consentimiento. Remove read key (Quitar clave de lectura) deja intactos el webhook, los pedidos y los enlaces de pago existentes. Una reconexión rápida o manual elimina el acceso de lectura retenido, mientras que la clave de conexión rápida se sigue usando una vez y descartando. Los controles de demostración u ocupados están desactivados; las acciones correctas y los cambios de proveedor borran la clave de lectura escrita. Vea la guía de Stripe para los permisos, las comprobaciones de reembolsos correctos, el enlace de eventos firmados y repeticiones y la recuperación explícita acotada de una sola sesión. Esta entrega de código no confirma el despliegue en producción ni la recuperación histórica en vivo.

Recuperación de entregas

Un conector nativo devuelve 503 cuando un reembolso llega antes que su pedido (hasta un día después de la creación del reembolso; después, el reembolso se confirma y se ignora), cuando falla una búsqueda de pedido de Revolut o cuando la ingestión no está disponible temporalmente. Los límites de frecuencia devuelven 429. Estas respuestas dejan la entrega apta para los reintentos del proveedor; Seean no mantiene una segunda cola de webhooks. Una vez almacenado el pedido original, repetir el reembolso con el mismo ID de reembolso lo aplica una sola vez.

Revise Settings → Integrations → Payment providers para ver la hora de la última entrega y el error de asignación o búsqueda registrado. Corrija las credenciales o los datos de pago no válidos en su origen. Una entrega correcta posterior borra el último error, así que revise también las entregas fallidas en el panel del proveedor. Los eventos no admitidos y los errores permanentes de carga o moneda se confirman con 200; los pedidos rechazados no se almacenan.

Los calendarios de reintento y la expiración los controla cada proveedor. Si los intentos de entrega expiran, use sus controles de reenvío cuando estén disponibles, o envíe el pedido o reembolso verificado mediante la Order API con los identificadores originales. Los fallos confirmados anteriormente no se repiten automáticamente con este cambio. Las lecturas opcionales de Stripe pueden establecer enlaces del pago inicial a partir de eventos de Checkout firmados recién entregados o de repeticiones exactas; activar la clave no inicia una recuperación histórica. Los propietarios autenticados pueden solicitar por separado una simulación de conciliación de una sola sesión y luego una aplicación explícita mediante una integración personalizada; no hay ninguna ejecución automática ni para todo el sitio. Los acuerdos de varias facturas o abonos no admitidos y las referencias ausentes requieren revisión. Nunca cree un nuevo ID de pedido solo para reintentar un pago.

Enviar pedidos desde su servidor

Abra Settings → Integrations → Revenue (Configuración → Integraciones → Ingresos) y expanda Custom server integration (Order API) (Integración de servidor personalizada) para elegir la moneda de informes y crear un secreto de la API de pedidos. Use su servidor o su controlador de webhooks de pago para enviar los pedidos verificados al punto de conexión mostrado. Mantenga el secreto en su servidor; no lo incluya en el código del navegador. Es una integración personalizada, no una conexión automática con todos los proveedores de pago.

El rastreador expone window.seean.attribution() con el ID de visitante, la ruta de destino, la ruta de conversión y la campaña. Pase esos campos a su servidor con el pedido: el ID de visitante es lo que vincula el pedido con las visitas del comprador. Sin él, el pedido se registra como sin atribuir. Reenvíe los eventos de pago solo después de verificarlos con su proveedor.

Moneda de informes

Cada sitio web tiene una moneda de informes. Abra el desplegable bajo Reporting currency (Moneda de informes) en la tarjeta de integración de Ingresos y elija un código ISO 4217 (USD por defecto); la selección se guarda automáticamente. Los importes se envían en las unidades menores de esa moneda: 2900 es USD 29,00, JPY no tiene unidad menor así que 2900 es JPY 2.900, y KWD usa tres decimales así que 2900 es KWD 2,900. Un pedido en cualquier otra moneda se rechaza con HTTP 400 y el mensaje Order currency EUR does not match the website's reporting currency USD (con los códigos implicados). Seean no convierte monedas.

Cambiar la moneda de informes no convierte los pedidos que ya envió. Los análisis los cuentan como excluidos y la página Ingresos muestra un aviso como «3 pedidos usan otra moneda y se excluyen de los totales en USD». Solo los pedidos en la moneda de informes actual forman los totales.

Reembolsos

Los reembolsos son un libro mayor por pedido. Un reembolso puede cubrir todo el importe restante o un amount parcial, opcionalmente lleva su refundId para que los reintentos se dedupliquen y puede llevar su propia marca de tiempo. Un reembolso que supera el importe restante se rechaza con HTTP 400; un pedido acepta como máximo 50 reembolsos. Cuando el total reembolsado alcanza el importe del pedido, el pedido se marca como reembolsado.

Los reembolsos reducen los ingresos netos en el período del pedido original, no en el período de la fecha del reembolso. Un pedido de junio reembolsado en julio reduce el neto de junio; julio no muestra nada al respecto. Revise el rango que contiene el pedido.

Atribución derivada

Para un pedido con un visitante conocido, Seean lee las visitas de ese visitante en los 90 días anteriores a la marca de tiempo del pedido:

• Contactos: el número de visitas en esa ventana.
• Primera fuente y Última fuente: el referente o utm_source de la primera y la última visita; Direct (Directo) cuando no hay ninguno.
• Página de destino: la página de entrada de la primera visita.
• Tiempo hasta la compra: desde el inicio de la primera visita hasta el pedido.
• Campaña: la campaña que suministra su integración; en su defecto, el utm_campaign de la visita etiquetada más reciente.

Si el visitante no tiene ninguna visita registrada en la ventana, se usan la primera fuente, la última fuente, los contactos y el tiempo hasta la compra que suministra su integración, y el pedido cuenta como atribuido solo cuando nombra un visitante y una ruta de destino. Los pedidos enviados sin ID de visitante son Unattributed (Sin atribuir). Los pedidos registrados antes de que existiera la atribución derivada se completan una vez a partir de las visitas registradas de su visitante; una campaña suministrada por su integración se conserva.

Límites de atribución

La ingestión de pedidos acepta historiales de hasta 2.000 eventos coincidentes dentro de la ventana de 90 días. Sondea como máximo 2.001 filas para detectar el desbordamiento, con un presupuesto de lectura de 1 MiB. Un recorrido guardado completo puede ocupar hasta 64 KiB. Estos límites se aplican al historial del visitante de cada pedido, no al tráfico total de un sitio web. Seean guarda todos los contactos cuando el historial completo cabe; ya no descarta las visitas posteriores a la trigésima.

Si el historial supera un límite, el pedido y los reembolsos se registran igualmente con exactitud. El informe de Ingresos muestra un aviso de historial incompleto y una fila de desglose Incomplete history (Historial incompleto) en lugar de asignar crédito a partir de una parte del recorrido. Estos pedidos no contribuyen a los ingresos atribuidos ni al tiempo medio hasta la compra; permanecen en los totales monetarios y en el denominador de la tasa de atribución. El informe cuenta los pedidos afectados para su moneda y período seleccionados, incluidos los totalmente reembolsados. Cambiar la ventana no recupera el historial que no pudo capturarse en la ingestión.

Los recorridos antiguos acortados también se marcan como incompletos hasta que pueda recuperarse su historial completo. Los resultados de informes guardados existentes se conservan. Los historiales sin visitas registradas conservan la atribución suministrada por la integración descrita arriba; son distintos de un historial que superó un límite. El enriquecimiento automático más allá de estos límites no está disponible actualmente.

Ignore las visitas de pago y de agradecimiento

El regreso desde el proveedor de pago suele iniciar una nueva visita en su página de agradecimiento o de pago, que se llevaría el crédito del último contacto. En Settings → Exclusions → Revenue attribution only (Configuración → Exclusiones → Solo atribución de ingresos), los administradores y propietarios añaden hasta 20 reglas de ruta con la sintaxis de exclusión de tráfico (/thanks exactamente, o /checkout/* para un prefijo). Las visitas que entran por una ruta coincidente se eliminan de los contactos del pedido antes de aplicar la ventana y el modelo; si no queda ningún contacto, el pedido es Unattributed. No se elimina nada: el tráfico, las páginas de Resumen y todos los demás informes conservan esas visitas, y la página de conversión sigue mostrando la ruta que suministró su integración. Las reglas se aplican solo a los cálculos nuevos: los informes de Ingresos y Resumen inician un nuevo análisis cuando cambia una regla, mientras que los resultados ya guardados, los informes programados ya calculados y los resultados de la API permanecen como estaban; la siguiente solicitud a la API calcula con las nuevas reglas. Los pedidos sin historial de visitas (enviados sin ID de visitante o anteriores a la atribución derivada) no pueden filtrarse; el informe los cuenta bajo el aviso de reglas.

Informe de ingresos

Abra Revenue (Ingresos) en la barra lateral del sitio web. Sus tablas mantienen cada valor en una línea; en pantallas estrechas una tabla se desplaza lateralmente dentro de su tarjeta y los recorridos de compra largos se acortan con puntos suspensivos (pase el cursor para ver la ruta completa). La barra de herramientas tiene el rango de fechas más los controles de atribución:

• Attribution model (Modelo de atribución): First touch (Primer contacto) acredita la primera visita en la ventana, Last touch (Último contacto) la visita que llevó al pedido, Linear (Lineal) reparte el pedido por igual entre sus visitas.
• Attribution lookback (Ventana de atribución): 7, 14, 30 o 90 días antes del pedido. Una visita anterior a la ventana no es un contacto. Las visitas guardadas completas se usan para el crédito del modelo, sujetas a los límites de atribución descritos arriba.
• Website default (Predeterminado del sitio web): la página se abre con el modelo y la ventana guardados del sitio web (último contacto, 30 días hasta que se guarde uno). Cuando su selección difiere, los administradores y propietarios ven Save as website default (Guardar como predeterminado del sitio web); el valor predeterminado se comparte con el crédito de ingresos de Resumen, la API de analítica y el get_revenue de MCP, y con todos los compañeros. Una selección en la URL siempre prevalece para esa vista. Overview: net / gross (Resumen: neto / bruto) elige lo que muestra el KPI de Resumen (vea KPI); el sitio web de demostración no puede cambiar estos ajustes.

La franja superior muestra bruto, reembolsos (con el recuento de reembolsos), neto, ingresos atribuidos, tasa de atribución y tiempo medio hasta la compra. Attribution breakdown (Desglose de atribución) tiene cinco pestañas: Landing pages, Converting pages, First source, Last source y Sources (Páginas de destino, Páginas de conversión, Primera fuente, Última fuente y Fuentes). Fuentes acredita cada fuente según el modelo seleccionado, así que con Lineal un pedido aparece una vez bajo cada una de sus fuentes con una parte de su importe neto. Revenue by product (Ingresos por producto) lista pedidos, ingresos, cuota y la porción atribuida. Touches before purchase (Contactos antes de la compra) agrupa los pedidos por el recuento de contactos derivado. Purchase journeys (Recorridos de compra) agrupa los pedidos pagados por la página de entrada de cada visita dentro de la ventana, de la más antigua a la más reciente (/ → /pricing → /checkout): las repeticiones consecutivas se agrupan, solo se conservan los últimos seis pasos tras unos puntos suspensivos, una ruta suministrada por su integración sustituye al recorrido derivado y los pedidos sin historial de visitas muestran su página de destino. Los recorridos son páginas de entrada de visitas, no todas las páginas vistas.

Orders (Pedidos) lista los pedidos del período de más reciente a más antiguo, veinte a la vez con Load more (Cargar más), solo en la moneda de informes: hora (pase el cursor para ver el momento exacto en su zona horaria de visualización), producto con insignias Refunded (Reembolsado) o Partially refunded −amount (Reembolsado parcialmente −importe), primera fuente, recorrido e importe según el modelo y la ventana seleccionados. Los pedidos con historial incompleto muestran Incomplete history. Refunds (Reembolsos) lista todos los reembolsos de esos pedidos (hora del reembolso, ID del pedido o su hora, producto, ID del reembolso e importe), también veinte a la vez; un reembolso total registrado antes de que existieran los libros de reembolsos aparece una vez como legacy. Los reembolsos siempre cuentan en el período de su pedido, tanto aquí como en los totales. Los lectores pueden leer ambas listas; las exportaciones en bruto siguen en Settings → Data.

Cambiar el modelo o la ventana inicia un nuevo análisis para el mismo rango; los resultados existentes y los pedidos almacenados no se reescriben.

Compare períodos

El botón de comparación junto al rango de fechas ofrece las mismas opciones que Resumen: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… y No comparison (vea rangos de fechas y filtros). Con una comparación activa, cada KPI de la franja superior muestra su cambio porcentual frente al intervalo de comparación en lugar de su recuento: bruto, reembolsos, neto, ingresos atribuidos, tasa de atribución y tiempo hasta la compra. Un aumento de los reembolsos o del tiempo hasta la compra se muestra como un descenso. Previous period se calcula en el mismo análisis; las demás opciones inician un análisis de ingresos adicional con el mismo modelo, ventana y moneda de informes. Las tablas de desglose, productos, contactos, recorridos, pedidos y reembolsos siguen siendo vistas del período actual, y All time (Todo el tiempo) no tiene comparación.

Traspaso de atribución

Tanto si el pedido lo registra un conector como su servidor, el vínculo con la visita es el ID de visitante. Con un conector, adjunte seean_visitor_id (y opcionalmente seean_landing_path, seean_converting_path, seean_campaign) desde window.seean.attribution() a los metadatos del checkout, los datos personalizados, los atributos del carrito o los atributos del suscriptor del proveedor, como muestra la guía del proveedor; Seean lee esas claves del evento verificado. El token público de seguimiento nunca autoriza la ingestión de pedidos.

Para una integración personalizada, capture window.seean?.attribution?.() cuando esté disponible durante la creación del pago y pase solo los campos admitidos a su servidor. Guárdelos con la referencia del pago o pedido para que el evento de pago verificado posterior pueda usarlos. El ayudante puede estar ausente antes de la carga o no devolver atribución cuando la recopilación está desactivada. Acepte un pedido sin atribuir en ese caso; no invente valores de visitante ni de campaña.

Después de que el rastreador cargue, espere window.seean?.ready antes de leer la atribución. Esto termina tras el intento de recopilación inicial o su tiempo de espera; no garantiza que exista un ID de visitante. Úselo dentro de su controlador de pago asíncrono y permita que el pago continúe sin atribución. Cada ejemplo de proveedor incluye la espera.

El hash de visitante predeterminado cambia a medianoche UTC y está limitado a un sitio web. La ventana de 90 días busca registros que lleven el identificador capturado; no une los distintos hashes diarios de ese visitante. Conserve la atribución del momento del pago para los webhooks de pago retrasados. Un regreso posterior en un nuevo día UTC tiene una nueva identidad, así que los recorridos de varios días no se reconstruyen. Los pedidos antiguos y los resultados guardados conservan sus identificadores y valores originales.

Mantenga identificadores de pedido externos estables entre reintentos. Reenvíe los pagos recurrentes como los pedidos pagados distintos que representan, y asigne cada reembolso al ID de pedido externo original con el ID de reembolso del proveedor. Su integración debe tener en cuenta el orden de los eventos y los duplicados del proveedor. Convierta los importes del proveedor a las unidades menores de la moneda de informes del sitio web solo cuando el pago se cobró realmente en esa moneda; Seean rechaza otras monedas en lugar de convertirlas.

Verifique su integración

Use las herramientas de prueba de su proveedor y un sitio web de prueba separado en Seean cuando sea posible. Verifique un pedido pagado, un reintento idéntico, un reembolso parcial, un reembolso total y un pedido sin atribución. Compare el informe de Ingresos del sitio web con los importes exactos y la atribución derivada. Una solicitud correcta del rastreador o una visita a la página de confirmación no demuestran que el pedido se ingirió.

Referencia de integración

Siga Order API y reembolsos para las cargas, el manejo de la clave del servidor, las reglas de moneda, las reglas de reembolso y el comportamiento de reintento. La disponibilidad de proveedores resume qué proveedores tienen un conector nativo.

Guías de proveedores

Cada guía cubre los pasos de configuración del proveedor, el fragmento de atribución para su checkout, qué se registra, los reembolsos, la moneda, la verificación y los límites.

El historial del visitante registrado se captura una vez cuando se acepta un pedido nuevo, ya sea mediante la Order API o un conector de proveedor admitido. Un fallo temporal en la búsqueda del historial devuelve una respuesta que admite reintento; un duplicado aceptado conserva la atribución original y el importe exacto. Vea reintentos de la Order API.

• Creem

  Connect Creem to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive completed checkouts and refunds.

• Mollie

  Connect Mollie to Seean through signed next-generation webhooks, pass the visitor ID as payment metadata and receive paid payments and refunds.

• Paddle

  Connect Paddle to Seean with the notification secret key, pass the visitor ID as checkout custom data and receive completed transactions and approved refunds.

• Polar

  Connect Polar to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive paid orders, renewals and refunds.

• RevenueCat

  Connect RevenueCat to Seean with the webhook authorization value, pass the visitor ID as Web Billing metadata or a subscriber attribute and receive purchases, renewals and refunds.

• Revolut

  Connect the Revolut Merchant API to Seean with the webhook signing secret and Merchant API secret key, pass the visitor ID as order metadata and receive completed orders.

• Shopify

  Connect a Shopify store to Seean with the webhook signing secret, write the visitor ID as a cart attribute and receive paid orders and refunds.

• Stripe

  Connect Stripe Checkout to Seean with the webhook signing secret, pass the visitor ID as session metadata and receive paid orders and refunds.

• Superwall

  Connect Superwall to Seean with the webhook signing secret, set the visitor ID as a user attribute and receive purchases and renewals.

• Whop

  Connect Whop to Seean with the webhook signing secret, pass the visitor ID as checkout metadata and receive successful payments and refunds.

¿Algo no queda claro? Contacte con soporte.