# What is Edge Content Protection?

Source: https://dev.arcxp.com/subscriptions/content-protection-metering/learn/what-is-edge-content-protection/

Edge Content Protection (ECP) runs at Arc's edge nodes to deliver differentiated reader experiences by appending a variant query parameter to incoming requests based on JWT entitlement claims and a rules document you configure.

Edge Content Protection (ECP) runs at Arc’s edge nodes and manipulates incoming request URLs before content is served by the CDN or PageBuilder. Rather than blocking unauthorized users, it routes requests to different PageBuilder templates by appending a `variant` query parameter to the URL. This lets you deliver multiple reader experiences — such as ad-supported, subscriber, or premium — from the same URL.

> **Note:**
> 
> Edge Content Protection requires provisioning before you can configure it. To enable it for your organization, submit a ticket through the [Arc XP Customer Support (ACS) portal](https://arcpublishing.atlassian.net/servicedesk/customer/portal/2).
> 
> For configuration steps, see [How to use Edge Content Protection](https://dev.arcxp.com/subscriptions/content-protection-metering/learn/how-to-use-edge-content-protection/).

## How ECP Differs from Arc’s Server-Side Paywall

|                         | Arc server-side paywall                                   | ECP                                                                                       |
| ----------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Enforcement model       | Blocks or allows the request                              | Routes the request to a specific PageBuilder template variant                             |
| Entitlement cookie      | One of two allowed values, applied across the entire site | A JWT you issue, containing a comma-separated list of arbitrary entitlement strings       |
| Rules scope             | Site-wide                                                 | Per-URL pattern matching with include/exclude paths and a priority-ordered rules document |
| Reader experiences      | Binary: authorized or unauthorized                        | Unlimited: any number of distinct experiences per URL                                     |
| PageBuilder integration | Works with standard resolvers                             | Requires resolvers configured to handle the variant query parameter                       |

## Key Concepts

### Path Include and Exclude Patterns

ECP uses path include/exclude patterns to determine whether it processes a request at all — before any cookie or JWT handling occurs.

- **Include paths**: if configured, only requests whose path matches at least one pattern are processed; all others are forwarded as-is without a `variant` parameter.
- **Exclude paths**: requests whose path matches any exclude pattern are forwarded as-is without a `variant` parameter, bypassing ECP entirely.

Patterns are `;`\-separated and support `*` and `?` wildcards.

### Reader Experiences and Variants

You can configure multiple PageBuilder templates that render the same content differently. For example:

- An anonymous user might see a page with ads and a limited article preview.
- A subscriber might see the full article without ads.
- A premium subscriber might see the full article with exclusive content.

ECP selects the correct template by appending a `variant` query parameter to the request URL (for example, `?variant=premium`). PageBuilder resolvers read this parameter and render the appropriate template.

### JWT Entitlement Cookie

You set a cookie in your own external system. The cookie value is a signed JWT (HS256 or HS512) that contains the reader’s entitlements. ECP validates this JWT at the edge and uses two claims to determine the variant:

| Claim        | Required | Description                                                                   |
| ------------ | -------- | ----------------------------------------------------------------------------- |
| entitlements | Yes      | Comma-separated list of entitlement strings (e.g., "sports\_no\_ads,premium") |
| prepend      | No       | A string prepended to the variant value before it is appended to the URL      |
| exp          | Yes      | Standard JWT expiration timestamp; validated by ECP                           |

### Rules Document

You upload a JSON rules document in the Delivery admin UI. The rules engine evaluates each rule in priority order against the incoming request URL and the `entitlements` claim. The first rule that matches both determines the variant value. If no rule matches, the request is forwarded without a `variant` parameter and PageBuilder renders the default template.

### Variant Construction

The final `variant` query parameter value is assembled as:

```
variant = <prepend claim value>_<resolver-query-param from matching rule>
```

If the `prepend` claim is absent, only the `resolver-query-param` value is used.

## PageBuilder Integration

ECP works closely with PageBuilder resolvers. Resolvers must be configured to read the `variant` query parameter and select the appropriate template.

For more information, see [Configuring resolvers](https://docs.arcxp.com/en/products/pagebuilder/pagebuilder-editor/developer-tools-overview/configuring-resolvers.html).

## Cost Considerations

Each unique `variant` value results in a separately cached render in PageBuilder. To optimize rendering costs, design your rules and `prepend` values to minimize the number of unique variants.

## Cache Clearing Compatibility

> **Caution:**
> 
> ECP is not compatible with Arc’s automated or manual cache clearing features. Pages cached under a variant-appended URL are subject to expiration only via the CDN’s default TTL. See [Web experience cache timing](https://dev.arcxp.com/caching/overview/#web-experience-cache-timing-default-ttls) for the values.