Why Analytics Numbers Don’t Match and What Your Team Can Do Next

Marketing analytics numbers do not match when systems measure different business facts, apply different definitions, identify people differently, use different dates, transform data differently, or report from different points in the customer journey. A discrepancy is not proof that one system is wrong.
The bigger risk is the opposite: two dashboards can agree while sharing the same bad definition or flawed transformation.
That changes the standard for analytics trust. The goal is not to force Google Ads, Google Analytics, CRM, sales, and finance to show identical totals. The goal is to know what each number means, how it was produced, which system has authority for the business fact, and whether the remaining uncertainty could change the decision.

Key Takeaways

• Marketing data discrepancies do not automatically mean tracking is broken. Marketing platforms, analytics, CRM, sales, and finance can report different numbers because they measure different business facts, use different identities, count at different grains, or assign events to different periods.
• Reconciliation starts with meaning, not dashboards. Align the business fact, metric definition, population, grain, identity rules, and reporting period first. Then trace data lineage and compare records to determine where material differences enter the measurement system.
• There is no universal source of truth for every metric. Assign authority by business fact: advertising platforms can own platform activity, CRM can own lifecycle status, and finance can own recognized revenue. Other systems should provide supporting evidence and reconciliation checks.
• Decision-grade trust does not require perfect numerical agreement. A metric should be comparable, traceable, reproducible, sufficiently complete and current, explainable, owned, and monitored. The acceptable discrepancy is the level of uncertainty that cannot materially change the decision.

A useful rule follows:

Cross-system disagreement becomes a measurement problem only after the systems are confirmed to measure the same business fact, population, unit, and period.

Marketing data reconciliation therefore works from meaning to evidence: align definitions, trace data lineage, resolve identity and timing boundaries, assign measurement ownership, explain each material difference, and define when the result is trustworthy enough to use. These controls form part of a broader analytics and attribution framework that connects measurement quality to the business decisions the data is meant to support.

Why disagreement is normal – and when it is dangerous

Different marketing, analytics, CRM, sales, and finance systems often disagree by design. They observe different stages of the same commercial process and apply rules suited to their own purpose.

The dangerous part is not the existence of a gap. It is being unable to explain why the gap exists or whether it matters.

Different systems answer different business questions

Consider one buyer who clicks a Google ad, visits a website, calls the company, becomes a CRM contact, enters a sales opportunity, and later becomes a customer.

Several systems can observe that journey:

• Google Ads records an advertising interaction and eligible conversions.
• Google Analytics records website or app activity.
• A call-tracking platform records the phone interaction.
• The CRM records contacts, lifecycle stages, and opportunities.
• A transaction or finance system records the commercial outcome.

Those records are connected, but they are not interchangeable.

An analytics conversion is not automatically a lead. A lead is not automatically a qualified opportunity. An opportunity is not revenue. If leadership compares these counts as if they represent the same object, a reporting discrepancy exists before any technical problem occurs.

This is why CRM vs analytics data discrepancies often survive even after tracking has been checked. The systems may be functioning correctly while answering different questions.

The four checks before you compare numbers

Before investigating a mismatch, establish whether both reports describe the same:

Boundary	Question to answer
Business fact	What event or state does the number represent?
Population	Which records qualify for inclusion?
Grain	What unit is being counted?
Period	Which date and reporting window determine inclusion?

Suppose marketing reports 600 conversions and sales reports 410 leads. The 190-record difference has little diagnostic meaning until these four boundaries are aligned.

Marketing may include repeated form submissions. Sales may deduplicate contacts. Marketing may count an event when it occurs. CRM reporting may use the contact creation date. One report may include unqualified submissions that the other intentionally excludes.

The totals are different, but the underlying problem may simply be comparability.

When normal variance becomes dangerous

Expected differences have a known mechanism. Dangerous differences do not.

A stable gap caused by documented timing rules, identity limits, or inclusion logic may require no repair. A sudden unexplained change in a previously stable relationship deserves investigation.

For example, Google documents multiple causes of discrepancies in Google Ads conversion reporting, including conversion delay, count settings, attribution settings, cross-device conversions, and other reporting differences. Google also provides “by conversion time” columns to make some comparisons with other reporting systems more aligned.

