Equipes que já coletam dados de marketplace tendem a abordar o Walmart da mesma forma que abordaram a Amazon, e os números saem errados de uma maneira fácil de não perceber. Nada dá erro. Os preços parecem plausíveis. Eles simplesmente não correspondem ao que um comprador em Dallas ou Tampa realmente vê, e a discrepância é sistemática, não aleatória.
O motivo é estrutural. O Walmart é uma rede de lojas com um site na frente, não um catálogo nacional. Preço e disponibilidade são resolvidos em relação a uma loja específica, e a loja é escolhida para você a partir de sinais que talvez você não esteja controlando.
A loja é a unidade de verdade
Para uma grande parte do sortimento, três coisas variam por loja:
Preço. Rollbacks, liquidações e preços regionais fazem com que o mesmo item possa ter preços diferentes em duas lojas a sessenta e quatro quilômetros de distância.
Disponibilidade. O estoque na loja é por definição por local, e as opções de envio e retirada oferecidas dependem de qual loja e qual centro de distribuição a sessão está vinculada.
Sortimento. Alguns itens simplesmente não são vendidos em algumas lojas, o que se apresenta como um produto ausente em vez de fora de estoque.
Se sua camada de coleta não fixar uma loja, o site escolhe uma para você com base na localização aparente da requisição, e pode escolher uma diferente amanhã. O resultado é uma série temporal em que os movimentos de preço são parcialmente reais e parcialmente a loja mudando silenciosamente por baixo de você. Isso é piores do que dados ausentes, porque parece uma tendência.
A mesma armadilha se aplica a qualquer varejista com atendimento local. A versão geral desse argumento está em monitoramento de disponibilidade e estoque de produtos.
Dois sinais decidem qual loja você recebe
Há a localização de onde sua requisição aparenta vir, ou seja, o endereço IP e sua geolocalização, e há a loja ou CEP que você seleciona explicitamente na sessão. São mecanismos diferentes e precisam concordar entre si.
Um IP de datacenter na Virgínia com uma sessão afirmando uma loja em Phoenix é um par inconsistente. Às vezes funciona, às vezes se resolve silenciosamente para outra coisa, e é exatamente o tipo de sinal que os sistemas antibot de varejo ponderam fortemente. Um IP residencial na região metropolitana que você está solicitando torna o par coerente, e esse é o ponto: você está reproduzindo um comprador, não afirmando uma localização.
Fixe a geografia, depois fixe a sessão
Com o gateway Shifter, o direcionamento vai no nome de usuário em vez de uma chamada de API separada. Aponte para p.shifter.io:443 e codifique a localização e a sessão nas credenciais:
customer-USERNAME-country-us-city-dallas-sid-store2354-ttl-600:PASSWORDTrês partes importam aqui. country-us e city-dallas colocam a saída na região metropolitana correta. sid-store2354 nomeia uma sessão persistente, então toda requisição marcada com esse identificador saí do mesmo IP. ttl-600 mantém esse IP por dez minutos, tempo suficiente para selecionar uma loja, percorrer uma categoria e ler um conjunto de páginas de produto sem que a localização mude no meio da varredura.
Observe que ttl só tem significado junto com sid. Sem um identificador de sessão não há nada a manter ativo, e a rotação padrão se aplica.
O modelo mental a manter: uma sessão persistente por loja, reutilizada nos itens que você está verificando para essa loja, em vez de uma sessão por requisição. Alternar entre cada página de produto é o erro de configuração mais comum aqui, porque isso reaciona constantemente a resolução de loja e produz exatamente a deriva que você estava tentando eliminar. As compensações são detalhadas em sessões persistentes vs rotativas.
Cidades usam nomes simples em minúsculas com underscores no lugar de espaços, e países usam códigos ISO alpha-2. Se um filtro for muito restrito para ser atendido, o gateway responde 502 em vez de silenciosamente lhe dar uma saída em outro lugar, o que é o comportamento desejado quando a precisão da loja é o ponto principal.
Registre a loja, não apenas o preço
O esquema é onde a maioria dos painéis do Walmart são ganhos ou perdidos. Uma linha que diz “o item X custou $14,98 na terça-feira” não é uma observação utilizável, porque omite a coisa que determina o preço.
No mínimo, capture:
- identificador do item
- identificador da loja para a qual a sessão realmente se resolveu
- preço, e separadamente qualquer preço tachado ou preço anterior
- estado de disponibilidade, dividido em na loja, retirada e envio
- vendedor, já que anúncios de terceiros se comportam diferente dos de primeira parte
- o país e a cidade de onde a requisição saiu
- registro de data e hora da coleta em UTC
O identificador da loja deve ser lido de volta a partir da resposta, em vez de assumido a partir do que você solicitou. Esse único campo transforma um salto de preço inexplicável em uma mudança de loja visível, e é a diferença entre um painel que você pode defender e um gráfico pelo qual você tem que se desculpar.
Distinga as quatro formas pelas quais uma verificação falha
A coleta no varejo produz modos de falha que todos parecem “sem dados”, a menos que você os separe:
Bloqueado. Você recebeu um desafio ou uma página intersticial. A observação está ausente, e o item deve ser tentado novamente, não registrado como indisponível.
Fora de estoque. Uma página válida que diz que o item está indisponível nessa loja. Isso é dado real e pertence à série.
Não vendido. O item não existe no sortimento dessa loja. Também é real, e diferente de fora de estoque.
Loja errada. A página foi renderizada, mas em relação a uma loja que você não solicitou. Essa é a perigosa, porque produz uma linha com aparência limpa, mas com o valor errado.
Somente a primeira justifica uma nova tentativa. Confundir as duas do meio nivela diferenças genuínas de sortimento, e tratar a quarta como válida é como números ruins chegam a um dashboard. No lado do transporte, 407 significa credenciais ou uma flag de direcionamento malformada, 502 significa que nenhuma saída corresponde ao seu filtro, e 509 significa que a cota de banda foi esgotada.
Cadência, e por que ela deve ser tediosa
Painéis de preço têm uma forte tentação de alta frequência. Resista por dois motivos.
O primeiro é que o volume de requisições contra um site de varejo é o sinal mais propenso a fazer um padrão de coleta ser notado, e a solução não é mais IPs, mas um cronograma que se parece com demanda em vez de uma varredura. Distribua as verificações ao longo do dia, mantenha a concorrência por loja modesta, e recue diante de erros em vez de insistir através deles. A mecânica é abordada em limitação de taxa e throttling de requisições.
O segundo é custo. O tráfego residencial é cobrado por banda, então a variável de controle são bytes por observação, não requisições por hora. Pule imagens, prefira a resposta mais leve que carrega os campos de que você precisa, e não busque novamente uma página de categoria completa quando você só precisa de três itens dela. Um tratamento mais detalhado está em reduzindo custos de banda de proxy.
Para a maioria dos painéis de varejo, uma leitura diária por loja por item é suficiente para detectar os movimentos que importam, com uma cadência mais rápida reservada para uma pequena lista de observação de itens de alto valor.
Dimensionando um painel do Walmart
A banda segue um produto simples: itens rastreados, vezes lojas rastreadas, vezes verificações por dia, vezes bytes por verificação. O multiplicador de lojas é o que as pessoas esquecem, e é o que cresce mais rápido, porque adicionar vinte regiões metropolitanas a um painel de cinco mil itens gera cem mil observações por passagem.
Comece com um conjunto restrito de lojas que reflita os mercados sobre os quais você realmente toma decisões, meça os bytes reais por verificação durante uma semana, depois expanda. Um método detalhado está em estimando a banda mensal de proxy residencial, e as taxas atuais estão na página de preços de proxy residencial.
Perguntas frequentes
Eu preciso de um IP residencial se já estou selecionando um CEP na sessão?
Para consistência, sim. Selecionar uma localização enquanto se chega de uma faixa de datacenter em outra região é um par incoerente, e é tratado como tal. A seleção explícita diz ao site o que você quer; o IP é o que ele acredita.
Quantas lojas uma sessão deve cobrir?
Uma. Reutilize uma sessão persistente entre os itens de uma única loja, depois pegue uma nova sessão para a próxima loja. Misturar lojas dentro de uma sessão é o que produz erros de atribuição.
A coleta de dados do Walmart é diferente da Amazon?
A mecânica se sobrepõe, mas a dimensão de loja é específica do Walmart e muda o esquema. Se você está estendendo um pipeline de marketplace existente, fazer scraping de dados de produtos da Amazon cobre as partes que se aplicam também.
E quanto aos anúncios de marketplace de terceiros?
Capture o campo de vendedor e trate as linhas de primeira parte e de terceiros como séries separadas. Misturá-las produz históricos de preço que saltam por motivos que não têm nada a ver com decisões de preço.
Conclusão
Os dados de preço e estoque do Walmart só têm significado quando são vinculados a uma loja, e vincular a uma loja significa controlar tanto a localização aparente da requisição quanto a persistência da sessão que a resolveu. Saídas residenciais geo-direcionadas com sessões persistentes lhe dão esse controle; registrar a loja resolvida lhe dá a capacidade de comprová-lo.
Acerte essas duas coisas e o resto do pipeline é coleta de varejo comum. Erre-as e você terá um dashboard que está confiante e consistentemente incorreto. Um contexto mais amplo de varejo está em proxies para atividades de e-commerce e no caso de uso de inteligência de preços.