Não rastreamos utilizadores. Eis o que rastreamos.
A página de analytics deste site tem seis números. Construímo-los a partir de logs de servidor e um único beacon ping por sessão. Não há cookie. Não há retenção de IP além de sete dias. Nenhum terceiro vê o visitante.
O que precisamos mesmo de saber
Para um site de estúdio como este, as perguntas que valem a pena responder são: as pessoas aterram na homepage e lêem além do hero, que case studies seguram atenção, de onde vêm os cliques no formulário de contacto, e com que frequência a caixa de pesquisa é usada.
Nenhuma destas perguntas exige saber quem é alguém.
O que o beacon envia
Um POST por sessão, disparado ~3s depois do load: { path, referrer_origin, lang, screen_w, ts }. Sem user agent, sem IP, sem fingerprint, sem UUID. A sessão é a pageview em si.
Os dados aterram num ficheiro JSON-lines (um append por pedido, sem DB). Rotação mensal. Inacessível da web — a pasta de storage tem Require all denied no .htaccess.
O dashboard de analytics
Um script PHP lê o JSONL, agrega por dia, e renderiza seis números + um pequeno gráfico de barras. Auth é HTTP basic. O script nunca sai do servidor.
O trade-off
Não conseguimos responder a perguntas como "este utilizador voltou?" ou "qual o caminho de conversão do visitante X?". Conseguimos responder a perguntas como "a homepage está a fazer o seu trabalho?" e "o press kit está a chegar a alguém?". Para um site de estúdio, o segundo conjunto importa e o primeiro não.
Se algum dia vendermos um produto B2C onde analytics ao nível do cliente importem, adicionamos uma plataforma de analytics como deve ser, com consent-gating. Até lá: menos é mais, sobretudo quando "mais" significa "mais dados de outras pessoas".
Perguntas frequentes
O que é que esta configuração de analítica regista, se não regista utilizadores?
Regista seis números construídos a partir dos registos do servidor e de um único ping de beacon por sessão, abrangendo se as pessoas leem para lá do herói, que estudos de caso prendem a atenção, de onde vêm os cliques no formulário de contacto e com que frequência a caixa de pesquisa é usada. Nenhum destes exige saber quem alguém é.
Que dados envia o beacon de facto?
O beacon envia um POST por sessão cerca de 3 segundos após o carregamento, contendo o caminho, a origem do referenciador, o idioma, a largura do ecrã e o carimbo temporal. Não envia user agent, nem IP, nem impressão digital, nem UUID.
Como são guardados os dados e como se mantém a privacidade?
Os dados são acrescentados a um ficheiro JSON-lines com uma entrada por pedido, sem base de dados, com rotação mensal e tornados inacessíveis a partir da web através de Require all denied no .htaccess. Um painel em PHP lê o ficheiro, agrega por dia e apresenta seis números mais um gráfico de barras protegido por autenticação básica HTTP, sem nunca sair do servidor.
O que é que esta abordagem não consegue responder?
Não consegue responder se um utilizador específico regressou nem traçar percursos de conversão por visitante, porque não há cookie nem identificador que ligue as sessões. Consegue responder se a página inicial está a cumprir o seu papel.
Alguma vez usariam uma abordagem de analítica diferente?
Sim — se o estúdio alguma vez vender um produto B2C em que a analítica ao nível do cliente seja importante, seria adicionada uma plataforma condicionada a consentimento. Até lá, a posição é que menos é mais.