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

# Identity stitching and resolution

> Identity stitching(or identity resolution) is the process of combining customer identifiers across devices and channels into a single, unified profile in Vero.

**Identity stitching** (or identity resolution) is the process of combining customer identifiers across devices and channels into a single, unified profile in Vero.

This ensures you can recognize a user across web, mobile, server, and third-party touchpoints — and message them without creating duplicates.

In this help article we'll walk through the different ways you can "identify" a user (customer) and how you can stitch together data as customers move from device to device.

## **Identifiers and channel addresses**

Each profile must have a single identifier:

* **User Identifier`id`** – *required*

..and can have multiple channel addresses:

* **Email address** `email` – optional, but required for sending email
* **Phone number** `phone_number` – optional, required for sending SMS
* **Device tokens (iOS/Android)** – optional, required for sending push notifications

Learn more details about the makeup of a user profile

## **Stitching rules and configuration**

Identity stitching rules determine **when Vero merges incoming data into an existing profile** and when it creates a new one.

By default, Vero only stitches on the id. You can optionally enable different stitching options by going to **Settings** > **Advanced** in the Vero 2.0 UI.

To understand how the different matching options work, lets look at two examples:

### Example 1: `id` + `email`

In this example two profiles have been tracked with the same email address but two different `id`'s.

```
id, email
1234, support@getvero.com, first_name: Bob
5678, support@getvero.com, first_name: Robert
```

With this example, here’s how each configuration behaves:

* **Default**
  * **Behaviour:** Profiles are matched only on id. If the id is new, a new profile is always created — even if the email matches another profile.
  * **Outcome:** Two profiles are created even though they share the same email. `id=1234, email=support@getvero.com, first_name=Bob` `id=5678, email=support@getvero.com, first_name=Robert`
  * **When to use:** Best if your id’s are stable.
* **Option: Match customer via email and update the user’s profile**
  * **Behaviour:** Profiles are matched on `id` first, and if no match is found, Vero falls back to matching on `email`. When an email match occurs, the existing profile is updated with the latest properties.
  * **Outcome:** One profile is created, the second call merges on email. `id=1234, email=support@getvero.com, first_name=Robert`
  * **When to use:** Best when `email` is your most reliable user identifier.
* **Option: Match customer via email and update the user’s profile and`id` is updated (Available on request - Contact support)**
  * **Behaviour:** Profiles are matched on `id`, then `email`. If an email match occurs, the profile is updated — and the id is replaced with the most recent one provided.

  * **Outcome:** One profile is created, because the last `id` wins when merging by email.

`id=5678, email=support@getvero.com, first_name=Robert`

* **When to use:** Use if `id`'s rotate/change.

### Example 2: `id` + Device token

In this example two profiles have been tracked with the same device tokens but two different `id`'s.

```
id, device_token
1234, token1
5678, token1
```

With this example, here’s how each configuration behaves:

* **Default**
  * **Behaviour:** Profiles are matched only on `id`. Device tokens are ignored when deciding whether to merge.

  * **Outcome:** Two profiles are created even though they share the same device token.

`id=1234, device_token=token1`

`id=5678, device_token=token1`

* **When to use:** Best if your id’s are stable and device tokens may be shared across multiple users.

* **Option: Match customer via device token and update the user’s profile**
  * **Behaviour:** Profiles are matched on `id` first, and if no match is found, Vero falls back to matching on device tokens. When a token match occurs, the existing profile is updated with the latest properties.

  * **Outcome:** One profile is created, the second call merges on device token.

`id=1234, device_token=token1`

* **When to use:** Best when device tokens are the most reliable way to identify a user (e.g. mobile-first apps).

* **Option: Match customer via device token and update the user’s profile and id is updated (Available on request – Contact support)**
  * **Behaviour:** Profiles are matched on `id`, then device tokens. If a token match occurs, the profile is updated — and the id is replaced with the most recent one provided.

  * **Outcome:** One profile is created, because the last id wins when merging by device token.

`id=5678, device_token=token1`

* **When to use:** Use if your system rotates or frequently changes `id` values, and you want the most recent id reflected in Vero.

### Phone numbers

At this time you cannot configure Vero to use the `phone_number` as a field when stitching profiles together. However, when importing phone numbers, they will always respect the `id` and `email` fields when stitching as per the above descriptions.