The practical distinction is:

Expected variance has a documented cause. Measurement failure creates a material difference that cannot be explained by the agreed measurement rules.

That distinction prevents teams from trying to eliminate every difference while missing the discrepancies that actually threaten decisions.

Definition drift

Definition drift occurs when a metric keeps the same label while its business meaning changes across teams, systems, reports, or time.

It is one of the most deceptive causes of marketing analytics discrepancies. The tracking can work perfectly while the reports become less comparable every month.

Same label, different business rule

“Lead” can mean a submitted form, a unique CRM contact, a marketing-qualified contact, or a record accepted by sales.

“Revenue” can mean order value, booked contract value, invoiced revenue, collected cash, or recognized revenue.

“Conversion” can also change according to system settings. Google Ads, for example, lets advertisers count either every conversion after an interaction or only one conversion for a conversion action. Google notes that “Every” is often suitable for sales, while “One” can be more appropriate for lead generation.

That creates a simple but important principle:

A metric name does not define a metric. Its counting and eligibility rules do.

Two reports should not be reconciled at the total level until those rules are explicit.

Grain changes the number before data quality does

Grain means the unit represented by one record or one count.

Marketing measurement can operate at the level of:

• event;
• session;
• user;
• contact;
• account;
• opportunity;
• order;
• transaction.

One person can create several sessions. One contact can submit several forms. Several contacts can belong to one account. One customer can make several purchases.

A system counting contacts and a system counting form events can therefore produce different totals without either containing duplicate or missing data.

This is why “what exactly are we counting?” should come before “which system is wrong?”

Once grain is aligned, a genuine missing-record problem becomes much easier to identify.

Definition versioning prevents false performance trends

Definitions also change over time.

Sales may tighten qualification criteria. Marketing may exclude a source it previously counted. Finance may change which revenue status enters management reporting. A dashboard may adopt a new filtering rule.

If the metric keeps the same name, the resulting graph appears continuous even though the measurement logic is not.

The business can then mistake a definition change for a performance change.

A decision-grade metric therefore needs version history for material changes:

• what changed;
• why it changed;
• when the new rule became effective;
• which reports use it;
• whether historical values were recalculated.

Definition versioning does not stop a business from improving its metrics. It stops the improvement from silently rewriting the meaning of the trend.

A metric contract makes the number reproducible

A practical way to control definition drift is a metric contract.

The contract is not a large governance document. It is the minimum specification required to reproduce and defend an important metric.

Metric-contract element	Required definition
Business fact	What does the metric represent?
Calculation	How is it calculated?
Grain	What unit is counted?
Inclusion rules	Which records qualify?
Exclusion rules	Which records do not qualify?
Source	Which underlying data is used?
Date rule	Which timestamp assigns the value to a period?
Owner	Who controls the business meaning?
Version	Which definition is currently valid?

A metric contract changes the diagnostic sequence.

If two systems use different contracts, align meaning first. If they use the same contract and still disagree, follow the data path.

That is where data lineage takes over.

Data lineage and transformation

Data lineage is the trace from the original source record through the transformations that produce a reported metric.

It matters because the number shown in a dashboard is often not source data. It is the output of collection, integration, filtering, joins, deduplication, business logic, and aggregation.

Follow the number from source to decision

A useful cross-system lineage can be expressed as:

Source collection integration transformation business logic reporting decision

This is more than a technical architecture diagram.

Each step answers a reconciliation question:

• Where was the original event or record created?
• How did it enter the measurement environment?
• Which systems received it?
• Which transformations altered it?
• Which business rules affected inclusion?
• Which reporting layer aggregated it?
• Which decision now depends on it?

Business-intelligence research similarly describes BI environments as systems that collect, integrate, analyze, and present information from operational sources to support decision-making.

For analytics reconciliation, the implication is direct: a final total should be treated as the end of a data path, not as an isolated fact.

Hidden transformations create invisible divergence

Suppose a CRM contains 10,000 records and the executive dashboard shows 9,250.

