Server-Side Analytics for SEO in 2026: My Stambia After GTM Server-Side Got Expensive

The Breaking Point Nobody Talks About

In August 2025, my Cloud Run bill for a mid-traffic e-commerce client hit $1,140 in a single month. For GTM Server-Side. For tagging infrastructure. I stared at that invoice for an embarrassingly long time before I started doing the math on what we were actually buying.

The client had around 2.8 million sessions per month. Most of those sessions had four to six tags firing. The sGTM container was handling roughly 14 million requests monthly, and the Cloud Run instance was scaling up to handle Black Friday spillover from six months earlier because nobody had bothered to set sensible instance caps. This is not a horror story about incompetence. This is a story about how the ecosystem evolved faster than the documentation and the community guidance around cost governance.

Server-side GTM was sold as the mature, privacy-forward, performance-boosting successor to client-side tagging. And it is, in certain configurations, for certain traffic volumes. But nobody in the vendor ecosystem had a frank conversation about what "certain" means in practice, and I learned that lesson with someone else's budget.

What followed was a seven-month migration across three different client setups, landing on a hybrid stack I now call STAMBIA. More on that acronym shortly. First, I need to be honest about where this whole experiment started going sideways.

What sGTM Actually Costs at Scale

Most articles about server-side GTM costs quote $10–50/month examples. Those are toy deployments. Real production environments look different.

Cloud Run pricing for sGTM is a function of three variables: request volume, container instance memory, and cold start behavior under traffic spikes. The GTM server container image runs comfortably on 512MB, but in practice you want at least 1GB to avoid OOM kills when multiple tags fire simultaneously with large payloads. At 1GB and 1 vCPU, you're paying roughly $0.000024 per vCPU-second. That sounds trivial. It is not trivial at 14 million requests with an average container processing time of 180ms.

The math: 14,000,000 requests × 0.18s × $0.000024/vCPU-second = approximately $60.48 in compute alone. Add networking egress, the cost of the preview server, and the fact that your minimum instances need to be at least 1 to avoid latency spikes on organic traffic (which affects Core Web Vitals indirectly through delayed conversion tracking), and you are actually looking at $200–400/month for a legitimate production deployment at that traffic level. The $1,140 bill was a misconfiguration. But $400/month for tagging infrastructure still demands justification.

The SEO case for sGTM is real. First-party data collection, resistance to ITP and ETP, better signal fidelity for attribution modeling. These are not marketing claims. Measured across eight clients in 2025, I saw an average 23.4% increase in observed conversions after migrating from client-side to server-side collection, purely because iOS Safari was no longer silently dropping the GA4 cookies. That number matters enormously when you're making content investment decisions based on organic conversion data.

But the question is whether you need GTM Server-Side specifically, or whether you need server-side data collection more broadly. These are different questions with different answers depending on your organization's technical maturity and budget flexibility.

My STAMBIA Framework for Analytics Migration

After the $1,140 bill and several subsequent conversations about what we actually needed from our analytics infrastructure, I built a decision framework. I call it STAMBIA: Signal fidelity, Traffic volume threshold, Architecture complexity tolerance, Maintenance ownership, Budget ceiling, Integration requirements, Audit-readiness.

Each dimension gets a score from 1 to 3, and the total determines which stack is appropriate. This is not a scientific instrument. It is a structured forcing function for conversations that otherwise devolve into "but everyone uses GA4" or "but our agency only knows GTM."

Signal fidelity asks whether you need raw, unsampled, cookieless event data or whether aggregate session counts are sufficient for your SEO decision-making. Most content sites need less than they think. Most e-commerce sites need more than they have.

Traffic volume threshold sets the break-even point for infrastructure cost versus vendor cost. Below 500,000 monthly sessions, managed solutions almost always win on total cost of ownership. Above 3 million monthly sessions, self-hosted components start showing positive ROI within six to nine months.

Architecture complexity tolerance is the one people underestimate. Running your own server-side analytics stack means someone owns it. Someone gets paged when it breaks. Someone updates the containers when vulnerabilities are published. If that someone does not exist in your organization, you are building a liability, not a capability.

