Migração de Avaliações

Também importação de avaliações, migração entre aplicações de avaliações, review migration

As avaliações são o único ativo de uma loja Shopify que não se pode comprar de volta: mil avaliações representam anos de encomendas, e é por isso que mudar de aplicação de avaliações pesa mais do que mudar qualquer outra peça da loja. Uma migração são duas tarefas ao mesmo tempo. Há uma transferência de dados, em que linhas saem de uma base de dados e chegam a outra, e há um acontecimento de pesquisa, em que os dados estruturados por detrás das estrelas deixam de ser escritos por uma aplicação e passam a ser escritos por outra. A maioria das migrações que correm mal falha na segunda tarefa, porque a primeira parecia ter corrido bem.

Uma exportação raramente é uma cópia completa. A classificação, o texto da avaliação, o nome do autor e a data original viajam de forma fiável. Quatro coisas muitas vezes não viajam. O estatuto de comprador verificado costuma ser derivado pela aplicação antiga a partir da sua própria correspondência com as encomendas, e não guardado como um campo portátil, pelo que a aplicação de destino ou aceita uma coluna de verificação ou volta a derivá-la, cruzando os e-mails dos autores com as encomendas do Shopify; convém confirmar qual dos dois casos se aplica, em vez de assumir que os selos reaparecem. As fotografias exportam normalmente como URL que apontam para o armazenamento da aplicação antiga e não como ficheiros, pelo que só funcionam enquanto essa conta estiver ativa: descarregue-as antes de desinstalar. As respostas do lojista ficam numa tabela separada e faltam com frequência na exportação. E as datas originais podem ser substituídas em silêncio pela data de importação, o que reinicia todos os sinais de recência que existiam.

A coluna de correspondência é onde as migrações se partem sem avisar. As aplicações não concordam sobre a forma como uma avaliação aponta para um produto: umas guardam o ID de produto do Shopify, outras o handle (o identificador legível que aparece no URL), outras um SKU, e nenhuma das três opções é segura sem condições. Os ID de produto são estáveis mas não sobrevivem à reconstrução de um catálogo. Os handles são legíveis mas editáveis, e um produto renomeado há dois anos pode arrastar um handle que ninguém se lembra de ter definido. Os SKU vivem na variante e não no produto, pelo que uma avaliação associada a um SKU tem de ser elevada ao produto principal, e um SKU vazio não é chave nenhuma. Escolha a chave em que as duas aplicações concordam de facto, e verifique dez produtos à mão antes de importar o ficheiro completo.

O ficheiro em si é um CSV simples, uma linha por avaliação, com aproximadamente estas colunas: identificador de produto, classificação, título, texto, nome do autor, e-mail do autor, data, estado de moderação e, por vezes, um campo de verificação e uma lista de URL de imagens. Dois pormenores mecânicos causam mais estragos do que qualquer questão conceptual. Os textos das avaliações contêm vírgulas e quebras de linha, por isso o ficheiro depende de aspas corretas e desfaz-se se uma ferramenta o voltar a gravar de outra maneira. E abrir a exportação numa folha de cálculo é a forma habitual de os SKU perderem os zeros à esquerda, de as datas serem reescritas num formato local que o importador não consegue interpretar e de os nomes acentuados ficarem em caracteres ilegíveis. Guarde o ficheiro descarregado original intacto, como cópia de segurança.

A lacuna nas estrelas dos resultados de pesquisa é a parte que custa dinheiro em silêncio. O Google não guarda as classificações da loja. Lê a marcação AggregateRating e Review na página em cada rastreio, pelo que as estrelas só existem enquanto alguma aplicação estiver a escrever essa marcação. Desinstalar a aplicação antiga na segunda-feira e preencher a nova na quinta significa que todas as páginas rastreadas nesse intervalo comunicam um produto sem classificação. A recuperação não é imediata: a marcação tem de estar de novo ativa e a página tem de ser rastreada outra vez, no calendário do Google e não no da loja. A ordem que evita a lacuna é instalar e preencher a aplicação nova enquanto a antiga ainda está a apresentar as avaliações, confirmar que a marcação é válida em páginas de produto reais e só depois remover o widget antigo, de modo a que haja exatamente um conjunto de marcação de avaliações ativo em cada momento. Dois conjuntos ao mesmo tempo são um defeito por si só.

Considere-se um lojista Shopify que vende artigos de cerâmica para café de filtro: 68 produtos, 1.900 avaliações ao longo de quatro anos, com média de 4,6. A exportação está associada ao ID interno de produto da aplicação antiga, que a aplicação nova nunca viu, pelo que se constrói uma tabela de correspondência a partir de um CSV de produtos do Shopify e se converte tudo para handles. As 140 avaliações que pertencem a produtos entretanto fundidos ou descontinuados não têm onde aterrar, por isso ficam retidas em vez de serem forçadas a um artigo parecido. As fotografias chegam como ligações para o armazenamento da aplicação antiga, pelo que as imagens são descarregadas enquanto esta ainda está instalada, e a coluna da data original é mapeada de forma explícita para que o importador não carimbe tudo com o dia da mudança. Depois da importação, o widget novo apresenta 4,6 em 1.760 avaliações, e a diferença corresponde exatamente às 140 avaliações órfãs, que é a reconciliação que diz que mais nada se perdeu. O widget antigo fica ativo mais três dias, até dez páginas de produto terem sido verificadas quanto à validade da marcação.

Por vezes a resposta honesta é não migrar. Se a aplicação antiga não oferece exportação, isto não é uma migração mas um recomeço, e essa é uma decisão a tomar de forma deliberada e não a descobrir depois de desinstalar. Com algumas dezenas de avaliações, o trabalho de correspondência custa mais do que voltar a recolher avaliações junto dos compradores recentes. Se o catálogo foi reconstruído depois de as avaliações terem sido escritas, os identificadores podem já não existir em lado nenhum, e uma correspondência que funciona quase sempre vai atribuir avaliações ao produto errado, de maneiras dolorosas de desfazer mais tarde. A época alta de vendas é a pior semana para fazer a mudança, porque o custo de uma página de produto sem avaliações cresce com o tráfego. E se o motivo da mudança é que as avaliações estão invisíveis para a pesquisa, confirme que a aplicação de destino as escreve na página em vez de as fechar num widget que um rastreador não consegue ler, ou a migração muda o problema de sítio em vez de o resolver. Esse teste aplica-se a todas as aplicações de destino, incluindo a nossa.

O mesmo teste decide como os motores de resposta tratam a loja depois. Quando o ChatGPT, o Perplexity ou o Google AI Overviews avaliam se vale a pena comprar um produto, trabalham a partir do conteúdo de avaliações que conseguem efetivamente recuperar, e uma migração é o momento em que esse conteúdo está mais exposto: datas reescritas, estatuto de verificação perdido, respostas desaparecidas, texto a aterrar dentro de um widget que nenhum rastreador lê. Manter o registo intacto não é o mesmo que torná-lo legível. Fazer com que as avaliações já existentes sejam lidas, corroboradas e citadas pela pesquisa e pela IA é a lacuna distinta que o BeyondReviews foi criado para fechar, e uma migração é o momento natural para resolver isso, em vez de arrastar o mesmo ponto cego para a aplicação seguinte.