As experiências digitais são a forma como as marcas se conectam com os clientes. Nos bastidores, as equipes técnicas são responsáveis por otimizar e implantar essas experiências em vários pontos de contato digitais. Como tal, é importante que as organizações compreendam os principais desafios relacionados à implantação, especialmente quando se trata de compreender as diferenças entre B2C e B2B entrega da experiência do cliente.
B2B desafios de entrega da experiência do cliente
Embora eles tenham dois terços de uma sigla em comum, o dimensionamento para entrega de experiência B2B é categoricamente diferente — e potencialmente mais desafiador — do que o dimensionamento para entrega de experiência B2C. Aqui estão algumas das principais razões:
- Mesmo os compromissos de B2B mais diretos envolvem várias partes interessadas com diferentes expectativas e necessidades. Um tamanho único não serve para todos, ou mesmo para a maioria.
- B2B compromissos normalmente envolvem vários pontos de contato durante um período de tempo mais longo, muitas vezes abrangendo meses ou até anos. Não conseguir energizar e impressionar os clientes em qualquer um desses pontos de contato pode efetivamente encerrar o relacionamento. E manter cada novo compromisso atualizado requer capturar e analisar dados em cada ponto de contato subsequente para aproveitar os insights.
- Como muitos dados podem ser desconectados e várias equipes podem envolver o mesmo cliente, é difícil avaliar com precisão a saúde e o momento do cliente ao longo da jornada. A jornada de pós-venda pode ser tão complexa quanto a jornada de pré-venda — o que é especialmente crítico para organizações como as do espaço SaaS, cujos modelos de negócios dependem de os clientes permanecerem na lista por vários anos.
5 questões-chave
Para escalar efetivamente de uma perspetiva operacional e atender às B2B demandas de experiência do cliente (por exemplo, desempenho, distribuição geográfica, redundância e alta disponibilidade), é importante considerar as cinco perguntas-chave a seguir:
1. Como é o sucesso?
É essencial responder claramente a esta pergunta antes de fazer qualquer outra coisa, porque o dimensionamento bem-sucedido requer uma compreensão profunda de:
- Como é a jornada do usuário
- Níveis de utilização previstos
- Padrões previstos de procura no sistema
- Aspetos aceitáveis relacionados ao desempenho (por exemplo, tempos de resposta do servidor, tempos de carregamento de página, funcionalidade, disponibilidade, etc.)
Geralmente, o primeiro passo é ter uma compreensão clara e definição dos requisitos da solução. Os requisitos afetam significativamente a composição do ambiente de entrega e, em última análise, o custo. Os principais problemas a serem resolvidos incluem: Onde os visitantes normalmente entram no site? Quantos visitantes normalmente visitam ao mesmo tempo? Existem picos de tráfego previsíveis em determinadas épocas do ano?
Esses tipos de perguntas irão guiá-lo na compreensão e mapeamento do comportamento de seus visitantes, o que pode ajudá-lo a identificar atritos e informar seus planos de teste de desempenho. Os testes de desempenho dependem dos requisitos para modelar com precisão as interações do usuário e as expectativas de nível de serviço, e esses insights podem ser usados para indicar quando uma solução está pronta para produção.
A equipe também precisa determinar o que será considerado um sucesso. Entender a jornada é fundamental, mas qual a quantidade de desempenho e disponibilidade considerada aceitável? Diferentes organizações terão tolerâncias diferentes para interrupções e tempos de resposta dependendo da importância de diferentes partes da aplicação para o negócio.
2. Onde estão os seus clientes?
Ter uma resposta rápida em uma região estratégica evita que seus visitantes o abandonem e ajuda a gerar mais conversões.
A necessidade de celeridade — considere o seguinte:
- 47% dos clientes esperam que um site seja carregado 2 segundos ou menos.
- 40% dos clientes abandonarão um site que leva mais de 3 segundos para carregar.
- Um atraso de 100 milissegundos no tempo de resposta da página diminui as taxas de conversão em 7%.
- Depois de esperar por 3 segundos, há um Redução de 16% na satisfação do cliente por cada segundo.
- A velocidade da página é agora um fator de classificação SEO direto por Atualização de velocidade do algoritmo do Google.
Manter uma infraestrutura altamente disponível e distribuída globalmente pode ser complexo e dispendioso para operar, bem como para hospedar. Para mitigar riscos e aumentar a eficiência, é vital saber onde seus clientes estão e que tipo de latências são permitidas em regiões que não são estratégicas para o seu negócio.
Você também pode investigar se a experiência do visitante pode aproveitar as Redes de Entrega de Conteúdo (CDNs) ou outras tecnologias de entrega de borda, como a solução Experience Edge da Sitecore para alcançar o seu público onde ele está.
3. Você planeja aproveitar a personalização?
A personalização é uma tática cada vez mais crítica para o sucesso. No entanto, aproveitar a personalização aumenta significativamente a complexidade de uma implantação, uma vez que afeta o desempenho e as características de escala. Também é necessário projetar o pico de uso no futuro, a fim de construir a capacidade do banco de dados de coleta. Testes de desempenho precisos são a única maneira de validar a capacidade de coleta para uma solução específica.
Planejar dias ou períodos de pico devido a campanhas sazonais ou lançamentos de produtos pode ser interessante. Análise de experiência precisa de ser dimensionado para o pior cenário se for pontual, mas nem sempre faz sentido, do ponto de vista dos custos, construir um ambiente para estas circunstâncias extraordinárias. Como tal, pode optar por desativar a análise durante os períodos de pico e, em vez disso, dimensionar para os picos médios encontrados ao longo do ano.
Analytics: ativar ou desativar?
O Analytics tem um impacto significativo em cada visita a uma solução. As organizações precisam fazer uma avaliação de custo-benefício para decidir se é mais vantajoso construir a infraestrutura para picos esperados e obter dados analíticos precisos ou desabilitar análises para economizar custos relacionados à topologia de implantação necessária.
Uma consideração importante é que a análise limitando a escala pode levar a tempo de inatividade em situações extremas de uso e, como tal, manter a análise habilitada para períodos de pico conhecidos é um risco que muitas organizações (especialmente aquelas no espaço B2C) não estão dispostas a correr.
Também é necessário prestar muita atenção ao combinar distribuição geográfica com análise. Se você está alavancando Sitecore Experience Database™ (xDB) — que é usado para criar uma visão de 360 graus do cliente, coletando e conectando dados entre canais em tempo real — e recursos nativos de rastreamento, cada solicitação precisará de um novo contato ou de um contato conhecido reidratado. Se o banco de dados de análise de Sitecore não estiver próximo ao local da solicitação de origem, isso afetará o desempenho observado nesse cliente. Geralmente, é melhor ter análises geograficamente situadas com a implantação da solução. No entanto, quando várias localizações geográficas fazem parte da solução, o desenvolvimento adicional é frequentemente necessário para garantir o desempenho e as preocupações funcionais.
Ainda sobre o tema de aproveitar a personalização por meio de experience analytics, é importante ter cuidado com chamadas assíncronas de JavaScript e XML (AJAX) que fluem de volta para os servidores de entrega. O Google Analytics depende de provedores de sessão ASP.NET, o que pode causar problemas de desempenho quando várias solicitações do mesmo contato fluem em paralelo. Além disso, as soluções devem definir quais solicitações precisam ser rastreadas e definir qualquer solicitação somente leitura.
Sobre solicitações somente leitura
Uma etapa crítica na otimização do uso do Sitecore xDB por uma solução é identificar solicitações que não devem fazer parte do rastreamento do xDB e solicitações que podem ser marcadas como somente leitura porque não gravam nenhuma informação de contato ou interação.
As solicitações somente leitura são especialmente importantes em soluções que incorporam solicitações paralelas com o mesmo contato e são frequentemente associadas ao AJAX. Solicitações paralelas não marcadas como somente leitura podem introduzir problemas de tempo de resposta, uma vez que cada solicitação deve aguardar acesso exclusivo ao objeto de sessão.
Normalmente, o Redis é o Provedor de Sessão recomendado. No entanto, uma preocupação com o Redis é que o banco de dados está na memória, o que restringe o pico de sessões do usuário. Você precisará levar em conta o número máximo de sessões paralelas e dimensionar o Redis adequadamente para acomodar o uso.
Também é uma prática recomendada incluir uma estratégia para a limpeza do banco de dados de coleta, que envolve determinar o período de tempo que os dados precisam ser mantidos. Normalmente, uma rotina é configurada para limpar dados com base no valor comercial, permitindo efetivamente que os pontos de extremidade de análise mantenham a qualidade do desempenho. Em implantações maiores, é aconselhável usar uma instância de expiração de sessão dedicada, o que garante o uso ideal de recursos de entrega.
4. Está a vender alguma coisa?
Uma quantidade significativa de conteúdo pode ser armazenada em cache para otimizar a entrega. No entanto, as experiências de compra são transacionais e únicas para cada cliente. Se a sua organização planeia ter uma capacidade de comércio através do seu canal, terá de abordar o seguinte:
- Onde ocorre a transação (país, estado)?
- Onde estão os gargalos no fluxo de compras/pedidos?
- Existem épocas de grande atividade?
- Qual é o tamanho do seu catálogo (quantos produtos, relacionamentos, idiomas, cartões de preço, cupons, categorias)?
- Quantos são esperados cheques/segundo pico?
- Quais são os perfis de clientes de pico?
- Quantos itens são esperados em carrinhos? (note que B2B tende a exigir carrinhos maiores do que B2C)
Equilibrar as necessidades de capacidade e velocidade para vários cenários de cima pode ajudar no desempenho e no planejamento. Por exemplo, você pode estar executando muito do seu conteúdo como um site estático com velocidades de resposta globais significativas em sua rede de entrega de borda. Os usuários podem estar tendo uma ótima experiência com essa parte do site, mas se o back-end de pedidos não puder lidar com transações de uma determinada região ou país, sua experiência de comércio será prejudicada. Dimensionar seus recursos de comércio para manter essa experiência rápida é fundamental.
5. Como podemos ver o que está a acontecer?
O monitoramento e a observabilidade são fundamentais para poder responder às demandas de escala. Você precisa ser capaz de identificar alterações no desempenho e, ao mesmo tempo, permitir que suas equipes se aprofundem para descobrir onde estão os gargalos de desempenho e os problemas de integridade do serviço. Um monitoramento eficaz ajuda sua organização a se antecipar aos problemas e dimensionar os recursos certos no momento certo.
Kubernetes (K8s) pode ajudar a simplificar este processo, estabelecendo uma infraestrutura de hospedagem dinâmica. Isso efetivamente aloca recursos para várias cargas de trabalho e fornece balanceamento de carga entre as instâncias que compõem as cargas de trabalho de uma solução. Com o controle granular sobre a infraestrutura, as equipes de operações podem responder dinamicamente a muitas situações de maneira mais econômica do que tentar provisionar demais antecipadamente.
Você também pode aproveitar ferramentas de monitoramento ou observabilidade, como Azure Application Insights, Grafana, Prometheus, New Relic, Datadog, Honeycomb ou qualquer número de outras ferramentas disponíveis. Essas ferramentas permitem que você visualize os dados sobre suas métricas de desempenho e identifique flutuações, cenários de perigo e analise possíveis áreas problemáticas. Você também pode se envolver Sitecore Managed Cloud ou seu parceiro de hospedagem para ajudar a adicionar esses recursos à sua solução.
Por exemplo, vamos supor que a infraestrutura está configurada para ser dimensionada automaticamente dada uma demanda específica para manter uma ótima experiência. Os usuários estão felizes! No entanto, a longo prazo, você quer manter seus custos operacionais baixos para que sua equipe também esteja feliz. Isso significa que você precisa ser capaz de ver quando esses problemas de desempenho estão acontecendo e começar a analisar as causas dos problemas. Pode haver uma falha na lógica do aplicativo, ou uma configuração específica que esteja causando um bloqueio, ou algum outro motivo que esteja fazendo com que seu aplicativo precise ser dimensionado. Se você puder identificar e eliminar essa causa subjacente, isso também eliminará a necessidade de dimensionamento automático futuro para esse cenário.
Próximos passos
As experiências digitais ligam as marcas aos clientes. Para estabelecer uma conexão forte, os desenvolvedores devem criar e oferecer essas experiências em vários pontos de contato digitais. Para mover sua organização nessa direção, recomendamos as seguintes etapas:
- Reveja as respostas às cinco perguntas destacadas acima com a sua equipa.
- Determine seu nível de conforto sobre como gerenciar e monitorar seu processo de escala.
- Continue abordando essas questões periodicamente e antes de qualquer evento que gere novos padrões de tráfego e/ou utilize novos canais.
Também encorajamos você a consultar o Sitecore Insights Blogs, que oferece uma biblioteca crescente de artigos de liderança de pensamento, abordando vários públicos sobre inúmeros aspetos da transformação digital. Visite agora.