AEP streaming data lands in the lake but not Real-Time Profile

A successful stream request and a data lake record are not the same as an accepted Real-Time Customer Profile record. An Experience League user saw repeat events land in the lake while identities disappeared from the Profile store; the failed batch reported “Identity not available.” This is a profile eligibility problem that can quietly change downstream audiences.

Start with the failed batch

Record the batch ID, response status, ingestion timestamp, and exact error before altering the payload. Adobe’s streaming troubleshooting guide distinguishes request acceptance from later validation and directs teams to monitoring and failed batches. A 200 or 207 response alone is insufficient proof of Profile availability.

Compare identity contracts

Inspect the identityMap namespace, ID value, primary flag, and any other fields designated as identities in the schema. Confirm the dataset is enabled for Profile and that custom namespaces are registered. Compare a previously successful record with the failing one, including record _id and event time.

Verify the downstream consequence

Use a single test identity to check Profile lookup and the audience that should include it. If the same payload succeeds only on first ingestion, preserve both requests and their batch IDs for support; do not repeatedly replay production data without an idempotency plan.

Adovo’s view

A data lake receipt is not a customer profile. The value of ingestion is measured at the consumer that needs the record, and that requires an identity contract that survives each validation stage. Close the incident where the audience sees the person, not where the API accepts bytes.