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.

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 for what consent gates on top of this.

Related

• Invocation codes — the cookie-policy parameter and the rest of the tag contract
• Frequency capping — which capping modes need a cookie
• Capping matrix