🧩 Three Systems, One Contact Record → How Data Persistence Broke Attribution

Resolves cross-system data contamination by enforcing interaction-level data integrity in a shared contact model.

🔧 Overview

At a glance, the setup seemed straightforward: multiple upstream systems feeding into a single survey platform. In practice, it was anything but.

Retail interactions, financial workflows, and web events all wrote to the same customer record—each triggering different survey types at different times, each carrying a different context.

The issue wasn’t that the data was wrong.

It was that data from one interaction stayed attached to the contact record and showed up in future surveys—whether it belonged there or not.

<aside> 🔍

What Was Actually Going Wrong

A typical customer lifecycle snippet:

• visit a store (Store Associate = Alex)
• later, interact with the finance team (Agent = Jordan)
• then, receive an NPS survey at their 3-month rotation

Where it breaks down:

The NPS survey could still include Jordan’s name from the finance interaction—even though it had nothing to do with that experience.

So when the customer responded:

• the wrong team received credit (or blame)
• reporting no longer reflected reality
• trust in the system eroded </aside>

Here’s what that looks like in practice:

🔨 Repairing the Reporting

Fixing the issue required rethinking not just all three integrations, but also how the system handled state over time.

Rather than treating each event as an incremental update, each interaction needed to carry only its own context—without inheriting from previous ones.

💫 System Flow

System Event (Retail / Financial / Web)
↓
Full Payload Sent to Survey Platform
↓
Contact Record Updated (Shared Model — overwrites or appends fields)
↓
Survey Triggered (NPS or CSAT)
↓
Response Attributed Based on Current Contact State

All events wrote to the same contact record, regardless of type or timing.

Each step looked deterministic.