Manejo de datos

Percus soporta dos modelos de personalización. Tienen propiedades de manejo de datos materialmente distintas, y cuál usa el cliente determina si los datos de personalización llegan siquiera a la infraestructura de Percus. Esta página describe ambos.

Los dos modelos

	Personalización del lado del cliente	Render data alojado en Percus
Dónde viven los datos	Sólo en la página del cliente	Infraestructura de Percus (DynamoDB)
Cómo llegan al player	postMessage desde la página al iframe del player	Se cargan por adelantado, se entregan al momento de la vista
Percus almacena los valores de personalización	No	Sí
Uso típico	El sistema del cliente ya renderiza la página y tiene los datos	Campañas masivas donde el link va por correo y no hay sistema anfitrión al momento de la vista

Ninguno de los dos es más correcto que el otro. La personalización del lado del cliente mantiene los valores fuera de Percus por completo; el render data alojado es lo que permite que un simple link de correo funcione sin que el cliente opere un sistema en tiempo real.

Modelo 1 — Personalización del lado del cliente

Sistema del cliente                    Infraestructura de Percus
─────────────────────────────────────  ────────────────────────────────────
Página anfitriona (sitio del cliente)  Campaign Service
  └── percus-embed-sdk                   └── Archivos de template (S3)
        └── postMessage PERCUS/INIT            └── servidos al iframe
              └── data: { nombre, saldo }
                        ↑
                 Sólo en memoria.
                 Nunca se envía a Percus.

En este modelo:

• Los datos pasan directamente de la página anfitriona al iframe del player.
• El player los mantiene en memoria sólo durante la fase de binding.
• Nunca se escriben en localStorage, sessionStorage, logs ni ninguna solicitud de red.
• Los payloads de error se sanitizan para que ningún valor aparezca en PERCUS/ERROR.
• Terminado el binding, el objeto deja de estar referenciado.

Existe una segunda forma de este modelo: en vez de pasar los datos en línea, el snippet puede nombrar tu propio endpoint (data-pc-data-url), que el player descarga al momento de la vista. Los datos viajan desde tu endpoint al navegador del destinatario y se mantienen en memoria durante la fase de binding, exactamente como arriba — no pasan por la infraestructura de Percus. Ver la Referencia del snippet.

Para este modelo, en cualquiera de sus dos formas, una brecha en la infraestructura de Percus no expone los valores de personalización, porque nunca fueron enviados allí.

Modelo 2 — Render data alojado en Percus

Las campañas masivas necesitan que el video personalizado funcione desde un link simple en un correo, donde no hay sistema anfitrión que provea los datos al momento de la vista. Para eso el cliente carga los datos por adelantado y Percus los almacena.

Carga (backoffice)                     Entrega (el destinatario abre el link)
─────────────────────────────────      ────────────────────────────────────
CSV, un objeto por viewer token        snippet + data-pc-viewer-token
        │                                        │
        ▼                                        ▼
Render Data API ─► PUT firmado ─► S3     se emite token de sesión de vista
                                 │              │
                          evento S3           GET /v1/render-data
                                 ▼              │
                          worker Lambda ─► DynamoDB ◄─┘
                                          se fusiona en el player al momento de la vista

En este modelo, Percus sí almacena los valores de personalización que el cliente carga. Dos propiedades acotan la exposición:

• El viewer token lo elige el cliente y es opaco para Percus. Percus almacena el objeto de personalización indexado por ese token; no guarda la relación entre el token y una identidad real, salvo que el cliente ponga valores identificatorios dentro del objeto.
• El acceso requiere un token de sesión de corta duración, emitido por vista contra el canal y su API key. Los datos almacenados no son legibles con sólo tener el link.

Los clientes que necesiten que los valores de personalización no lleguen a Percus deben usar el Modelo 1.

Qué almacena Percus

Dato	Dónde	Notas
Cuentas de usuario	Identity Service (PostgreSQL)	Correo, nombre, roles — desde el login SSO
Metadata de organización	Identity Service	Nombre, configuración
Proyectos y templates	Campaign Service (PostgreSQL)	Nombres, descripciones, archivos de template
Assets de template	S3	Animaciones, imágenes, video — cifrados en reposo
Render data por destinatario	Render Data Service (DynamoDB)	Sólo cuando el cliente usa el Modelo 2. Objetos de personalización indexados por un token opaco elegido por el cliente
Personalización de shares	Campaign Service (PostgreSQL)	Sólo para links de video compartidos que llevan su propia personalización
Credenciales de API	Campaign Service	API key en texto plano; el secreto se guarda como hash de una vía
Eventos de auditoría	Campaign Service	Quién hizo qué acción y cuándo
Eventos de analítica	Analytics Service	Eventos de reproducción e interacción — ver la documentación de Analytics para el modelo de identidad

Retención y borrado

El render data está atado al proyecto que lo posee. Cuando un proyecto se archiva, un proceso de retención elimina los datos por destinatario asociados. Los clientes que necesiten un período de retención específico o un proceso de borrado documentado deben plantearlo en el onboarding, ya que forma parte del acuerdo contractual y no de un comportamiento por defecto de la plataforma.

Archivos de template

Los archivos de template (Lottie JSON, manifiestos, video) que suben los motion designers se almacenan en S3 con cifrado del lado del servidor. Contienen estructura de animación y definiciones de binding — no datos de clientes.

Secretos de API

Cuando se crea una credencial de API, el secreto se devuelve una sola vez y no se almacena de forma recuperable. Percus guarda sólo un hash de una vía. Si se pierde, debe rotarse; no se puede recuperar.

Residencia de datos

La infraestructura de Percus corre en AWS. La región específica se determina al desplegar y se comunica a los clientes durante el onboarding.