The 750-record difference does not automatically mean records were lost.

The reporting model may have intentionally:

• removed test entries;
• filtered invalid statuses;
• excluded certain markets;
• joined another dataset;
• deduplicated contacts;
• removed cancelled transactions;
• applied a different date field.

Each transformation may be legitimate.

The problem begins when nobody can see that it happened.

Data lineage converts a vague total mismatch into a more useful question:

At which step did the records stop being equivalent?

That is much easier to investigate than comparing the same two dashboard totals repeatedly.

Parallel transformations create competing versions of the same metric

A particularly difficult form of drift appears when several teams independently calculate the same metric.

Marketing may derive revenue inside a BI model. Sales operations may calculate it from CRM properties. Finance may maintain another transformation based on transaction data.

The pipelines begin with related records, but they evolve independently.

One filter changes. One mapping is updated. One team changes a status definition. Another backfills historical records.

Soon, each system can defend its number.

The organization has not created three sources of truth. It has created three transformation paths.

Where possible, shared business logic should be defined once and reused. Where separate logic is necessary, the difference should be deliberate and named.

Recent data can legitimately change after reporting

Timing inside the data pipeline creates another source of disagreement.

Google Analytics states that data processing can take 24 to 48 hours and that values in reports may change during that period. It also distinguishes between reporting surfaces with different freshness intervals.

Google Ads documents conversion lag separately. A person can interact with an ad and convert later, which means recent CPA can initially appear higher and ROAS lower while additional conversions are still being recorded.

The broader rule is not specific to Google:

Recent data and closed-period data should not receive the same confidence automatically.

A CRM may already contain today’s updated opportunity status while a warehouse refresh has not run. Finance may have closed a reporting period while marketing systems continue receiving delayed outcomes.

If the systems are compared before their processing states align, the discrepancy is partly created by the comparison itself.

Reporting surfaces can differ without a broken pipeline

Even reports from the same platform may expose different views of the available data. Google Analytics documents different freshness intervals and notes that some reports can also be affected by data thresholds, which may withhold information under defined conditions.

That means a reconciliation record should identify the actual reporting surface.

“GA4 says 8,200” is less useful than specifying whether the figure came from a standard report, exploration, API query, export, or downstream warehouse model.

The same discipline applies to CRM and BI environments.

When a number can be traced through its material transformations, the next question becomes narrower: are both systems referring to the same person, record, and time boundary?

Identity and timing boundaries

Identity and time determine which records systems group together and which reporting period receives them.

A mismatch can therefore survive perfect definitions and perfect data movement. The systems may still disagree about who the customer is or when the business event belongs.

A user is not the same entity as a contact, account, or transaction

Analytics systems often begin with a digital identity. CRM and commercial systems usually work with business entities.

Those are different layers.

A website visitor may appear as:

device user contact account opportunity customer transaction

The path is not always one-to-one.

One person may use several devices. Two people may share a device. Several contacts may belong to one B2B account. One customer can generate several opportunities or transactions.

Google Analytics illustrates this identity problem directly. GA4 can use User-ID, device ID, and, under some configurations, modeling to construct its reporting identity and deduplicate users across interactions.

A CRM uses different identifiers and different merging rules.

So a user count and a CRM contact count should not be expected to match merely because both appear to describe “people”.

Deduplication changes totals by design

Deduplication is not always a cleanup step. It is also a business rule.

A marketing system may preserve every form submission. A CRM may merge submissions with the same contact. Sales may create one opportunity from several interactions. A transaction system may later contain several purchases from that person.

The correct relationship might be:

• one-to-one;
• one-to-many;
• many-to-one;
• many-to-many.

Until that relationship is known, duplicate counts cannot be classified reliably.

This gives cross-system reconciliation another useful rule:

Match entities before matching totals.

If two systems use different identity models, the expected record relationship should be documented before variance is judged.

The date rule can move the same event between reporting periods

One commercial outcome can have several legitimate dates.

A lead may be created in January, qualified in February, converted to an opportunity in March, closed in April, and paid in May.

Which month owns the result?

That depends on the metric.

