Prazo da página de agradecimento do Shopify: auditoria até 26 de agosto

26 de agosto de 2026 é o prazo para lojas em planos Shopify não Plus atualizarem as páginas legadas de agradecimento e status do pedido para as novas versões. O guia de atualização para lojas não Plus da Shopify informa que, ao fazer a atualização, as páginas atuais e suas personalizações são substituídas. Apps incompatíveis, scripts, pixels e personalizações de página precisam ser revisados e trocados por opções compatíveis, quando ainda forem necessários.

Essas são páginas exibidas após o checkout. A Shopify descreve a página de agradecimento como uma página única, mostrada após a finalização bem-sucedida da compra, e a página de status do pedido como um destino que o cliente pode revisitar depois que o pedido é criado. Dependendo da configuração da loja, essas páginas também podem incluir rastreamento e conteúdos fornecidos por apps, como pesquisas, downloads, mensagens de fidelidade ou indicação, upsells, informações de entrega, ferramentas de devolução e links de suporte.

Para lojistas Shopify, gestores de ecommerce, agências e equipes de TI, esse prazo deve ser tratado como uma auditoria de migração e mensuração. O objetivo não é apenas publicar as novas páginas. É comprovar que os dados de receita, as experiências pós-compra e os fluxos operacionais continuam funcionando após a mudança.

O que a documentação da Shopify confirma

O prazo se aplica às páginas pós-checkout de agradecimento e status do pedido. A orientação publicada pela Shopify não anuncia uma desativação geral do checkout em 26 de agosto. Ela exige que lojas não Plus atualizem essas páginas até essa data e informa que as páginas existentes e suas personalizações são substituídas quando a atualização é feita. Esse texto não deve ser interpretado como garantia de que uma configuração de loja não testada ficará sem problemas.

A Shopify também informa separadamente que uma loja elegível que esteja usando a opção temporária de reversão será atualizada automaticamente se não fizer a atualização novamente antes de 26 de agosto. Essa observação aparece nas condições da reversão e não deve ser generalizada como um resultado universal documentado para todas as lojas não Plus.

Como a Shopify exige a substituição de rastreamentos incompatíveis e personalizações de página, os lojistas devem verificar cada função necessária após a migração, em vez de presumir que um script existente ou o comportamento de um app foi mantido.

O que está mudando?

A Shopify está substituindo as páginas legadas de pós-checkout por versões que usam o editor de checkout e contas, blocos de apps, extensões de UI do checkout e o framework de pixels da Shopify. Quando o lojista faz a atualização, as páginas atuais de agradecimento e status do pedido, junto com suas personalizações, são substituídas pelas novas páginas.

Os caminhos de substituição variam conforme a função da personalização antiga:

• O conteúdo visível da página deve ser migrado para recursos nativos da Shopify, blocos de apps compatíveis ou uma extensão personalizada de UI do checkout.
• Rastreamento e analytics devem ser migrados para app pixels ou, quando necessário, para um custom pixel revisado.
• Apps que ainda dependem de comportamentos legados incompatíveis precisam de uma atualização do fornecedor ou de substituição.
• Código que depende de scraping do DOM ou usa um pixel para renderizar elementos de interface não pode ser migrado sem alterações para o sandbox de pixels da Shopify; ele precisa de um mecanismo de substituição compatível.

A documentação para desenvolvedores da Shopify lista casos de uso compatíveis para extensões, como pesquisas, pedidos de avaliação, ofertas de upsell, compartilhamento social e links de download. Ela também diferencia a página única de agradecimento da página de status do pedido, que pode ser revisitada e onde os dados do pedido ficam disponíveis após a criação.

Por que isso é um projeto de rastreamento, e não apenas uma migração de página

Additional Scripts podiam ser usados para rastreamento e analytics ou para personalizações de página. O guia de atualização personalizado da Shopify identifica os scripts existentes e os categoriza por finalidade, incluindo categorias como autenticação e rastreamento de pedidos. Os lojistas devem documentar o que cada script listado faz, qual plataforma recebe seus dados e se a função ainda é necessária.

A Shopify informa que Additional Scripts não são compatíveis com as novas páginas. Para rastreamento, a Shopify recomenda app pixels e permite custom pixels quando um app adequado não atende à necessidade. Personalizações visíveis devem ser recriadas com blocos compatíveis ou outros recursos suportados.

