Google Analytics 4

GA4's event-based data model is architecturally correct — everything as an event with parameters is more flexible than UA's hit-type taxonomy. The problem isn't the model; it's the implementation. Event parameters are stored as nested RECORD fields in BigQuery, making routine queries unnecessarily complex. The lack of session_id as a first-class dimension (it's derived from session_start events, which are generated client-side and unreliable) means every session-level analysis starts with a sessionisation query that shouldn't be necessary.

The BigQuery export is GA4's redemption. Raw, unsampled, event-level data with every parameter, user property, and device attribute. This is where GA4 becomes a serious analytical tool. But you need to understand the schema: event_params is an ARRAY of STRUCT with key-value pairs, requiring UNNEST and conditional aggregation for every parameter extraction. Build dbt models that flatten this into queryable tables on day one. Without that intermediate layer, every analyst on your team writes slightly different UNNEST logic, and your metrics diverge.

Consent mode's modelled conversions deserve scepticism. Google models the behaviour of non-consenting users based on consenting users' patterns, then adds modelled conversions to your reports. This assumes consent is randomly distributed across your user base — it isn't. Technical users, ad-blocker users, and privacy-conscious demographics systematically decline consent, and their behaviour differs from the consenting population. Observed data shows a 15-25% divergence between modelled and actual data when compared against server-side logs. Treat modelled data as directional, never as ground truth.

Data-driven attribution is a black box. Google won't disclose the model architecture, the feature set, or the training methodology. You can't audit it, reproduce it, or explain it to a CFO who asks 'why did we shift $200K of budget based on this model's recommendation?' For high-stakes attribution decisions, build your own Markov chain or Shapley value model on your BigQuery data. You'll sacrifice Google's data breadth for transparency and auditability — a worthwhile trade for any team making material budget decisions.

The real-time reports are decorative. They don't support segmentation, can't be filtered by meaningful dimensions, and show only the last 30 minutes. For genuine real-time operational awareness — monitoring a launch, detecting a tracking outage, observing the immediate impact of a deployment — you need server-side logging or a purpose-built real-time tool. Robin Signals' real-time dashboard is vastly more useful for these operational scenarios.

Audience building for remarketing remains GA4's strongest use case. If your primary analytics objective is feeding user lists to Google Ads, GA4 is the right tool. The predictive audiences (likely purchasers, likely churners) are genuinely useful for media buying, even if the underlying models are opaque. This is Google's product, and it integrates with Google's ad ecosystem better than anything else ever will.

Production recommendation: GA4 for Google Ads integration and BigQuery raw data export. A cookieless platform for source-of-truth traffic metrics and behavioural analysis. dbt for the transformation layer between raw exports and queryable models. This architecture gives you the best of each tool without depending on any single vendor for your analytical truth.