🎯 Clinicafy — Auditoria cs-*

📊 cs-product-analyst — Product Analytics & KPI Design

Auditoria técnica e estratégica pela ótica cs-product-analyst — Product Analytics & KPI Design. Achados classificados por severidade, plano de ação e matriz de decisão.

Veredito: Eventos de produto definidos no código mas sem destino analytics — produto essencialmente cego a dados de uso real.

PRODUCT_EVENTS (server.ts:78-88) define 9 eventos críticos: signup_completed, checkout_started, purchase, first_appointment_created, first_consultation_completed, etc. Estes eventos são disparados mas enviados apenas ao Meta CAPI (se configurado) e Mautic — sem destino de analytics de produto (GA4, Mixpanel, Amplitude). Sem funil de ativação, sem retention cohorts, sem feature usage. Decisões de produto são cegas.

9
PRODUCT_EVENTS definidos
0
Eventos enviados para product analytics
0
Dashboards de produto
0
Retention cohorts
0
Feature usage tracking

Dimensões Analisadas

Pontuação por área de análise.

Event Tracking

40

9 eventos definidos e disparados. Destino: apenas Meta CAPI + Mautic. Sem product analytics.

2 achados 1 bloqueante(s)

Activation Funnel

15

Sem funil documentado. AHA moment não mapeado. Conversão free→Pro desconhecida.

2 achados

Retention Analysis

10

Zero retention tracking. DAU/WAU/MAU desconhecidos.

1 achados

Feature Usage

15

Sem tracking de quais features são usadas. Impossible saber se MarketingInsights tem usuários.

1 achados

🔎 Achados (4)

1 crítico(s) · 2 alto(s) · 1 bloqueante(s). Clique para expandir.

9 PRODUCT_EVENTS sem destino de analytics de produtoCríticaBloqueanteEsforço baixoProduct Analytics / Event Taxonomy

O que é: server.ts:78-88 define PRODUCT_EVENTS com 9 eventos. A função sendMetaCapiEvent (L293) os envia apenas para o Meta CAPI — e apenas se metaPixelId estiver configurado. Não há envio para GA4, Mixpanel, Amplitude ou qualquer ferramenta de product analytics.

Onde: server.ts:78-88, server.ts:293-342

Impacto: Sem dados de produto, todas as decisões de roadmap, pricing e growth são baseadas em intuição. Impossível calcular activation rate, D7 retention, feature adoption.

✅ Correção: Adicionar ao handler de PRODUCT_EVENTS: envio para GA4 via Measurement Protocol (server-side, sem cookies). 10 linhas de código. Ou: integrar Mixpanel server-side SDK.
Funil de ativação não instrumentado — conversão free→Pro invisívelAltaEsforço medioAARRR / Pirate Metrics

O que é: Não há tracking do funil: Cadastro → Primeiro paciente → Primeira consulta → Upgrade Pro. Os eventos existem (first_appointment_created, purchase) mas sem funil visual. Taxa de conversão free→Pro é desconhecida.

Onde: server.ts:80-84 (eventos presentes) + ausência de analytics dashboard

Impacto: Sem saber onde usuários dropam, impossível priorizar o que melhorar no onboarding.

✅ Correção: Conectar eventos a GA4. Criar funil no GA4 Explorations: Cadastro → first_appointment_created → first_consultation_completed → purchase. Medir taxa de cada etapa.
Feature usage tracking ausente — 26 features sem dados de adoçãoAltaEsforço medioFeature Analytics / Adoption

O que é: App.tsx:40-64 tem 26 lazy-loaded routes. Nenhuma tem tracking de visualização de página além do Navigation já no router. Não há tracking de: uso do módulo de estoque, emissão de guias TISS, uso de anamnese, etc.

Onde: src/App.tsx:40-64 + src/pages/ (ausência de analytics calls)

Impacto: Features podem ter 0 usuários sem que ninguém saiba. Esforço de desenvolvimento desperdiçado em features não usadas.

✅ Correção: Adicionar trackPage('page_name') em cada page component. Enviar para GA4 como page_view custom event com feature_name. Construir tabela de adoção por feature.
MARKETING_ATTRIBUTION_KEYS coletados mas sem relatório de atribuiçãoMédiaEsforço medioMarketing Attribution

O que é: server.ts:89-104: MARKETING_ATTRIBUTION_KEYS coleta UTMs, gclid, fbclid, etc. no signup. Esses dados são salvos (provavelmente no DB) mas sem relatório de atribuição — impossível saber qual canal traz mais conversões.

Onde: server.ts:89-104

Impacto: Budget de marketing sem direção. Canais rentáveis e não rentáveis são indistinguíveis.

✅ Correção: Criar relatório de atribuição: GROUP BY utm_source/utm_medium na tabela de usuários. Dashboard simples no Google Sheets via API.

📋 Plano de Ação

Cronograma de implementação recomendado.

1

GA4 Measurement Protocol server-side (1 dia)

Adicionar PRODUCT_EVENTS → GA4 via Measurement Protocol. 10 linhas de código.
analytics
1 dia · CRÍTICO
2

Funil de ativação GA4 (2h pós item 1)

Criar GA4 Funnel Exploration: Cadastro → first_appointment → purchase
analytics
2h
3

Feature usage tracking (3 dias)

trackPage() em cada uma das 26 rotas. GA4 custom events.
analytics
3 dias
4

Relatório de atribuição (1 semana)

Query SQL: SELECT utm_source, COUNT(*), SUM(plano='pro') FROM users GROUP BY utm_source → Google Sheets
atribuicao
1 semana

Matriz de Decisão

CritérioFonteStatusBloqueante
Product Analytics Destinationcs-product-analystEventos sem destino analyticsSIM
Activation Funnelcs-product-analystInvisívelnão
Retention Trackingcs-product-analystZeronão
Feature Adoptioncs-product-analyst26 features sem trackingnão
Marketing Attributioncs-product-analystDados coletados, sem relatórionão