A Shopify alerta que conectar um app pixel antes de desativar um Additional Script cria um curto período de eventos duplicados, enquanto desativar o script primeiro pode interromper o rastreamento durante a mudança. A sequência documentada pela Shopify é conectar e testar o pixel substituto, confirmar que a plataforma de destino está recebendo os eventos e só então desativar o script legado para evitar novas duplicidades.

Etapa 1: abra o guia de atualização personalizado da Shopify

Comece no admin da Shopify em Configurações > Checkout. Na seção Configurações, expanda o aviso com o título “Atualize as páginas de agradecimento e status do pedido até 26 de agosto de 2026” e selecione Revisar personalizações.

A Shopify gera um relatório específico da loja que identifica as personalizações existentes e separa apps compatíveis e incompatíveis, rastreamento e analytics, personalizações de página e Additional Scripts. Use esse relatório como inventário inicial e depois compare com os sistemas usados por marketing, financeiro, suporte, operações e agências externas.

Concluído quando: uma pessoa responsável documentou o guia de atualização e cada item listado tem um responsável, uma finalidade, um caminho de substituição e um status de teste.

Etapa 2: monte um inventário completo do pós-compra

Audite quatro grupos de dependências.

1. Rastreamento e analytics

• Eventos de compra no GA4 e Google Ads
• Pixels da Meta, TikTok, Pinterest ou outras plataformas de mídia
• Tags de conversão de afiliados e redes de parceiros
• Atribuição de receita para email ou SMS
• Testes A/B, gravação de sessão, mapas de calor e rastreamento de pesquisas
• Eventos personalizados de data layer e analytics internos

2. Conteúdo visível no pós-compra

• Pesquisas, pedidos de avaliação e convites para indicação
• Ofertas pós-compra, estímulos de recompra e mensagens de fidelidade
• Links de download de produtos digitais
• Instruções de entrega, retirada, armário inteligente, pagamento na entrega ou pagamento
• Links de suporte, informações de contato, políticas e mensagens de confiança

3. Ações do pedido e autoatendimento do cliente

• Rastreamento de pedidos e status de múltiplos envios
• Links para devoluções, trocas, cancelamento e edição de pedidos
• Links para gestão de assinatura ou renovação
• Funcionalidade de comprar novamente e recompra
• Autenticação da conta do cliente e links expirados da página de status do pedido

4. Premissas técnicas ocultas

• URLs da página de agradecimento fixadas no código
• Código que faz scraping do DOM ou lê variáveis irrestritas da página
• Scripts que assumem um número de pedido ou identificador de cliente específico
• Tags instaladas manualmente e também por meio de um app
• Domínios de conta do cliente que não compartilham o domínio raiz da loja virtual

Etapa 3: priorize pelo risco para o negócio

Não atribua a mesma urgência a toda personalização legada. Use três níveis de risco para que a equipe proteja primeiro a receita e a operação com clientes.

• Crítico: o item registra uma compra, transporta valores de receita ou moeda, atribui uma venda de afiliado, entrega um produto digital pago ou fornece informações essenciais sobre pedido e entrega.
• Importante: o item afeta a confiança do cliente, recompra, coleta de avaliações, fidelidade, devoluções, autoatendimento de assinatura ou carga de trabalho do suporte.
• Baixo risco: o item está desatualizado, duplicado, sem uso ou é um conteúdo informativo que a Shopify já oferece em outro lugar.

Uma regra útil para exclusão: se ninguém consegue explicar quem é o responsável por um script, qual plataforma recebe seus dados ou de qual decisão ele depende, não o reconstrua automaticamente. Primeiro, valide se ele ainda é necessário.

Etapa 4: escolha a substituição compatível

Para rastreamento: prefira app pixels e, depois, custom pixels

O gerenciador de pixels da Shopify oferece suporte a app pixels instalados por apps de marketing e dados, além de custom pixels adicionados por um desenvolvedor. Os pixels são carregados em toda a loja virtual, checkout, página de agradecimento, página de status do pedido e contas de cliente, sujeitos às permissões e regras de sandbox aplicáveis.

