Ciclo de vida (no servidor)
Envíe a ligazón da reprodución a ActiveCampaign, Mailchimp, Iterable ou Klaviyo desde o noso servidor en canto unha sesión recibe o seu propio ID de cliente.
1. Por que existe xunto á ponte do navegador
MousePlayer xa ten unha ponte de ciclo de vida que escribe no SDK da súa propia páxina: Klaviyo, Braze, Customer.io e outras seis plataformas. Esta fai o mesmo traballo desde o noso servidor e existe porque en dúas das maiores plataformas a vía do navegador simplemente non está dispoñible:
- ActiveCampaign non ten ningunha API de navegador para eventos. O seu
vgo()pode establecer unha conta e un enderezo de correo e iniciar o seguimento, pero non enviar un evento. Os eventos pasan pola Event Tracking API cunha clave de eventos separada, só no servidor. - Mailchimp ten unha, pero cun vocabulario pechado. O seu píxel de seguimento do sitio acepta
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDe uns poucos nomes predefinidos máis. Non hai espazo para un evento personalizado e encaixar os nosos datos nunPAGE_VIEWEDsería mentir no seu propio modelo de datos.
Para Iterable e Klaviyo a vía do servidor simplemente é máis fiable: sen bloqueadores de anuncios, sen SDK que pode terse cargado ou non e sen lapelas que se pechan antes de tempo.
2. Que necesita
Tres campos; cales cobre depende da plataforma.
| Plataforma | Campo de conta | Clave |
|---|---|---|
| ActiveCampaign | actid | Website → Site Tracking, xunto á clave de eventos |
| Mailchimp | O ID da audiencia | Unha clave API — conserve o sufixo de tipo -us14 para identificar o centro de datos |
| Iterable | non é necesario — déixeo baleiro | Unha clave co permiso "Allow event track calls" |
| Klaviyo | non é necesario — déixeo baleiro | Unha clave API privada |
O terceiro campo é o nome do evento co que aparecerá. Mantéñao curto: como máximo 32 caracteres. É o límite da API, non o noso; acurtámolo ao gardar e non ao enviar, pois doutro xeito o formulario mostraría algo distinto do que chega.
Mailchimp: conserve o sufixo da clave API. A parte posterior ao último guión (-us14) indica o centro de datos da conta e o enderezo constrúese a partir del. Unha clave sen ela rexéitase cunha mensaxe clara en lugar de fallar onde non o pode ver.
3. Cando se activa e cando non
No momento de identificar a sesión: cando o seu sitio chama a MousePlayer.setUserId(), cando a ponte de analítica le un identificador único ou cando o servidor chama ao endpoint identify. Antes diso non sabemos de quen é a gravación.
Só cun enderezo de correo electrónico
As catro plataformas identifican os contactos polo correo. Se o seu ID de cliente é un número de contrato non se envía nada: poñer na cola unha tarefa que só pode fallar enchería o rexistro de ruído.
O contacto xa debe existir. Ningunha destas plataformas crea un contacto a partir dun evento; ActiveCampaign descarta o evento completo se non recoñece o enderezo. Esta ponte enriquece os contactos existentes, non constrúe a lista.
Cada evento leva un ID
Para que a mesma sesión non se conte dúas veces, mesmo se se reintenta unha tarefa.
4. Que chega ao outro lado
Un evento coa ligazón de reprodución nunha propiedade chamada mouseplayer_session_url. Ábraa e estará na gravación desa mesma sesión.
A partir de aí actúa a lóxica da plataforma: use o evento para activar unha automatización, como condición dun segmento ou simplemente para que o equipo abra a gravación desde o contacto.
A clave nunca sae do noso servidor
Gárdase cifrada con AES-256-GCM, non volve mostrarse tras gardala e non se inclúe deliberadamente na cola interna que leva a tarefa: o proceso de traballo recupera a clave directamente da base de datos.
HTTP 200 non significa entregado
ActiveCampaign responde co estado 200 e {"success":0} cando rexeita un evento. Lemos o corpo da resposta, non só o estado, para que o rexeitamento apareza como fallo no rexistro de entregas e non como un éxito silencioso.
5. Braze, Customer.io e Brevo
Tres plataformas máis na vía do servidor. Dúas necesitan algo que as demais non: un lugar.
| O que proporciona | Identificado por | |
|---|---|---|
| Braze | Endpoint REST e clave API | enderezo de correo electrónico |
| Customer.io | ID do sitio, clave API e a súa rexión | o seu propio ID de cliente |
| Brevo | só a clave do rastrexador | enderezo de correo electrónico |
Dúas están nun lugar concreto
Braze ten endpoints REST ligados á instancia; Customer.io ten dúas rexións separadas con hosts distintos. Ningún se pode deducir da clave e escoller o incorrecto devolve 401, o que o leva a revisar a clave. Os dous campos existen só por ese motivo.
Customer.io non necesita correo electrónico
Coñece as persoas polo mesmo ID que vostede lles asigna; esixir un correo sería un obstáculo inventado. As outras seis usan o correo e nelas unha sesión identificada por un número de contrato non produce nada, correctamente.
Sen novos perfís
A chamada a Braze leva _update_existing_only. É a mesma decisión que na ponte CRM: unha sesión do navegador non é unha declaración fiable de quen son os seus clientes e unha plataforma de ciclo de vida que crea un perfil por visitante anónimo é peor que non ter integración.
Brevo responde 204; Braze responde 201 cunha excepción
Brevo non devolve ningún corpo: alí un 2xx é realmente toda a verdade. Braze devolve "message": "success" e pode levar unha matriz errors ao lado: os problemas fatais aparecen en message e as perdas de campos toleradas só en errors. Ler un só dos dous dá un resultado incorrecto nun sentido ou noutro.
Todas as marcas mencionadas aquí pertencen aos seus respectivos propietarios. MousePlayer non ten relación comercial con estes provedores.