O que você mais gosta Adobe Journey Optimizer?
Temos vários IPs, então, teoricamente, deveríamos ser capazes de enviar grandes volumes sem nos preocupar com a entregabilidade.
Somos agora uma empresa da Adobe usando vários produtos, então, teoricamente, há um benefício em agrupar. Revisaremos esta avaliação se encontrarmos isso.
Gostamos de apontar as falhas do AJO para as equipes de Cyber e TI que nos forçaram a usar o AJO quando nosso último ESP era perfeito para nossas necessidades. Análise coletada por e hospedada no G2.com.
O que você não gosta Adobe Journey Optimizer?
Ainda estamos enfrentando problemas de entregabilidade, apesar do fato de que:
- Somos o 6º maior banco dos EUA com uma reputação de remetente excelente.
- Fizemos o aquecimento de IP com sucesso com a ajuda da Adobe.
- Estamos limitando o envio de e-mails lentamente.
E-mails de teste para nossa própria caixa de entrada da empresa são entregues cerca de 60% das vezes e deveríamos estar na lista de permissões.
Recursos básicos de ESP (em outros ESPs) exigem ajuda dos engenheiros de software da Adobe e de nossos próprios parceiros internos de MarTech. Os recursos não são intuitivos para os profissionais de marketing ou gerentes de e-mail juniores.
A limitação é um grande incômodo porque o AJO não possui um recurso de limitação pronto para uso. Você tem que construir um programa complicado com várias divisões para enviar 250K p/h.
Temos cerca de 50 tipos diferentes de e-mails com 50 nomes de remetente diferentes. Só podemos usar 10 nomes de remetente porque a interface tem um problema em que a caixa de seleção suspensa só mostra 10.
O AJO literalmente altera o código HTML e o reestrutura, o que muitas vezes quebra o modelo (perde cores de fundo, quebra contornos de tabelas, quebra módulo de 3 colunas, etc.). O Litmus renderiza o e-mail perfeitamente em todos os clientes. Se eu enviar o e-mail em nosso antigo ESP, ele é renderizado perfeitamente em todos os lugares. Mas o AJO requer HTML "pronto para a web", o que não é exigido por outras ferramentas MAP/ESP e nem mesmo é uma prática recomendada para desenvolvimento de e-mails. O AJO parece ser o resultado de desenvolvedores web se reunindo para criar um produto de e-mail. Isso está quebrando cerca de 30% de nossos modelos de e-mail, causando mais problemas e atrasos.
Não podemos pausar ou editar jornadas ao vivo, um recurso que tínhamos em nossas duas últimas plataformas. Você só pode parar uma jornada ao vivo, cloná-la, revisá-la e então iniciar a nova jornada. Migrar clientes no meio da jornada antiga para o novo clone é quase impossível.
O programa é massivo e, portanto, funciona extremamente devagar, especialmente à tarde no horário EST. Temos time-outs, as coisas não salvam, perda de trabalho e tempo. Estamos tendo que tomar medidas extras (desnecessárias) (por exemplo, listas que se auto-deletam após um tempo) para manter o banco de dados super enxuto. Isso supostamente ajuda, mas acabamos de começar no AJO e já estamos tendo timeouts. Uma vez que tivermos centenas de programas e coisas rodando simultaneamente, só vai piorar.
Esta revisão está apenas arranhando a superfície. Temos um documento cada vez maior com várias páginas listando todos os problemas, funcionalidade ruim e riscos. Esperamos esgotamento, rotatividade e perda significativa de receita devido aos muitos atrasos.
De acordo com um relatório direto anterior, a Intuit recentemente deixou o AJO. Eles tiveram uma experiência muito semelhante. Infelizmente, estávamos muito avançados no processo de integração e implementação para dar ouvidos ao seu aviso. Agora provavelmente estamos presos por alguns anos para que Cyber e TI possam tentar provar que a plataforma vale o custo exorbitante. Análise coletada por e hospedada no G2.com.