Marketing might analyze the interaction or conversion date. Sales may report opportunity close date. Finance may report invoice, payment, or recognition timing.

Google Ads provides a concrete example. Standard conversion reporting can associate conversions with the date of the ad interaction, while “by conversion time” columns allow reporting based on when the conversion happened.

Both views can be useful.

They answer different time questions.

Conversion windows add another boundary

A conversion can also fall inside one system’s eligibility window and outside another’s.

Google Ads allows conversion windows to be configured for conversion actions. A conversion outside the chosen window will not be reported for that interaction. Changes to the window can also affect which future conversions qualify.

This matters for reconciliation, but only to a point.

When the dispute concerns how a conversion receives marketing credit rather than whether the underlying event occurred, the problem moves into attribution. BiViSee treats that as a separate question in Why Attribution Models Disagree.

Cross-system reconciliation should establish the event, identity, value, and timing boundary first.

Close the period before comparing systems

The cleanest reconciliation period is one in which the relevant systems have reached an agreed level of stability.

That does not always mean waiting for every possible future update. It means defining a cut-off appropriate to the decision.

For example:

• the analytics processing window has passed;
• expected conversion lag has been considered;
• the CRM sync has completed;
• warehouse transformations have run;
• material backfills are known;
• finance or sales reporting has reached its defined close.

A closed period removes one major source of noise.

Once identity and timing are aligned, the remaining disagreement becomes a question of authority: which system should govern which business fact?

Measurement ownership

Measurement ownership defines who controls the meaning of a metric, who maintains its implementation, and which system has authority when valid reports disagree.

Without that clarity, analytics reconciliation can identify the difference but still fail to settle the decision.

Stop searching for one universal source of truth

A single source of truth is useful for a defined business fact. It is usually a weak model for an entire commercial journey.

Different systems may legitimately own different facts.

Google Ads can be the authoritative source for spend recorded in Google Ads. A CRM can hold the accepted opportunity stage. A transaction system can own completed orders. Finance can control recognized revenue.

None needs to become universally authoritative.

A stronger model is:

one defined authority for each material business fact.

That lets systems retain their operational roles without creating permanent ambiguity in decision-making.

Separate system of observation, system of record, and decision authority

Three roles clarify measurement ownership.

A system of observation records evidence that an activity occurred.

A system of record maintains the accepted operational record for a defined object or process.

Decision authority identifies the source and owner that govern a specific decision when valid representations differ.

For example, analytics may observe a purchase event while the commerce platform records the transaction and finance governs recognized revenue.

These systems are not competing for one universal truth. They occupy different positions in the evidence chain.

BiViSee’s broader Marketing Measurement and Attribution framework applies the same principle across marketing, website, CRM, sales, and revenue data: reporting becomes useful when the systems can support the same business decision without pretending they observe the same thing.

Metric owner and technical steward are different roles

The metric owner controls business meaning.

The technical steward controls implementation reliability.

Those responsibilities need to work together, but they should not be confused.

A data engineer can maintain a reliable pipeline without having authority to decide what “sales-qualified opportunity” means. A commercial owner can define that stage without being responsible for maintaining warehouse transformations.

The separation matters when definitions change.

The business owner approves the meaning. The technical steward ensures the systems implement it correctly. The report owner, where separate, ensures the published view reflects the approved logic.

Clear roles prevent technical convenience from silently changing business meaning.

Assign authority by business fact

A measurement authority map makes these relationships explicit.

Business fact	Typical system of record	Typical decision owner
Advertising spend	Ad platform	Paid media / marketing
Website behavior	Analytics platform or governed warehouse	Analytics
Lead lifecycle status	CRM	Marketing or revenue operations
Opportunity stage	CRM	Sales operations
Completed transaction	Commerce or transaction system	Revenue operations
Recognized revenue	Finance system	Finance

The exact structure depends on the organization.

The important part is that the mapping exists before a disagreement reaches an executive meeting.

Otherwise, “Which number is right?” becomes a political question.

With ownership established, the organization can finally reconcile the systems in a repeatable way.

Reconciliation workflow

A good reconciliation workflow starts with the decision, not the dashboards.

