analytics().logScreenView, custom definition not working in GA4

by

Summary

A custom eid parameter sent through analytics().logScreenView() appeared correctly in DebugView and in raw event payloads, but GA4 reports and Explorations showed incorrectly low counts. The issue was caused by sending a numeric parameter for a field that GA4 treats as a string, combined with GA4’s strict rules for custom dimensions and event-scoped parameters.

Root Cause

The underlying failure came from a combination of GA4 constraints:

  • GA4 requires custom dimension parameters to be strings, even if the value is numeric.
  • Numeric parameters do not populate custom dimensions, so Explorations show near‑zero values.
  • screen_view events behave differently from custom events and often ignore parameters unless explicitly registered.
  • The custom dimension was likely registered after events were already sent, causing historical data to be dropped.

Why This Happens in Real Systems

Real analytics pipelines often fail in subtle ways because:

  • Type mismatches silently break reporting in GA4.
  • GA4 does not retroactively apply custom dimension definitions.
  • Screen view events are auto-collected, and developers assume they behave like custom events.
  • DebugView shows raw payloads, which misleads engineers into thinking reporting will match.

Real-World Impact

This type of issue typically causes:

  • Underreported engagement metrics
  • Incorrect funnel counts
  • Misleading product analytics dashboards
  • Difficulty debugging because DebugView looks correct
  • Stakeholders losing trust in analytics accuracy

Example or Code (if necessary and relevant)

Below is the corrected version where eid is explicitly converted to a string:

const callEventDetailInitialData = async (eid: number) => {
  analytics().logScreenView({
    screen_name: 'Event',
    screen_class: 'EventDetails',
    eid: String(eid),
    oid: String(response?.data?.data?.oid),
  });
};

How Senior Engineers Fix It

Experienced engineers typically resolve this by:

  • Ensuring all custom dimension parameters are strings
  • Re-registering the custom dimension in GA4 with the correct scope
  • Validating parameter types in code before sending
  • Creating a dedicated custom event instead of relying on screen_view
  • Documenting GA4’s non-retroactive behavior for the team

Why Juniors Miss It

This issue is easy for less experienced developers to overlook because:

  • DebugView shows the parameter, giving a false sense of correctness
  • GA4 does not warn about type mismatches
  • Screen view events feel “special” and behave inconsistently
  • Documentation is fragmented and unclear about parameter type requirements
  • Most assume GA4 will coerce numeric values automatically

If you want, I can also outline a recommended GA4 event model for React Native apps so your analytics stays clean and reliable.

Leave a Comment