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

# Browse Consumers

> Search a Consumer by exact ID, inspect their profile, and review every Offer, Reward, voucher, transfer, and bank synchronization tied to their account.

export const RequiredRoles = ({roles}) => <Note>
    <strong>Required Shift role:</strong> {roles}. See <a href="/program/shift/access-and-roles">Users management</a> for the full role matrix.
  </Note>;

<RequiredRoles roles="Consumer support" />

The **Consumers** section of [Shift](/glossary#shift) is where you find a single [Consumer](/glossary#consumer) and reconstruct everything that happened on their account: which [Offers](/glossary#offer) were displayed, which [Rewards](/glossary#reward) were generated, which payouts went out, and whether their bank connection is healthy. Use it to answer a support ticket, audit a disputed [Cashback](/glossary#cashback), or debug an integration.

## Find a Consumer

To open a profile, you need the Consumer's exact ID. **All**, **Active**, and **Inactive** at the top show Consumer counts only.

<Steps>
  <Step title="Enter the Consumer ID">
    In **Consumers**, paste the exact [Consumer](/glossary#consumer) ID into the search field. Search matches that ID only, not a name, an email, or a phone number, so look it up in your own customer record first.
  </Step>

  <Step title="Click Search">
    An exact match opens the Consumer profile directly. If nothing matches, the page returns to the empty state with **No Consumer has been found with this ID…**.
  </Step>
</Steps>

Shift reopens the last Consumer you searched for, so a profile can still be on screen when you come back after a break. Close the browser tab at the end of a support session.

<Warning>
  The activity tabs keep their own memory, and it is not tied to a Consumer. The selected tab, the page, the sort order, and the **Date from** / **Date to**, status, and Reward type filters carry over to the next profile you open. A date range left over from a previous ticket hides the Rewards you are looking for. Clear the filters before concluding that a Reward is missing.
</Warning>

## Consumer profile

The profile page is split between Consumer-level metadata at the top and a tabbed activity zone below.

### Consumer details

| Field | What it tells you |
| - | - |
| **TOS acceptance** | Date the Consumer accepted the terms of service. |
| **Privacy policy acceptance** | The Consumer's consent state. Click the cross next to a granted consent to revoke it. **Basic** is greyed out and cannot be revoked. |
| **Last activity** | Date the Consumer last opened the Program app. |
| **Status** | `Active` or `Inactive`. Inactive accounts no longer generate Rewards. |
| **Account sync** | Whether Shift is in sync with the Consumer's bank data, for example `Synced`. |
| **Forwarded KYC** | `yes` or `no`. Only on a Program whose Ventilation Paylead operates. See [Reading Forwarded KYC](#reading-forwarded-kyc). |
| **Segments** | The [Segments](/glossary#segment) the Consumer belongs to. Empty when the Consumer is in none. |
| **Target account** | IBAN of the bank account that receives Cashback payouts. Only on a Program whose Ventilation Paylead operates. |

**Forwarded KYC** and **Target account** only concern Programs whose [Ventilation](/glossary#ventilation) Paylead operates. On a Program that runs its own Ventilation, Paylead does not execute the payouts and both squares are absent. **Target account** is also absent when payouts are aggregated rather than sent per Consumer.

### Reading Forwarded KYC

When Paylead operates the Ventilation, it pays Consumers through a payment service provider that requires their identity to be registered before it can send money. **Forwarded KYC** says whether that registration exists: `yes` on a green square, `no` on a red one.

A Consumer whose **Forwarded KYC** reads `no` cannot be paid, however many validated Cashbacks sit in their pool. On a Consumer chasing a payout, a red square is the answer to their ticket.

### Consent

The **Privacy policy acceptance** box lists every consent the Consumer has granted, each with its acceptance date and a cross to revoke it, after a confirmation dialog. The consents surfaced are:

* **Basic**, greyed out: it cannot be revoked from Shift. It is the consent that authorizes Offer matching in the first place, so withdrawing it amounts to removing the Consumer from the [Program](/glossary#program) rather than adjusting a preference.
* **Statistics**
* **Targeting**
* **Smart ranking**, which enables [Offer Smart Ranking](/glossary#offer-smart-ranking)
* **Transaction triggers**
* **Web Analytics**

An absent level was never granted, or has already been revoked. What each consent authorizes is defined by your Program's privacy policy, set with Paylead. See the [Status reference](/program/shift/status-reference#privacy-policy-acceptance) for a short definition of each level.

<Warning>
  Revoking a consent is one-way in Shift: the Consumer has to accept it again from your own app. It does not cancel the Rewards they have already earned, which keep their status and are paid out as usual. What changes is what Paylead may do with their data from that point on.
</Warning>

A Consumer who wants to leave the [Program](/glossary#program) entirely does it from your own app: withdrawing the **Basic** consent is a Consumer-side action.

### Pool

The **Pool** zone is the last block of the **Consumer details** card, a full-width strip under **Segments** and **Target account**.

It counts the Consumer's Cashbacks, and totals their amounts, for four states only:

* `Pending validation`: The Cashback is being validated.
* `Validated`: The Cashback is locked and ready for payout.
* `Pool`: The Cashback sits in the Consumer's wallet, waiting to be transferred.
* `Paid`: The Cashback has been transferred to the Consumer's bank account.

These are display labels. Behind `Pool` and `Paid` sit the technical statuses `PAID_IN` and `PAID_OUT`, which is what the [Paylead API](/program/user-journey/quickstart) and your own back-office return for the same Cashback. Match the two before quoting a status to a developer: see [How to read a status in Shift](/program/shift/status-reference#how-to-read-a-status-in-shift).

The `Pool` counter carries a colored dot that explains why a validated Cashback has not been paid out yet. Hover it to read the payout threshold, worded `<amount> minimum to trigger the cagnotte` (`cagnotte` is the Pool). The threshold is set once for your whole Program, not per Consumer.

The color compares the `Pool` amount alone, not the sum of `Validated` and `Pool`, against that threshold:

| Dot | What it means |
| - | - |
| Red | The `Pool` amount is zero. Nothing is waiting to be transferred. |
| Orange | The `Pool` amount is below the threshold, so the Consumer has to earn more before a transfer is triggered. This is the normal answer to "my Cashback is validated but I was never paid". |
| Green | The `Pool` amount has reached the threshold, so a payout is due. If the **Transfers** tab shows nothing yet, the transfer has not been executed, not that the Cashback was lost. |
| Grey | Your Program sets no payout threshold, so there is nothing to compare. |

What happens once the dot turns green depends on your Program's [Ventilation](/glossary#ventilation) model: a scheduled payment batch, or a payout with a manual and an automatic trigger. Check which one you run before telling a Consumer when to expect the money.

Two more states exist for a Cashback, but the Pool zone counts neither of them:

* `Not attribued`: The Cashback was duplicated across sources (for example, the bank feed and an account aggregator both reported the same transaction). One of the duplicates was kept and the rest are marked `Not attribued`. See [Reward Attribution](/glossary#reward-attribution) for the deduplication logic.
* `Cancelled`: The Cashback is no longer eligible (matching issue, technical error, or merchant cancellation).

See the [Status reference](/program/shift/status-reference#pool) for the full Pool status table.

## Consumer activity

The activity zone groups everything that happened on the Consumer's account into four tabs, five when your [Program](/glossary#program) has the [Easy Vouchers (EVO)](/glossary#easy-vouchers-evo) option enabled, which is what adds the **Vouchers** tab.

<Tabs>
  <Tab title="Offers">
    The **Offers** tab lists every Offer the Consumer is currently eligible to see. When [Offer Smart Ranking](/glossary#offer-smart-ranking) is enabled, the order reflects the algorithm's score (purchase habits, location, [Brand](/glossary#brand) power, editorial spotlight).

    Use the calendar picker to inspect eligibility on a past date, useful when a Consumer claims they saw a specific Offer but never received the Cashback. Filter by Reward type to narrow the list.

    Click any row to expand it in place. The panel that opens adds three values for that Offer: **Minimum basket**, **Maximum amount**, and **Capping**. Each one shows `N/A` when the Offer does not set it. See [Publish an Offer](/program/shift/publish-offers) for the full Offer reference.
  </Tab>

  <Tab title="Rewards">
    The **Rewards** tab lists every Reward generated for the Consumer, Cashbacks and [Gifts](/glossary#gift) alike. Each row shows the date, the status, the Reward type, the origin, the Offer name, and the amount. The matched transaction is not in the row: open the Reward to see it.

    Filter by **Date from** / **Date to** to scope to a period, and by status to focus on one state. The status filter offers **All**, **Pending validation**, **Validated**, **Pool**, and **Paid**, each prefixed with the number of Rewards it holds. `Cancelled` and `Not attribued` Rewards cannot be isolated this way.

    Click the view icon on a row to open the Reward detail page. It contains up to three cards:

    * **Reward details**: the linked Offer and its origin, the Cashback amount, and the current status.
    * **Reward history**: the originating transactions first (identifier, label, amount, merchant, execution date), then every status transition with its date. Gift Rewards have no transaction block. This card is the source of truth when reconstructing a payout dispute.
    * **Attributions**: shown only when several candidates claimed the same transaction. See [Reading the Attributions card](/program/shift/customer-support-workflow#reading-the-attributions-card).
  </Tab>

  <Tab title="Vouchers">
    The **Vouchers** tab lists the Vouchers the Consumer ordered. A Voucher is not a Cashback: the Consumer buys it, for a code or a fixed value redeemable at a [Brand](/glossary#brand), which is why the statuses below talk about payment. The tab appears only when [Easy Vouchers (EVO)](/glossary#easy-vouchers-evo) is enabled on your Program.

    Filter by date range to scope the list. Each row shows the reservation date, the voucher status, the Brand, the Offer reference, and the value. See [Status reference](/program/shift/status-reference#vouchers) for what each voucher status means.

    Click the view icon to open the voucher detail page. See [Working on a single voucher](#working-on-a-single-voucher) for what you can do there, and [Vouchers report](/program/shift/vouchers-report) for the Program-wide export of the same data.
  </Tab>

  <Tab title="Transfers">
    The **Transfers** tab lists every Cashback payout sent to the Consumer's bank account. The Target account configured in the Consumer details zone is the destination IBAN.

    Filter by **Date from** / **Date to** to scope to a payout window. Each row shows:

    | Column | What it represents |
    | - | - |
    | **Date** | Date the payment was executed. While the transfer has not been executed, the column falls back to the date it was created, with no visual distinction. |
    | (no header) | A status icon for the transfer. Hover it to read the status: `Ok`, `Error`, or `Failed`. |
    | **ID** | Internal transfer identifier. Quote this in any payout dispute. |
    | **Accounts** | Source and destination bank accounts, last digits only. The symbol between them repeats the status: an arrow when the transfer succeeded, a cross when it failed, a tilde while it has not been executed. |
    | **Amount** | Total amount transferred. |

    The status is the answer to "the money never arrived", so read it before anything else:

    | Status | What to conclude |
    | - | - |
    | `Ok` | The payout left Paylead on the **Date** shown. If the Consumer still sees nothing, the question moves to their bank: give them the **ID** and the amount. |
    | `Error` or `Failed` | The payment did not go through. No money left. Escalate to Paylead with the transfer **ID**. |
    | No icon at all | The transfer exists but has not been executed yet. The **Date** column is showing its creation date, not a payment date. Nothing is lost; nothing has moved either. |

    Click the view icon to open the transfer detail page. It breaks the lump-sum transfer down into the individual Rewards that funded it, which is what you need to reconcile a Consumer's bank statement against Shift.
  </Tab>

  <Tab title="Synchronizations">
    The **Synchronizations** tab is the health check for the Consumer's bank connections. Each row is one bank connection; below the bank name, the linked accounts are listed.

    | Column | What it represents |
    | - | - |
    | **Name** | Bank name and linked account references. |
    | **1st connection** | When the bank account first connected to the Program. |
    | **Last successful connection** | Last successful sync. |
    | **Most recent transaction** | Date of the latest banking transaction Paylead received. |
    | (no header) | A question mark icon, shown only when the connection reported an error. Hover it to read the message. |

    A **Status** column reports the connection state, as a translated label rather than the raw API value. See [Status reference](/program/shift/status-reference#bank-synchronization) for the mapping and what each state means.
  </Tab>
</Tabs>

### Reading the Activations column

The **Activations** column of the **Offers** tab can carry two different values, and both use the same `x / y` format:

* The fidelity badge, shown only when the Offer runs a fidelity Campaign that sets a purchase frequency (a Reward is only granted after N purchases). It reads `current / target`: `3 / 5` means three of the five qualifying purchases have been recorded.
* The activation capping, shown only when the Offer sets a maximum number of activations. It reads `activations / maximum`.

When the Offer sets no maximum, the column shows the activation count on its own, with no denominator.

### Working on a single voucher

The voucher detail page opens on four cards, with **Back** as the only button at the top of the page:

| Card | What it holds |
| - | - |
| **Voucher details** | The Offer reference and its Brand, the face value, and the current status. |
| **Voucher history** | Every status the order went through, most recent first, each with its date. |
| **Voucher content** | The four parts of the voucher (card number, PIN, URL, PDF), each with a check mark or a cross, and the date of the last update. |
| **Voucher downloads** | Every download of the voucher PDF, with the Shift account that clicked and the date and time. |

Two buttons sit in those card headers, each under its own condition. **Synchronize** appears in **Voucher content** while at least one part is missing: Shift asks the external provider for the current state, then reloads the page. **Download** appears in **Voucher downloads** once the provider has produced a file.

For what to do with all of this on a ticket, see the [Voucher support workflow](/program/shift/voucher-support-workflow).

## What's next

<CardGroup cols={2}>
  <Card title="Customer support workflow" icon="headset" href="/program/shift/customer-support-workflow">
    The full Level 1 triage playbook, from ticket intake to resolution.
  </Card>

  <Card title="Status reference" icon="list-checks" href="/program/shift/status-reference">
    Every Reward, voucher, and synchronization status, with the exact transitions and root causes.
  </Card>
</CardGroup>
