Journey Optimizer · custom actions
Cuando el CRM no contesta
Empiezan las rebajas y 60.000 clientas compran en un minuto. El journey de confirmación llama al CRM con una custom action para poner sus puntos en el email. El CRM aguanta 200 llamadas por segundo. Mira cuántas reciben sus puntos, cuántas un email genérico y cuántas se quedan paradas.
Supuestos del ejemplo
Pico, capacidad del CRM y tasas de error de ejemplo. El reparto de fallos en saturación es una simulación simplificada.
Las 60.000 compras del pico
Qué email recibe cada clienta
Evento de compra, custom action que consulta los puntos en el CRM y email con los puntos. Si falla y hay camino alternativo, sale un email sin puntos.
Journey y sistema externo
Por qué sale así
Una custom action hace que tu journey dependa de la disponibilidad del sistema al que llama.
La recomendación
Un timeout acorde con el sistema, un camino alternativo siempre y el endpoint protegido antes del pico
Una custom action convierte la disponibilidad de otro sistema en la de tu journey. Hay que decidir qué pasa cuando falla, no descubrirlo en las rebajas.
- 01
Camino alternativo siempre
Actívalo en cada custom action, con un contenido que funcione sin la respuesta. En esa rama están jo_status_code y, si se define, la respuesta de error.
- 02
Timeout según el sistema
Por encima del tiempo de respuesta real del endpoint en carga, y dentro del máximo de 30 segundos. Un timeout corto con un sistema lento lo convierte todo en error.
- 03
Throttling para los picos
El capping por defecto, 300.000 llamadas por minuto por host y por sandbox, no protege a un CRM que aguanta 200 por segundo. El throttling encola lo que sobra. El capping lo descarta.
- 04
No contar con los reintentos
Los reintentos arreglan fallos sueltos, pero cada uno es una llamada más. Con el sistema saturado, lo empeoran.