Update time: November 14, 2022
If you are implementing Adobe Analytics and checking where your data goes, you will quickly run into two similar-looking terms: RDC and DPC.
They are related, but they do different jobs.
The short version is this: RDC is about where Adobe collects the hit from the visitor. DPC is about where Adobe processes that hit for reporting. A visitor in Singapore might send the hit to a nearby collection location, but that does not automatically mean the final report processing happens in Singapore.
Let’s make that clearer.
What Are RDC and DPC?
Think of Adobe Analytics data collection like sending a package.
The RDC is the nearby local drop-off point. It helps the package enter Adobe’s network as close to the visitor as possible.
The DPC is the processing facility. That is where Adobe prepares the data so it can appear in Adobe Analytics reports.
More precisely:
| Term | Full name | Main purpose |
|---|---|---|
| RDC | Regional Data Collection | Collects hits at an Adobe edge location close to the visitor |
| DPC | Data Processing Center | Processes collected hits into Adobe Analytics report suite data |
How Adobe Analytics Data Flows
A typical Adobe Analytics collection flow looks like this:
- A visitor loads your website or app.
- Adobe Analytics collection code, such as AppMeasurement or an Adobe Analytics extension in Adobe Experience Platform Data Collection, sends a hit.
- The hit routes to a nearby Adobe regional data collection location.
- Adobe securely forwards the collected data to a core processing location.
- After processing, the data becomes available in Adobe Analytics reports and other connected Adobe Experience Cloud services, depending on your implementation.
Simple, right? The important part is not to confuse the collection location with the processing location.
RDC：Regional Data Collection
RDC exists mainly for performance and resilience.
When a visitor’s browser sends an Adobe Analytics hit, routing it to a nearby Adobe collection location can reduce network latency. That can help the request complete faster and make data collection more reliable.
RDC can also help with redundancy. If one edge location has a communication issue, Adobe can route traffic through another location or temporarily store and forward data when communication is restored.
Third-Party vs First-Party Data Collection
Before choosing or reviewing an RDC setup, you need to know whether your implementation uses third-party or first-party data collection.
| Collection type | What it means | Example |
|---|---|---|
| Third-party data collection | The Adobe Analytics request goes to an Adobe-owned or Adobe-controlled collection domain that does not match your site domain | omtrdc.net, adobedc.net, 2o7.net |
| First-party data collection | The Adobe Analytics request goes through your own domain, usually with a CNAME implementation | metrics.example.com or smetrics.example.com |
If your goal is a standard implementation, third-party collection is often simpler. If your goal is stronger browser cookie durability and a cleaner first-party setup, first-party collection is usually the better direction, but it requires additional configuration.
Can You Specify the RDC?
For first-party data collection, your RDC type is selected as part of the Adobe-Managed Certificate Program setup process. If you need to check or change it, you should contact your Adobe Account Team.
For third-party data collection, Adobe routes requests through its collection domains and DNS infrastructure.
Do not assume that changing a domain value manually is enough. RDC selection can depend on your collection method, account configuration, certificate setup, and whether you use AppMeasurement or Web SDK.
Available RDC Options
Adobe’s current RDC options differ depending on whether you use first-party or third-party data collection.
Third-party data collection
| RDC Type | Data Collection Centers |
|---|---|
| Default | Oregon, Virginia, Ireland, Paris, Mumbai, Singapore, Tokyo, Sydney, China* |
First-party data collection
| RDC Type | Data Collection Centers |
|---|---|
| Global (Default) | Oregon, Virginia, Ireland, Paris, Mumbai, Singapore, Tokyo, Sydney |
| Global + China* | China*, Oregon, Virginia, Ireland, Paris, Mumbai, Singapore, Tokyo, Sydney |
| Americas Only | Oregon, Virginia |
| Europe Only | Ireland, Paris |
| Asia Pacific Only | Mumbai, Singapore, Tokyo, Sydney |
| China Only* | Beijing |
Heads up: China RDC requires Adobe’s China Performance Optimization add-on package. Adobe also notes that China RDC applies to Adobe Analytics AppMeasurement data collection and does not support Web SDK data collection.
DPC：Data Processing Center
DPC stands for Data Processing Center.
This is where Adobe Analytics receives raw collected data and processes it into report suite data for reporting and retrieval.
Unlike RDC, DPC is not something you normally choose in implementation code. A hit collected in Singapore can still be processed in another Adobe Analytics processing location, depending on how the report suite and Adobe infrastructure are assigned.
Adobe’s current Adobe Analytics processing locations are:
| Region | Adobe Analytics processing location |
|---|---|
| United States | Oregon |
| United Kingdom | London |
| Asia Pacific | Singapore |
This is one of the most important distinctions in this topic: RDC optimizes collection proximity. DPC determines where the report suite data is processed.
RDC vs DPC: The Practical Difference
| Question | RDC | DPC |
|---|---|---|
| What does it affect? | Where hits are collected | Where hits are processed for reporting |
| Is it visitor-proximity based? | Yes, generally routed to a nearby edge location | Not necessarily |
| Can implementation teams influence it? | Sometimes, especially with first-party collection setup | Usually not directly in code |
| Example location | Tokyo, Singapore, Sydney, Virginia | Oregon, London, Singapore |
| Main reason it matters | Performance, reliability, collection routing | Reporting processing, data residency discussions, governance |
Final Thoughts
RDC and DPC are easy to mix up because both are part of Adobe Analytics data infrastructure. But they answer different questions.
- If you want to understand where the hit is collected, look at RDC.
- If you want to understand where the data is processed for reporting, look at DPC.
My recommendation is simple: whenever you document or audit an Adobe Analytics implementation, separate collection routing from processing location. This makes conversations about performance, China traffic, first-party collection, and data governance much clearer.