Cicle de vida (al costat del servidor)
Enviï l’enllaç de reproducció a ActiveCampaign, Mailchimp, Iterable o Klaviyo des del nostre servidor tan bon punt una sessió rebi el seu identificador de client propi.
1. Per què existeix al costat del pont del navegador
MousePlayer ja té un pont de cicle de vida que escriu a l’SDK que s’executa a la seva pàgina: Klaviyo, Braze, Customer.io i sis més. Aquest fa la mateixa feina des del nostre servidor i existeix perquè, per a dues de les plataformes més grans, la via del navegador senzillament no està disponible:
- ActiveCampaign no té cap API d’esdeveniments per al navegador. La seva API
vgo()pot definir un compte i una adreça electrònica i iniciar el seguiment, però no pot enviar cap esdeveniment. Els esdeveniments passen per Event Tracking API amb una clau d’esdeveniment separada, només al costat del servidor. - Mailchimp en té una, però amb un vocabulari tancat. El seu píxel de seguiment del lloc accepta
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDi uns quants altres noms predefinits. No hi ha cap lloc per a un esdeveniment personalitzat, i forçar les nostres dades dins d’unPAGE_VIEWEDseria falsejar el seu propi model de dades.
Per a Iterable i Klaviyo, la via del servidor simplement és més fiable: sense bloquejadors d’anuncis, sense un SDK que potser no s’ha carregat i sense pestanyes que es tanquen abans d’hora.
2. Què necessita
Tres camps; quins ha d’emplenar depèn de la plataforma.
| Plataforma | Camp del compte | Clau |
|---|---|---|
| ActiveCampaign | actid | Website → Site Tracking, al costat de la clau d’esdeveniment |
| Mailchimp | L’identificador del públic | Una clau d’API; conservi el sufix de tipus -us14 perquè se’n dedueix el centre de dades |
| Iterable | no cal; deixi’l buit | Una clau amb el permís «Allow event track calls» |
| Klaviyo | no cal; deixi’l buit | Una clau privada d’API |
El tercer camp és el nom d’esdeveniment amb què apareixerà. Mantingui’l curt: com a màxim 32 caràcters. És el límit de l’API, no el nostre, i l’escurcem en desar-lo, no en enviar-lo; si no, el formulari mostraria una cosa diferent de la que arriba.
Mailchimp: conservi el sufix de la clau d’API. La part després de l’últim guionet (-us14) indica el centre de dades on es troba el compte i s’utilitza per construir l’adreça. Una clau sense aquesta part es rebutja amb un missatge clar, en lloc de fallar en un lloc que no pot veure.
3. Quan s’activa i quan no
En el moment en què s’identifica una sessió: quan el seu lloc crida MousePlayer.setUserId(), quan el nostre pont d’analítica llegeix un identificador distintiu o quan el seu servidor crida l’endpoint d’identificació. Abans no sabem a qui pertany la gravació.
Només amb una adreça electrònica
Totes quatre plataformes identifiquen un contacte per l’adreça electrònica. Si el seu identificador de client és un número de contracte, no s’envia res; posar a la cua una tasca que només pot fallar simplement ompliria el registre de soroll.
El contacte ja ha d’existir. Cap d’aquestes plataformes no en crea un a partir d’un esdeveniment; ActiveCampaign descarta tot l’esdeveniment si no reconeix l’adreça. Aquest pont enriqueix els contactes existents, no crea la seva llista.
Cada esdeveniment conté un identificador
Així, la mateixa sessió no es pot comptar dues vegades, encara que es reintenti una tasca.
4. Què arriba a l’altra banda
Un esdeveniment que conté l’enllaç de reproducció com a propietat amb el nom mouseplayer_session_url. Obri’l i accedirà a la gravació d’aquella mateixa sessió.
A partir d’aquí, actua la lògica de la seva plataforma: utilitzi l’esdeveniment com a activador d’automatitzacions, com a condició de segment o simplement deixi que l’equip obri la gravació des del contacte.
La clau no surt mai del nostre servidor
Es desa xifrada amb AES-256-GCM, no es torna a mostrar després de desar-la i, expressament, no s’inclou a la cua interna que transporta la tasca: el procés executor l’obté directament de la base de dades.
HTTP 200 no vol dir lliurat
ActiveCampaign respon amb estat 200 i {"success":0} quan rebutja un esdeveniment. Llegim el cos de la resposta, no només l’estat, perquè un rebuig aparegui com a error al registre de lliuraments i no com a èxit silenciós.
5. Braze, Customer.io i Brevo
Tres plataformes més per la via del servidor. Dues necessiten una cosa que les altres no necessiten: una ubicació.
| Què cal proporcionar | Com s’identifica | |
|---|---|---|
| Braze | Endpoint REST i clau d’API | adreça electrònica |
| Customer.io | identificador del lloc, clau d’API i regió | el seu identificador de client propi |
| Brevo | la clau del tracker, res més | adreça electrònica |
Dues tenen una ubicació específica
Braze utilitza endpoints REST vinculats a cada instància; Customer.io té dues regions separades amb hosts diferents. Cap dels dos no es pot deduir de la clau, i triar-ne un d’erroni retorna 401, cosa que el porta a revisar la clau. Aquests dos camps existeixen només per aquest motiu.
Customer.io és la que no necessita correu electrònic
Identifica les persones amb el mateix identificador que vostè els assigna; per tant, exigir una adreça electrònica seria un obstacle inventat. Les altres sis sí que estableixen correspondència per correu electrònic, i en aquestes una sessió identificada amb un número de contracte no genera res, correctament.
Cap perfil nou
La crida a Braze conté _update_existing_only. És la mateixa decisió que al pont CRM: una sessió de navegador no és una afirmació fiable sobre qui són els seus clients, i una plataforma de cicle de vida que crea un perfil per cada visitant anònim és pitjor que no tenir integració.
Brevo respon 204; Braze respon 201 amb un matís
Brevo no retorna cap cos; en aquest cas, un 2xx sí que ho diu tot. Braze retorna "message": "success" i pot incloure una matriu errors al costat: els problemes fatals apareixen al missatge; les pèrdues de camps tolerades, només a errors. Llegir-ne només un porta a equivocar-se en un sentit o en l’altre.
Totes les marques esmentades aquí pertanyen als seus propietaris respectius. MousePlayer no té cap relació comercial amb aquests proveïdors.