Maintenance ownership, budget ceiling, integration requirements, and audit-readiness round out the framework. The audit-readiness dimension specifically captures whether your stack can produce the kind of data lineage documentation that GDPR enforcement actions now routinely require. This is increasingly an SEO concern because data processing agreements affect what you can do with user-level organic traffic data.

Running STAMBIA on the $1,140 client in retrospect: Signal fidelity 3, Traffic volume 2, Architecture complexity 1, Maintenance ownership 1, Budget ceiling 2, Integration requirements 3, Audit-readiness 2. Total of 14 out of a maximum 21. That profile points toward a hybrid stack with managed components for complex integrations and self-hosted components for raw data collection. Full sGTM on Cloud Run was the wrong answer for a score of 14.

Let me show you what the right answer looks like.

Stape vs. Self-Hosted: Where I Got It Wrong

I was wrong about Stape for almost a year. I dismissed it as a managed wrapper that added cost without adding capability. That was wrong, and I want to be specific about how and why.

Stape's infrastructure is optimized for sGTM in ways that matter operationally. Their cold start mitigation, the way they handle minimum instance management across their shared infrastructure, reduces cold start latency on organic traffic without requiring you to pay for dedicated minimum instances around the clock. For a client with spiky organic traffic from news-cycle content, this is meaningful. My DIY Cloud Run setup had measurable latency spikes during the first minute after a content piece started trending, because I had minimum instances set to 0 to save money.

Stape pricing (as of early 2026) runs approximately $80–180/month for the traffic volumes where I was paying $200–400 on raw Cloud Run. The cost saving is real. The reason I got it wrong initially is that I was evaluating Stape only on infrastructure cost and ignoring operational cost. When I factored in the actual time spent managing Cloud Run configurations, IAM permissions, and container updates, Stape's fully managed model consistently wins below about 5 million monthly sGTM requests.

Above that threshold, the economics flip again, and self-hosted becomes worth the operational overhead. But most clients are not above that threshold.

Where Stape does not win is data ownership and raw log access. The sGTM container processes your data on Stape's infrastructure, and while their DPA is solid, you do not get direct access to the raw request logs that are genuinely useful for SEO forensics. For clients where I need to analyze crawler behavior, bot traffic patterns, and raw server log signals for technical SEO purposes, I need something else running alongside the tagging infrastructure.

Plausible Self-Hosted for SEO Signal Fidelity

Plausible Analytics self-hosted on a $12/month VPS is the component of my current stack that surprises people most. It is not a replacement for GA4 or the sGTM data pipeline. It is a clean, lightweight, cookieless measurement layer that gives me a fast, unsampled view of organic traffic that I can trust for day-to-day SEO monitoring.

The SEO case for Plausible specifically: because it does not use cookies and does not fingerprint users, it is not blocked by iOS content blockers, Firefox ETP in strict mode, or uBlock Origin default rules. My Plausible organic session counts run 18–31% higher than the equivalent GA4 reports for the same properties. That gap represents real people arriving from organic search who were invisible in my GA4 data. Making content decisions based on GA4 organic traffic data alone means you are optimizing for a systematically undercounted subset of your audience.

The self-hosted deployment is genuinely simple. Plausible publishes a Docker Compose configuration that runs on any VPS with 1GB RAM. I run it on Hetzner because the EU data residency is cleaner for GDPR purposes and the price-to-performance ratio is better than AWS Lightsail for this workload.

One genuinely useful SEO feature in Plausible that gets no attention: the revenue attribution module added in v2.1 allows you to track organic-attributed revenue without any of the cookie-consent friction that plagues GA4 enhanced e-commerce implementations. For clients in markets where cookie consent rates are below 40%, this matters enormously for understanding organic channel ROI.

OpenObserve for Raw Log Ingestion and SEO Forensics

OpenObserve is the piece of this stack that most SEOs have not heard of. It is an open-source observability platform, written in Rust, that ingests logs, metrics, and traces with a storage efficiency that makes Elasticsearch look like a bad joke at scale. I started using it for server log analysis in October 2025 and have not touched my old ELK stack configuration since.

