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

# Segments

> Dynamic rule-based customer groups that update automatically as customer data changes — the targeting engine for campaigns and automations.

Customer Segments are dynamic groups defined by rules evaluated against contact data. Unlike lists, which are maintained manually, segments maintain themselves — as a customer's orders, spend, engagement, or tags change in Shopify, their segment membership updates automatically. This makes segments the right tool for any audience group defined by behavior, lifecycle stage, or data thresholds.

Segments are used as campaign audience targets, automation triggers, automation condition evaluations, and automation exclusion rules — they are woven into nearly every part of the Galantis platform.

## What this covers

* How segment rules work
* All available rule conditions and operators
* AND/OR grouping for complex rule logic
* How segment evaluation works
* Using segments in campaigns and automations

## How segment rules work

A segment is defined by one or more rule conditions. When Galantis evaluates a segment, it runs the rules against every customer in your workspace and identifies which customers match. Customers who match become members; customers who no longer match are removed.

Rules use two levels of logic:

* **AND logic within a group** — all conditions in a group must be true for a customer to match that group
* **OR logic between groups** — a customer who matches any group is included in the segment

This structure allows complex expressions like:

```
(Total spent > 500 AND Country = MX)
OR
(Orders count >= 3 AND Consent = Yes)
```

A customer who matches either group is a segment member — they do not need to match both.

## Rule conditions

<Tabs>
  <Tab title="Contact & Phone">
    **Phone number** — Match customers by exact phone number.

    | Operator    | Behavior                                    |
    | ----------- | ------------------------------------------- |
    | exact match | Customer's phone equals the specified value |

    **Added to list** — Match customers who are members of a specific Customer List.

    | Operator | Behavior                                  |
    | -------- | ----------------------------------------- |
    | in list  | Customer is a member of the selected list |

    <Note>
      The `Added to list` condition creates an intersection between a dynamic segment and a static list — useful for applying additional rule-based filters on top of a manually curated list.
    </Note>
  </Tab>

  <Tab title="Engagement">
    **Last message received** — Match customers based on the date of their most recent inbound WhatsApp message.

    | Operators | date comparison |
    | --------- | --------------- |

    **Last engaged at** — Match customers based on when they last engaged with a WhatsApp message (opened, replied, or clicked).

    | Operators | before / after / between / in last X days |
    | --------- | ----------------------------------------- |

    **Messages received** — Match customers by total count of WhatsApp messages received.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Messages read** — Match customers by total count of WhatsApp messages they opened.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Automation completions** — Match customers by how many times they have completed an automation flow.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    Engagement-based conditions are powerful for re-engagement and suppression logic — for example, excluding customers who have not opened any of the last 5 messages from a re-engagement campaign, or targeting customers whose engagement has dropped over a defined period.
  </Tab>

  <Tab title="Purchase History">
    **Orders count** — Total number of orders placed.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Total spent** — Cumulative order value across all orders.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Average order value** — Average value per order.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Days since last order** — Number of days since the customer's most recent order.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Days since first order** — Number of days since the customer's first-ever order.

    | Operators | `>`, `<`, `>=`, `<=`, `=`, `between` |
    | --------- | ------------------------------------ |

    **Purchased collection** — Whether the customer has purchased from a specific Shopify collection.

    | Operators | in / not in |
    | --------- | ----------- |

    **Purchased brand** — Whether the customer has purchased products from a specific brand (vendor).

    | Operators | in / not in |
    | --------- | ----------- |

    **Purchased price range** — Whether the customer has purchased products within a specific price range.

    | Operators | between / not between |
    | --------- | --------------------- |

    Purchase history conditions are the foundation of lifecycle segmentation — separating first-time buyers from repeat customers, identifying high-LTV customers, building lapsed-buyer segments based on days since last order, and targeting customers by product category.
  </Tab>

  <Tab title="Customer Profile">
    **Country** — Customer's country from their Shopify profile.

    | Operators | is / is not / in / not in |
    | --------- | ------------------------- |

    **Language** — Customer's locale/language setting.

    | Operators | is / is not / in / not in |
    | --------- | ------------------------- |

    **Consent status** — Customer's current `marketing_state`.

    | Operators | is / is not (Yes / No / Unknown) |
    | --------- | -------------------------------- |

    **Lifecycle stage** — Customer's current lifecycle stage in Galantis.

    | Operators | is / is not / in / not in |
    | --------- | ------------------------- |

    Country and language conditions are essential for international stores sending localized content — defining separate segments per market and routing them to language-appropriate templates is the standard pattern for multi-region campaigns.

    Adding `Consent status = Yes` as a rule to any segment ensures the segment only contains `SUBSCRIBED` customers — which means the segment can be used as a campaign audience without the consent filter removing customers at send time.
  </Tab>
