A coleta de dados com login costuma envolver várias contas, e os limites de acesso nem sempre estão no script. Separar o risco de associação entre características do dispositivo, saída de rede, estado da sessão e ritmo de requisições ajuda a identificar com clareza as variáveis que podem ser controladas.
A coleta de dados de comércio eletrônico normalmente se divide em dois tipos: coleta de páginas públicas que não exigem login e coleta com sessão autenticada, por exemplo para consultar dados de back-office de concorrentes ou obter resultados exibidos após personalização.
No primeiro caso, geralmente basta controlar a frequência. Quando o segundo envolve várias contas, o fator decisivo deixa de ser o quanto o script é inteligente e passa a ser a capacidade de cada conta existir de forma independente. Se essa camada não estiver bem resolvida, limitações e bloqueios parecem aleatórios; alterar o script, reduzir a frequência ou trocar seletores não melhora o problema.
De onde vem o risco
As plataformas avaliam se várias contas são operadas pela mesma parte por meio de verificações cruzadas: endereços de rede, características do navegador e do dispositivo, dados de Cookie e de sessão e padrões de uso. Uma sobreposição alta em qualquer uma dessas categorias pode fazer com que as contas sejam agrupadas sob o mesmo operador.
É importante traçar um limite. A lógica de detecção é atualizada continuamente, e depender de truques temporários para enfrentá-la traz benefícios curtos a um custo alto. Por isso, o foco aqui não é como contornar controles de risco. A questão útil é outra: depois de esclarecer as fontes de risco, quais variáveis conseguimos controlar e manter estáveis no longo prazo? São elas que determinam se várias contas legítimas podem acabar afetando umas às outras.
Características do dispositivo e do navegador
Uma das combinações mais sujeitas a problemas é abrir várias janelas na mesma máquina e entrar em contas diferentes. Mesmo limpando o cache ou usando o modo anônimo, essas janelas continuam compartilhando o mesmo ambiente de sistema e dados do navegador. As características seguem sobrepostas, e a plataforma enxerga um único dispositivo alternando identidades repetidamente.
Uma abordagem controlável é dar a cada conta seu próprio ambiente: uma conta por ambiente independente, com impressão digital, Cookies e armazenamento local separados. O ponto principal é manter esse ambiente fixo para a conta, em vez de gerar uma combinação aleatória a cada inicialização. Combinações aleatórias muitas vezes entram em conflito entre si: fuso horário, idioma, resolução e UA podem não combinar, parecendo mais anormais do que uma configuração estável.
No fim, a estabilidade vem da consistência, não da aleatoriedade.
Saída de rede
A saída deve ser vinculada à conta: um ambiente, uma saída, e a região da saída precisa ser coerente com o perfil da conta, o fuso horário e o idioma. Se várias contas têm ambientes separados, mas compartilham a mesma saída, grande parte do isolamento anterior perde o efeito.
A saída também deve permanecer relativamente estável. Trocas frequentes de região tornam difícil explicar o sinal de localização da conta. Ao escolher uma saída, endereços residenciais costumam se parecer mais com acessos de usuários normais do que endereços de data centers. Também é importante evitar endereços já usados em grande escala, pois eles podem estar sujeitos a monitoramento mais intenso.
Cookies e sessões
O estado da sessão já funciona como um registro de identidade. Se várias contas compartilham os mesmos Cookies ou o mesmo armazenamento local, cria-se uma ligação direta entre elas, independentemente de quão bem os demais ambientes estejam separados.
Uma sessão em um ambiente novo também não deve começar com uso de alta intensidade. É melhor acumular primeiro um período de navegação normal e, depois, aumentar a carga gradualmente. Esse princípio vale também fora da coleta: ter ou não um histórico de uso influencia diretamente a quantidade de atividade que uma conta consegue sustentar.
Ritmo de requisições
A densidade de requisições é um sinal comportamental. Scripts costumam apresentar uma regularidade típica: intervalos fixos entre acessos, sequência fixa de páginas e nenhuma atividade fora da coleta. Adicionar números aleatórios não resolve esse padrão, porque o problema principal está no volume total.
A direção controlável é manter a carga dentro de uma faixa razoável: escalonar os horários de execução entre contas, evitar que todas operem no máximo ao mesmo tempo, deixar intervalos sensatos entre páginas e separar tarefas de alta e baixa prioridade. O limite é claro: a coleta não deve pressionar o serviço de destino. Qualquer ganho de velocidade obtido à custa de afetar esse serviço deixa de ser uma escolha válida.
Por que um ambiente fixo por conta é mais estável do que alternar aleatoriamente
A motivação da troca aleatória é parecer diferente a cada vez, mas as verificações de associação observam se os sinais permanecem estáveis entre diferentes dimensões e se entram em contradição. Se uma conta sai de um local hoje e de outro amanhã, com uma combinação diferente de características em cada ocasião, essa inconsistência já se torna um sinal anormal.
Um ambiente fixo segue a lógica oposta. Desde o registro, a conta mantém uma identidade consistente: ambiente fixo, saída fixa, fuso horário e idioma compatíveis e histórico de sessão que se acumula aos poucos. Quanto mais tempo essa consistência dura, mais fácil é a atividade se parecer com a de um usuário normal. Esse é o valor da camada de ambiente: estabilidade de longo prazo, e não variação chamativa.
Isso também explica por que o script de coleta não deve gerenciar sozinho as instâncias do navegador. Os ambientes precisam ser agendados de forma independente para que contas diferentes recebam ambientes exclusivos; o estado deve poder ser consultado para identificar ambientes anormais e contas inválidas; os ambientes precisam poder ser liberados para evitar o acúmulo de instâncias zumbis em operações de longa duração; e novas tentativas de uma tarefa de coleta muitas vezes exigem trocar de ambiente, algo que só funciona bem quando o agendamento é independente. Nesse tipo de arquitetura, PurpleMark é a camada de recursos de ambiente. O script cuida da lógica de coleta, enquanto identidade e recursos ficam com a camada de ambiente.
Limites de conformidade
Os pontos a seguir são mais importantes do que qualquer otimização anterior.
Respeite os termos de serviço e as regras de robots do site de destino. Muitas plataformas de comércio eletrônico restringem explicitamente o acesso automatizado em seus termos, então confirme antes de começar se o uso pretendido é permitido. Colete apenas informações públicas de produtos, preços e estoque e não colete informações pessoais. Não contorne medidas técnicas de proteção. Ao encontrar proteções como CAPTCHA ou interfaces criptografadas, ajuste a estratégia de coleta ou solicite autorização em vez de tentar quebrá-las. Controle a frequência das requisições independentemente do número de contas e nunca prejudique o funcionamento normal do serviço de destino.
A premissa desta discussão é como manter várias contas legítimas independentes e sem interferência mútua, não como evitar as regras da plataforma. A primeira questão é higiene operacional; a segunda é outra coisa.