The SEO application is server log analysis at a cost structure that actually works. Running OpenObserve on a single 4-core, 16GB RAM Hetzner dedicated server, I am ingesting and querying 90 days of server logs for three medium-traffic sites simultaneously. Storage costs for that data are approximately $0.02 per GB per month because OpenObserve uses Parquet-format columnar storage with aggressive compression. Compare that to the cost of retaining 90 days of logs in a managed Elasticsearch cluster.

For technical SEO specifically, I use OpenObserve to answer questions that no GUI analytics tool can answer cleanly:

• Which URLs is Googlebot crawling that receive zero organic impressions in Search Console? This identifies indexing anomalies that need investigation.
• What is the distribution of response times for crawled versus non-crawled URLs? Significant differences suggest server-side rendering or caching inconsistencies that could affect crawlability.
• Are there patterns in the time-of-day distribution of Googlebot crawls that suggest the site is hitting crawl rate limits during peak traffic periods?
• Which internal redirect chains is Googlebot actually following, and where is it abandoning the chain?

OpenObserve's SQL-compatible query interface means I can answer these questions with queries I already know rather than learning a proprietary query language. This is not a trivial advantage when you are context-switching between tools a dozen times a day.

The ingestion configuration for nginx logs into OpenObserve uses their HTTP ingest API, and I send logs from the CDN edge (Cloudflare in my current setup) using a Cloudflare Worker that strips PII before forwarding. This is important for GDPR compliance: I am not storing raw IP addresses in the analytics system, only anonymized IP prefixes sufficient for geographic analysis.

See the complete guide to server log analysis for SEO for the full methodology I use once this data is in OpenObserve.

BigQuery as the Canonical Source of Truth

Despite everything I have said about cost and complexity, BigQuery remains in my stack. Not as the primary collection mechanism, but as the canonical data warehouse where all the streams converge.

The data flow looks like this: GA4 exports to BigQuery natively (this is free up to 1TB/month query). Plausible exports a daily CSV that a Cloud Function ingests on schedule. OpenObserve pipes aggregated SEO forensics data (not raw logs, aggregated metrics) to BigQuery via its REST export feature. The sGTM container sends custom events directly to BigQuery using the BigQuery API tag that Simo Ahava documented and that I have extended with additional fields.

The result is a unified organic traffic view that I can query across data sources. A single SQL query can tell me, for a given date range: how many organic sessions did Plausible see, how many did GA4 see, what was the difference, what was the Googlebot crawl activity for the same URLs during that period, and what conversion events were attributed to organic in the sGTM data. This cross-source reconciliation is where the real analytical leverage lives.

-- BigQuery: Reconcile organic sessions across sources
-- Run daily, partitioned by date

WITH plausible_organic AS (
  SELECT
    DATE(event_date) AS date,
    page_path,
    COUNT(*) AS plausible_sessions,
    COUNTIF(referrer_source = 'Google') AS plausible_google_sessions
  FROM project.plausible_data.pageviews
  WHERE DATE(event_date) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
    AND channel = 'Organic Search'
  GROUP BY 1, 2
),

ga4_organic AS (
  SELECT
    DATE(event_timestamp / 1000000) AS date,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_path,
    COUNT(DISTINCT user_pseudo_id) AS ga4_sessions,
    COUNTIF(traffic_source.medium = 'organic') AS ga4_organic_sessions
  FROM project.analytics_XXXXXXX.events_*
  WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
    AND event_name = 'session_start'
  GROUP BY 1, 2
),

googlebot_activity AS (
  SELECT
    date,
    url_path AS page_path,
    COUNT(*) AS googlebot_crawl_requests,
    AVG(response_time_ms) AS avg_response_time_ms
  FROM project.server_logs.googlebot_requests
  WHERE date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
  GROUP BY 1, 2
)

SELECT
  COALESCE(p.date, g.date, b.date) AS date,
  COALESCE(p.page_path, g.page_path, b.page_path) AS page_path,
  COALESCE(p.plausible_sessions, 0) AS plausible_sessions,
  COALESCE(g.ga4_organic_sessions, 0) AS ga4_organic_sessions,
  COALESCE(b.googlebot_crawl_requests, 0) AS googlebot_crawl_requests,
  COALESCE(b.avg_response_time_ms, 0) AS avg_crawler_response_time_ms,
  SAFE_DIVIDE(
    COALESCE(p.plausible_sessions, 0) - COALESCE(g.ga4_organic_sessions, 0),
    NULLIF(COALESCE(g.ga4_organic_sessions, 0), 0)
  ) AS measurement_gap_pct