That changes the investigation from “Which tool is correct?” to “What evidence must agree before we can use this number?”

1. Define the decision and the business fact

Start by naming the action that depends on the number.

Examples include:

• reallocating marketing budget;
• judging lead quality;
• forecasting pipeline;
• evaluating customer acquisition economics;
• reporting revenue performance.

Then state the business fact precisely.

Avoid “conversions” when the decision really depends on “unique qualified opportunities created during the quarter”.

Avoid “revenue” when the required fact is “recognized revenue from customers acquired during the reporting period”.

A precise business fact determines which systems should enter the reconciliation.

2. Align the metric contract, grain, and period

Before comparing totals, confirm:

• definition;
• inclusion and exclusion logic;
• counting unit;
• identity boundary;
• date rule;
• reporting cut-off;
• metric version.

If these conditions differ, quantify the structural differences first.

Do not debug a pipeline to fix a mismatch created by incompatible definitions.

3. Map the lineage and compare records at the lowest useful grain

Trace each metric back through the systems that produced it.

Then compare the lowest practical common unit: transaction ID, opportunity ID, order ID, contact ID, or another durable key.

Aggregate totals show that a difference exists.

Record-level reconciliation explains it.

Instead of discussing why one system has 4,320 records and another has 4,117, identify which 203 records differ and group them by cause.

That is where the discrepancy becomes actionable.

4. Build a reconciliation bridge

A reconciliation bridge converts System A into the comparable basis used by System B.

A simple structure is:

System A total

+/- definition differences

+/- identity and deduplication differences

+/- timing and freshness differences

+/- missing or late records

+/- transformation differences

= comparable System B total

The purpose is not accounting-style perfection for every marketing metric.

The purpose is explainability.

A strong bridge shows which differences are expected, which can be corrected, and which remain uncertain.

5. Classify the remaining differences

Every material discrepancy should finish in one of four states.

Expected: The difference follows documented system rules.

Explainable: The cause is understood and the difference is acceptable for the current use.

Fixable: A technical or governance problem should be corrected.

Unresolved: The cause remains unknown and could affect confidence.

This classification prevents two opposite mistakes: wasting time eliminating harmless structural differences and accepting unexplained differences that can change a decision.

6. Record the accepted result and the next review trigger

Reconciliation should leave an operating record.

Capture:

• the business fact;
• metric contract;
• systems compared;
• accepted authority;
• explanation for material differences;
• known limitations;
• owner;
• conditions requiring another review.

Review triggers may include a CRM migration, tracking release, schema change, new lifecycle rule, material variance shift, or change in reporting ownership.

The result is more than a corrected report.

It is a controlled relationship between systems that can survive future change.

Decision-grade acceptance criteria

Decision-grade analytics does not require every system to agree. It requires enough evidence to know whether the number can safely support the decision.

That is a higher standard than dashboard consistency and a more practical standard than perfect measurement.

Agreement is not the same as accuracy

Two dashboards can match because both inherit the same error.

They may use the same incomplete source, flawed transformation, duplicate logic, or incorrect definition.

Agreement therefore proves consistency between outputs. It does not prove the underlying business fact is correct.

The stronger question is:

Can the number be traced, reproduced, explained, and connected to an appropriate authority?

A number that passes those tests can remain useful even when another system reports a different total.

There is no universal acceptable discrepancy percentage

A fixed rule such as “5% is acceptable” ignores what the metric is used for.

Materiality depends on:

• the business fact;
• the systems being compared;
• historical variance;
• monetary exposure;
• decision consequence;
• data maturity;
• explainability of the gap.

A small unexplained difference in a high-value revenue metric can deserve more attention than a larger understood variance in a directional marketing signal.

The acceptance threshold should therefore be decision-specific.

The right tolerance is the amount of uncertainty that can exist without changing the decision or misrepresenting its risk.

Establish normal variance before treating every movement as failure

Historical reconciliation can reveal whether a system pair has a stable relationship.

If a known timing or identity difference normally produces a consistent gap, that history becomes useful context.

The baseline does not make bad data acceptable.

It makes change easier to detect.

