Thema: Tracking-Qualität

User-ID-Coverage - was 20 % Login-Quote über deine Cross-Device-Realität sagen

Bernhard Prange · 2026-05-19 · 7 Min. Lesezeit

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_id zusammen 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

  1. Soft-Login fördern - Newsletter, Wishlist, Kundenkonto im Checkout-Flow als optional, aber attraktiv präsentieren.
  2. Login-Persistenz erhöhen - Sessions länger gültig halten, Remember-Me-Cookies setzen, damit die User-ID über Besuche stabil bleibt.
  3. 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.
  4. Consent-Setup audit - Über Consent Mode v2 verstehen prüfen, ob die User-Identifikation nicht versehentlich mit gesperrt wird.
  5. Im Auditor unter Event-Qualität & PII-Hinweise sicherstellen, dass die user_id nicht versehentlich Klartext-Mails oder Telefonnummern enthält - GA4 sperrt sonst die Property.

Verwandte Themen

user-id cross-device login coverage

Verwandte Beiträge

Event-Qualität & PII-Hinweise

Wie der Auditor Event-Schema-Fehler, PII-Risiken, (not set)-Anteile und Duplikate in GA4 erkennt - mit Schwellen aus dem Code.