Meta's own Conversions API documentation notes that browser-based pixel tracking routinely misses 20% or more of conversion events due to browser restrictions, ad blockers, and consent drop-off before any data reaches a downstream system. That number matters for a specific reason: analytics engineers work on data that has already been collected. If event schema errors, missing parameters, or client-side signal loss occur at the collection layer, the transformation and modeling downstream will reproduce those errors at scale, with higher confidence and cleaner formatting.
The analytics engineering hire is one of the most common moves a scaling data team makes. dbt, BigQuery, well-modeled tables, documented marts. It looks like the right step. Sometimes it is. But a meaningful share of teams making this hire have a collection layer problem, not a modeling layer problem, and the two are not interchangeable. Hiring a skilled analytics engineer to work on a broken foundation does not fix the foundation. It builds a more sophisticated structure on top of it.
What analytics engineers actually own, and where their scope ends
The analytics engineer role sits between raw data ingestion and business-facing reporting. In a modern stack, that means working inside the warehouse: writing dbt models, defining transformation logic, building mart layers, documenting lineage, and creating the governed tables that analysts and dashboards read from.
That scope is substantial. A strong analytics engineer produces output that is reproducible, version-controlled, well-tested, and legible to non-technical stakeholders. They are also, by definition, working entirely post-ingestion.
The boundary is structural, not a matter of skill or seniority. dbt's own documentation describes source freshness monitoring and schema tests, both of which operate on data that has already landed in the warehouse. There is no mechanism in transformation tooling to reconstruct an event that was never sent, recover a parameter that was stripped at the browser level, or deduplicate purchase events that were double-fired at the collection layer. Those problems exist upstream of every table the analytics engineer will ever touch.
The skills that make someone a strong analytics engineer, SQL fluency, data modeling judgment, dbt proficiency, documentation discipline, do not transfer to diagnosing a misconfigured GA4 purchase event, a server-side GTM (sGTM) routing failure, or a consent management setup that silently drops 40% of sessions before they reach any destination. These are different technical domains with different tooling, different diagnostic methods, and different remediation paths.
This distinction is not a criticism of the analytics engineering role. It is a statement about architecture. The signal layer and the transformation layer are separate layers of a measurement system, and problems in one cannot be resolved by investment in the other.
The signal layer is a collection and routing problem, not a modeling problem
The signal layer is the infrastructure that captures user behavior and routes it to downstream systems: tag management configuration, data layer specification, event schema design, server-side routing, consent handling, and identity resolution. It sits upstream of the warehouse. Problems in this layer produce incomplete, malformed, or duplicated data before any transformation has occurred.
Client-side signal loss is the most common and most underestimated failure mode. Browser-based tracking, which still underpins most GA4 implementations, is subject to Apple's Intelligent Tracking Prevention (ITP), Firefox Enhanced Tracking Protection, third-party ad blockers, and consent rate variation across geographies. The compounding effect of these mechanisms means a meaningful share of conversion events are never recorded. Research from server-side tracking providers, including RudderStack and Segment, and conversion API documentation from Meta and Google, consistently places this signal loss in the 20-60% range depending on audience composition and geography.
Server-side measurement via sGTM, Meta's Conversions API (CAPI), or platforms such as Tealium or RudderStack addresses part of this problem by moving the measurement origin from the browser to a controlled server environment. But server-side infrastructure introduces its own failure modes. A Cloud Run deployment handling sGTM traffic can generate 429 rate limit errors under load as autoscaling lags behind traffic spikes, dropping events before they reach the routing layer. HTTP success at the proxy does not confirm the downstream analytics platform accepted the event. Each layer requires independent validation, and none of that validation happens inside the warehouse.
Event schema problems are a separate failure mode. GA4 purchase events in production environments frequently carry malformed or missing parameters: duplicate transaction IDs from page refresh events, currency fields missing or inconsistent, item arrays missing item_id or price values. In Analytico's audit work, schema errors of this kind appear in the majority of GA4 implementations that have not been formally audited and remediated. These errors land in the warehouse intact. They do not self-correct during transformation. A dbt model that joins purchase events to a user table will produce clean, well-documented output; it will also reproduce the schema error at the mart layer and propagate it into every downstream report.
The signal layer is a collection and routing problem. Fixing it requires diagnostic work at the browser, the tag management container, the server-side routing configuration, and the event schema. None of those touch points are inside dbt.
How broken foundations produce cleaner-looking wrong numbers
This is the mechanism that makes signal layer problems dangerous in a way that is distinct from ordinary data quality issues. A warehouse with obvious gaps produces reports that look incomplete. Stakeholders ask questions. Gaps get investigated. But a warehouse that has been modeled well on top of corrupted input produces reports that look authoritative.
Consider the purchase event scenario. GA4 is firing purchase events, but 30% of them are either missing or duplicated, a net undercounting of actual conversions. Those events land in BigQuery. An analytics engineer builds a clean dbt model, tests it, documents it, and publishes a revenue mart. The mart passes schema tests because the data it received was structurally valid; only its completeness was compromised. A dashboard is built on the mart. Leadership reviews ROAS by channel, LTV by cohort, and conversion rate by landing page, all of which look credible and are formatted correctly.
The numbers are wrong. They are precisely, consistently wrong in ways that will persist until the collection layer is fixed, and the wrong numbers are presented with the confidence of a governed, documented data model.
The downstream consequences compound. Marketing teams allocating budget based on ROAS figures built on undercounted conversions will overestimate performance for channels that serve privacy-restricted audiences (iOS users, Firefox users, EU audiences with low consent rates). They will optimise toward the segment that happens to be most trackable, not the segment that actually drives revenue. Google's own measurement best practices documentation acknowledges that attribution model accuracy degrades in proportion to conversion signal completeness.
For teams using Meta's Advantage+ or Google's Smart Bidding, the damage is more direct: both systems train on conversion signals fed back through CAPI and Google Ads conversion tracking respectively. A 30% undercounting of conversions does not produce a 30% degradation in model performance; it trains the algorithm on a systematically biased signal, which produces allocation decisions that optimise for the wrong audience composition.
A well-structured data warehouse built on a broken signal layer is not a neutral foundation waiting to be improved. It is an amplifier for errors that originated upstream.
The audit that should precede the hire
The correct sequencing is a measurement architecture assessment before an analytics engineering hire, not after. The reason is straightforward: the audit determines whether the bottleneck is in the collection layer or the transformation layer. That answer dictates what kind of role to fill next.
A GA4 audit and GTM audit covers the collection layer directly: event schema validation, purchase event deduplication, parameter completeness, consent management configuration, and server-side routing behavior. The output is a map of where signal is being lost or corrupted before it reaches the warehouse.
In a subset of engagements, the audit confirms the collection layer is sound and the analytics engineering hire is the right next step. In a different subset, the audit finds that 25-40% of purchase events are missing or malformed. In that case, making the analytics engineering hire first produces a sequencing error with a quantifiable cost. Median analytics engineer compensation in the US ranges from $120,000 to $160,000 annually, per levels.fyi and Glassdoor data from 2023-2024. A hire made before the architectural problems are addressed typically delays the real fix by six to 12 months while adding that headcount cost.
Signal layer remediation, whether through server-side tagging, event schema reconstruction, or Meta CAPI implementation, is a precondition for transformation work that produces defensible measurement. The audit is how you determine which problem you actually have.
When an analytics engineer is the right next step versus an architecture fix
An analytics engineering hire is the right next step when:
- The collection layer has been audited and validated. Events are well-formed, complete, and routed correctly to the warehouse.
- The warehouse is receiving accurate data but lacks governed transformation. Raw tables exist but no modeling layer translates them into business-readable outputs.
- The team has outgrown manual SQL queries and needs version-controlled, tested, documented models that multiple stakeholders can trust.
An architecture fix should precede the hire when:
- No formal audit of the GA4 implementation has occurred since deployment.
- Purchase events and conversion events are the foundation for budget allocation decisions, and the accuracy of those events has not been independently validated.
- Server-side routing exists but has not been tested for failure modes under load, particularly if the deployment is on Cloud Run or a similar autoscaling infrastructure.
- Multiple platforms (GA4, Meta Ads, Google Ads, Stripe or another backend revenue system) report different conversion numbers and the discrepancy has not been formally reconciled.
- Ad platform automation, predictive modeling, or LTV forecasting is on the roadmap. Signal readiness for AI applications has the same precondition as signal readiness for attribution. A model trained on a broken signal layer inherits the errors at the feature level.
The signal problem often goes unexamined because it is invisible from inside the warehouse. The signal layer diagnostic that precedes a major hire determines whether the hire addresses the actual bottleneck. Most teams find the gap is smaller than expected once they map it. The harder part is usually deciding to look before committing the headcount.