Tag: CDI

You have a cross-channel dashboard ready for review, but some campaign numbers arrived through an import rather than Google’s native collection. The dangerous failure may not look like an error. A campaign can appear in the report while its cost, clicks, or impressions are absent, leaving a dashboard that looks complete enough to trust.

Google’s Campaign Data Import Validation Report gives you a quality-control checkpoint. It reviews non-Google campaign data and previously imported data, then highlights campaigns that may be missing cost, clicks, or impressions. The practical move is to treat this validation as a release gate for reporting, not merely as a troubleshooting screen.

Read each result as a completeness warning

The validation report is designed to help answer a narrow but important question: are essential reporting fields missing from imported campaign data? It does not remove the need to determine why a field is absent or whether a populated value is correct.

Keep three data states separate:

• Present and correct: the imported value agrees with the originating platform for the same campaign and reporting window.
• Present but incorrect: the field contains a value, but a mapping, transformation, unit, scope, or duplication problem changed its meaning.
• Missing: the import contains no usable observation for a field that should have been supplied.

The validation report is especially useful for finding the third state. Do not automatically convert it into the first by replacing a missing field with zero. Zero means the platform recorded none of the activity being measured. Missing means you do not yet have a usable value. Treating those states as interchangeable can understate totals and make derived performance metrics look valid when they are not.

Run validation before the dashboard is released

A report that is checked after executives or clients have acted on it is an incident review, not a control. Put validation between the import and the reporting handoff.

1. Define the expected scope. Record the non-Google platforms, accounts, campaigns, and reporting window that the import is supposed to cover. Without an expected set, an omitted campaign can remain invisible because there is nothing to compare against.
2. Complete the import. Keep the import run, date range, and source files identifiable so that a flagged result can be traced back to the data that produced it.
3. Review the validation report. Identify campaigns with missing cost, clicks, or impressions. Include previously imported data in the review when it remains part of the reporting period.
4. Create an exception record. For every unresolved campaign, capture the platform, campaign, missing field, reporting window, owner, cause, and planned reporting treatment.
5. Repair the earliest broken layer. Correct the source extract, field mapping, transformation, or import scope instead of typing a replacement value into the final dashboard.
6. Import the corrected data and validate again. A change is not complete merely because the pipeline ran without an operational error. Confirm that the original warning has been resolved.
7. Reconcile against the originating platform. Compare campaign coverage and totals for the same reporting window before approving the dashboard.

Your pass condition should be explicit. Every expected campaign should either contain the applicable metrics or have a documented exception explaining why a metric is unavailable and how the campaign will be handled. If a platform genuinely does not provide a particular field, record that limitation rather than manufacturing a value.

Trace a missing metric to the layer that failed

A validation flag identifies the symptom. Diagnose it in pipeline order so you do not waste time fixing a later layer that never received the data.

1. Check the source extract. Find the affected campaign and reporting window in the exported data. If the metric is absent there, the importer could not have populated it. Correct the export selection or document the source limitation.
2. Check field mapping. Confirm that the source column for cost, clicks, or impressions maps to the intended destination field. Pay attention to renamed columns and platform-specific labels.
3. Check transformations. Look for parsing rules, data-type conversions, filters, and blank-value handling that could remove a valid value before loading it.
4. Check scope. Compare the account, campaign, and date filters used in the extract with those used in the import. A valid metric from the wrong period does not repair the affected reporting window.
5. Check the load result. Verify that the corrected campaign row reached the imported dataset and that a repeated import did not create an unintended duplicate.

If several metrics are absent for the same campaign, check row coverage and scope before debugging each field independently. If only one metric is absent while the others are populated, inspect that field’s source column, mapping, and transformation path first. These are diagnostic priorities, not assumptions about the cause.

Fix the problem where it first appears. A manual patch in a dashboard may repair one visible number while leaving the import pipeline broken for the next refresh.

A clean validation result still needs reconciliation

Completeness and accuracy are different controls. A populated cost field can still contain the wrong currency, the wrong reporting period, a duplicate value, or data from the wrong campaign. Presence validation cannot establish that the number carries the intended meaning.

After resolving missing-field warnings, run these checks:

• Campaign coverage: compare the imported campaign roster with the expected roster from each non-Google platform. Use a stable campaign identifier where one is available; names alone may be ambiguous.
• Reporting window: confirm that both systems use the same start date, end date, and time-zone treatment.
• Units and currency: verify that cost values have not been mixed across currencies or transformed into an unexpected unit.
• Metric definitions: make sure the source field represents the same type of click or impression that your cross-channel report labels. Similar names do not guarantee identical platform definitions.
• Aggregate totals: compare imported totals with totals from the originating platform for the same scope. Define how documented processing differences or rounding will be handled instead of accepting any unexplained mismatch.
• Reimport behavior: determine whether a correction replaces, updates, or appends to previous data. Then check for duplication after the corrected load.

This second control catches an important failure mode: the wrong value in the right field. A fully populated import can pass a completeness check while still producing a misleading channel comparison.

Key takeaways

• Use the Campaign Data Import Validation Report to identify non-Google and previously imported campaigns that may be missing cost, clicks, or impressions.
• Treat a missing metric as unknown until you investigate it. Do not silently convert it to zero.
• Validate after the import but before the data reaches a decision-making dashboard or recurring report.
• Repair problems in the source extract, mapping, transformation, scope, or load rather than patching the presentation layer.
• Reconcile campaign coverage and totals after clearing validation warnings because complete data can still be incorrect.

For your next reporting cycle, make the handoff require three items: validation status, a list of unresolved exceptions, and confirmation that source totals were reconciled. That turns imported-data quality from an assumption into a control someone must complete.

References

• Search Engine Land — Google adds Campaign Data Import Validation Report