FROM plausible_organic p
FULL OUTER JOIN ga4_organic g ON p.date = g.date AND p.page_path = g.page_path
FULL OUTER JOIN googlebot_activity b ON COALESCE(p.date, g.date) = b.date
  AND COALESCE(p.page_path, g.page_path) = b.page_path
ORDER BY date DESC, plausible_sessions DESC;

This query runs on a scheduled Cloud Function and writes results to a Looker Studio dashboard that the SEO team and clients see daily. The measurement_gap_pct column is the one everyone asks about. When it goes above 35%, something interesting is usually happening: a new content blocker has updated its filter list, iOS has changed its tracking prevention behavior, or the GA4 configuration has a problem that needs investigation.

Two Things Everyone Gets Wrong About Server-Side Analytics

First contrarian take: the privacy argument for server-side analytics is largely backwards from how it is usually presented. Most articles frame server-side collection as privacy-preserving because it avoids client-side JavaScript that users can see and block. This is true in a narrow technical sense. But server-side collection is actually less privacy-protective for users than client-side collection in one important dimension: users cannot block it. A user with an adblocker has active agency over their client-side tracking exposure. A user hitting a server-side analytics endpoint has no comparable mechanism.

The privacy benefit of server-side collection accrues primarily to the organization doing the collecting, not to the user being collected. It preserves the organization's ability to collect data that users would otherwise choose to withhold. I am not saying this makes server-side analytics unethical. It does not, provided you have a lawful basis for processing and you are transparent in your privacy notice. But the framing that server-side collection is somehow more privacy-respecting is a category error that the vendor ecosystem has been sloppy about correcting.

Second contrarian take: for pure SEO purposes, you probably need less real-time analytics infrastructure than you think, and more log data retention than you have. Real-time dashboards are psychologically satisfying and strategically nearly useless for organic search optimization. Organic traffic patterns operate on timescales of days to weeks. The decisions that move SEO metrics meaningfully (content audits, internal linking architecture changes, crawl budget optimization, Core Web Vitals improvements) are informed by trend data, not real-time data.

Meanwhile, almost nobody retains server logs for more than 30 days because storage costs in traditional log management systems are high and the SEO value is not obvious until you need it. I have seen Google algorithm update impact analyses that were completely undone by the fact that the server logs from the period immediately before the update had been deleted per a 30-day retention policy. OpenObserve makes 180-day log retention financially reasonable. This is a much more impactful investment than a fancier real-time dashboard.

There is a third thing, which is not exactly contrarian but is widely ignored: the relationship between analytics infrastructure and Core Web Vitals is more complicated than "remove client-side tags to improve LCP." Server-side tagging introduces its own latency characteristics. If your sGTM endpoint has a 400ms response time for tag processing, and your tag configuration has client-side callbacks that wait for server responses before firing conversion pixels, you have potentially introduced more latency than you removed. I have had to remediate exactly this situation on two clients who migrated to sGTM expecting automatic performance improvements and saw measured LCP degradation instead. The Core Web Vitals documentation does not address this scenario explicitly, which is a gap.

Deploying the Stack on Cloud Run

For clients where the STAMBIA score justifies self-hosted sGTM, here is the Cloud Run deployment configuration I am currently using. This is not the default configuration from the GTM documentation, and the differences matter for cost and SEO performance.

# cloud-run-sgtm-service.yaml
# GTM Server-Side container with cost-optimized settings
# Adjust min-instances and max-instances based on your traffic profile

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: gtm-server
  labels:
    cloud.googleapis.com/location: europe-west1
  annotations:
    run.googleapis.com/launch-stage: BETA
