Avaliar se migrar do feed tradicional para a nova Merchant API no Google Shopping vale a pena exige analisar a arquitetura do seu e-commerce e a frequência de variação do seu catálogo antes de alocar qualquer hora de desenvolvimento. A substituição gradual da antiga Content API v2.1 pela arquitetura reestruturada do Google altera a forma como os produtos chegam ao Merchant Center Next, exigindo um cálculo claro entre o custo de engenharia e a necessidade real de velocidade na sincronização.
Os três critérios de decisão para a mudança no Google Merchant Center
Antes de autorizar o time de tecnologia a codificar chamadas REST para a nova API do Google, a operação precisa responder a três perguntas práticas sobre a dinâmica de inventário.
Frequência de atualização de preço e estoque por SKU ao longo do dia
Se o seu e-commerce altera preços e saldos de estoque múltiplas vezes por hora — um cenário comum em operações com precificação dinâmica automatizada ou com lojas físicas integradas consumindo o mesmo estoque —, o tempo entre o ajuste no ERP e a refletividade no Google é determinante.
Quando o preço do site muda e o anúncio no Google exibe o valor antigo por 30 minutos, o consumidor clica na oferta, encontra divergência no checkout e abandona o carrinho.
Além disso, o robô de varredura do Google identifica a inconsistência entre a página de destino e o payload do feed, gerando reprovações automáticas por divergência de preço.
Volume total do catálogo e taxa de rejeição de produtos na aprovação inicial
Um catálogo de 3.000 SKUs apresenta dinâmicas operacionais completamente diferentes de uma base com 80.000 SKUs. Em bases menores, um erro de mapeamento afeta poucas dezenas de itens e pode ser corrigido pontualmente.
Em bases gigantescas, falhas em atributos obrigatórios como GTIN, NCM ou categoria do Google suspendem famílias inteiras de produtos em bloco, pausando a veiculação de campanhas inteiras de Performance Max.
Custo de horas de desenvolvimento interno versus mensalidade do ecossistema de plataforma
O custo direto de desenvolvimento não se limita à entrega inicial da integração. Ele inclui manutenção contínua, tratamento de exceções, atualização de bibliotecas e monitoramento de indisponibilidade do servidor intermediário.
Uma hora de desenvolvedor sênior alocada na manutenção de conexões com o Google é uma hora a menos dedicada à otimização da taxa de conversão do checkout, aos testes A/B na página de produto ou à infraestrutura própria do site.
Abordagem 1: Desenvolvimento próprio da nova Merchant API
A nova Merchant API do Google foi desenhada com uma estrutura modular dividida em sub-recursos claros, separando a gestão da conta (Accounts) da injeção de dados (Data Sources). Essa arquitetura substituiu as chamadas monolíticas do modelo antigo.
+-----------------------------------------------------------------------+
| SISTEMA PROPRIETÁRIO / ERP / WMS |
+-----------------------------------------------------------------------+
|
(Regras de Negócio e Tratamento Interno)
v
+-----------------------------------------------------------------------+
| MIDDLEWARE PRÓPRIO (REST / OAuth2) |
| - Processamento de filas |
| - Gestão de cotas da API |
| - Formatação para a especificação do Google |
+-----------------------------------------------------------------------+
|
(Endpoints da nova Merchant API)
v
+-----------------------------------------------------------------------+
| GOOGLE MERCHANT CENTER NEXT |
| - Sub-recurso: Accounts |
| - Sub-recurso: Data Sources (Supplemental & Primary) |
+-----------------------------------------------------------------------+
Desenvolver uma camada própria de comunicação dá ao time de engenharia controle absoluto sobre o payload enviado ao Google.
Você consegue manipular exatamente o momento em que cada sub-recurso de Data Sources é acionado, utilizando chamadas incrementais para alterar pontualmente o valor ou o estoque de um único SKU sem precisar reprocessar o feed inteiro.
Isso reduz a carga no servidor e elimina filas de espera para produtos prioritários.
Construir essa infraestrutura do zero exige investimento significativo. O time de TI precisa codificar a autenticação via OAuth2 ou Service Accounts, mapear todas as variações de atributos exigidos pelo Google, tratar retornos de erro 4xx e 5xx, e implementar mecanismos de retry automático.
Se o seu servidor middleware passar por uma instabilidade durante a noite ou estourar a cota de requisições por minuto imposta pela API do Google, o envio das atualizações é interrompido.
A consequência prática é a veiculação de anúncios com dados desatualizados, resultando em verba de tráfego queimada em itens sem estoque ou com preços defasados.
Abordagem 2: Conectores nativos e aplicativos de plataforma
As principais plataformas de e-commerce do mercado — como VTEX, Shopify e Tray — mantêm ecossistemas de conectores nativos para o Google Merchant Center. Essas ferramentas abstraem a complexidade do código e tratam a comunicação com os endpoints da API nos servidores da própria plataforma.
Ao adotar o conector nativo, a sua operação utiliza uma estrutura homologada que distribui a carga de dados entre milhares de lojistas.
Quando o Google atualiza uma exigência de atributo — como a obrigatoriedade de novas especificações para vestuário ou eletrônicos —, a responsabilidade técnica de adequar o código é da plataforma, não do seu time interno.
A contrapartida é a perda de autonomia no cronograma de atualização.
Se o seu e-commerce precisa de uma funcionalidade específica recém-lançada na Merchant API e a plataforma ainda não implementou esse parâmetro no conector, a operação precisa aguardar o roadmap do fornecedor.
O custo financeiro, por outro lado, é previsível. Em vez de aportar dezenas de milhares de reais em horas de engenharia, a loja paga uma taxa fixa mensal integrada à fatura da plataforma ou ao aplicativo de gestão de feeds, mantendo a despesa operacional sob controle.
Comparativo de investimento, tempo de resposta e risco de reprovação
A escolha entre construir ou contratar depende do equilíbrio entre a complexidade do catálogo e o orçamento disponível. A tabela abaixo detalha as diferenças operacionais de cada caminho:
| Critério de Avaliação | Desenvolvimento Próprio (Merchant API) | Conector Nativo de Plataforma |
|---|---|---|
| Custo Inicial de Implementação | Alto (80 a 150 horas de dev sênior) | Zero ou taxa única de configuração |
| Custo de Manutenção Contínua | Recorrente (mão de obra interna ou squad) | Fixo (mensalidade do app ou plataforma) |
| Latência na Atualização de Estoque | Quase em tempo real (segundos via API) | Em lotes (a cada 15 a 60 minutos) |
| Gestão de Exceções e Erros | Exige painel próprio e monitoramento | Visível no painel da plataforma/Google |
| Autonomia de Atributos Customizados | Total sobre todos os campos da API | Limitada aos campos mapeados pelo conector |
| Risco Operacional de Instabilidade | Concentrado na infraestrutura do e-commerce | Distribuído na infraestrutura da plataforma |
No cálculo financeiro em 12 meses, um desenvolvimento próprio consome facilmente R$ 25.000 em horas de implementação inicial, somados a pelo menos R$ 2.000 mensais em suporte e servidores intermediários.
O investimento total supera R$ 49.000 no primeiro ano.
Um conector corporativo pago, por sua vez, varia entre R$ 200 e R$ 1.500 mensais dependendo do volume de SKUs. O custo anual fica entre R$ 2.400 e R$ 18.000, sem exigir dedicação da equipe de TI do e-commerce.
A latência também afeta diretamente o desempenho de tráfego pago.
Se o tempo de atualização via conector é de 30 minutos e você vende a última unidade de um item de alta giro durante uma campanha ativa de Performance Max, a campanha continua gerando cliques pagos para aquele produto esgotado até que o próximo lote de dados seja processado.
Em operações de grande volume, esse atrito consome margem diariamente.
Qual caminho escolher para a sua operação
A decisão técnica deve acompanhar a estrutura operacional e o modelo de negócios do seu e-commerce.
Escolha o desenvolvimento próprio se:
- O seu catálogo supera 50 mil SKUs ativos com rotação de estoque contínua ao longo do dia.
- A loja utiliza um ERP ou WMS proprietário sem integração nativa com o ecossistema do Google.
- A precificação dos produtos varia dinamicamente em intervalos inferiores a 15 minutos com base em margem, concorrência ou estoque disponível.
- A equipe de TI interna possui capacidade ociosa para assumir a manutenção contínua de pipelines de integração sem comprometer a evolução da loja virtual.
Escolha o conector nativo se:
- A sua operação trabalha com até 50 mil SKUs e utiliza plataformas de mercado como VTEX, Shopify, Tray ou Nuvemshop.
- As atualizações de preço e estoque ocorrem em intervalos previsíveis (ex: uma ou duas vezes ao dia).
- O foco da sua equipe de engenharia e produto deve estar 100% focado na taxa de conversão, checkout e velocidade de carregamento do site.
- A operação busca previsibilidade de custos fixos sem surpresas de horas extras de desenvolvimento.
O impacto prático no inventário após 18 de agosto
O ciclo de vida das integrações do Google passou por uma virada crucial. Conforme documentado na página oficial do Google Developers sobre a migração para a Merchant API, os chamados legados baseados na Content API v2.1 entram na fase final de descontinuação, exigindo adequação de todas as conexões ativas.
Isso significa que integrações antigas deixam de receber suporte e atualizações de novos recursos.
Para a operação diária de e-commerce, o encerramento do suporte às chamadas antigas exige auditoria imediata.
Sua equipe técnica ou a sua provedora de plataforma precisa garantir que as requisições enviadas ao Google Merchant Center Next sigam a nova especificação, sob pena de bloqueio no envio de novos itens ou falha na sincronização de alterações.
A rotina de gestão de anúncios deve incluir uma verificação diária na aba de diagnósticos do Merchant Center Next.
Identificar inconsistências de NCM, falta de atributos como marca e GTIN ou erros de validação tributária antes que o produto seja rejeitado é o único caminho para manter 100% do catálogo elegível para veiculação nas campanhas de Performance Max e na busca orgânica do Google Shopping.
Perguntas frequentes
Posso utilizar um conector nativo para o catálogo e enviar atualizações pontuais de estoque por API própria?
Sim, a estrutura do Merchant Center Next permite combinar origens de dados primárias e suplementares. Você pode manter o conector nativo da plataforma para cadastrar a base fixa de produtos (título, descrição, categoria e imagens) e utilizar chamadas de API próprias via Data Sources suplementares para atualizar apenas os campos de preço e disponibilidade em tempo real.
Como a migração para a Merchant API afeta os atributos customizados (custom labels) das campanhas de Performance Max?
A nova API reorganizou a estrutura dos dados, mas manteve os campos de rótulos personalizados (custom_label_0 a custom_label_4). A diferença está na forma de envio: caso o seu conector ou código próprio não atualize esses atributos no novo payload REST, as regras de agrupamento de produtos criadas no Google Ads perderão a referência, fazendo com que os itens caiam na segmentação geral da campanha.
O limite de chamadas diárias da Merchant API pode bloquear a sincronização de produtos em operações de grande porte?
Sim, o Google impõe cotas de requisições por minuto e por dia para prevenir sobrecarga nos servidores. Se o seu código próprio ou conector tentar enviar requisições individuais para cada variação de SKU em vez de utilizar atualizações em lote (batching), a conta atinge o limite de cota quickly, gerando o erro HTTP 429 (Too Many Requests) e travando a atualização do catálogo até a renovação do limite.