A Shopify recomenda app pixels em seu guia de atualização por oferecerem mais estabilidade, segurança e desempenho. Se nenhum app adequado atender à necessidade, a Shopify permite o uso de um custom pixel.

Para conteúdo visível: use blocos ou extensões de UI

Use o editor de checkout e contas para adicionar blocos de apps compatíveis. Requisitos personalizados podem usar extensões de UI do checkout, mas a implementação deve seguir as APIs suportadas pela Shopify, em vez de recriar JavaScript legado irrestrito.

A nova página de status do pedido também inclui recursos nativos, como Comprar novamente e, quando configurado, devoluções por autoatendimento. Revise o que a Shopify já oferece antes de pagar para reconstruir um comportamento personalizado equivalente.

Para Google Tag Manager: trate como uma decisão deliberada

A orientação da Shopify para migração do GTM recomenda o app Google & YouTube para a maioria das lojas. Lojistas com um custom pixel de GTM já existente podem atualizá-lo, mas o Google não recomenda nem oferece suporte a essa configuração com custom pixel, e o Google Tag Assistant não consegue testá-la.

Se a loja mantiver um custom pixel de GTM, confirme que ele está inscrito no evento checkout_completed da Shopify e teste os dois lados da conexão: Shopify Pixel Helper para entrega do evento e o produto do Google relevante para recebimento. Atualize também qualquer lógica de URL fixada no código, porque a nova página de agradecimento altera o handle de /thank_you para /thank-you.

Para tags não relacionadas ao Google que antes eram configuradas no Google Tag Manager, a Shopify orienta os lojistas a instalar apps alternativos que usem app pixels. Cada destino deve ser testado separadamente.

Etapa 5: valide consentimento, domínios e qualidade dos eventos

Um evento bem-sucedido não é apenas aquele que dispara. Ele precisa disparar com o consentimento correto, identificadores corretos, receita, moeda e comportamento de deduplicação adequados.

• Consentimento: em mercados configurados para exigir consentimento, que segundo a Shopify normalmente são o EEE e o Reino Unido, os web pixels só são executados depois que o cliente concede as permissões exigidas pela configuração do pixel.
• Continuidade de domínio: se a loja usa um domínio personalizado, configure o domínio da conta do cliente como um subdomínio do domínio da loja virtual. A Shopify informa que, caso contrário, os pixels e o consentimento de cookies não funcionarão na página de status do pedido.
• Dados de receita: confirme na plataforma de destino os valores de total, moeda, descontos, impostos, frete e identificador do pedido.
• Deduplicação: se eventos do navegador e do servidor reportam compras, verifique se a plataforma consegue identificar um único pedido em vez de duas conversões.
• Atribuição: como recomendação de auditoria, estabeleça uma linha de base pré-migração para os pedidos da Shopify e para cada plataforma de destino, e investigue mudanças bruscas nessa relação após a migração.

Não interprete mal uma queda causada por consentimento. A Shopify observa que app pixels e custom pixels podem reportar menos eventos do que scripts antigos porque os pixels suportados respeitam o consentimento configurado. Um volume menor não significa automaticamente que a migração falhou; isso precisa ser avaliado à luz das configurações de consentimento, dos pedidos da Shopify e dos diagnósticos da plataforma de destino.

Etapa 6: teste jornadas reais de clientes

Uma prévia da página não basta. Faça pedidos controlados e revisite a página de status do pedido da mesma forma que um cliente faria: pelo email de confirmação, SMS, navegação da conta e links de suporte.

• Checkout padrão com cartão no desktop e no mobile
• Shop Pay ou outros fluxos de pagamento acelerado usados pela loja
• Pagamento na entrega, incluindo confirmação e instruções de entrega
• Uma nova assinatura e um carrinho misto com assinatura e compra avulsa
• Pedidos com retirada local, entrega local ou armário inteligente
• Um fluxo de upsell pós-compra ou recompra
• Um pedido de produto digital com link de download
• Um pedido internacional com idioma e moeda corretos
• Um pedido parcialmente atendido ou dividido, com múltiplas atualizações de rastreamento
• Um cliente recorrente abrindo a página de status do pedido após a sessão original
• Um cliente que concedeu e outro que não concedeu consentimento para marketing ou analytics

