I85PREP
⌘ K
Adobe Analytics Architect Master study materials
Adobe Analytics Architect Master study resources

Propagation Drift Across a Multi-Suite Implementation

Adobe Analytics Architect Master · Put your knowledge to work in context.

All case studies

Propagation Drift Across a Multi-Suite Implementation

A media company runs three report suites: news-prod, sports-prod, and corp-prod, all fed by one Web SDK data stream. A section prop and an articleId eVar are set on page load. Recently, sports-prod shows a 40% jump in 'unknown' section values while news-prod looks normal. The team also reports that articleId last-touch attribution in corp-prod looks inflated. Data governance requires that PII never enters props/evars and that classifications stay consistent across suites. The data layer pushes page.section only after an async personalization call resolves, and a recent release moved that call 300ms later.

1. Propose a root-cause hypothesis for the 'unknown' section spike in `sports-prod` only, and describe the validation steps to confirm it.

Read the worked answer

Hypothesis: the section prop is being set before the async personalization call populates page.section, so the Web SDK sends the page view with an empty/unknown value. The delay moved the data-layer push later than the sendEvent for page view.

Why only sports-prod? Likely the sports pages have a heavier personalization dependency (more modules, slower resolve) so the race is lost more often there, while news pages resolve fast enough to win the race.

Validation:

  1. Debugger trace on a sports page: confirm order of operations - does sendEvent for page view fire before page.section is pushed?
  2. Compare timing: instrument timestamps for personalization resolve vs. page-view sendEvent across a sample of sports and news pages.
  3. Check the data element: is section read at sendEvent time (correct) or cached earlier (stale)?
  4. Correlate the spike date with the release that moved the call 300ms later.

Fix direction: gate the page-view sendEvent on the data-layer readiness event, or read section from a reliable synchronous source (URL/route) as a fallback, and add a validation rule that flags empty section before send.

2. The `articleId` last-touch inflation in `corp-prod` is reported. How would you investigate whether this is a variable-persistence problem versus a data-quality problem, and what governance controls apply?

Read the worked answer

Investigate persistence first:

  • Check eVar settings for articleId in corp-prod: allocation (last-touch), expiration, and whether it is set on every hit or only article pages. If it expires too slowly or is set on non-article pages, it will over-attribute.
  • Check whether articleId is being set on every sendEvent including non-article pages (e.g., a shared component setting it globally), which inflates last-touch.
  • Compare raw vs. classified values to rule out classification mapping errors.

Governance controls:

  • PII guardrail: confirm articleId and section cannot carry PII; add a schema/validation check in the data layer and a processing-rule or validation-rule guard that rejects values matching PII patterns.
  • Classification consistency: maintain a shared classification file/import process across all three suites so section and articleId map identically; version and review changes.
  • Change control: document variable settings per suite and require review before changing allocation/expiration.
  • Monitoring: alert on 'unknown'/'none' rates and on unexpected last-touch share shifts.

Distinguish: persistence/allocation issues produce systematic over-attribution; data-quality issues produce inconsistent or invalid values. Both can coexist, so check both.