Data Collection Components data-collection-components

Data collection components include the Data Collection Servers, the DIL API, inbound server-to-server data transfers, and log files.

Audience Manager contains the following data-collection components:

Data Collection Servers (DCS) and Profile Cache Servers (PCS) dcs-pcs

The DCS and PCS work together and separately provide services related to trait realization, audience segmentation, and data storage.

Data Collection Servers (DCS) Function

In Audience Manager, the DCS:

DCS Manages Demand Through Global Server Load Balancing (GSLB)

The DCS is a geographically distributed and load-balanced system. This means Audience Manager can direct requests to and from a regional data center based on the geographic location of a site visitor. This strategy helps improve response times because a DCS response goes directly to a data center that contains information about that visitor. GSLB makes our system efficient because relevant data is cached in servers closest to the user.

In an event call, geographic location is captured in a key-value pair returned in a larger body of JSON data. This key-value pair is the "dcs_region": region ID parameter.

As a customer, you engage with the DCS indirectly through our data collection code. You can also work directly with the DCS through a set of APIs. See Data Collection Server (DCS) API Methods and Code.

Profile Cache Servers (PCS)

The PCS is a large database (basically, a huge server-side cookie). It stores data received for active users from server-to-server transfers and the DCS. PCS data consists of device IDs, authenticated profile IDs, and their associated traits. When the DCS receives a real time call, it checks the PCS for other traits a user may belong to or qualify for. And, if a trait is added to a segment at a later time, those trait IDs are added to the PCS and users can qualify for that segment automatically, without a visit to a particular site or app. The PCS helps deepen Audience Manager’s understanding of your users because it can match and segment users in real time or behind the scenes with new and historic trait data. This behavior gives you a more complete and accurate picture of your users than from real-time qualifications alone.

There are no UI controls that lets our customers work directly with the PCS. Customer access to the PCS is indirect, through its role as a data store and data transfers. The PCS runs on Apache Cassandra.

Purging inactive IDs from the PCS

As indicated previously, the PCS stores trait IDs for active users. An active user is any user who has been seen by the edge data servers from any domain during the last 14-days. These calls to the PCS keep a user in an active state:

The PCS flushes traits if they’re inactive for 17-days. These traits aren’t lost however. They’re stored in Hadoop. If the user is seen again at another time, then Hadoop pushes all of their traits back to the PCS, typically within a 24-hour period.

Other DCS/PCS Processes: Privacy Opt-out

These server systems handle privacy and user opt-out requests. User cookie information is not collected in the log file if a user has opted out of data collection. For more information about our privacy policies see the Adobe Privacy Center.

Data Integration Library (DIL) dil

DIL is code you place on the page for data collection. See the DIL API for more information about available services and methods.

Inbound Server-to-Server inbound-outbound-server

These are systems that receive data sent in by various server-to-server integrations with our clients. See the documentation on sending audience data for more information.

Log Files log-files

The PCS creates and writes data to the log files. These are sent to other database systems for processing, reporting, and storage.