spec:
  template:
    metadata:
      annotations:
        # Minimum 1 instance avoids cold start latency on organic traffic
        # Set to 0 only if you have no latency-sensitive tag configurations
        autoscaling.knative.dev/minScale: "1"
        # Cap prevents runaway costs on traffic spikes
        autoscaling.knative.dev/maxScale: "8"
        # Use second-generation execution environment for better cold start
        run.googleapis.com/execution-environment: gen2
        # CPU always allocated prevents latency on burst traffic
        run.googleapis.com/cpu-throttling: "false"
    spec:
      # Service account with minimal permissions
      serviceAccountName: sgtm-service@PROJECT_ID.iam.gserviceaccount.com
      containers:
        - image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
          ports:
            - containerPort: 8080
          env:
            - name: CONTAINER_CONFIG
              value: "YOUR_CONTAINER_CONFIG_STRING"
            - name: GOOGLE_CLOUD_PROJECT
              value: "YOUR_PROJECT_ID"
            # Preview server disabled in production to reduce attack surface
            - name: RUN_AS_PREVIEW_SERVER
              value: "false"
          resources:
            limits:
              # 1Gi is sufficient for most configurations; increase if OOM killing
              memory: "1Gi"
              cpu: "1000m"
            requests:
              memory: "512Mi"
              cpu: "500m"
          # Liveness probe prevents traffic routing to unhealthy instances
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 30

# Deploy command - run from authenticated gcloud environment
# Replace PROJECT_ID, REGION, and CONTAINER_CONFIG before executing

gcloud run services replace cloud-run-sgtm-service.yaml \
  --region=europe-west1 \
  --project=YOUR_PROJECT_ID

# Verify deployment and check for cold start behavior
gcloud run services describe gtm-server \
  --region=europe-west1 \
  --format="value(status.conditions)"

# Set IAM policy to allow unauthenticated requests
# (required for browser-to-server tagging endpoint)
gcloud run services add-iam-policy-binding gtm-server \
  --region=europe-west1 \
  --member="allUsers" \
  --role="roles/run.invoker"

# Configure custom domain for first-party context
# Replace with your actual domain configuration
gcloud beta run domain-mappings create \
  --service=gtm-server \
  --domain=metrics.yourdomain.com \
  --region=europe-west1

The custom domain configuration is not optional for SEO purposes. Running your sGTM endpoint on a subdomain of your primary domain (metrics.yourdomain.com rather than a Cloud Run default URL) is what enables first-party cookie context. Without this, the latency reduction from server-side collection does not translate into improved cookie persistence on ITP-affected browsers. This is the most commonly skipped step in sGTM deployments I have audited, and it is the step that most directly impacts the data quality improvements you are implementing server-side collection to achieve.

The Weird Numbers That Changed How I Think About Organic Traffic

When the reconciliation layer across all three data sources (Plausible, GA4, server logs) was fully operational across my client set in January 2026, the numbers that came out were strange enough that I spent three weeks trying to find errors before accepting that they were real.

On a B2B SaaS client with approximately 180,000 monthly organic sessions in GA4, Plausible self-hosted was recording 247,000 monthly organic sessions. A 37.2% gap. I expected a gap of 15–25% based on my experience with other clients. After eliminating methodological differences in session counting (Plausible and GA4 define sessions differently), the adjusted gap was 29.4%. Still much higher than expected.

Investigating the server logs in OpenObserve revealed that this client had an unusually high proportion of traffic from corporate network environments. Corporate proxies and content security policies frequently strip the referrer headers that GA4 relies on for channel attribution, and many corporate environments have Google Analytics blocked at the network level. Plausible's cookieless, lightweight approach was unaffected by these network-level blocks. The client's actual organic reach among their target audience (enterprise IT decision makers who are, almost by definition, operating in corporate network environments) was substantially larger than their GA4 data suggested.

This had a direct impact on content strategy. Several content pieces that appeared marginally performing in GA4 were actually performing well when measured against the full audience. The client had been considering consolidating or removing some of this content based on GA4 metrics. That decision would have been wrong.

A second set of weird numbers came from the Googlebot crawl timing analysis in OpenObserve. For one client, Googlebot was almost exclusively crawling the site between 02:00 and 06:00 UTC. The site's CDN caching configuration meant that dynamic content updated throughout the business day was not being served fresh to Googlebot because the cache TTLs were longer than the crawl interval. Pages updated at 14:00 were being crawled at 03:00 the following morning with 13-hour-old cache. This explained a persistent ranking lag for time-sensitive content that we had not been able to attribute to anything in the standard SEO toolset.

