{"id":17982,"date":"2021-05-13T11:41:35","date_gmt":"2021-05-13T11:41:35","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/05\/13\/monitoramento-de-experiencias-digitais-uma-visao-geral\/"},"modified":"2026-08-26T18:44:56","modified_gmt":"2026-08-26T18:44:56","slug":"monitoramento-de-experiencias-digitais-uma-visao-geral","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/monitoramento-de-experiencias-digitais-uma-visao-geral\/","title":{"rendered":"O que \u00e9 Monitoramento de Experi\u00eancia Digital? Como Observar Jornadas do Cliente de Fora para Dentro"},"content":{"rendered":"<figure id=\"attachment_34540\" aria-describedby=\"caption-attachment-34540\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34540\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring.webp\" alt=\"Um painel de opera\u00e7\u00f5es de ecommerce mostrando um status verde de uptime ao lado de uma etapa de checkout com falha\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/hero-digital-experience-monitoring-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34540\" class=\"wp-caption-text\">Um painel verde de uptime e um checkout com problema podem acontecer ao mesmo tempo.<\/figcaption><\/figure>\n<p>Seu monitor de uptime informa 100%. Seus servidores est\u00e3o respondendo em 180 ms. E os pedidos ca\u00edram 30% desde ter\u00e7a-feira de manh\u00e3.<\/p>\n<p>O monitoramento da experi\u00eancia digital (DEM) existe para essa situa\u00e7\u00e3o. M\u00e9tricas do lado do servidor confirmam que sua infraestrutura atendeu \u00e0 solicita\u00e7\u00e3o. Elas n\u00e3o dizem nada sobre se um comprador em Frankfurt conseguiu realmente concluir o checkout em um Android intermedi\u00e1rio com um script de pagamento lento na frente do bot\u00e3o de pagamento.<\/p>\n<p>A maioria dos guias sobre esse tema define DEM para equipes de TI que monitoram laptops de funcion\u00e1rios e t\u00faneis VPN. Este aborda a outra vers\u00e3o: monitorar as jornadas voltadas para o cliente que geram receita. O que o DEM mede, onde cada fonte de dados fica cega, como configur\u00e1-lo em uma loja real e qual verifica\u00e7\u00e3o do Dotcom-Monitor captura cada falha.<\/p>\n<p><strong>O que tem neste guia<\/strong><\/p>\n<ul>\n<li><a href=\"#o-que-\u00e9-monitoramento-da-experi\u00eancia-digital\">O que \u00e9 Monitoramento da Experi\u00eancia Digital?<\/a><\/li>\n<li><a href=\"#por-que-seus-pain\u00e9is-ficam-verdes-enquanto-o-checkout-est\u00e1-quebrado\">Por que seus pain\u00e9is ficam verdes enquanto o checkout est\u00e1 quebrado<\/a><\/li>\n<li><a href=\"#monitoramento-sint\u00e9tico-vs-rum-vs-an\u00e1lise-de-caminho-de-rede\">Monitoramento sint\u00e9tico vs. RUM vs. an\u00e1lise de caminho de rede<\/a><\/li>\n<li><a href=\"#o-que-medir-em-um-caminho-de-receita\">O que medir em um caminho de receita<\/a><\/li>\n<li><a href=\"#quatro-falhas-que-seu-check-de-uptime-n\u00e3o-detectar\u00e1\">Quatro falhas que seu check de uptime n\u00e3o detectar\u00e1<\/a><\/li>\n<li><a href=\"#como-configurar-o-monitoramento-da-experi\u00eancia-digital\">Como configurar o Monitoramento da Experi\u00eancia Digital<\/a><\/li>\n<li><a href=\"#como-escolher-uma-ferramenta-de-monitoramento-da-experi\u00eancia-digital\">Como escolher uma ferramenta de Monitoramento da Experi\u00eancia Digital<\/a><\/li>\n<li><a href=\"#como-o-dotcom-monitor-lida-com-o-monitoramento-da-experi\u00eancia-digital\">Como o Dotcom-Monitor lida com o Monitoramento da Experi\u00eancia Digital<\/a><\/li>\n<li><a href=\"#heading-faq\">Perguntas frequentes sobre Monitoramento da Experi\u00eancia Digital<\/a><\/li>\n<li><a href=\"#conclus\u00e3o\">Conclus\u00e3o<\/a><\/li>\n<\/ul>\n<h2 id='o-que-\u00e9-monitoramento-da-experi\u00eancia-digital'  id=\"boomdevs_1\" id=\"what-is-digital-experience-monitoring\">O que \u00e9 Monitoramento da Experi\u00eancia Digital?<\/h2>\n<p>O monitoramento da experi\u00eancia digital \u00e9 a pr\u00e1tica de medir como as pessoas experimentam seu site ou aplicativo de ponta a ponta, atrav\u00e9s da rede, navegador e dispositivo que usam para acessar voc\u00ea. Em vez de perguntar &#8220;o servidor respondeu?&#8221;, pergunta &#8220;algu\u00e9m conseguiu concluir o que veio fazer aqui, e quanto tempo levou?&#8221;. Essa medi\u00e7\u00e3o pode vir de sess\u00f5es reais, de jornadas roteirizadas executadas em uma programa\u00e7\u00e3o, ou de ambos.<\/p>\n<p>O escopo \u00e9 mais amplo que uptime. Uma configura\u00e7\u00e3o DEM monitora a renderiza\u00e7\u00e3o da p\u00e1gina, transa\u00e7\u00f5es multilplexo como busca e checkout, as APIs por tr\u00e1s dessas etapas, scripts de terceiros e como tudo isso muda por regi\u00e3o, navegador e velocidade de conex\u00e3o. Voc\u00ea ver\u00e1 essa pr\u00e1tica vendida tamb\u00e9m como monitoramento da experi\u00eancia do usu\u00e1rio final, monitoramento da experi\u00eancia da aplica\u00e7\u00e3o, ou gest\u00e3o da experi\u00eancia digital. Os r\u00f3tulos diferem; o que \u00e9 medido, em grande parte, n\u00e3o.<\/p>\n<h3 id='os-dois-tipos-de-dem-e-por-que-eles-se-confundem'  id=\"boomdevs_2\" id=\"the-two-kinds-of-dem-and-why-they-get-confused\">Os dois tipos de DEM (e por que eles se confundem)<\/h3>\n<p>Pesquise esse termo e a primeira p\u00e1gina tende a favorecer fortemente fornecedores de rede e seguran\u00e7a: Palo Alto Networks, Fortinet, Cloudflare, ThousandEyes, Tanium. A maior parte do que essas p\u00e1ginas descrevem \u00e9 voltada para o empregado, monitorando a sa\u00fade dos endpoints, t\u00faneis SASE e o caminho entre o laptop do trabalhador remoto e o Microsoft 365. Alguns tamb\u00e9m cobrem o tr\u00e1fego do cliente, mas as defini\u00e7\u00f5es no topo dos resultados tendem \u00e0 for\u00e7a de trabalho.<\/p>\n<p>Esse \u00e9 um segmento real resolvendo um problema real. S\u00f3 n\u00e3o \u00e9 o problema que uma equipe de ecommerce ou opera\u00e7\u00f5es digitais tem.<\/p>\n<p>A vers\u00e3o voltada para o cliente aponta para fora. Seus usu\u00e1rios s\u00e3o estranhos em redes que voc\u00ea n\u00e3o controla, usando dispositivos que voc\u00ea n\u00e3o forneceu, e saem sem abrir um chamado. Ningu\u00e9m reclama sobre um campo de c\u00f3digo promocional quebrado. Eles v\u00e3o para a concorr\u00eancia.<\/p>\n<blockquote><p>DEM para funcion\u00e1rios responde &#8220;por que a chamada no Zoom da Sarah est\u00e1 inst\u00e1vel.&#8221; DEM para clientes responde &#8220;por que as finaliza\u00e7\u00f5es de carrinho ca\u00edram 18% no Brasil ontem \u00e0 noite.&#8221; Mesmo acr\u00f4nimo, ferramentas diferentes, donos diferentes.<\/p><\/blockquote>\n<p>O restante deste guia trata do segundo caso.<\/p>\n<h2 id='por-que-seus-pain\u00e9is-ficam-verdes-enquanto-o-checkout-est\u00e1-quebrado'  id=\"boomdevs_3\" id=\"why-your-dashboards-go-green-while-checkout-is-broken\">Por que seus pain\u00e9is ficam verdes enquanto o checkout est\u00e1 quebrado<\/h2>\n<p>Tr\u00eas configura\u00e7\u00f5es comuns falham da mesma forma, e falham silenciosamente.<\/p>\n<p><strong>Um ping de uptime verifica a coisa errada.<\/strong> Um check HTTP na sua homepage confirma que uma URL retornou 200. O checkout pode retornar 200 com &#8220;N\u00e3o conseguimos processar seu pagamento&#8221; exibido na p\u00e1gina. O c\u00f3digo de status n\u00e3o opina sobre o conte\u00fado.<\/p>\n<p><strong>M\u00e9tricas do lado do servidor param na sua borda.<\/strong> Tempo de resposta da aplica\u00e7\u00e3o, CPU e taxa de erros descrevem sua infraestrutura. N\u00e3o incluem resolu\u00e7\u00e3o de DNS, handshake TLS, comportamento no CDN edge, execu\u00e7\u00e3o de tags de terceiros ou os 2.8 segundos que um widget de chat bloqueia a thread principal no celular.<\/p>\n<p><strong>O monitoramento de usu\u00e1rio real tem um problema de sobreviv\u00eancia.<\/strong> <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/aprenda-com-o-dotcom-monitor\/glossario\/o-que-e-o-real-user-monitoring-rum\/\">O monitoramento de usu\u00e1rio real<\/a> coleta dados de um beacon JavaScript dentro da p\u00e1gina. Ou seja, reporta apenas sess\u00f5es onde a p\u00e1gina carregou e o beacon foi disparado. Usu\u00e1rios que sofrem uma falha de DNS, um 403 do CDN, ou um erro TLS nunca chegam a carregar o beacon, ent\u00e3o n\u00e3o reportam nada. As piores quedas produzem menos dados RUM, e o tr\u00e1fego que desaparece silenciosamente parece um dia lento de vendas.<\/p>\n<p>A velocidade de detec\u00e7\u00e3o agrava tudo isso. Muitas falhas reais s\u00e3o curtas, e falhas curtas s\u00e3o as que ningu\u00e9m percebe olhando um painel. Se seus cheques rodam a cada cinco minutos, uma falha de quatro minutos pode come\u00e7ar e terminar entre eles e n\u00e3o deixar evid\u00eancias exceto os pedidos que voc\u00ea n\u00e3o recebeu.<\/p>\n<p>Fechar essas tr\u00eas lacunas requer as mesmas tr\u00eas coisas: checar de fora da sua pr\u00f3pria infraestrutura, renderizar em um navegador real e julgar o resultado pelo conte\u00fado da p\u00e1gina e n\u00e3o pelos c\u00f3digos de status. \u00c9 o que o <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/synthetic-monitoring\/\">monitoramento sint\u00e9tico<\/a> faz, e \u00e9 o que o restante deste guia explica.<\/p>\n<h2 id='monitoramento-sint\u00e9tico-vs-rum-vs-an\u00e1lise-de-caminho-de-rede'  id=\"boomdevs_4\" id=\"synthetic-monitoring-vs-rum-vs-network-path-analysis\">Monitoramento Sint\u00e9tico vs RUM vs An\u00e1lise de Caminho de Rede<\/h2>\n<p>Analistas normalmente dividem DEM em tr\u00eas entradas. Elas se sobrep\u00f5em e cada uma fica cega onde as outras veem.<\/p>\n<figure id=\"attachment_34547\" aria-describedby=\"caption-attachment-34547\" style=\"width: 896px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34547\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots.webp\" alt=\"Matriz de cobertura mostrando quais etapas do caminho da requisi\u00e7\u00e3o o monitoramento sint\u00e9tico, monitoramento de usu\u00e1rio real e an\u00e1lise de caminho de rede cobrem\" width=\"896\" height=\"406\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots.webp 896w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots-300x136.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-data-sources-blind-spots-768x348.webp 768w\" sizes=\"(max-width: 896px) 100vw, 896px\" \/><figcaption id=\"caption-attachment-34547\" class=\"wp-caption-text\">Cada fonte de dados cobre um trecho diferente do caminho entre um cliente e sua origem.<\/figcaption><\/figure>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Fonte<\/th>\n<th>O que mede<\/th>\n<th>O que captura primeiro<\/th>\n<th>Ponto cego<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Monitoramento sint\u00e9tico<\/td>\n<td>Jornadas roteirizadas executadas em programa\u00e7\u00e3o de locais fixos, em navegador real<\/td>\n<td>Etapas quebradas, falhas regionais, lentid\u00e3o de terceiros, certificados expirados, quedas fora de pico<\/td>\n<td>Testa apenas os caminhos que voc\u00ea roteirizou, com os dispositivos e locais escolhidos<\/td>\n<\/tr>\n<tr>\n<td>Monitoramento de usu\u00e1rio real<\/td>\n<td>Dados de campo de sess\u00f5es reais: Core Web Vitals, mistura de dispositivos, mistura de navegadores<\/td>\n<td>Problemas em dispositivos e navegadores pouco comuns, distribui\u00e7\u00e3o real do tr\u00e1fego<\/td>\n<td>Vi\u00e9s de sobreviv\u00eancia: precisa de tr\u00e1fego e p\u00e1gina que carregou. Silencioso durante falhas severas e em p\u00e1ginas de baixo volume<\/td>\n<\/tr>\n<tr>\n<td>An\u00e1lise de caminho de rede<\/td>\n<td>Roteamento hop-a-hop, lat\u00eancia e perda de pacotes entre pontos de vantage e seu servi\u00e7o<\/td>\n<td>Altera\u00e7\u00f5es de roteamento ISP, problemas de peering, quest\u00f5es BGP, lat\u00eancia regional<\/td>\n<td>N\u00e3o informa se a l\u00f3gica do aplicativo funcionou<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Sint\u00e9tico e RUM s\u00e3o a combina\u00e7\u00e3o que a maioria das equipes realmente usa. Sint\u00e9tico oferece um sinal constante que n\u00e3o depende de algu\u00e9m estar acordado e fazendo compras. RUM mostra como \u00e9 seu p\u00fablico real. Use sint\u00e9tico para detectar e alertar, RUM para priorizar o que corrigir.<\/p>\n<p>O Dotcom-Monitor cobre as linhas um e tr\u00eas. <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/monitoramento-de-aplicativos-web\/\">Monitoramento de aplica\u00e7\u00f5es web<\/a> executa as jornadas roteirizadas no navegador, e os cheques de Infraestrutura de Internet cuidam do DNS, TLS e das camadas de rede abaixo deles. N\u00e3o coleta dados RUM, ent\u00e3o se quiser an\u00e1lises por sess\u00e3o de compradores reais, use uma ferramenta de monitoramento de usu\u00e1rio real lado a lado.<\/p>\n<p>O sint\u00e9tico tem um limite pr\u00f3prio: s\u00f3 conhece as jornadas que voc\u00ea roteiriza. Se ningu\u00e9m roteirizou o checkout de convidado, o checkout de convidado pode ficar quebrado por uma semana.<\/p>\n<h2 id='o-que-medir-em-um-caminho-de-receita'  id=\"boomdevs_5\" id=\"what-to-measure-on-a-revenue-path\">O que medir em um caminho de receita<\/h2>\n<p>Comece pela jornada, n\u00e3o pela lista de m\u00e9tricas. Para a maioria dos sites de ecommerce e SaaS, quatro caminhos carregam quase todo o risco: busca, adicionar ao carrinho, checkout e login.<\/p>\n<p>Para cada um, acompanhe:<\/p>\n<ul>\n<li><strong>Sucesso em n\u00edvel de etapa.<\/strong> Cada etapa foi conclu\u00edda e a p\u00e1gina continha o texto esperado? Um n\u00famero de confirma\u00e7\u00e3o \u00e9 um sinal melhor que um c\u00f3digo de status. No EveryStep, isso \u00e9 uma <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/assertions-monitoring\/\">afirma\u00e7\u00e3o de conte\u00fado<\/a> ligada a cada passo, podendo checar texto, elementos, status HTTP, cabe\u00e7alhos de resposta ou payload JSON.<\/li>\n<li><strong>Dura\u00e7\u00e3o em n\u00edvel de etapa.<\/strong> Tempo total da jornada esconde o problema. Voc\u00ea quer ver que &#8220;aplicar c\u00f3digo promocional&#8221; foi de 400 ms para 9 segundos enquanto o resto permaneceu est\u00e1vel. Os Script Time Watchers do EveryStep definem limite por etapa, para que uma falhe sozinha ao inv\u00e9s de desaparecer dentro de uma jornada que ainda passa.<\/li>\n<li><strong>Core Web Vitals.<\/strong> Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift nas p\u00e1ginas que convertem, n\u00e3o s\u00f3 na homepage. O <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/monitoramento-de-paginas-da-web-dotcom-monitor\/\">monitoramento de p\u00e1ginas<\/a> reporta isso por p\u00e1gina junto ao gr\u00e1fico de waterfall dos elementos.<\/li>\n<li><strong>Tempo para o primeiro byte (TTFB).<\/strong> Separa o atraso em obter a primeira resposta, que inclui DNS, TLS, redirecionamentos, comportamento CDN edge e lat\u00eancia de origem, do trabalho de renderiza\u00e7\u00e3o que ocorre depois. Uma p\u00e1gina lenta com TTFB r\u00e1pido \u00e9 um problema de front-end.<\/li>\n<li><strong>Tempo dos elementos de terceiros.<\/strong> Fornecedores de pagamento, gerenciadores de tags, widgets de chat, plataformas de avalia\u00e7\u00e3o, pixels de an\u00fancios. O <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/monitoramento-de-conteudo-de-terceiros\/\">monitoramento de conte\u00fado de terceiros<\/a> importa porque s\u00e3o ativos que voc\u00ea n\u00e3o pode corrigir, s\u00f3 contornar. O gr\u00e1fico waterfall lista cada requisi\u00e7\u00e3o de terceiro como linha pr\u00f3pria, mostrando qual fornecedor adicionou 900 ms neste m\u00eas. Monitore tamb\u00e9m os dom\u00ednios de terceiros: um gateway de pagamento com certificado expirado derruba o checkout tanto quanto sua pr\u00f3pria queda.<\/li>\n<li><strong>Tempo e corre\u00e7\u00e3o da resposta da API.<\/strong> Invent\u00e1rio, pre\u00e7os, impostos, frete e pagamentos est\u00e3o atr\u00e1s de cada passo do funil. Os cheques Web Services acessam direto essas APIs e fazem afirma\u00e7\u00f5es sobre o corpo da resposta, para pegar payloads ruins antes que cheguem a uma p\u00e1gina.<\/li>\n<li><strong>Sa\u00fade de certificado e DNS.<\/strong> Um certificado expirado em um subdom\u00ednio de pagamento derruba o checkout completamente, e \u00e9 totalmente evit\u00e1vel com <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/ssl-certificate-monitoring\/\">monitoramento de certificados SSL<\/a> e <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/ferramenta-de-monitorizacao-de-dns-dotcom-monitor\/\">monitoramento de DNS<\/a> rodando junto com os cheques no navegador.<\/li>\n<li><strong>Varia\u00e7\u00e3o geogr\u00e1fica.<\/strong> A mesma p\u00e1gina vista de Chicago, Londres e Singapura. Diverg\u00eancias entre locais geralmente apontam para CDN ou DNS e n\u00e3o seu aplicativo, por isso o Dotcom-Monitor roda o mesmo script em 30+ locais globais, n\u00e3o em apenas um.<\/li>\n<\/ul>\n<h2 id='quatro-falhas-que-seu-check-de-uptime-n\u00e3o-detectar\u00e1'  id=\"boomdevs_6\" id=\"four-failures-your-uptime-check-will-miss\">Quatro falhas que seu check de uptime n\u00e3o detectar\u00e1<\/h2>\n<p>Cada uma deixa um painel verde de uptime para tr\u00e1s.<\/p>\n<h3 id='1-a-p\u00e1gina-de-erro-200-ok'  id=\"boomdevs_7\" id=\"1-the-200-ok-error-page\">1. A p\u00e1gina de erro 200 OK<\/h3>\n<p>Um processador de cart\u00e3o muda um contrato de API. Seu checkout captura a exce\u00e7\u00e3o, exibe uma mensagem amig\u00e1vel &#8220;Algo deu errado, tente novamente&#8221; e retorna HTTP 200. Todo check de uptime na internet diz que o site est\u00e1 ok. Os pedidos param.<\/p>\n<p>A corre\u00e7\u00e3o \u00e9 uma afirma\u00e7\u00e3o de conte\u00fado: a jornada roteirizada tem que encontrar o n\u00famero de confirma\u00e7\u00e3o do pedido, ou a etapa falha.<\/p>\n<p><strong>O que captura:<\/strong> um cheque Web Applications (UserView) com uma afirma\u00e7\u00e3o na etapa de confirma\u00e7\u00e3o. O EveryStep valida o texto renderizado, ent\u00e3o &#8220;Algo deu errado&#8221; falha o check mesmo com o servidor retornando 200.<\/p>\n<h3 id='2-um-script-de-terceiros-que-s\u00f3-prejudica-o-mobile'  id=\"boomdevs_8\" id=\"2-a-third-party-script-that-only-hurts-mobile\">2. Um script de terceiros que s\u00f3 prejudica o mobile<\/h3>\n<p>Uma equipe de marketing adiciona uma tag de personaliza\u00e7\u00e3o. No desktop mal se nota. Em uma conex\u00e3o m\u00f3vel limitada, adiciona tr\u00eas segundos antes do bot\u00e3o de pagamento ficar interativo, ent\u00e3o a convers\u00e3o m\u00f3vel cai enquanto o desktop parece normal. Ningu\u00e9m conecta isso por uma semana, porque a implanta\u00e7\u00e3o veio de um gerenciador de tags, n\u00e3o de um release.<\/p>\n<p>Rodar o checkout tanto em desktop quanto em perfil m\u00f3vel limitado deixa a divis\u00e3o vis\u00edvel no mesmo dia. \u00c9 por isso que o <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/browser-monitoring-in-e-commerce-conversion-optimization\/\">monitoramento do navegador para otimiza\u00e7\u00e3o de convers\u00e3o<\/a> aparece sempre em an\u00e1lises de funil p\u00f3s-morte.<\/p>\n<p><strong>O que captura:<\/strong> o mesmo script EveryStep reproduzido em 40+ navegadores e dispositivos m\u00f3veis assim como no desktop. Compare os tempos por etapa entre os dois e a tag aparece como uma etapa lenta \u00fanica, n\u00e3o um vago &#8220;o site est\u00e1 lento no m\u00f3vel.&#8221;<\/p>\n<h3 id='3-uma-falha-regional-de-cdn-ou-dns'  id=\"boomdevs_9\" id=\"3-a-regional-cdn-or-dns-failure\">3. Uma falha regional de CDN ou DNS<\/h3>\n<p>Um push de configura\u00e7\u00e3o no CDN quebra um ponto de presen\u00e7a. Clientes em S\u00e3o Paulo recebem 403 do edge e nunca carregam seu JavaScript. Seus dados RUM n\u00e3o caem, apenas param de receber sess\u00f5es brasileiras, o que parece um dia fraco de tr\u00e1fego.<\/p>\n<p>Uma localiza\u00e7\u00e3o de monitoramento em S\u00e3o Paulo falha no primeiro check. Esse \u00e9 o argumento para uma <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/recursos-monitoramento-de-rede\/\">rede de monitoramento global<\/a>, e n\u00e3o cheques de apenas uma regi\u00e3o de nuvem.<\/p>\n<p><strong>O que captura:<\/strong> rodar a jornada de 30+ locais, com grava\u00e7\u00e3o de v\u00eddeo sincronizada ao gr\u00e1fico waterfall na falha. Voc\u00ea v\u00ea a p\u00e1gina 403 que o cliente brasileiro viu e a requisi\u00e7\u00e3o que a produziu, ao inv\u00e9s de um chamado de suporte tr\u00eas dias depois.<\/p>\n<h3 id='4-uma-api-que-degrada-ao-inv\u00e9s-de-falhar'  id=\"boomdevs_10\" id=\"4-an-api-that-degrades-instead-of-failing\">4. Uma API que degrada ao inv\u00e9s de falhar<\/h3>\n<p>Seu servi\u00e7o de c\u00e1lculo de frete come\u00e7a a responder em 11 segundos em vez de 300 ms. Nunca retorna erro, ent\u00e3o alertas de taxa de erro ficam silenciosos. Clientes chegam na etapa de frete, veem o spinner e desistem.<\/p>\n<p><strong>O que captura:<\/strong> um check Web Services (WebView) contra o endpoint de frete com limite de tempo de resposta e afirma\u00e7\u00e3o no JSON retornado. Isso dispara na API em si, em vez de esperar o timeout da jornada no navegador.<\/p>\n<h2 id='como-configurar-o-monitoramento-da-experi\u00eancia-digital'  id=\"boomdevs_11\" id=\"how-to-set-up-digital-experience-monitoring\">Como configurar o Monitoramento da Experi\u00eancia Digital<\/h2>\n<figure id=\"attachment_34554\" aria-describedby=\"caption-attachment-34554\" style=\"width: 2298px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34554\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map.webp\" alt=\"Diagrama de fluxo de uma jornada roteirizada de ecommerce da homepage para busca, para p\u00e1gina de produto, para carrinho, para checkout, para confirma\u00e7\u00e3o, com afirma\u00e7\u00f5es e checkpoints de tempo em cada etapa\" width=\"2298\" height=\"568\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map.webp 2298w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-300x74.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-1024x253.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-768x190.webp 768w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-1536x380.webp 1536w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2019\/11\/dem-setup-journey-map-2048x506.webp 2048w\" sizes=\"(max-width: 2298px) 100vw, 2298px\" \/><figcaption id=\"caption-attachment-34554\" class=\"wp-caption-text\">Roteirize a jornada em etapas, depois fa\u00e7a afirma\u00e7\u00f5es sobre o que cada etapa deve conter.<\/figcaption><\/figure>\n<p>Esta ordem funciona tanto se voc\u00ea est\u00e1 come\u00e7ando do zero quanto se est\u00e1 aprofundando cheques de uptime j\u00e1 existentes.<\/p>\n<p><strong>Passo 1: Mapeie as jornadas que geram dinheiro.<\/strong> Extraia seu relat\u00f3rio de funil e liste os tr\u00eas a cinco caminhos que os clientes realmente fazem: busca, adicionar ao carrinho, checkout como convidado, checkout com conta, login. Anote a condi\u00e7\u00e3o exata de sucesso para cada um.<\/p>\n<p><strong>Passo 2: Grave cada jornada como uma transa\u00e7\u00e3o roteirizada.<\/strong> Clique no caminho uma vez no EveryStep Web Recorder e ele captura cliques, preenchimento de formul\u00e1rios, navega\u00e7\u00e3o e esperas, incluindo dropdowns, modais, conte\u00fado carregado via AJAX e iframes. N\u00e3o precisa escrever seletores. Trate os pontos complicados deliberadamente: banners de cookies, IDs din\u00e2micos de elementos, senhas de uso \u00fanico e um m\u00e9todo de pagamento teste que n\u00e3o cobrar\u00e1 ningu\u00e9m. D\u00ea ao script sua pr\u00f3pria conta teste e um SKU seguro para invent\u00e1rio, para que o monitoramento nunca crie pedidos reais. \u00c9 para isso que serve o <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/guia-de-monitoramento-de-transacoes-na-web\/\">monitoramento de transa\u00e7\u00f5es web<\/a>.<\/p>\n<p><strong>Passo 3: Adicione uma afirma\u00e7\u00e3o a cada etapa.<\/strong> Cada etapa verifica texto ou elemento que s\u00f3 aparece no sucesso: &#8220;Pedido confirmado&#8221;, um n\u00famero de confirma\u00e7\u00e3o, subtotal do carrinho que bate com o pre\u00e7o do item. O EveryStep tamb\u00e9m faz afirma\u00e7\u00f5es sobre status HTTP, cabe\u00e7alhos e payloads JSON, para que uma etapa possa falhar por m\u00e1 resposta de API antes mesmo da p\u00e1gina ser renderizada errada. Sem afirma\u00e7\u00f5es, voc\u00ea est\u00e1 de volta a checar c\u00f3digos de status.<\/p>\n<p><strong>Passo 4: Escolha locais e dispositivos que correspondam ao seu tr\u00e1fego.<\/strong> Pegue suas principais regi\u00f5es da an\u00e1lise e monitore nelas, n\u00e3o de onde seus servidores est\u00e3o. O Dotcom-Monitor oferece 30+ locais e 40+ navegadores e dispositivos m\u00f3veis, ent\u00e3o escolha os tr\u00eas ou quatro que correspondem ao seu p\u00fablico e adicione pelo menos um perfil m\u00f3vel throttled. Sua <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/frequencia-de-monitoramento-sintetico\/\">frequ\u00eancia e localiza\u00e7\u00e3o de monitoramento<\/a> devem refletir seus clientes reais.<\/p>\n<p><strong>Passo 5: Defina a frequ\u00eancia pelo impacto na receita.<\/strong> Checkout merece intervalo mais curto que uma p\u00e1gina de carreiras. Scripts de transa\u00e7\u00e3o completos custam mais para rodar que cheques de p\u00e1gina \u00fanica, ent\u00e3o invista onde est\u00e3o os pedidos.<\/p>\n<p><strong>Passo 6: Monitore os servi\u00e7os subjacentes.<\/strong> Adicione cheques para as APIs do funil, al\u00e9m de DNS, certificados TLS e qualquer endpoint parceiro no caminho de pagamento. O <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/monitoramento-de-api\/\">monitoramento de API<\/a> com afirma\u00e7\u00f5es de resposta captura degrada\u00e7\u00e3o que a jornada no navegador mostra depois.<\/p>\n<p><strong>Passo 7: Direcione alertas para que algu\u00e9m aja.<\/strong> Confirme uma falha de outro local antes de acionar algu\u00e9m, para eliminar falsos alertas por ru\u00eddo local. Use um segundo local na mesma regi\u00e3o. Checar em n\u00f3 outro continente suprime as falhas regionais que voc\u00ea quer capturar. As <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/recursos-alertas\/\">regras de alerta<\/a> do Dotcom-Monitor cuidam dos limites e da l\u00f3gica de confirma\u00e7\u00e3o, e encaminham para PagerDuty, Slack e Teams nativamente, para que falhas no checkout cheguem a quem pode reverter um deploy.<\/p>\n<p><strong>Passo 8: Reveja os waterfalls de forma regular.<\/strong> Uma vez por semana, abra o gr\u00e1fico waterfall da jornada mais lenta e veja o que mudou. Ativos de terceiros aumentam devagar e nunca se anunciam. Em uma execu\u00e7\u00e3o com falha, o waterfall vem junto com a grava\u00e7\u00e3o de v\u00eddeo da sess\u00e3o, que normalmente responde &#8220;o que o cliente realmente viu&#8221; em cerca de dez segundos. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/otimizando-o-desempenho-da-web-entendendo-graficos-de-cachoeira\/\">Ler gr\u00e1ficos waterfall<\/a> transforma um n\u00famero lento em um pedido espec\u00edfico de corre\u00e7\u00e3o, e <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/caracteristicas-relatorios\/\">pain\u00e9is p\u00fablicos e relat\u00f3rios por email<\/a> colocam os mesmos dados diante de quem pergunta sobre convers\u00e3o.<\/p>\n<h2 id='como-escolher-uma-ferramenta-de-monitoramento-da-experi\u00eancia-digital'  id=\"boomdevs_12\" id=\"how-to-choose-a-digital-experience-monitoring-tool\">Como escolher uma ferramenta de Monitoramento da Experi\u00eancia Digital<\/h2>\n<p>A maioria dos fornecedores mostrar\u00e1 um painel. Menos respondem a estas perguntas.<\/p>\n<ul>\n<li><strong>Roda em navegador real?<\/strong> Cheques em n\u00edvel HTTP n\u00e3o executam JavaScript, ent\u00e3o perdem tudo que uma loja moderna faz depois da resposta inicial.<\/li>\n<li><strong>Qu\u00e3o dif\u00edcil \u00e9 roteirizar uma jornada multilplexo?<\/strong> Se um script de checkout leva dois dias para criar, ningu\u00e9m o mant\u00e9m quando a p\u00e1gina do carrinho \u00e9 redesenhada.<\/li>\n<li><strong>De onde pode testar?<\/strong> Conte os locais que correspondem aos seus clientes, n\u00e3o o total. Vinte n\u00f3s na Am\u00e9rica do Norte n\u00e3o ajudam um lan\u00e7amento europeu.<\/li>\n<li><strong>Pode fazer afirma\u00e7\u00f5es sobre conte\u00fado, n\u00e3o s\u00f3 status?<\/strong> Isso separa monitoramento de transa\u00e7\u00e3o de um ping fancy.<\/li>\n<li><strong>Uma falha vem com dados de causa raiz?<\/strong> Um waterfall, um print no momento da falha, o elemento que falhou. Um alerta que s\u00f3 diz &#8220;checkout falhou&#8221; come\u00e7a sua investiga\u00e7\u00e3o do zero.<\/li>\n<li><strong>Se encaixa no seu fluxo de incidentes?<\/strong> Alertas que chegam no PagerDuty, Slack, Teams, SMS ou webhook s\u00e3o tratados. Alertas parados em dashboard que ningu\u00e9m abre, n\u00e3o.<\/li>\n<li><strong>Consegue alcan\u00e7ar ambientes internos ou staged?<\/strong> Apps pr\u00e9-produ\u00e7\u00e3o e firewallizados precisam de agente privado dentro da rede.<\/li>\n<li><strong>O que o pre\u00e7o faz ao adicionar jornadas?<\/strong> Pre\u00e7o por etapa ou por execu\u00e7\u00e3o pune o monitoramento profundo de jornada pelo qual voc\u00ea est\u00e1 pagando.<\/li>\n<\/ul>\n<h2 id='como-o-dotcom-monitor-lida-com-o-monitoramento-da-experi\u00eancia-digital'  id=\"boomdevs_13\" id=\"how-dotcom-monitor-handles-digital-experience-monitoring\">Como o Dotcom-Monitor lida com o Monitoramento da Experi\u00eancia Digital<\/h2>\n<p>O Dotcom-Monitor cobre o lado sint\u00e9tico do DEM, que \u00e9 a camada de detec\u00e7\u00e3o para tudo acima. Quatro tipos de dispositivos mapeiam as camadas da jornada do cliente e a maioria das lojas usa os quatro.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Tipo de dispositivo<\/th>\n<th>O que monitora<\/th>\n<th>O que fornece em caso de falha<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Aplica\u00e7\u00f5es Web<\/strong> (UserView)<\/td>\n<td>Jornadas multilplexo roteirizadas em navegador real: busca, carrinho, checkout, login<\/td>\n<td>Grava\u00e7\u00e3o de v\u00eddeo da sess\u00e3o sincronizada ao gr\u00e1fico waterfall, plus tempo por etapa<\/td>\n<\/tr>\n<tr>\n<td><strong>P\u00e1ginas Web<\/strong> (BrowserView)<\/td>\n<td>Renderiza\u00e7\u00e3o de p\u00e1gina \u00fanica, Core Web Vitals, tempo de elementos e ativos de terceiros<\/td>\n<td>Waterfall em n\u00edvel de elemento mostrando qual requisi\u00e7\u00e3o atrasou a p\u00e1gina<\/td>\n<\/tr>\n<tr>\n<td><strong>Servi\u00e7os Web<\/strong> (WebView)<\/td>\n<td>Chamadas REST, SOAP, GraphQL e importadas do Postman atr\u00e1s do funil<\/td>\n<td>Tempo de resposta, status, cabe\u00e7alhos e resultados de afirma\u00e7\u00f5es sobre o payload<\/td>\n<\/tr>\n<tr>\n<td><strong>Infraestrutura de Internet<\/strong> (ServerView)<\/td>\n<td>DNS, certificados TLS, email, FTP, TCP e cheques de ping<\/td>\n<td>Camada que falhou, para voc\u00ea parar de debugar app quando for um registro DNS<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>Jornadas s\u00e3o gravadas no <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/everystep\/\">EveryStep Web Recorder<\/a> como captura ponto-e-clique, n\u00e3o escrita manual de seletores, e reproduzidas em 40+ navegadores e dispositivos m\u00f3veis e 30+ locais na rede global de monitoramento. Limites por etapa capturam a etapa lenta. Afirma\u00e7\u00f5es de conte\u00fado capturam a etapa que parece ok mas n\u00e3o est\u00e1. <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/caracteristicas-agentes-privados\/\">Agentes privados<\/a> executam os mesmos cheques contra ambientes staged ou atr\u00e1s do firewall, o que \u00e9 importante para capturar um deploy de checkout ruim antes de ir para produ\u00e7\u00e3o.<\/p>\n<p>Duas ressalvas honestas. O Dotcom-Monitor \u00e9 plataforma sint\u00e9tica e n\u00e3o coleta dados RUM, ent\u00e3o use junto com uma ferramenta RUM se precisar de an\u00e1lises por sess\u00e3o. E n\u00e3o \u00e9 um APM: indica qual passo falhou e onde, n\u00e3o qual linha do c\u00f3digo causou. Equipes que precisam dos dois geralmente rodam <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/retail-and-ecommerce-monitoring\/\">monitoramento de varejo e ecommerce<\/a> junto com um APM interno, tratando a camada sint\u00e9tica como aviso pr\u00e9vio externo.<\/p>\n<h2 id='conclus\u00e3o'  id=\"boomdevs_14\" id=\"the-bottom-line\">Conclus\u00e3o<\/h2>\n<p>O monitoramento da experi\u00eancia digital fecha a lacuna entre &#8220;nossos servidores est\u00e3o no ar&#8221; e &#8220;nossos clientes conseguem comprar&#8221;. A maior parte da receita perdida por problemas de performance desaparece dentro dessa lacuna: p\u00e1ginas de erro 200 OK, scripts terceiros que s\u00f3 prejudicam o mobile, falhas regionais de CDN que seu dados RUM n\u00e3o veem, e APIs que degradam sem nunca gerar erro.<\/p>\n<p>Voc\u00ea n\u00e3o precisa de um programa grande para come\u00e7ar. Escolha a jornada de maior valor, grave no EveryStep com afirma\u00e7\u00e3o em cada passo, rode de tr\u00eas regi\u00f5es onde seus clientes est\u00e3o, e direcione alertas para quem possa agir. Esse check \u00fanico vai capturar falhas que seu painel atual est\u00e1 escondendo.<\/p>\n<p>Depois que rodar limpo por uma semana, roteirize a pr\u00f3xima jornada e repita. A maioria das equipes cobre todo o funil em tr\u00eas ou quatro ciclos.<\/p>\n<section class=\"final-cta\">\n<h2 id='monitore-as-jornadas-que-importam'  id=\"boomdevs_15\" id=\"see-what-external-checks-catch\">Monitore as Jornadas que Importam<\/h2>\n<p>Grave seu caminho de checkout no EveryStep, adicione uma afirma\u00e7\u00e3o na etapa de confirma\u00e7\u00e3o e execute de 30+ locais em navegadores reais. Comece um <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">teste gratuito do Dotcom-Monitor<\/a> e descubra o que seu painel de uptime tem ocultado.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Seu monitor de uptime informa 100%. Seus servidores est\u00e3o respondendo em 180 ms. E os pedidos ca\u00edram 30% desde ter\u00e7a-feira de manh\u00e3. O monitoramento da experi\u00eancia digital (DEM) existe para essa situa\u00e7\u00e3o. M\u00e9tricas do lado do servidor confirmam que sua infraestrutura atendeu \u00e0 solicita\u00e7\u00e3o. Elas n\u00e3o dizem nada sobre se um comprador em Frankfurt conseguiu [&hellip;]<\/p>\n","protected":false},"author":21,"featured_media":34545,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5170],"tags":[],"class_list":["post-17982","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nao-categorizado"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/17982","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=17982"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/17982\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/34545"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=17982"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=17982"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=17982"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}