A system pair that normally differs predictably and suddenly breaks that pattern creates a stronger diagnostic signal than a system pair that has never been comparable.

Use a decision-grade trust test

A cross-system metric is ready for material use when it is sufficiently:

Criterion	Decision question
Comparable	Are the systems measuring equivalent business facts?
Traceable	Can the number be followed back to its source?
Reproducible	Can the documented rules recreate it?
Complete	Are material records present?
Current	Is the data stable enough for the reporting period?
Explainable	Are material differences understood?
Reliable	Could residual uncertainty change the decision?
Owned	Is authority for the metric explicit?
Monitored	Will material changes trigger review?

These criteria do not demand impossible certainty.

They define controlled uncertainty.

That distinction is important for analytics trust: confidence should come from knowing the limits of the number, not from hiding them.

Know when to audit, govern, accept, or pause

The pattern of the discrepancy should determine the response.

A sudden unexplained variance after a tracking or integration change points toward technical investigation.

Gradual divergence across teams often points toward definition drift or duplicated transformations.

Recurring arguments over the same accepted data suggest an ownership problem.

Stable, explainable structural variance may require no repair at all.

Leadership should pause or qualify a decision when the unresolved difference could materially change the action, especially when the metric definition is unclear, important records cannot be reconciled, the lineage contains an unknown transformation, or nobody has authority to determine which business fact governs the decision.

That is the boundary between analytics imperfection and decision risk.

Keep adjacent measurement problems separate

Cross-system number reconciliation should not become a catch-all for every analytics problem.

If the underlying outcome is accepted but models disagree about which marketing touchpoint deserves credit, the issue belongs to attribution-model analysis rather than reconciliation. See Why Attribution Models Disagree.

If the numbers are reliable but the business is optimizing the wrong metric, the issue is KPI design. BiViSee examines that risk separately in KPI Tunnel Vision.

Channel self-attribution and channel bias also require a different question: whether reported channel credit represents actual contribution. And when events are missing, duplicated, or malformed, the problem moves into tracking implementation.

Keeping those problems separate makes the reconciliation page more useful.

The final standard is straightforward:

Analytics numbers do not need to match perfectly to be trustworthy. They need to have defined meaning, traceable lineage, compatible identity and timing rules, explicit authority, explainable variance, and a known level of uncertainty for the decision they support.

Once those conditions exist, the question “Which dashboard is right?” becomes much less important.

The business can answer the question that actually matters: Which number should govern this decision, and why can we trust it enough to act?

Scientific context and sources

The sources below provide scientific and first-party technical context for the principles used on this page. The research explains why data quality depends on more than numerical accuracy and why its usefulness is tied to the decision being made. The official platform documentation shows how differences in counting, identity, timing, processing, and conversion settings can create legitimate reporting discrepancies between systems.

Scientific research

• Data quality is broader than numerical accuracy
  Beyond Accuracy: What Data Quality Means to Data Consumers
  Richard Y. Wang and Diane M. Strong – Journal of Management Information Systems, 1996
  Develops a multidimensional framework for data quality based on what information users need from data. It supports the distinction between numerical agreement and decision-grade trust: accuracy is only one dimension of whether data is fit for use.
  https://doi.org/10.1080/07421222.1996.11518099
• Data quality depends on the decision context
  Supporting Data Quality Management in Decision-Making
  Ganesan Shankaranarayanan and Yu Cai – Decision Support Systems, 2006
  Proposes a decision-support framework in which data quality is evaluated both objectively and in relation to the decision context. It supports using decision-specific acceptance criteria rather than assuming that one universal discrepancy threshold determines whether data is trustworthy.
  https://doi.org/10.1016/j.dss.2004.12.006
• The usefulness of data quality is context-dependent
  Data Quality Assessment in Context: A Cognitive Perspective
  Stephanie Watts, Ganesan Shankaranarayanan, and Adir Even – Decision Support Systems, 2009
  Examines how decision-makers evaluate information quality using objective quality information alongside the context of the task. It supports the principle that the same dataset can be adequate for one decision and inadequate for another.
  https://doi.org/10.1016/j.dss.2009.07.012