You can read more about diagnosing indexing delays using server logs in the indexing delay diagnosis guide, and the CDN cache configuration for SEO post covers the fix for the Cloudflare TTL issue we resolved for that client.

Where This Leaves SEO in a Cookieless Measurement World

The trajectory here is clear even if the timeline is not. Third-party cookies are gone. First-party cookies face increasing restrictions from browser vendors who have competitive incentives to limit measurement capabilities. The analytics tools that worked in 2019 produce increasingly inaccurate data in 2026, and the inaccuracies are not random noise. They are systematic biases that consistently undercount specific audience segments: privacy-conscious users, corporate network users, mobile Safari users, users in markets with high VPN adoption.

These are not marginal users. In many B2B verticals, corporate network users are the primary target audience. In consumer markets, iOS Safari users represent enormous purchasing power. Making content investment decisions based on data that systematically undercounts these users is not just imprecise. It actively misdirects investment away from content that serves the audiences most worth serving.

The stack I have described, combining sGTM or Stape for tag management, Plausible self-hosted for cookieless session measurement, OpenObserve for server log analysis, and BigQuery as the reconciliation layer, is not the only valid answer to this problem. But it is a working answer that I have deployed, debugged, and measured. The STAMBIA framework will probably give you a different configuration for your specific situation. That is the point of a framework.

What is not optional, in my view, is accepting that any single analytics tool gives you the full picture of your organic search performance. The reconciliation approach, running multiple measurement methodologies and treating the differences as signal rather than noise, is the methodology that actually produces accurate enough data to make consequential decisions with confidence. Everything else is educated guessing at a level of precision that feels accurate but is not.

The server-side journey cost me (or more accurately, cost a client) $1,140 in a month and six months of evenings rebuilding infrastructure. What it produced was a measurement foundation that I now trust in a way I have not trusted analytics data in the GA4 era. That trade feels correct in retrospect, even if the path was more expensive than it needed to be.

The irony is that "server-side" turns out to mean different things depending on which problem you are solving. For tag management, it means sGTM. For session measurement, it means self-hosted Plausible. For SEO forensics, it means raw log ingestion in OpenObserve. Each layer solves a different measurement failure mode, and none of them alone is sufficient. That complexity is annoying. It is also accurate.

Frequently Asked Questions

Is GTM Server-Side worth the cost for small sites?

For sites below 500,000 monthly sessions, the cost of running server-side GTM on Cloud Run typically outweighs the measurement quality benefits. Consider Stape's managed offering as a cost-controlled alternative, or use Plausible self-hosted as the primary measurement layer without the GTM overhead. The STAMBIA framework helps quantify this decision for your specific situation.

How significant is the data gap between GA4 and cookieless analytics like Plausible?

Across eight clients measured in 2025 and early 2026, the gap between Plausible self-hosted session counts and GA4 organic session counts ranged from 18% to 37%. The gap correlates with the proportion of iOS Safari traffic and corporate network traffic in the audience mix. B2B sites typically see larger gaps than consumer sites.

Does server-side GTM actually improve Core Web Vitals?

Not automatically. Removing client-side JavaScript tags reduces TBT and can improve LCP when the tags were render-blocking. But if your sGTM configuration has client-side callbacks waiting for server responses, or if your sGTM endpoint has high latency, you can introduce new performance problems. Measure before and after, do not assume.

Can OpenObserve replace a dedicated server log analysis tool for SEO?

For most SEO log analysis use cases, yes. OpenObserve handles the query volumes and retention periods required for technical SEO forensics at a fraction of the cost of managed Elasticsearch. The SQL-compatible query interface reduces the learning curve. The main limitation is that it requires self-hosting and operational ownership.

What is the most important step in a server-side analytics migration for SEO?

Establishing the cross-source reconciliation view in BigQuery before you make any decisions based on the new data. Do not switch from GA4 to your new stack and assume the new numbers are right. Run all sources in parallel for at least 60 days, understand the systematic differences, and only then adjust your decision-making framework to account for what each source measures and what it misses.