---
title: "Cookies the ad server sets"
description: "Every cookie Epom's ad-serving domains write — what each one is for, how long it lives, what it holds, and which ones a busy visitor accumulates."
type: "reference"
audience: [network-manager, publisher]
keywords: [cookies, uuid, epomUUID, OPTOUT, capping cookie, daisy chaining cookie, cookie policy, cookie names, privacy, GDPR, maxActionDataCount]
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Cookies the ad server sets

Every cookie below is written by an **ad-serving domain** — the host in your invocation code — not
by the publisher's own domain, so to a visitor's browser they are third-party cookies. The console
(`/account/**`) sets only a session cookie and the interface-language one.

The names are **configurable per network** (`epom-cookies.json`), so a network may run with
different ones; the names here are the ones Epom ships. If you are auditing a specific network,
read the names off its configuration rather than this page.

## What a visitor gets

Most of these are **jars**: one cookie holding a record per campaign, entity or placement, not one
cookie per entity. The ad server writes them with the full 400-day lifetime and re-issues them
each time they change; what runs out sooner is a record inside the jar, on its own clock.

| Cookie | Lives | Holds | Written when |
|---|---|---|---|
| `epomUUID` | 400 days | The visitor identifier the whole ad server keys on: capping, unique-visitor counting, conversion attribution and the OpenRTB `user.id` | The first ad request from a browser that has none and accepts cookies |
| `OPTOUT` | 400 days | `1` | The visitor opens `/user/opt-out`. While it is there every other Epom cookie is removed and none is written again |
| `ubv` | 400 days; a record older than that is dropped | One record per campaign — campaigns sharing a **Campaign alias** share one: the creative, placement and transaction of the visitor's latest impression, its time, and the conversions already counted against it. A conversion checks its post-view window against that time | An impression of a creative whose campaign has conversion actions; a conversion rewrites it to mark itself counted |
| `ubvc` | 400 days; a record older than that is dropped | The same for the visitor's latest click, checked against the post-click window | A click on such a creative. A new click clears the conversions the record counted, so the visitor can convert again |
| `ucv` | 400 days; each record lasts the network's *Unique users counting span* (24 hours by default) | One record per campaign: that the visitor has already been counted as a unique user of it | Each impression; a campaign's record is added on the visitor's first impression of it within the span |
| `<cap>fc`, `<cap>sc` | 400 days; each record ends with its capping period | One record per capped entity: its id and when its period ends — in `sc` also the cap and the count so far | An impression, request, click or action that a cookie-based cap counts |
| `dbv<placement id>`, `dcv<placement id>` | 400 days; cleared when the chain starts over or its settings change | How many times each creative (`dbv`) or campaign (`dcv`) of that placement's daisy chain has been shown to the visitor | Each impression in a daisy-chained placement |
| `drc`, `dhc` | 400 days | Per daisy-chained placement: how many times its chain has started over (`drc`), and a hash of its chain settings, so changing them restarts the visitor's chain (`dhc`) | A daisy-chained placement serves |
| `eas_3p_<name>` | what the call asks for, 365 days when it asks nothing, never over 400 | A value a tag or partner asked the ad server to keep, for cookie-value targeting and cookie sync | A `set-cookie.gif` or `multi-cookie` call carrying `<name>=<value>`. A lifetime rides after the value: `<value>\|30d` (`y`, `d`, `h`, `m`, `s`; a bare number is days) |
| `eas_3p_rtb_uid_<partner>` | 365 days | The DSP partner's own user ID for this visitor, sent to it as `user.buyeruid` in bid requests | The partner's user-sync call; `<partner>` is its short name. It is read only while the partner has **Enable user sync** on |
| `mcd_<names>` | the shortest lifetime among the values being set | Which domains a cookie-sync round has already visited | A `multi-cookie` sync split across several requests; `<names>` are the cookies the round sets, joined with `_` |
| `ucd_<partner>` | 400 days | The `customdata` a DSP partner returned with its winning bid, sent back to it as `user.customdata` in its next bid requests | A winning bid with custom data from a DSP partner with **Enable custom data processing** on; `<partner>` is its short name |

