202 lines
8.0 KiB
Markdown
202 lines
8.0 KiB
Markdown
# Amplitude — Plan de Integración para SaveFamily
|
|
|
|
## Por qué Amplitude
|
|
|
|
- **Analytics a nivel de usuario individual** — ver qué hizo "Juan Pérez" y cuándo
|
|
- **Free tier de 50M eventos/mes** — más que suficiente para la escala actual
|
|
- **Complementa Firebase Analytics** — Firebase para métricas agregadas, Amplitude para análisis de usuarios individuales
|
|
- **Integración mínima** — la arquitectura multi-client de `sf_tracking` permite añadir Amplitude como un segundo client sin tocar ningún módulo
|
|
|
|
---
|
|
|
|
## 10 Ejemplos de lo que podríamos obtener
|
|
|
|
### 1. Timeline de usuario individual
|
|
> "El usuario testapps.savefamily@gmail.com hoy a las 10:32 hizo login, fue a ubicación, cambió de dispositivo al SENIOR SF, abrió configuración de alarmas, creó una alarma, volvió al panel, y cerró la app a las 10:45"
|
|
|
|
Ver cronológicamente cada acción de un usuario específico. Útil para soporte: cuando un usuario reporta un problema, ves exactamente qué hizo.
|
|
|
|
### 2. Segmentación por tipo de dispositivo
|
|
> "Los usuarios con relojes Android (sistema=android) usan la app 3x más que los de RTOS. Los de Android visitan 'Uso de apps' y 'Videollamada', los de RTOS ni los ven"
|
|
|
|
Segmentar usuarios por las capabilities de sus dispositivos para priorizar features.
|
|
|
|
### 3. Feature adoption por usuario
|
|
> "De los 500 usuarios activos, solo 23 han usado 'Hacer amigos', 180 usan 'Historial de llamadas', y 45 han configurado geofences"
|
|
|
|
Saber qué features se usan realmente y cuáles no, a nivel de usuario individual — puedes contactar a los que no usan cierta feature para entender por qué.
|
|
|
|
### 4. Funnel de onboarding con nombres
|
|
> "De 50 registros esta semana, 48 completaron el paso de datos personales, 40 escanearon la montre, 35 crearon el perfil del niño, pero solo 12 hicieron el primer depósito. Estos son los 23 que abandonaron en el depósito: [lista de emails]"
|
|
|
|
Identificar exactamente quién abandona en cada paso y poder contactarles.
|
|
|
|
### 5. Usuarios con problemas recurrentes
|
|
> "El usuario maria.garcia@gmail.com ha visto la pantalla de error de conexión 15 veces esta semana. Su dispositivo 9024387350 está siempre desconectado"
|
|
|
|
Detectar patrones de error por usuario para soporte proactivo.
|
|
|
|
### 6. Frecuencia de uso por padre
|
|
> "Los padres que configuran 'argent de poche automatique' abren la app 2 veces/semana. Los que no lo configuran abren 5 veces/semana (para hacer depósitos manuales). Estos son los 200 usuarios sin auto-allowance configurada"
|
|
|
|
Entender cómo las features afectan el engagement y segmentar para comunicaciones.
|
|
|
|
### 7. Retención por cohorte de signup
|
|
> "Los usuarios que se registraron en marzo retienen un 60% al mes 2. Los de abril un 45%. ¿Qué cambió? Los de marzo pasaron por el onboarding con el nuevo flujo de 3 pasos"
|
|
|
|
Medir impacto de cambios en la app por cohorte temporal.
|
|
|
|
### 8. Uso del mapa de localización
|
|
> "El 70% de los usuarios activos visita el mapa diariamente. El 30% usa historial de posiciones. Solo el 5% crea geofences. Los que crean geofences tienen una retención del 85% vs 50% de los que no"
|
|
|
|
Correlacionar uso de features con retención.
|
|
|
|
### 9. Dispositivos múltiples por usuario
|
|
> "Los usuarios con 3+ dispositivos representan el 15% de la base pero generan el 40% de las sesiones. Su patrón: revisan ubicación de cada dispositivo secuencialmente cada mañana"
|
|
|
|
Entender el comportamiento de power users.
|
|
|
|
### 10. Impacto de actualizaciones
|
|
> "Después del update 1.0.0+5 (fix de posición), los usuarios que antes tenían errores de 'posición desactualizada' dejaron de reportar. Confirmado: 0 usuarios ven la posición vieja vs 34 antes del fix"
|
|
|
|
Medir el impacto real de cada release en la experiencia del usuario.
|
|
|
|
---
|
|
|
|
## Plan de Integración Técnica
|
|
|
|
### Fase 1: Cuenta y SDK (15 min)
|
|
|
|
1. Crear cuenta en [amplitude.com](https://amplitude.com) (plan Starter gratuito)
|
|
2. Crear proyecto "SaveFamily" → obtener **API Key**
|
|
3. Añadir dependencia al package `sf_tracking`:
|
|
|
|
```yaml
|
|
# packages/sf_tracking/pubspec.yaml
|
|
dependencies:
|
|
amplitude_flutter: ^4.x.x
|
|
```
|
|
|
|
### Fase 2: Crear AmplitudeTrackingClient (30 min)
|
|
|
|
Crear `packages/sf_tracking/lib/src/clients/amplitude_tracking_client.dart`:
|
|
|
|
```dart
|
|
import 'package:amplitude_flutter/amplitude.dart';
|
|
import 'package:sf_tracking/src/tracking_client.dart';
|
|
|
|
class AmplitudeTrackingClient implements TrackingClient {
|
|
AmplitudeTrackingClient({required String apiKey}) {
|
|
_amplitude = Amplitude.getInstance();
|
|
_amplitude.init(apiKey);
|
|
_amplitude.trackingSessionEvents(true);
|
|
}
|
|
|
|
late final Amplitude _amplitude;
|
|
|
|
@override
|
|
Future<void> setAnalyticsStatus({bool enabled = true}) async {
|
|
_amplitude.setOptOut(!enabled);
|
|
}
|
|
|
|
@override
|
|
Future<void> setConsentStatus(bool hasConsent) async {
|
|
// Amplitude respects opt-out via setOptOut
|
|
}
|
|
|
|
@override
|
|
Future<void> setUserId(String? userId) async {
|
|
if (userId != null) {
|
|
_amplitude.setUserId(userId);
|
|
} else {
|
|
_amplitude.setUserId(null);
|
|
}
|
|
}
|
|
|
|
@override
|
|
Future<void> setUserProperty(String name, String value) async {
|
|
final identify = Identify()..set(name, value);
|
|
_amplitude.identify(identify);
|
|
}
|
|
|
|
@override
|
|
Future<void> track(String name, [Map<String, Object>? parameters]) async {
|
|
_amplitude.logEvent(name, eventProperties: parameters);
|
|
}
|
|
|
|
@override
|
|
Future<void> trackScreenView(
|
|
String screenName, [
|
|
Map<String, Object>? parameters,
|
|
]) async {
|
|
_amplitude.logEvent(
|
|
'screen_view',
|
|
eventProperties: {'screen_name': screenName, ...?parameters},
|
|
);
|
|
}
|
|
}
|
|
```
|
|
|
|
### Fase 3: Registrar el client (5 min)
|
|
|
|
En `apps/mobile_app/lib/core/init_app.dart`, añadir Amplitude junto a Firebase:
|
|
|
|
```dart
|
|
final trackingClients = <TrackingClient>[
|
|
FirebaseTrackingClient(consentAnalytics: true),
|
|
AmplitudeTrackingClient(apiKey: 'TU_API_KEY'),
|
|
if (kDebugMode) DebugTrackingClient(),
|
|
];
|
|
|
|
final sfTracking = SfTrackingRepository(clients: trackingClients);
|
|
```
|
|
|
|
**Eso es todo.** No hay que tocar ningún módulo, ningún mixin, ningún evento. Todos los eventos existentes (100+) se enviarán automáticamente a Amplitude gracias al patrón `_broadcast` del `SfTrackingRepository`.
|
|
|
|
### Fase 4: User Properties adicionales (opcional, 15 min)
|
|
|
|
Enriquecer el perfil de usuario en Amplitude con propiedades extra que ya tenemos:
|
|
|
|
```dart
|
|
// En UserInfoTrackingListener o en el login flow
|
|
await tracking.setUserProperty('device_count', devices.length.toString());
|
|
await tracking.setUserProperty('primary_device_type', device.type);
|
|
await tracking.setUserProperty('primary_device_system', device.capabilities?.system ?? 'unknown');
|
|
await tracking.setUserProperty('app_version', packageInfo.version);
|
|
await tracking.setUserProperty('app_build', packageInfo.buildNumber);
|
|
```
|
|
|
|
### Fase 5: Verificar en dashboard (10 min)
|
|
|
|
1. Abrir la app, hacer login, navegar
|
|
2. Ir a Amplitude dashboard → User Look-Up
|
|
3. Buscar por userId → ver el timeline del usuario
|
|
4. Verificar que los eventos aparecen con sus parámetros
|
|
|
|
---
|
|
|
|
## Resumen de cambios en código
|
|
|
|
| Archivo | Cambio |
|
|
|---------|--------|
|
|
| `packages/sf_tracking/pubspec.yaml` | Añadir `amplitude_flutter` |
|
|
| `packages/sf_tracking/lib/src/clients/amplitude_tracking_client.dart` | **Nuevo** — implementación de TrackingClient |
|
|
| `packages/sf_tracking/lib/sf_tracking.dart` | Export del nuevo client |
|
|
| `apps/mobile_app/lib/core/init_app.dart` | Registrar AmplitudeTrackingClient en la lista de clients |
|
|
|
|
**4 archivos tocados, 0 módulos afectados.**
|
|
|
|
---
|
|
|
|
## Consideraciones
|
|
|
|
1. **API Key** — no hardcodear en código. Añadir al config JSON (`development.json`, `staging.json`, `production.json`) como `amplitudeApiKey` y leerlo via `String.fromEnvironment()`
|
|
|
|
2. **GDPR** — Amplitude respeta `setOptOut()`. El flujo de consent existente (`setConsentStatus`) ya se propaga a todos los clients
|
|
|
|
3. **Costes** — Plan Starter gratuito: 50M eventos/mes, retención de datos 1 año. Más que suficiente
|
|
|
|
4. **Datos existentes** — Solo se capturan datos desde la integración en adelante. No hay datos históricos
|
|
|
|
5. **Proyectos separados** — Crear un proyecto Amplitude para staging y otro para production (igual que Firebase)
|