Kickstarter — Como foi feito (explicado fácil)

O Kickstarter é tipo uma vaquinha online: você tem uma ideia (lançar um jogo, um livro, um disco) e pede dinheiro pra galera da internet. Quem bate a meta, leva. Quem não bate, fica de mãos vazias.

Eu peguei um arquivo enorme com 378.661 projetos reais que já passaram por lá e fui investigar: por que alguns dão certo e outros não?. Pra isso usei SQL — pensa numa linguagem pra fazer perguntas pra uma planilha gigante, tipo um Excel com centenas de milhares de linhas (onde abrir no navegador trava o computador).

Por que SQL e não Excel? Porque com SQL eu pergunto o que quero ("quantos projetos da categoria Música deram certo?") e o computador faz a conta em segundos. No Excel, eu teria que rolar à mão.

1 · Abrir o arquivo e dar uma "espiada". Antes de qualquer análise, eu precisava saber o que tinha ali dentro. É como abrir uma caixa que você acabou de receber: tem o quê? quantas coisas? estão organizadas?. Joguei o arquivo numa tabela chamada ks e fiz duas perguntas básicas — quantos projetos no total, e quais "status" cada um tem (deu certo? falhou? foi cancelado?):

-- Quantos projetos? Quais estados existem?
SELECT COUNT(*) FROM ks;
SELECT state, COUNT(*) AS qtd
FROM ks GROUP BY state ORDER BY qtd DESC;

Olha que coisa: failed (falhou) é mais comum que successful (deu certo). Já dá pra suspeitar que a maioria não bate a meta — e tem ainda os "indefinidos" e os que estão "rolando ainda" (live), que não acabaram, então não dá pra contar como sucesso nem fracasso. É como tentar calcular a média da prova de matemática incluindo o povo que ainda nem fez.

2 · Arrumar a casa antes de analisar. Dados do mundo real vêm sujos. Achei dois problemas: tem projeto com data de 1970 (impossível, Kickstarter nem existia) e os tais estados "indefinidos" que falei. Antes de qualquer conta, eu filtrei pra deixar só projetos que terminaram de verdade — o equivalente a separar as roupas sujas antes de pôr na máquina:

-- só estados conclusivos e datas válidas (370.454 projetos restantes)
WHERE state IN ('successful','failed','canceled')
  AND CAST(strftime('%Y', launched) AS INT) >= 2009

3 · Fazer a pergunta certa. Agora a parte divertida. Eu queria saber: "o quanto a meta que a pessoa pediu importa pro projeto vingar?". Quem pede pouco tem mais chance? Quem pede muito se ferra?

Pra isso, separei os projetos em 5 faixas de meta (de "menos de mil dólares" até "mais de cem mil") e calculei a taxa de sucesso de cada faixa. A query parece grande, mas o que ela faz é simples: "pra cada faixa, conta quantos deram certo e divide pelo total":

SELECT CASE
         WHEN usd_goal_real <   1000  THEN '< US$ 1k'
         WHEN usd_goal_real <   5000  THEN 'US$ 1k–5k'
         WHEN usd_goal_real <  20000  THEN 'US$ 5k–20k'
         WHEN usd_goal_real < 100000  THEN 'US$ 20k–100k'
         ELSE '> US$ 100k'
       END AS faixa_meta,
       ROUND(100.0 * SUM(CASE WHEN state='successful' THEN 1 ELSE 0 END)
                   / COUNT(*), 1) AS taxa_sucesso
FROM ks
WHERE state IN ('successful','failed','canceled')
GROUP BY faixa_meta
ORDER BY taxa_sucesso DESC;

Olha o padrão saltando aos olhos: quanto maior a meta, menor a chance. Pedir menos de US$ 1.000 dá certo metade das vezes. Pedir mais de US$ 100.000 dá certo em 1 a cada 13 tentativas. Faz sentido — é mais fácil convencer 100 amigos a doar US$ 5 do que convencer 100 mil estranhos a doar US$ 1.

4 · Transformar números em imagem. Tabela com vários números cansa o olho. Joguei os resultados num gráfico pra ficar imediato — você bate o olho e já vê o que aconteceu, sem precisar ler número por número.

Que analisar dados não é mágica — é uma sequência de passos: olhar o que tem, arrumar o que está bagunçado, fazer a pergunta certa, e mostrar a resposta de um jeito que outra pessoa entenda. SQL é só a ferramenta — a habilidade é saber o que perguntar.

Coisas técnicas que apareceram aqui (caso queira pesquisar mais): SELECT, GROUP BY, CASE, WHERE, agregação condicional, tratamento de valores ausentes.