# Configuration

The **Member Identifier Configuration** section defines how Open Loyalty distinguishes between members in your database. This configuration plays a key role in maintaining data quality, avoiding duplicates, and ensuring proper member-event matching.

<figure><img src="https://2658975168-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FcNVX03KZzmrGwJihLiEx%2Fuploads%2F7qHFIqr0bCgoe2KtfGvn%2Fimage.png?alt=media&#x26;token=dd414d95-b584-4f91-8d68-f210787659ab" alt=""><figcaption></figcaption></figure>

## Purpose

Each member must be **uniquely** identified to:

* Match events (like transactions and custom events) correctly.
* Avoid duplicates in the system.
* Ensure consistent member experiences across integrations.

***

## Configuration Options

You can choose from the following identifiers:

* **Email**
* **Phone number**
* **Loyalty card number**

Each of these identifiers can be configured in the following ways:

| Configuration Option | Description                                                                                     |
| -------------------- | ----------------------------------------------------------------------------------------------- |
| **Required field**   | The identifier is mandatory during registration. Only one identifier can be marked as required. |
| **Event matching**   | Used to match incoming events (e.g., transactions, custom events) with members.                 |
| **Unique field**     | Must be unique across the entire tenant (e.g., no two users can share the same email).          |

{% hint style="success" %}
**Tip:** The **Loyalty card number** is often used as an external UUID to map members between systems.
{% endhint %}

The system follows a **top-to-bottom** order when matching incoming data with member identifiers. You can **drag and drop** identifiers in the table to change the priority.

***

## Important Rules

* Once an identifier is set as **non-unique**, it:
  * **Cannot** be required,
  * **Cannot** be used for event matching,
  * **Cannot** be used in integrations,
  * **Cannot** be reverted to **unique** option.
* **Required registration fields must be unique.**
* **Only unique identifiers** can be used for event matching.
* This configuration is **tenant-based**.

***

## Active Member Settings

In this section, you can define conditions to determine whether a member is considered **active**.\
By default, the condition is:

* A **transaction** has been made in the last **X days** (e.g., 30 days).

You might change the configuration to:

* Track the **custom events** (selected or all of the custom event types)
* Change the time period you are looking at (e.g., last 7 days)
* Use the combination of events that define a member as active.

{% hint style="info" %}
**Note**: It might take up to 24 hours for changes to be reflected in the dashboard, as recalibration occurs once per day.
{% endhint %}

***

## Final Steps

After configuring the settings, click **Save changes**.

{% hint style="warning" %}
Please review carefully — some settings, such as setting an identifier to non-unique, **cannot be undone**.
{% endhint %}