Dica Rápida: o CSV entrou certo, mas o pandas mudou seu ID

Seção: Dicas Rápidas

Tem um erro que parece detalhe de importação, mas pode contaminar o resto inteiro da análise: deixar o pandas adivinhar sozinho o tipo de uma coluna que, na prática, é um identificador.

O CSV chega certo. O código do cliente vem com seis dígitos. O CEP está completo. O SKU bate com o ERP. O telefone tem zero na frente. Aí entra um pd.read_csv() inocente, o pandas entende aquilo como número e pronto: o valor muda antes mesmo da primeira limpeza.

Em rotina real, isso costuma aparecer tarde demais. Você só percebe quando o merge falha, quando a deduplicação não fecha ou quando uma base aparentemente igual para de casar com a outra.

O problema em 30 segundos

Imagine uma coluna cliente_id que chega assim no CSV:

000123
000124
000125

Se o pandas inferir isso como inteiro, a leitura pode virar:

import pandas as pd

df = pd.read_csv("clientes.csv")
print(df["cliente_id"].head())

Saída provável:

123
124
125

O dado não ficou “mais limpo”. Ele ficou diferente.

E, quando outra base continua guardando 000123 como texto, o merge quebra a correspondência sem fazer alarde.

Onde isso costuma estragar o trabalho

Esse problema aparece muito em colunas como:

• código de cliente;
• CEP;
• CPF ou CNPJ;
• SKU;
• matrícula;
• telefone;
• código de pedido vindo de sistemas legados.

Todas elas têm uma coisa em comum: parecem número, mas funcionam como identidade.

Quando você trata identidade como medida, começa a perder formato, contexto e comparabilidade.

Sinal verde

Se a coluna identifica algo, o caminho mais seguro é declarar isso já na entrada:

import pandas as pd

df = pd.read_csv(
    "clientes.csv",
    dtype={
        "cliente_id": "string",
        "cep": "string",
        "telefone": "string",
    },
)

Esse cuidado pequeno evita três dores muito comuns:

• sumiço de zero à esquerda;
• mistura inconsistente entre número e texto;
• merge falhando porque cada fonte guardou a chave de um jeito.

O erro mais comum

O erro não é só “esquecer o dtype”. O erro mais comum é perceber o problema tarde e tentar corrigir assim:

df["cliente_id"] = df["cliente_id"].astype(str)

Isso até transforma a coluna em texto, mas não devolve o valor original se ele já foi lido errado antes. 000123 não volta sozinho depois que virou 123.

É por isso que eu prefiro uma regra bem simples:

se a coluna existe para identificar, preserve como texto desde a leitura.

Ação rápida de 1 minuto

Antes de seguir para limpeza, agrupamento ou merge, faça este check curto:

1. Veja df.dtypes.
2. Abra cinco exemplos reais com df["cliente_id"].head().
3. Compare com a origem bruta do CSV.
4. Se houver zero à esquerda, código grande ou formatação relevante, volte e declare dtype.

É um minuto que economiza muito debug depois.

Quando isso engana até time bom

Porque o problema não explode.

O arquivo abre. A tabela aparece. O notebook continua rodando. O gráfico sai. Só que a chave já entrou torta.

E chave torta costuma se espalhar:

• o merge perde linhas;
• a reconciliação acusa falso erro;
• o drop_duplicates() age em cima de valor alterado;
• a checagem com outra fonte parece apontar divergência de negócio, quando era só leitura mal configurada.

Muita análise “misteriosamente inconsistente” começa nesse ponto.

Uma prática que vale adotar

Se você trabalha com arquivos recorrentes, vale manter um mapa mínimo de schema para entrada:

schema_clientes = {
    "cliente_id": "string",
    "cep": "string",
    "telefone": "string",
    "cidade": "string",
}

df = pd.read_csv("clientes.csv", dtype=schema_clientes)

Isso deixa a leitura mais previsível e reduz a chance de um arquivo novo mudar a interpretação da coluna sem você notar.

Resumo direto

Quando o pandas infere tipo sozinho, ele pode tomar uma decisão tecnicamente válida e analiticamente ruim.

Se a coluna é chave, código ou identificador, trate como texto na entrada. Não espere o problema aparecer no merge.

Em Python para analistas, muito erro não nasce no cálculo. Nasce na forma como a base entrou.