Our GA4 numbers look off but we can’t pinpoint why – how do we know if we have a tracking problem?

The most common signs of a GA4 tracking problem include: 

• Unexpectedly high direct or unassigned traffic (above 30–40%) 
• Session counts that don’t match server-side records 
• Key conversion events missing from reports 
• A sudden drop in traffic after a platform migration 

A structured GA4 audit checks the most frequent failure points: duplicate or missing GTM container firing, misconfigured data streams, conversion events not marked as key events, cross-domain tracking missing for multi-domain journeys, and consent mode configuration that’s suppressing data without a modelled recovery mechanism.  

At Connective3, our implementation audits produce a prioritised fault list with specific fixes, not a general health score. Most clients find that two or three underlying issues are responsible for the majority of their data quality problems.

Our developers keep mentioning a data layer – what is it, and why does it matter for our reporting accuracy?

A data layer is a structured JavaScript object that sits on your website and acts as a single, reliable source of truth for everything your analytics and tag management tools need to collect. Without one, tracking tags have to scrape information directly from the page, reading product names from visible text and pulling transaction values from DOM elements, which then breaks every time a developer changes a headline or restructures a page template. 

With a properly implemented data layer, your developers explicitly define what gets passed to analytics at every key interaction: page type, user status, product details, transaction values, form data. This makes tracking robust, consistent, and independent of front-end design changes. Connective3 produces full data layer specifications as part of every tracking implementation project. This includes a structured technical document that developers can build and QA against, rather than a verbal brief that gets interpreted differently every time.

We’re reporting out of four different platforms and none of them agree — how do we get everything into one place?

Consolidating marketing data from multiple platforms including Google Ads, Meta, LinkedIn, GA4, CRM – requires a data pipeline that extracts from each source, standardises everything into a consistent schema, and loads it into a central warehouse or Business Intelligence tool. 

The most common architecture for marketing teams is to pull platform data via APIs into a cloud data warehouse (typically Google BigQuery or Azure SQL), apply transformations to align naming conventions and metrics, then connect to a visualisation layer like Looker Studio or Power BI.  

Connective3 builds and maintains these pipelines for clients, handling the ongoing maintenance most in-house teams underestimate such as the API version changes, platform schema updates, and the data quality checks needed to catch silent failures before they corrupt reports.  

The result? A single dashboard where all channel performance is visible in one place, with a consistent definition of what each metric actually means.

What’s the difference between a data layer, Google Tag Manager, and GA4 — and how do they all fit together?

These are three distinct components that work together in a chain: the data layer stores the information, Google Tag Manager reads from the data layer and decides when to fire tags, and GA4 receives the data that GTM sends it.  

Think of it this way: the data layer is a whiteboard your website writes onto whenever something meaningful happens such as product viewed, checkout started, form submitted. GTM is the person watching the whiteboard and when a specific event appears, they fire the appropriate tag. GA4 is one of the destinations those tags send data to, alongside tools like Meta Pixel or Google Ads conversion tracking.  

When the chain works correctly, every meaningful user action is captured accurately and sent to the right platform. When it breaks (usually because the data layer was never properly implemented, or GTM tags fire at the wrong time) all three tools end up with incomplete or inaccurate data.

How long does it realistically take to build a marketing data pipeline that we can actually trust?

A functional pipeline connecting three to five platforms into a single reporting dashboard typically takes around eight weeks to build, depending on the complexity of the source APIs and the transformations required. 

 The timeline breaks down into:  

• 1-2 weeks for discovery and data source mapping (agreeing what data is needed, from where, and how metrics should be defined) 
• 2-4 weeks for pipeline build and testing (covering API authentication, rate limits, and schema normalisation) 
• 1-2 weeks for dashboard build and stakeholder review

The most common cause of delays is inconsistently defined metrics across platforms, often what counts as a “conversion” in Google Ads is different from what is labelled a “conversion” in Meta or your CRM. To combat this Connective3 produces a data dictionary as part of every pipeline project that locks in metric definitions before build begins, preventing the rework that typically extends timelines.

GA4, our ad platforms, and our CRM all show different conversion numbers – which one should we report from?

Discrepancies between GA4, paid platforms, and CRM data are normal and expected as the three systems measure fundamentally different things, which is why they will never fully agree. GA4 measures browser sessions and on-site events. Ad platforms report based on their own attribution models, often claiming credit for any conversion that occurred within their attribution window. CRMs record actual business outcomes such as leads, sales, customers. 

The right approach isn’t to pick one source and trust it exclusively, but to understand what each is best suited to measure and to build reporting that uses each source accordingly:

• Ad platform data is most reliable for media efficiency comparisons within the same channel 
• GA4 is best for understanding on-site behaviour and funnel progression 
• CRM data is the source of truth for commercial outcomes 

Connective3 builds reporting layers that present each data source in its appropriate context, with a clear hierarchy that stops inflated ad platform numbers from driving budget decisions.

What does a properly configured GA4 setup actually include, and how do we know if ours is complete?

A complete GA4 setup includes:  

• Correctly configured data streams with enhanced measurement enabled appropriately 
• Key conversion events defined and marked as such 
• A data layer covering all meaningful user interactions 
• Consent mode v2 configured for GDPR compliance 
• Cross-domain tracking for any multi-domain journeys 
• BigQuery export enabled for raw data access 
• Custom dimensions registered for any business-specific data points not captured by default.

Most GA4 properties set up quickly during the UA migration are missing at least two or three of these. The most common omissions are consent mode configuration (which can suppress 30–40% of data without modelled recovery), BigQuery export (meaning historical data can’t be recovered if the property is later reconfigured), and custom dimensions (meaning key business context is absent from every report). Connective3 runs a 20-point GA4 configuration checklist as part of every implementation audit, with each point scored as complete, partial, or absent.

We know users are converting across multiple devices, how do we track that journey accurately?

Accurate cross-device tracking in GA4 requires a combination of User-ID implementation, Google Signals, and for the highest accuracy, a server-side measurement setup that isn’t dependent on browser cookies. 

Google Signals stitches together cross-device journeys for users logged into a Google account, but it only covers a subset of users and is subject to thresholds that prevent reporting on small groups. User-ID implementation, by passing your own authenticated user identifier to GA4, provides accurate cross-device tracking for logged-in users. For businesses where a significant proportion of conversions come from unauthenticated users, server-side tagging via Google’s server-side GTM container reduces dependence on browser cookies and provides more durable tracking as browser privacy restrictions continue to tighten.  

Connective3 designs measurement architectures based on the specific mix of authenticated and unauthenticated users in each client’s context.

We have more data than we’ve ever had, so why can’t we get a straight answer out of it?

The gap between having data and having useful insights is almost always a structural problem, not a data volume problem. The most common cause is that reports are built around what the tools make easy to export, rather than the specific decisions the business actually needs to make. 

The starting point is to work backwards from the decision: what are the three to five business questions that, if answered accurately, would change how you allocate budget, prioritise development, or approach retention? Once those are defined, you can identify whether the data to answer them already exists, whether it needs to be joined across sources, or whether new tracking needs to be implemented.  

We run insight architecture workshops that map business questions to data sources and identify the shortest path from existing data to actionable output. The most common finding is that the data needed for the most important decisions already exists, but it’s sitting across three different platforms with no common key to join them.