# 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 %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.openloyalty.io/main-features/members/configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.