mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-18 03:09:40 +02:00
Move inactive projects out of active workspace: - bauntown (community website) - maerchenzauber (AI story generation) - memoro (voice memo app) - news (news aggregation) - nutriphi (nutrition tracking) - reader (reading app) - uload (URL shortener) - wisekeep (AI wisdom extraction) Update CLAUDE.md documentation: - Add presi to active projects - Document archived projects section - Update workspace configuration Archived apps can be re-activated by moving back to apps/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
411 lines
14 KiB
Markdown
411 lines
14 KiB
Markdown
# Referral & Attribution Tracking System für uload
|
|
|
|
## Executive Summary
|
|
|
|
Dieses Dokument beschreibt die Konzeption und Implementierungsstrategie eines umfassenden Referral- und Attribution-Tracking-Systems für die uload-Plattform. Das Ziel ist es, die komplette User Journey von einem geteilten Link über den App-Download bis hin zur zahlenden Kundschaft nachvollziehen zu können, während gleichzeitig höchste Datenschutzstandards gemäß DSGVO eingehalten werden.
|
|
|
|
## Problemstellung und Zielsetzung
|
|
|
|
### Aktuelle Herausforderung
|
|
|
|
Die uload-Plattform ermöglicht es Nutzern, verkürzte Links zu erstellen und zu teilen. Derzeit wird zwar das Klickverhalten auf diese Links getrackt (Browser, Gerät, Betriebssystem, Referer), jedoch endet die Nachverfolgung beim Klick. Es fehlt die Möglichkeit, die weitere User Journey zu verfolgen:
|
|
|
|
- Wer hat nach dem Klick tatsächlich die App heruntergeladen?
|
|
- Welche Nutzer haben sich nach dem Download registriert?
|
|
- Wer ist schließlich zahlender Kunde geworden?
|
|
- Welche Link-Ersteller generieren die wertvollsten Nutzer?
|
|
|
|
### Zielsetzung
|
|
|
|
Das neue System soll folgende Kernfunktionen bieten:
|
|
|
|
1. **Vollständige Attribution**: Nachverfolgung der User Journey vom ersten Klick bis zur Conversion
|
|
2. **Multi-Touch-Attribution**: Erfassung aller Berührungspunkte eines Nutzers mit verschiedenen Links
|
|
3. **Conversion-Tracking**: Messung von Downloads, Registrierungen und Käufen
|
|
4. **Performance-Analyse**: Identifikation der erfolgreichsten Link-Ersteller und Kampagnen
|
|
5. **DSGVO-Konformität**: Vollständige Einhaltung europäischer Datenschutzstandards
|
|
|
|
## Technische Herausforderungen
|
|
|
|
### Cross-Domain und Cross-Platform Tracking
|
|
|
|
Die größte technische Herausforderung besteht darin, Nutzer über verschiedene Domänen und Plattformen hinweg zu verfolgen:
|
|
|
|
1. **Domain-Wechsel**: Der Nutzer klickt auf ulo.ad, wird aber zur App-Download-Seite einer anderen Domain weitergeleitet
|
|
2. **Platform-Wechsel**: Vom Web-Browser zum App Store, dann zur nativen App
|
|
3. **Zeit-Verzögerung**: Zwischen Klick und App-Installation können Stunden oder Tage vergehen
|
|
4. **Gerätewechsel**: Nutzer klickt am Desktop, lädt aber die App am Smartphone herunter
|
|
|
|
### Datenschutzrechtliche Einschränkungen
|
|
|
|
Die DSGVO und moderne Browser-Technologien schaffen zusätzliche Hürden:
|
|
|
|
1. **Cookie-Beschränkungen**: Safari's Intelligent Tracking Prevention (ITP) und Firefox's Enhanced Tracking Protection blockieren Third-Party-Cookies
|
|
2. **Fingerprinting-Verbot**: Device Fingerprinting ist ohne explizite Einwilligung nicht DSGVO-konform
|
|
3. **Datensparsamkeit**: Nur notwendige Daten dürfen erhoben werden
|
|
4. **Transparenz**: Nutzer müssen über die Datenerhebung informiert werden
|
|
|
|
## Vergleich bestehender Lösungen
|
|
|
|
### Branch.io Ansatz
|
|
|
|
Branch.io nutzt eine Kombination aus verschiedenen Matching-Technologien:
|
|
|
|
**Deterministic Matching** (100% Genauigkeit):
|
|
|
|
- Verwendet eindeutige Identifikatoren wie IDFA (iOS) oder GAID (Android)
|
|
- Click-IDs in URL-Parametern
|
|
- Login-basiertes Matching über User-Accounts
|
|
|
|
**Probabilistic Matching** (70-90% Genauigkeit):
|
|
|
|
- Kombiniert IP-Adresse, User-Agent, Zeitstempel und Geräteinformationen
|
|
- Erstellt einen "Fingerprint" für wahrscheinliche Zuordnung
|
|
- Nutzt ein Zeitfenster von typischerweise 24-72 Stunden
|
|
|
|
**Deferred Deep Linking**:
|
|
|
|
- Speichert die Ziel-Information vor der App-Installation
|
|
- Nach Installation fragt die App den Branch-Server nach pending Deep Links
|
|
- Nutzer wird automatisch zum richtigen Inhalt in der App geleitet
|
|
|
|
### AppsFlyer/Adjust Methode
|
|
|
|
Diese Plattformen setzen auf:
|
|
|
|
**Server-to-Server Integration**:
|
|
|
|
- Direkte API-Kommunikation zwischen App-Backend und Attribution-Plattform
|
|
- Umgeht Browser-Restriktionen komplett
|
|
- Höhere Datenqualität durch serverseitige Validierung
|
|
|
|
**SKAdNetwork Integration** (iOS):
|
|
|
|
- Apples Privacy-freundliche Attribution-API
|
|
- Aggregierte Daten ohne Nutzer-Identifikation
|
|
- 24-48 Stunden Verzögerung in Reporting
|
|
|
|
**Multi-Touch Attribution Models**:
|
|
|
|
- First-Touch: Kredite gehen an ersten Touchpoint
|
|
- Last-Touch: Kredite gehen an letzten Touchpoint vor Conversion
|
|
- Linear: Gleichmäßige Verteilung auf alle Touchpoints
|
|
- Time-Decay: Neuere Touchpoints erhalten mehr Gewicht
|
|
|
|
### Limitierungen bestehender Lösungen
|
|
|
|
1. **Kosten**: Enterprise-Lösungen kosten oft 2000€+ pro Monat
|
|
2. **Komplexität**: Aufwendige Integration und Wartung erforderlich
|
|
3. **Datenschutz**: Nicht alle Ansätze sind DSGVO-konform
|
|
4. **Genauigkeit**: Probabilistic Matching erreicht nur 70-90% Genauigkeit
|
|
5. **Plattform-Abhängigkeiten**: iOS schränkt Tracking stark ein
|
|
|
|
## DSGVO-konforme Lösungsansätze
|
|
|
|
### Ansatz 1: Referral Code System
|
|
|
|
**Konzept**: Jeder Link-Ersteller erhält einen eindeutigen Referral-Code, der in der URL mitgegeben wird. Dieser Code wird durch die gesamte Journey hindurch weitergereicht.
|
|
|
|
**Funktionsweise**:
|
|
|
|
- Link-Ersteller teilt: `https://ulo.ad/download?ref=USER123`
|
|
- Code wird auf Download-Seite im LocalStorage gespeichert
|
|
- App liest Code beim ersten Start aus und meldet ihn zurück
|
|
- Keine personenbezogenen Daten des Endnutzers werden getrackt
|
|
|
|
**Vorteile**:
|
|
|
|
- 100% DSGVO-konform, da nur der Referrer getrackt wird
|
|
- 100% genaue Attribution möglich
|
|
- Keine Cookies oder Fingerprinting erforderlich
|
|
- Funktioniert plattformübergreifend
|
|
|
|
**Nachteile**:
|
|
|
|
- Erfordert aktive Weitergabe des Codes durch die App
|
|
- Kann bei App-Store-Downloads verloren gehen
|
|
- Keine Multi-Touch-Attribution möglich
|
|
|
|
### Ansatz 2: Session-basiertes Tracking mit Consent
|
|
|
|
**Konzept**: Temporäre Sessions mit kurzer Lebensdauer und anonymisierten Daten.
|
|
|
|
**Funktionsweise**:
|
|
|
|
- Bei Klick wird Session-ID generiert (30 Minuten Gültigkeit)
|
|
- Nur aggregierte Daten ohne Personenbezug werden gespeichert
|
|
- Täglicher Salt für Hashing verhindert langfristige Nachverfolgung
|
|
- Enhanced Tracking nur mit Legitimate Interest oder Consent
|
|
|
|
**Drei-Stufen-Modell**:
|
|
|
|
1. **Basis-Tracking** (ohne Consent):
|
|
- Aggregierte Metriken (Klicks pro Tag, Land, Gerätetyp)
|
|
- Gesaltete Hashes (ändern sich täglich)
|
|
- Keine persistenten Identifikatoren
|
|
|
|
2. **Analytics** (Legitimate Interest):
|
|
- Kurzzeitige Session-Cookies (max. 30 Minuten)
|
|
- Conversion-Tracking ohne Personenbezug
|
|
- Fraud-Detection
|
|
|
|
3. **Marketing** (explizites Opt-in):
|
|
- Vollständige User Journey
|
|
- Multi-Touch-Attribution
|
|
- Langzeit-Analyse
|
|
|
|
**Vorteile**:
|
|
|
|
- Flexibles Privacy-Modell
|
|
- Bessere Insights bei vorhandenem Consent
|
|
- Basis-Funktionalität ohne Einwilligung
|
|
|
|
**Nachteile**:
|
|
|
|
- Komplexere Implementierung
|
|
- Reduzierte Genauigkeit ohne Consent
|
|
- Consent-Banner kann Conversion beeinträchtigen
|
|
|
|
### Ansatz 3: Magic Link System
|
|
|
|
**Konzept**: Nutzer gibt E-Mail-Adresse ein und erhält personalisierten Download-Link.
|
|
|
|
**Funktionsweise**:
|
|
|
|
- Nutzer gibt E-Mail auf Landing Page ein
|
|
- System sendet Magic Link mit verschlüsseltem Token
|
|
- Token enthält Attribution-Informationen
|
|
- Nach Download kann Nutzer direkt zugeordnet werden
|
|
|
|
**Vorteile**:
|
|
|
|
- Explizite Einwilligung durch E-Mail-Eingabe
|
|
- 100% genaue Attribution
|
|
- Möglichkeit für Follow-up-Kommunikation
|
|
- DSGVO-konform mit Double-Opt-In
|
|
|
|
**Nachteile**:
|
|
|
|
- Zusätzlicher Schritt im Conversion-Funnel
|
|
- Nicht alle Nutzer wollen E-Mail angeben
|
|
- Verzögerung durch E-Mail-Versand
|
|
|
|
### Ansatz 4: Voucher/Promo-Code System
|
|
|
|
**Konzept**: Gamification-Ansatz mit manueller Code-Eingabe.
|
|
|
|
**Funktionsweise**:
|
|
|
|
- Jeder Link enthält prominenten Promo-Code
|
|
- Nutzer wird incentiviert, Code in App einzugeben
|
|
- Code aktiviert Vorteile (Rabatte, Features)
|
|
- Attribution erfolgt bei Code-Einlösung
|
|
|
|
**Vorteile**:
|
|
|
|
- Kein technisches Tracking erforderlich
|
|
- Nutzer hat volle Kontrolle
|
|
- Zusätzlicher Conversion-Anreiz
|
|
- 100% DSGVO-konform
|
|
|
|
**Nachteile**:
|
|
|
|
- Erfordert manuelle Aktion des Nutzers
|
|
- Nicht alle werden Code eingeben
|
|
- Zusätzliche Incentive-Kosten
|
|
|
|
## Empfohlene Implementierungsstrategie
|
|
|
|
### Phase 1: Quick Win mit Referral Codes (1 Woche)
|
|
|
|
**Ziel**: Schnelle Basis-Implementation ohne komplexe Infrastruktur
|
|
|
|
**Umsetzung**:
|
|
|
|
- Integration von Referral-Codes in bestehende Link-Struktur
|
|
- Weitergabe der Codes über URL-Parameter
|
|
- Einfaches Dashboard für Link-Ersteller
|
|
- Server-to-Server Webhook für App-Events
|
|
|
|
**Metriken**:
|
|
|
|
- Anzahl Klicks pro Referral-Code
|
|
- Conversions (Download, Registrierung, Kauf)
|
|
- Conversion-Rate pro Link-Ersteller
|
|
|
|
### Phase 2: Enhanced Analytics (1 Monat)
|
|
|
|
**Ziel**: Verbessertes Tracking mit Privacy-First-Ansatz
|
|
|
|
**Umsetzung**:
|
|
|
|
- Session-basiertes Tracking mit täglichem Salt
|
|
- Aggregierte Analytics ohne Personenbezug
|
|
- A/B-Testing verschiedener Attribution-Methoden
|
|
- Implementierung eines Consent-Banners für erweiterte Features
|
|
|
|
**Neue Features**:
|
|
|
|
- Conversion-Funnels
|
|
- Zeitbasierte Analysen
|
|
- Geografische Verteilung
|
|
- Device/Browser-Statistiken
|
|
|
|
### Phase 3: Multi-Touch Attribution (3 Monate)
|
|
|
|
**Ziel**: Vollständige Customer Journey Analyse
|
|
|
|
**Umsetzung**:
|
|
|
|
- Kombination mehrerer Tracking-Methoden
|
|
- Machine Learning für Probabilistic Matching
|
|
- Integration mit externen Analytics-Tools
|
|
- Advanced Reporting und Insights
|
|
|
|
**Erweiterte Funktionen**:
|
|
|
|
- Attribution-Modelle (First-Touch, Last-Touch, Linear)
|
|
- Kohorten-Analyse
|
|
- Lifetime-Value-Berechnung
|
|
- Predictive Analytics
|
|
|
|
### Phase 4: Enterprise Features (6 Monate)
|
|
|
|
**Ziel**: Professionelle Attribution-Plattform
|
|
|
|
**Umsetzung**:
|
|
|
|
- Fraud-Detection-System
|
|
- Real-Time Dashboards
|
|
- API für Drittanbieter-Integration
|
|
- White-Label-Lösungen für Großkunden
|
|
|
|
## Technische Architektur
|
|
|
|
### Datenmodell
|
|
|
|
**tracking_sessions**:
|
|
|
|
- Temporäre Sessions mit kurzer Lebensdauer
|
|
- Anonymisierte Nutzer-Identifikatoren
|
|
- Verknüpfung zu Links und Referrern
|
|
|
|
**conversion_events**:
|
|
|
|
- Event-Stream aller Conversions
|
|
- Attribution zu Sessions und Referral-Codes
|
|
- Zeitstempel und Event-Typen
|
|
|
|
**attribution_analytics**:
|
|
|
|
- Aggregierte Metriken
|
|
- Keine personenbezogenen Daten
|
|
- Optimiert für schnelle Abfragen
|
|
|
|
### API-Design
|
|
|
|
**Tracking-Endpoints**:
|
|
|
|
- POST /api/track/click - Initiale Klick-Erfassung
|
|
- POST /api/track/event - Event-Tracking (Download, Register, Purchase)
|
|
- GET /api/analytics/attribution - Attribution-Reports
|
|
|
|
**Webhook-System**:
|
|
|
|
- Empfang von App-Events
|
|
- Validierung und Zuordnung
|
|
- Asynchrone Verarbeitung
|
|
|
|
### Sicherheit und Datenschutz
|
|
|
|
**Datenschutz-Maßnahmen**:
|
|
|
|
- Verschlüsselung aller Daten in Transit und at Rest
|
|
- Automatische Datenlöschung nach definierten Zeiträumen
|
|
- Pseudonymisierung von Nutzer-Daten
|
|
- Audit-Logs für alle Datenzugriffe
|
|
|
|
**Compliance**:
|
|
|
|
- DSGVO-konforme Datenverarbeitung
|
|
- Privacy-by-Design-Prinzipien
|
|
- Transparente Datenschutzerklärung
|
|
- Nutzer-Rechte (Auskunft, Löschung, Portabilität)
|
|
|
|
## Metriken und KPIs
|
|
|
|
### Primäre Metriken
|
|
|
|
1. **Click-to-Install Rate**: Prozentsatz der Klicks, die zu App-Installationen führen
|
|
2. **Install-to-Registration Rate**: Prozentsatz der Installationen, die zu Registrierungen führen
|
|
3. **Registration-to-Purchase Rate**: Prozentsatz der Registrierungen, die zu Käufen führen
|
|
4. **Overall Conversion Rate**: End-to-End Conversion vom Klick zum zahlenden Kunden
|
|
|
|
### Sekundäre Metriken
|
|
|
|
1. **Time-to-Conversion**: Durchschnittliche Zeit von Klick zu Conversion
|
|
2. **Attribution-Window Performance**: Conversions nach Zeitfenstern
|
|
3. **Channel Performance**: Erfolg verschiedener Traffic-Quellen
|
|
4. **User Lifetime Value**: Langzeitwert der geworbenen Nutzer
|
|
|
|
### Qualitäts-Metriken
|
|
|
|
1. **Attribution Match Rate**: Prozentsatz erfolgreich zugeordneter Conversions
|
|
2. **False Positive Rate**: Fehlerhafte Zuordnungen
|
|
3. **Data Completeness**: Vollständigkeit der gesammelten Daten
|
|
4. **System Latency**: Verzögerung in der Datenverarbeitung
|
|
|
|
## Risiken und Mitigationsstrategien
|
|
|
|
### Technische Risiken
|
|
|
|
**Datenverlust bei Platform-Wechsel**:
|
|
|
|
- Mitigation: Redundante Tracking-Methoden, Fallback-Mechanismen
|
|
|
|
**Ungenauigkeit bei Probabilistic Matching**:
|
|
|
|
- Mitigation: Konservative Zuordnung, manuelle Validierung bei hochwertigen Conversions
|
|
|
|
**Skalierungsprobleme**:
|
|
|
|
- Mitigation: Event-Streaming-Architektur, horizontale Skalierung
|
|
|
|
### Rechtliche Risiken
|
|
|
|
**DSGVO-Verstöße**:
|
|
|
|
- Mitigation: Privacy-by-Design, regelmäßige Audits, Datenschutzbeauftragter
|
|
|
|
**Internationale Datenschutzgesetze**:
|
|
|
|
- Mitigation: Geo-basierte Compliance-Rules, lokale Datenspeicherung
|
|
|
|
### Geschäftliche Risiken
|
|
|
|
**Nutzer-Akzeptanz**:
|
|
|
|
- Mitigation: Transparente Kommunikation, Opt-in-Incentives
|
|
|
|
**Kosten-Nutzen-Verhältnis**:
|
|
|
|
- Mitigation: Phasenweise Einführung, kontinuierliche ROI-Messung
|
|
|
|
## Zusammenfassung und Ausblick
|
|
|
|
Das vorgeschlagene Referral- und Attribution-Tracking-System bietet uload die Möglichkeit, die komplette Customer Journey nachzuvollziehen und gleichzeitig höchste Datenschutzstandards einzuhalten. Durch die phasenweise Implementierung können schnelle Erfolge erzielt und das System kontinuierlich verbessert werden.
|
|
|
|
Die Kombination aus technischen Tracking-Methoden und nutzergesteuerten Elementen (wie Promo-Codes) schafft ein robustes System, das auch bei zunehmenden Privacy-Restriktionen funktionsfähig bleibt. Die vorgeschlagene Architektur ist skalierbar und kann mit dem Wachstum der Plattform mitwachsen.
|
|
|
|
Langfristig positioniert sich uload damit nicht nur als Link-Shortener, sondern als vollwertige Attribution-Plattform, die einen echten Mehrwert für Marketing-Teams und Content-Creator bietet. Dies eröffnet neue Monetarisierungsmöglichkeiten und stärkt die Wettbewerbsposition im Markt.
|
|
|
|
## Nächste Schritte
|
|
|
|
1. **Entscheidung über Implementierungsansatz**: Auswahl der initialen Tracking-Methode
|
|
2. **Technische Spezifikation**: Detaillierte Ausarbeitung der gewählten Lösung
|
|
3. **Datenschutz-Folgenabschätzung**: Formale DSGVO-Prüfung
|
|
4. **Proof of Concept**: Implementierung einer Minimal-Version
|
|
5. **Pilotphase**: Test mit ausgewählten Nutzern
|
|
6. **Rollout**: Schrittweise Einführung für alle Nutzer
|
|
|
|
Der Erfolg des Systems wird maßgeblich davon abhängen, wie gut es gelingt, die Balance zwischen Tracking-Genauigkeit und Datenschutz zu finden. Mit dem vorgeschlagenen mehrstufigen Ansatz ist uload bestens positioniert, um diese Herausforderung zu meistern und einen neuen Standard für datenschutzfreundliches Attribution-Tracking zu setzen.
|