• Data provenance supports traceability and reproducibility
  A Survey on Provenance: What For? What Form? What From?
  Melanie Herschel, Ralf Diestelkämper, and Houssem Ben Lahmar – The VLDB Journal, 2017
  Reviews data provenance research and its use for accountability, reproducibility, process debugging, and understanding how data products were produced. It provides scientific context for treating data lineage as a core requirement of trustworthy cross-system reconciliation.
  https://doi.org/10.1007/s00778-017-0486-1
• Data-quality information can affect decision-making
  Determining the Use of Data Quality Metadata for Decision Making Purposes and Its Impact on Decision Outcomes – An Exploratory Study
  Helen-Tadesse Moges, Véronique Van Vlasselaer, Wilfried Lemahieu, and Bart Baesens – Decision Support Systems, 2016
  Examines how decision-makers use information about data quality and how that information can affect decision outcomes. It reinforces the distinction between exposing data-quality limitations and assuming that one quality measure is sufficient for every decision environment.
  https://doi.org/10.1016/j.dss.2015.12.006
• Business intelligence depends on integrated data management
  Towards a Conceptual Framework for Data Management in Business Intelligence
  Ramakolote Judas Mositsa, John Andrew Van der Poll, and Cyrille Dongmo – Information, 2023
  Describes business intelligence as combining data collection, integration, analysis, management, and presentation to support organizational decision-making. It provides research context for treating an executive metric as the product of a data-management chain rather than an isolated dashboard value.
  https://www.mdpi.com/2078-2489/14/10/547

Official platform documentation

The sources below document specific Google Ads and Google Analytics behaviors that can cause two valid reports to show different values. They provide first-party technical evidence for the practical examples used throughout this page.

• Conversion windows determine which conversions qualify for reporting
  About Conversion Windows – Google Ads Help
  Google Ads defines a conversion window as the period after an ad interaction during which a conversion can be recorded. Conversions occurring outside the selected window are not reported for that interaction, and changes to the setting apply to future conversions.
  https://support.google.com/google-ads/answer/3123169?hl=en
• Google Ads documents multiple causes of reporting discrepancies
  Data Discrepancies: Factors and Troubleshooting – Google Ads Help
  Google identifies conversion delay, tag setup, lookback windows, count settings, cross-device conversions, view-through conversions, invalid traffic, and attribution settings among the reasons Google Ads can differ from Analytics or third-party reporting. It also recommends conversion-time columns for more aligned comparisons where appropriate.
  https://support.google.com/google-ads/answer/7457111?hl=en
• Reporting identity changes how GA4 represents users
  Reporting Identity – Google Analytics Help
  Google Analytics can use User-ID, device ID, and, under eligible configurations, modeling to construct reporting identity. These identity spaces can combine activity into a unified user journey and deduplicate users, which helps explain why GA4 user counts may not correspond directly to CRM contact counts.
  https://support.google.com/analytics/answer/10976610?hl=en
• GA4 data can change while processing is still underway
  Data Freshness and Service Level Agreement Constraints – Google Analytics Help
  Google Analytics documents different freshness intervals for realtime, intraday, and daily data. Processing can take 24-48 hours, and report values may change while fuller processing becomes available. Recent reports therefore should not automatically be treated as equivalent to stabilized closed-period data.
  https://support.google.com/analytics/answer/12233314?hl=en
• Conversion lag can temporarily distort performance metrics
  About Conversion Lag Reporting – Google Ads Help
  Google Ads defines conversion lag as the delay between an ad interaction and the later conversion. Until delayed conversions are recorded, recent CPA can appear higher and ROAS lower than their eventual values, creating temporary differences between recent and more mature reporting periods.
  https://support.google.com/google-ads/answer/9347141?hl=en
• Conversion-count settings can change reported totals
  About Conversion Counting Options – Google Ads Help
  Google Ads allows a conversion action to count either every qualifying conversion after an interaction or one conversion. Google explains that counting every conversion is often appropriate for sales, while counting one can be useful for lead-generation actions where repeated submissions should not represent additional unique leads.
  https://support.google.com/google-ads/answer/3438531?hl=en

Questions You Might Ponder