The Processing Rule That Ate the Campaign
A B2B client imports lead data into Adobe Analytics via a Data Sources full import, joining on marketingCloudId (the CRM ID) mapped to a custom eVar. They also have a processing rule that sets campaign from a query parameter when present, and a VISTA rule (legacy) that overwrites campaign with a value from a lookup table for a specific set of pages. Last month, a marketing ops analyst ran a Data Sources import with a malformed column header, and the import was accepted but 60% of rows landed in 'Unspecified'. Separately, the client reports that campaign attribution for a recent webinar is undercounted by roughly half. The Data Sources file is 180,000 rows and is imported monthly.
1. Separate the Data Sources issue from the campaign attribution issue. Are they related, and how would you determine the root cause of each?
Read the worked answer
They are almost certainly not the same root cause, and conflating them is the trap.
Data Sources issue: A malformed column header that is 'accepted' but lands 60% of rows in 'Unspecified' points to a mismatch between the file's column headers and the Data Sources template's defined columns. Data Sources matches by header name (or position, depending on configuration). If the header was renamed, the column is ignored and the mapped eVar stays null. The import 'succeeds' because the file is structurally valid - it just does not map. Root cause: header mismatch, not data quality of the values.
Campaign attribution issue: Undercounting by ~half for a webinar is a different signal. The most likely cause is precedence among the three campaign-setting mechanisms: query parameter processing rule, VISTA rule, and any Data Sources or classification overlay. If the VISTA rule overwrites campaign on a set of pages that includes the webinar landing pages, it will clobber the query-parameter campaign value. VISTA rules run server-side and typically take precedence over processing rules. The 'half' is consistent with a subset of webinar traffic hitting pages covered by the VISTA lookup. Root cause: rule precedence, not Data Sources.
Investigation:
- For Data Sources: pull the import template, diff the file headers against it, and check the import log for column-level warnings. Re-import a corrected file for the affected rows if the import is idempotent on the join key.
- For campaign: build a segment for the webinar campaign and break it down by page, then check which pages are in the VISTA lookup set. Compare a hit-level trace (via a debug tool) to see which rule wins.
2. The client wants to re-import the 108,000 affected rows. What must you verify before re-importing, and what could go wrong?
Read the worked answer
Re-importing is not free. Before doing it, verify:
- Idempotency on the join key. Data Sources full imports overwrite by key if the key is defined; if not, re-importing creates duplicate rows or double-counts. Confirm the
marketingCloudId-to-eVar mapping is a defined key and that the import type (full vs. incremental) matches the intent. A full import typically replaces the date range; an incremental appends. Re-importing 108,000 rows as incremental would double the affected data. - Date range scope. Data Sources imports are date-scoped. Confirm the original import's date range and re-import only that range. Re-importing a wider range can overwrite legitimate data outside the affected window.
- The malformed header is actually fixed. Validate the corrected file against the template before upload, not after. A second failed import wastes a cycle and may partially apply.
- Downstream dependencies. If the eVar feeds a classification, a calculated metric, or an external integration, re-importing changes those downstream values. Notify the consumers.
- Processing rules and VISTA interaction. Data Sources data is joined to existing hits; if a processing rule or VISTA rule also writes to the same eVar, the join may not behave as expected. Confirm which mechanism has precedence for the joined value.
What could go wrong: partial import, double-counting if the key is not defined, overwriting data outside the intended range, and silent classification desync. I would run the re-import in a low-traffic window, validate a sample of 100 known IDs against the CRM, and only then confirm completion.