Para cada jornada, registre se:

• A página correta de agradecimento e status do pedido foi exibida
• Os blocos essenciais dos apps apareceram e continuaram utilizáveis no mobile
• O evento de compra chegou uma vez em cada plataforma esperada
• Receita, moeda, identificadores do pedido e dados do produto estavam corretos
• Links do pedido, downloads, devoluções, acesso à conta e rastreamento continuaram funcionando
• O suporte conseguia explicar a experiência sem recorrer a um procedimento manual

Perguntas para fazer a fornecedores de apps e agências

• Seu app usa blocos de app, extensões de UI do checkout ou web pixels nas novas páginas de agradecimento e status do pedido?
• Qual personalização legada a nova implementação substitui?
• O lojista precisa adicionar um bloco, conectar uma conta, ativar um pixel ou publicar uma configuração?
• Quais eventos devem aparecer no Shopify Pixel Helper e na plataforma de destino?
• Como vocês evitam eventos de compra duplicados durante e após a migração?
• A implementação respeita as configurações de privacidade e consentimento do cliente na Shopify?
• Funciona com domínios personalizados de conta do cliente, múltiplos mercados, assinaturas, pagamento na entrega, retirada e fulfillment dividido?
• Qual é o plano de rollback ou suporte antes de 26 de agosto?

Uma resposta vaga não significa prontidão. Peça etapas de configuração do lado do lojista, páginas suportadas, nomes de eventos, instruções de teste e um caminho de suporte documentado.

O que monitorar após a migração

• Pedidos da Shopify versus eventos de compra registrados por plataforma
• Precisão de receita e moeda
• Taxa de conversões duplicadas e mudanças repentinas de atribuição
• Alertas em campanhas pagas ou mudanças de desempenho sem explicação
• Renderização dos blocos de agradecimento e status do pedido no desktop e no mobile
• Falhas em rastreamento de pedido, devolução, download e acesso à conta
• Tickets de suporte mencionando ausência de confirmação, rastreamento ou ações pós-compra
• Desempenho da página e erros reportados por apps ou extensões personalizadas

A Progus recomenda definir um responsável pelo monitoramento diário pelo menos durante a primeira semana, para que eventos ausentes ou duplicados sejam investigados antes de afetarem um período maior de análise.

Checklist prático de conclusão

1. Guia de atualização revisado. Concluído quando nenhum item crítico estiver sem responsável ou sem explicação.
2. Scripts legados resolvidos. Concluído quando cada script tiver sido substituído, aposentado de forma deliberada ou documentado como desnecessário.
3. Conteúdo da página publicado. Concluído quando todos os blocos de app necessários aparecerem na página e no dispositivo corretos.
4. Pixels verificados. Concluído quando a Shopify e cada plataforma de destino receberem o evento esperado uma vez, com os valores corretos.
5. Duplicidades removidas. Concluído quando o rastreamento substituto validado continuar ativo após a desativação dos scripts legados.
6. Consentimento e domínios verificados. Concluído quando os pixels se comportarem corretamente em jornadas com e sem consentimento no domínio da conta do cliente.
7. Jornadas principais aprovadas. Concluído quando os cenários de pagamento, mercado, assinatura, pagamento na entrega e entrega usados pela loja funcionarem de ponta a ponta.
8. Suporte preparado. Concluído quando a documentação, os responsáveis por escalonamento e as orientações voltadas ao cliente estiverem atualizados.
9. Monitoramento ativo. Concluído quando houver documentação do responsável, linha de base, cadência de revisão e limite de alerta.

Considerações finais

O prazo de 26 de agosto cobre duas páginas, mas as funções colocadas nelas podem conectar marketing, analytics, suporte, fulfillment e experiência do cliente. Por isso, a migração deve incluir um inventário e um teste funcional, e não apenas uma revisão no editor de páginas.

Use a migração para remover código desconhecido, mover o rastreamento para pixels compatíveis, reconstruir apenas os elementos de página que os clientes ainda precisam e comprovar o resultado com pedidos reais. Uma atualização bem-sucedida não é apenas uma nova página de agradecimento. É mensuração confiável, comunicação clara sobre o pedido e menos surpresas operacionais antes da alta temporada.