Analyze the data › Data Warehouse
Best Practices and Use Cases
Somebody asks for last month's revenue by marketing channel. An analyst builds a Data Warehouse request, schedules it, and tells the person it will arrive tomorrow.
That report takes about forty seconds to build in Analysis Workspace, on screen, with the numbers visible while the two of them are still talking. The export added a day to a question that had no size problem, no row problem and no automation behind it.
Knowing what Data Warehouse is for is mostly about knowing what it is not for, because it is the tool people reach for whenever the word export is spoken.
Three ways out, and they are not interchangeable
Adobe gives you three ways to get data out, and they sit at different points on the same line. The line runs from data that has been shaped and summarised for you, to data that has been shaped for nobody.
Reading that line the right way is most of the decision. Moving right does not get you better data. It gets you less finished data, and everything Adobe was doing for you becomes your job.
| Reach for | When | Because |
|---|---|---|
| Analysis Workspace | A person wants an answer | It is instant, interactive, and takes calculated metrics |
| Data Warehouse | A system wants a complete table, or the row count is too big for a report | No Low Traffic in most cases, unlimited rows, delivered as a file |
| Data Feeds | You need the individual hits, or you are rebuilding the data somewhere else | One row per server call, nothing summarised |
What Data Warehouse is genuinely best at
Four jobs, and it is better than the alternatives at all of them.
Long-tail dimensions in full. Every search term, every product ID, every campaign code, with nothing bucketed into Low Traffic. This is the reason the tool exists and no other export gives you the same thing with the values already grouped and counted.
Joining Adobe data to something else. Store visits and offline sales, CRM records, cost data from an ad platform, a product margin table. The join happens in your system, and Data Warehouse gives you an aggregated table with a key you can join on rather than millions of raw hits you would have to summarise first.
Feeding a BI tool or a warehouse of your own. A scheduled request landing in cloud storage on a fixed cycle is a perfectly good input to a pipeline. It is not a live connection, and it does not need to be for most reporting.
Classified values in bulk. This one is easy to miss and it is a real advantage. Data Warehouse carries classification values, so a request can return the friendly campaign name rather than the tracking code. The raw feed does not do that, as Classifications Overview explains. If you need classified data outside Adobe, this is the export that has it.
Data Feeds and scheduled Data Warehouse requests both run against the parent report suite, never against a virtual one. This surprises teams who have built their whole reporting on a virtual report suite and assume the export will inherit its filters. It will not, and the export will quietly contain data the virtual suite was designed to exclude. The workaround is to rebuild the virtual suite's filter as a segment and apply that segment to the request, provided the definition is compatible. The mechanics are in Virtual Report Suites.
Requests that should not have been requests
Three patterns come up repeatedly, and all three are somebody using an export to avoid a conversation.
The first is the request that answers a question the interface already answers. Revenue by channel, orders by campaign, visits by device. If it fits on a screen and nobody needs it in a file, building an export adds a day and removes the ability to ask a follow-up question.
The second is the export as a substitute for analysis. Somebody wants a number, so they are given every number and left to find it. This is very common and it looks generous. What it actually does is move the analysis onto a person who has less context than you and no way to check their answer.
The third is the standing request nobody reads. A weekly file has been landing in a bucket for two years, feeding a dashboard that was decommissioned eighteen months ago. It costs storage, it costs processing, and it will keep running until somebody looks.
Setting up a scheduled request takes a few minutes and creates something that will run every week until a person deliberately stops it. Nobody owns it, nobody reviews it, and the person who built it will change role. The cost is not the processing, it is that the estate slowly fills with files whose purpose nobody can explain, which makes it impossible to tell which exports matter when something eventually breaks. Give every scheduled request a name that says what it feeds and a notification address that belongs to a team, and put a note somewhere that says why it exists and who asked for it.
Look after them, because they outlive their authors
Three habits, and none of them is technical.
Name requests for the thing they feed, not for the data they contain. A request called finance-monthly-revenue-reconciliation tells the next person what breaks if they stop it. One called revenue-export-2 does not.
Point notifications at a shared inbox. Failure notices sent to an individual stop being read the week that individual changes team, and a failing scheduled request is completely silent to everybody else.
Review the list once or twice a year. Open the Data Warehouse page, read down the requests, and for each one ask what would notice if it stopped. Anything nobody can answer for is a candidate to switch off.
Follow along: audit what is already running
Most companies that have had Adobe Analytics for a few years have requests running that nobody can account for. This takes twenty minutes and it is usually the most valuable thing in this module for an established implementation.
-
Open
Tools›Data Warehouseand list every scheduled request. Note the name, the schedule, the destination and the notification address for each one. - For each request, write one sentence saying what would break if it stopped tomorrow. If you cannot write the sentence, that request is your candidate list.
- Check where each one delivers, and whether anything is still reading that location. Buckets outlive pipelines. A file arriving somewhere nobody reads is the most common finding.
- Check the notification addresses for people who have left. This is where silent failures come from. Replace them with a shared inbox.
- For anything you are keeping, confirm the manifest and empty-file options are switched on. Older requests predate the habit and usually have neither.
- Stop the ones nobody can account for, rather than deleting them. Stopping is reversible and somebody will surface within a month if it mattered.
There is nothing to build here. A list, a sentence per request, and the discipline to switch off what nobody can explain. Doing it once a year keeps the estate readable.
Complete, classified, and delivered elsewhere
Data Warehouse is for a complete table that a system needs, not for a number a person wants. Its real strengths are the long tail with nothing bucketed, classified values outside Adobe, and a scheduled file landing where a pipeline can collect it. Its weaknesses are the wait, the rigidity, and the flat refusal of calculated metrics.
The most common mistake is not misconfiguring a request. It is building one at all for a question the screen already answers, or handing somebody every number because working out which number they needed would have taken a conversation.
And the requests you build will outlive you in the role, so name them for what they feed, notify a team rather than a person, and read the list once a year.
One thing this module has taken for granted throughout is that Adobe hands you data already grouped and counted. Rows arrive summarised, visits are already visits, and a search term already has its orders attached. Underneath all of that sits the layer where none of it has happened yet: every single server call your site has ever sent, one per row, in the order they arrived. Data Feeds Overview opens that layer, and it is where the tracking calls from earlier in this curriculum finally reappear as rows you can look at.
Analytics > Tools > Data Warehouse lists every request in the login company, with its schedule and status. This is the page to audit.
A scheduled request can be opened, edited or stopped from here. A completed one-off cannot be edited, though it can be copied as the starting point for a new request.
This article focuses on the concepts, architecture, and practical guidance behind the topic. For the latest UI walkthroughs and step-by-step implementation instructions, use the links below. They leave this site and open Adobe's own documentation in a new tab.