</Tabs>

## Full rule condition reference

| Rule                   | Available operators                       |
| ---------------------- | ----------------------------------------- |
| Phone number           | exact match                               |
| Added to list          | in list                                   |
| Last message received  | date comparison                           |
| Last engaged at        | before / after / between / in last X days |
| Orders count           | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Total spent            | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Days since last order  | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Days since first order | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Average order value    | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Country                | is / is not / in / not in                 |
| Language               | is / is not / in / not in                 |
| Consent status         | is / is not (Yes / No / Unknown)          |
| Purchased collection   | in / not in                               |
| Purchased brand        | in / not in                               |
| Purchased price range  | between / not between                     |
| Messages received      | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Messages read          | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Automation completions | `>`, `<`, `>=`, `<=`, `=`, `between`      |
| Lifecycle stage        | is / is not / in / not in                 |

## How segment evaluation works

When a segment is evaluated, Galantis runs the rule query against all customer records, syncs the membership pivot table, and emits `UserAddedToSegment` events for customers who newly match the rules — customers who matched before evaluation and still match do not generate a new event.

This event-driven mechanism is what powers the `USER_ADDED_TO_SEGMENT` automation trigger. When a customer's data changes — a new order pushes them over a spending threshold, a tag is added, days since last order increments — the next segment evaluation detects the membership change and fires the trigger for that customer.

## Building effective segments

**A high-LTV lapsed buyer segment**

```
Total spent > [your LTV threshold]
AND Days since last order > 60
AND Consent status = Yes
```

Pairs with the [VIP Win-Back automation recipe](/whatsapp/automations/recipes/vip-win-back).

**A first-time buyer cross-sell segment**

```
Orders count = 1
AND Days since last order < 14
AND Consent status = Yes
```

Customers who made their first purchase in the last 2 weeks — a high-intent window for a second-purchase prompt.

**A Mexico high-spend segment**

```
Country = MX
AND Total spent > 500
AND Consent status = Yes
```

Market-specific high-value audience for a localized campaign.

**A re-engagement suppression segment**

```
Last engaged at > 90 days ago
AND Messages received > 5
```

Customers who have received multiple messages but haven't engaged in 90 days — useful as a campaign exclusion to protect deliverability.

## Best practices

* **Always include `Consent status = Yes` in segments used as campaign audiences.** This ensures the segment only contains `SUBSCRIBED` customers and prevents the consent filter from silently reducing your reach at send time.
* **Use segments as automation exclusions for active sequence participants.** If a customer is enrolled in a post-purchase sequence, a segment defined as `Automation completions < 1 for [post-purchase automation]` can be used as an exclusion to prevent them from being enrolled in a separate re-engagement flow simultaneously.
* **Name segments clearly and include the defining criteria.** `High LTV Lapsed - MX - >500 spent` is more useful than `Segment 3` when you are selecting an audience in the campaign builder.
* **Build and verify segments before referencing them in automations.** A segment used as a trigger source or exclusion rule should have its membership count and rule logic confirmed before the automation is activated.
* **Do not over-segment.** A large number of similar, slightly different segments becomes difficult to maintain. Prefer fewer, well-defined segments that cover clear lifecycle stages or targeting needs.

## Related guides

* [Lists](./lists) — Static groups that complement dynamic segments
* [Consent & Opt-outs](./consent-optouts) — How consent state maps to the `Consent status` segment rule
* [Automations — Triggers](/whatsapp/automations/triggers) — USER\_ADDED\_TO\_SEGMENT trigger behavior
* [Automations — Conditions](/whatsapp/automations/conditions) — SEGMENT\_MEMBERSHIP condition in flow branching
* [Campaigns — Audience Targeting](/whatsapp/campaigns/audience-targeting) — Using segments as campaign audience sources