> ## Documentation Index
> Fetch the complete documentation index at: https://help.maestra.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What Happens to a Customer's Name and Other Data After a Merge

When Maestra merges two customer profiles, the resulting profile keeps a single set of identity fields and combines everything else. Here's exactly how each piece of data is handled.

## Core identity fields

First name, last name, middle name, gender, date of birth, and zone are taken from the **priority customer** — the profile that wins during deduplication.

The values from the lower-priority profile are dropped for these fields, even if they look more complete. If you want a specific profile's identity data to survive, make sure that profile is the priority customer before the merge runs.

## Additional (custom) fields

Custom fields also default to the priority customer's values. There's one important exception:

<Note>
  If the lower-priority profile has a value in a custom field and the priority profile does **not**, the lower-priority value is carried over to the merged profile. Nothing is lost just because it lives on the non-priority side.
</Note>

In other words, Maestra fills in blanks from the other profile rather than overwriting filled-in priority values.

## Action history

Actions from both customers are combined and kept on the final merged profile. This includes the full interaction history — orders, campaign opens, clicks, site events, subscriptions, and any other tracked actions from either profile. You end up with one consolidated timeline rather than two partial ones.

## Quick reference

| Data                                                                 | Source after merge          |
| -------------------------------------------------------------------- | --------------------------- |
| First name, last name, middle name                                   | Priority customer           |
| Gender                                                               | Priority customer           |
| Date of birth                                                        | Priority customer           |
| Zone                                                                 | Priority customer           |
| Custom fields (priority profile has a value)                         | Priority customer           |
| Custom fields (priority profile is empty, other profile has a value) | Other profile               |
| Action history                                                       | Combined from both profiles |

## Why this matters

The priority rule keeps identity data predictable: one profile wins, and you always know which one. The fill-in-the-blanks behavior for custom fields means you don't lose useful attributes — say, a loyalty tier or a preferred store — just because they were collected on the non-priority side. And merging the action histories means segmentation, lifetime value, and flow eligibility all reflect everything the customer has ever done with you, not just the half attached to the surviving profile.