Data Feeds Overview

Two people disagree about a number. The analyst says the report is right and the tag must be firing twice. The developer says the tag is fine and something is wrong with the reporting. Both have looked at their own tools and both are confident.

There is a place where that argument ends. It is a text file, it has one row for every server call your site has ever sent, and the hit they are arguing about is in it.

That file is a data feed, and it is the bottom of the stack. Everything else in Adobe Analytics is built on top of it.

One row for every server call your site sends

A data feed is the raw hit data, exported. Each row in the main file is a single server call. Not a visit, not a session, not a summary of anything. One call.

Which means the tracking calls covered earlier in this curriculum have a physical destination you can look at. When a page loads and AppMeasurement sends its request, that request becomes a row. When somebody clicks a tracked link and a link call goes out, that becomes another row. The mechanics of those calls are in Page View Tracking and Link Tracking. This is where they land.

https://yourco.sc.omtrdc.net/b/ss/yourrsid/1/...
    ?pageName=Product%20Detail
    &v1=blue%20running%20shoes
    &events=scView
    &products=%3B12345
    &g=https%3A%2F%2Fwww.example.com%2Fshoes%2F12345

Every one of those parameters has a column waiting for it. The page name lands in a page name column, the eVar lands in an eVar column, the event lands in the event list, the products string lands in a product list column, and the page URL lands in its own column. The row is wide, often several hundred columns, and most of them are empty on any given hit.

Where every number you argue about comes from

This is the reason the module matters, and it is worth being direct about it.

Every number you have ever presented from Adobe Analytics was produced by counting and grouping these rows. A visit is a set of rows sharing a visitor ID and a visit number. A unique visitor is a distinct visitor ID across a period. Revenue is parsed out of the product list column and added up. An attributed order is one of these rows, credited to a value found on an earlier row.

Nothing else is happening. There is no separate store of visits somewhere, no second copy of revenue. There are rows, and there are rules for counting them.

Once you have seen that, reports stop being magic and start being arithmetic you could check. That is a different relationship with the tool, and it is the main thing this module is for.

It also settles the argument at the top of this section in about ten minutes. If the tag fired twice, there are two rows. If the tag fired once and the report shows two, the counting rules are doing something you have not understood yet. Either way, somebody can now point at evidence rather than at their own tool.

Raw data is not the same as useful data

It is worth saying plainly, because the word raw carries a promise it does not keep.

Nobody opens a data feed to answer a business question. The file has several hundred columns, no header row, numeric codes instead of names in many places, and one row per hit rather than per anything a person cares about. A single busy day can run to tens of gigabytes. There is nothing in it you can read.

Getting the raw data does not get you closer to an answer. It moves you further from one, because everything Adobe was doing for you now has to be done by you, correctly, before you have a number at all.

So the value of this module is not that you will start exporting feeds. Most people never will. The value is that you now know what sits underneath, which changes how you read every report above it and gives you somewhere to go when two tools disagree.

What people actually use it for

Four uses cover nearly all of it.

Loading into a warehouse or lake. The feed lands in cloud storage, a pipeline reads it, and the hits become tables the business queries alongside everything else it holds. This is the most common use by volume.

Feeding Customer Journey Analytics. Adobe's own newer product takes the raw hit data rather than the finished reports, which tells you something about which layer is considered the real one.

Data science. Sequence models, propensity scoring, path analysis beyond what the interface offers. All of it needs individual events in order, which is exactly what the feed is.

Validation and debugging. The narrowest use and the one most people benefit from. When something looks wrong, the feed shows what was actually received, with no processing opinion applied on top. It answers questions that no report can, because a report is already the answer to a different question.

Follow along: find your own hit in the raw data

If your organisation already has a feed running, this takes about fifteen minutes and it is the single most useful exercise in the module. If you do not have one, read it anyway, then come back once you have a feed configured.

The bottom of the stack

A data feed is the raw hit data with one row per server call. The tracking request that leaves a browser becomes a row, its parameters land in named columns, and every report in Adobe Analytics is produced by counting and grouping those rows.

Knowing that is worth more than having the file. Raw data is not more useful than a report, it is less useful, because none of the work has been done yet. What it gives you is a floor to stand on: somewhere to check what was really received when two tools or two people disagree.

The jobs that genuinely need feeds all have the same shape, which is that something outside Adobe is going to do the counting. Warehouses, CJA, data science, and implementation validation.

Which raises the practical question of how the file gets to you at all. A feed is a standing instruction rather than a one-off request, it runs on a cycle you choose, and several of its settings are decided once and are awkward to change afterwards. Feed Configuration covers setting one up.