User-ID-Coverage - was 20 % Login-Quote über deine Cross-Device-Realität sagen
Wer in GA4 Cross-Device-Tracking ernst nimmt, kommt an einer Zahl nicht vorbei: der User-ID-Coverage. Sie misst, welcher Anteil deiner Sessions überhaupt einer identifizierbaren Person zugeordnet ist. Bei SaaS-Produkten mit Login-Zwang liegt sie oft bei 80-95 %, bei E-Commerce-Shops mit Gast-Checkout bei 5-15 %. Der Unterschied entscheidet, was du in den Reports sehen kannst - und was nicht.
Was im Code passiert
Der Check in app/queries/checks/user_id_coverage.sql
berechnet drei Coverage-Quoten parallel: Events, Sessions und User mit
gesetzter user_id:
overall_coverage AS (
SELECT
COUNT(*) AS total_events,
COUNTIF(user_id IS NOT NULL AND user_id != '') AS events_with_user_id,
COUNT(DISTINCT session_id) AS total_sessions,
COUNT(DISTINCT CASE WHEN user_id IS NOT NULL AND user_id != ''
THEN session_id END) AS sessions_with_user_id,
COUNT(DISTINCT user_pseudo_id) AS total_users,
COUNT(DISTINCT CASE WHEN user_id IS NOT NULL AND user_id != ''
THEN user_pseudo_id END) AS users_with_user_id
FROM user_id_analysis
)
Die drei Quoten unterscheiden sich oft deutlich - z. B. weil eine User-ID zwar in den Events nach Login gesetzt wird, aber nicht in den vorherigen Events derselben Session.
Schwellenwerte
| Status | Bedingung |
|---|---|
| Grün | >50 % - gutes Cross-Device-Tracking möglich |
| Gelb | 10-50 % - nur Logged-in-User identifizierbar |
| Rot | <10 % - Cross-Device praktisch unmöglich |
Typische Ursachen für niedrige Coverage
- Kein Login auf der Site - Nutzer browsen anonym, es gibt schlicht
keine
user_id, die gesetzt werden könnte. - User-ID erst nach Purchase gesetzt - Häufiges Muster bei Shops: Der Pre-Purchase-Funnel hat keine ID, erst beim Account-Anlegen im Checkout wird sie gesetzt - zu spät für sinnvolle Analyse.
- GTM-Tag feuert nicht oder mit
FALSE-Bedingung - Klassischer Implementierungs-Bug: Die Variable wird gesetzt, aber der Trigger matcht nicht. - Consent-Manager blockiert User-Identifikation - Manche
CMP-Konfigurationen schalten
user_idzusammen mit anderen Identifikatoren ab, auch wenn analytics-Consent vorhanden ist.
So zeigt's der Auditor
Die Sektion create_user_id_coverage_section in
app/components/dashboard/sections/content.py
liefert:
- Overall-Coverage-Karte mit den drei Quoten (Events / Sessions / User).
- Summary-Karten für Anzahl Events, Sessions und User mit ID.
- Daily-Trend-Tabelle: wie entwickelt sich die Coverage über die Zeit (steigt sie nach einem Login-Hinweis-Banner)?
- Explanation-Accordion mit Hintergrund zur Cross-Device-Logik.
Strategien zur Verbesserung - auch ohne Login-Zwang
- Soft-Login fördern - Newsletter, Wishlist, Kundenkonto im Checkout-Flow als optional, aber attraktiv präsentieren.
- Login-Persistenz erhöhen - Sessions länger gültig halten, Remember-Me-Cookies setzen, damit die User-ID über Besuche stabil bleibt.
- User-ID rückwirkend auf Session-Anfang setzen - Sobald sich der User einloggt, kann das GTM-Tag die User-ID auch für die laufende Session beim nächsten Event mitsenden. Damit bleibt die ID nicht erst ab Login-Klick, sondern für die ganze Session sichtbar.
- Consent-Setup audit - Über Consent Mode v2 verstehen prüfen, ob die User-Identifikation nicht versehentlich mit gesperrt wird.
- Im Auditor unter Event-Qualität & PII-Hinweise
sicherstellen, dass die
user_idnicht versehentlich Klartext-Mails oder Telefonnummern enthält - GA4 sperrt sonst die Property.
Verwandte Themen
- Hilfeseite Event-Qualität & PII-Hinweise
- Hilfeseite Consent Mode v2 verstehen
- Blog Consent Mode v2 in GA4 - was du wissen musst