**Capping cookie names.** `<cap>` names the kind of cap and the level it is set on: `c`, `b`, `af`
and `pfc` for impression caps on a campaign, creative, advertiser and placement; `cr`, `br`, `pr`
for request caps; `cc`, `bc`, `pcc` for click caps; `ca`, `ba`, `pac` for action caps; `cnc` and
`bnc` for no-click caps. `fc` holds the **Flat** caps and `sc` the rest, so a visitor's ordinary
campaign impression caps sit in `csc`. Each cookie is written only while the cap's subject keeps
its counter in a cookie — see [Frequency capping](https://epom.com/ad-server/docs/guides/delivery/frequency-capping.md).

The console sets two more, on the console host only: the servlet session cookie, and `ui_locale`
(one year) which remembers the interface language so the login page is in it too.

## How long a cookie can live

Browsers cap a cookie's life at **400 days**, and the ad server caps every cookie it writes at the
same figure: a longer lifetime is logged and shortened rather than sent. Every cookie above except
the `eas_3p_` and `mcd_` ones is written with exactly that lifetime. The jars are re-issued with a
fresh 400 days each time they change, so on an active visitor they do not expire; `epomUUID` and
`OPTOUT` are written once and run out 400 days later. A capping period, a conversion window or the
unique-user span limits the record inside the jar instead: an expired capping record stops
counting, a conversion outside its window is checked against the record's time, and a `ucv` record
past its span lets the visitor count as unique again.

## Can a visitor accumulate too many?

Fewer cookies than entities: conversion, unique-visitor and capping data sit in a fixed set of jars
(`ubv`, `ubvc`, `ucv` and two per kind of cap), and each jar grows by a record per campaign or
entity the visitor meets. **`maxActionDataCount` (25 by default)** limits the `ubv` and `ubvc`
jars: when one is written with more records than that, the oldest are left out. The `ucv` and
capping jars have no count limit; their records leave only as they expire. The cookies that do
multiply are one `dbv`/`dcv` per daisy-chained placement the visitor meets and one `eas_3p_` per
value set.

> **Corner case:** a browser keeps no cookie larger than about 4 KB, name and value together, and
> ignores a write that would exceed it — the visitor keeps the previous, smaller jar, so new
> impressions and clicks stop being recorded while the old ones still count. That reads as
> attribution failing for recent traffic rather than as a cookie problem. `maxActionDataCount`
> keeps `ubv` and `ubvc` under the limit — raise it with care.

## Turning cookies off

Three different switches, often confused:

| Switch | Where | Effect |
|---|---|---|
| `cookie-policy` on the tag | Invocation code | `0` normal; `1` no cookies and no server-side capping; `2` no cookies but server-side capping still runs; `3` only the user-id cookie is left out |
| **Collect cookies** off for a site | Site settings, *Advanced settings* | The ad server still writes its own cookies for that site's traffic — user ID, conversion, unique-visitor, capping, daisy-chain and `eas_3p_` ones — and leaves out the rest, which in the table above is `ucd_`. A network can be configured to write none at all for such a site; ask Epom support or your account manager |
| `OPTOUT` | The visitor, at `/user/opt-out` | Removes every Epom cookie on that domain and stops new ones |

Without a user-id cookie the ad server falls back to server-side capping where the network allows
it, and attribution falls back to what the click and impression URLs carry. See
[GDPR & TCF consent](https://epom.com/ad-server/docs/guides/admin/gdpr-tcf-consent.md) for what consent gates on top of this.

## Related

- [Invocation codes](https://epom.com/ad-server/docs/reference/invocation-codes.md) — the `cookie-policy` parameter and the rest of the tag contract
- [Frequency capping](https://epom.com/ad-server/docs/guides/delivery/frequency-capping.md) — which capping modes need a cookie
- [Capping matrix](https://epom.com/ad-server/docs/reference/capping-matrix.md)