Late-Arriving Offline Conversions in a Daily-Refresh Dataset
A retailer sends 40 million rows per day into a Customer Journey Analytics dataset via the Adobe Experience Platform Web SDK plus a separate offline purchase feed. The offline feed lands in Platform ~36 hours after the event timestamp because the fulfillment system batches nightly. The connection uses a rolling 90-day window and daily refresh. Analysts report that week-over-week revenue is understated for the most recent two days, then 'jumps' on day three. The offline feed uses purchase_id as the event ID but the web SDK stream uses a UUID. The team's SLA requires revenue at T+1 to be within 3% of source truth.
1. Diagnose why the recent two days look understated and explain what dataset/connection settings control whether the late rows are picked up.
Read the worked answer
The understatement is a late-arriving-data symptom, not a query bug. The offline rows carry event timestamps ~36h in the past but arrive after the daily refresh has already processed that date.
Key mechanics to reason through:
- Connection data window (rolling 90 days) determines which historical range CJA will re-read on refresh. 36h is well inside 90 days, so the window is not the blocker.
- Dataset-level late-data behavior: whether the dataset is configured to allow late-arriving events and the refresh cadence. If the dataset is set to a shorter window or refresh is weekly, the two-day gap persists.
- Event ID / dedup: the two feeds use different ID schemes (
purchase_idvs UUID). If the same order is represented in both, you may double-count after backfill rather than under-count; verify by counting distinct order keys per day before and after refresh.
So: the understatement is expected until the next refresh picks up the backfill; the jump on day three is the backfill landing. To meet T+1 within 3%, either shorten the offline feed latency, or accept T+1 as partial and report revenue at T+3 as the authoritative number, or add a separate 'estimated' metric for recent days.
2. The team wants T+1 revenue within 3%. Propose two concrete configuration or process changes and state the tradeoff of each.
Read the worked answer
Option A - Reduce feed latency. Push the offline purchase events closer to real time (e.g., stream fulfillment status changes instead of a nightly batch). Tradeoff: engineering work on the fulfillment side and higher Platform ingestion volume; also purchase events may fire before returns/adjustments settle, so you trade latency for accuracy on net revenue.
Option B - Align refresh cadence and window with the business SLA. Keep the 36h batch but ensure the dataset allows late-arriving events and refresh runs at least daily over a window that covers the lag (90 days already does). Then communicate that T+1 is a partial view and T+3 is authoritative. Tradeoff: you don't actually hit the 3% T+1 SLA - you redefine it. If the SLA is contractual, this needs stakeholder sign-off.
Option C (variant of A) - Split the metric. Report 'web-attributed revenue' at T+1 (complete, no lag) and 'total revenue including offline' at T+3. Tradeoff: two numbers to explain; risk of confusion if dashboards mix them.
Reject: shortening the connection window to 'force' a refresh - that would drop historical data and doesn't address the lag.