Adobe RT-CDP Business Practitioner Pro: The 30-Day Backfill That Broke the Profile Count

The 30-Day Backfill That Broke the Profile Count

A retailer has 4.2 million customer profiles built primarily from a nightly CRM batch and a web SDK stream. Last week the team loaded a 30-day historical backfill of 9 million purchase events to correct a reporting gap. Events arrived with original timestamps but were ingested over two days. Within 48 hours the profile count jumped to 6.8 million, the loyalty_tier attribute on ~400,000 profiles reverted to null, and an audience called High-Value Repeat Buyers (used by a paid-media destination) grew from 120,000 to 310,000 members. The CRM batch job was untouched. Segment activation budget is fixed, so an inflated audience directly increases spend.

1. Diagnose why the profile count and the audience size both increased, and explain the `loyalty_tier` nulling. What is the most likely mechanism linking these three symptoms?

Read the worked answer

The unifying mechanism is identity fragmentation plus last-write-wins attribute resolution, not a segmentation logic error.

Profile count growth: the backfill events carried device/ECID and hashed email identities in combinations that did not previously exist. Real-Time CDP stitches identities into a graph, but stitching is not retroactive across all time - new identity links create new merged profiles or leave orphan clusters. 9M events over 2 days is a large influx of previously unseen identity pairs, so net-new profiles appear before graph convergence.
loyalty_tier nulling: if the backfill payload included a loyalty_tier field (even empty or default), those events became the most recent write to the profile attribute store by ingestion time. Last-write-wins on the attribute means a stale/blank value from a historical event overwrites the good CRM value. Timestamp of the event does not protect the attribute; recency of ingest does.
Audience growth: more profiles + broken tier data = more entities that satisfy the qualifying rule (e.g., lifetime_orders >= 3 now counts backfilled purchases that were previously missing). The audience is behaving correctly on corrupted inputs.

Fix direction: re-ingest the backfill with a dataset that does not write profile attributes (event-only, no attribute upsert), or suppress loyalty_tier in the backfill mapping; then re-run the CRM batch to restore tier values. Audit identity namespaces in the backfill before any re-load.

2. The team proposes simply deleting the 9M backfilled events to 'undo' the damage. Evaluate this. What would you actually do, in order?

Read the worked answer

Deletion is a partial and risky undo. It removes event records but does not roll back attribute values already written to profiles, and it does not un-merge identity graphs. You would still have nulled tiers and possibly orphaned profiles.

Recommended order:

Contain spend first: pause the High-Value Repeat Buyers destination or add a temporary guard (e.g., require loyalty_tier IS NOT NULL). Stopping the bleed is the only reversible, immediate action.
Quantify: compare profile counts and audience membership against a pre-backfill snapshot/export. Identify how many profiles are net-new vs. re-tiered.
Restore attributes: re-run the authoritative CRM batch (full or delta) so loyalty_tier is rewritten with correct values and the latest ingest wins.
Correct the data, don't just delete it: if the backfill events are legitimately needed, re-load them through a dataset profile that does not upsert attributes. If they are not needed, use a targeted delete (dataset/record-level) - but understand deletion is asynchronous and does not restore attributes.
Verify audience size returns to baseline before re-enabling the destination.

Key judgement: the exam wants you to separate event data from profile attribute state from identity graph state - deleting one does not fix the others.