> For the complete documentation index, see [llms.txt](https://help.openloyalty.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.openloyalty.io/main-features/members/configuration.md).

# 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="/files/W3fDcsyXwo0z4rwczKUu" 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
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.