Server-Side Collection

Everything so far has happened inside a browser. A person loads a page, a library fires, a pixel goes out. But step back and look at where your most important events actually occur, and a lot of them happen nowhere near a browser. The refund processed at 2am by a back-office system. The order taken over the phone by a call-center agent. The subscription that quietly lapses when a renewal fails. The purchase rung up at a physical till. None of these involve a page load, so none of them can be caught by AppMeasurement or the Web SDK. And yet they are often the events the business cares about most.

Server-side collection is how you get those into Adobe Analytics. Instead of the browser sending the hit, one of your own servers does, talking straight to Adobe's collection servers, with no page, no JavaScript, and no tag manager anywhere in the picture.

What changes when the browser is gone

The mechanics are not the interesting part, but you should know the shape. You construct the data for a hit and your server sends it to Adobe directly. The thing to internalize is what you lose by leaving the browser behind: all the context that used to arrive for free is now gone. There is no cookie, so the hit does not know who the visitor is. There is no automatic user agent, no referrer, no screen size, none of the ambient detail the browser quietly attached to every beacon. A server-side hit contains exactly what you put in it and nothing else. That sounds obvious, but it is the source of both problems that make this section worth its weight.

One consequence of that missing context bites harder than the rest, and it is worth calling out early. With no user agent on the hit, Adobe falls back to the user agent of the machine that actually sent it, your server, which typically looks like Apache-HttpClient or a similar library string. Adobe's bot rules can read that as non-human traffic and quietly exclude the hit. So a server-side hit should carry a real, deliberate user agent, or mapped client hints, or a chunk of your most important data can vanish into the bot reports with no error to warn you.

The three ways to send it

There are three mechanisms, and they map neatly onto the two worlds already drawn.

• Data Insertion API: the classic, AppMeasurement-era method. One hit at a time, sent as XML or a query string. It is the original server-side path and it still works. Adobe has not put it on a retirement schedule, but it now recommends the Bulk Data Insertion API for new work, so it is not where a fresh implementation should start.
• Bulk Data Insertion API: the one Adobe recommends for new server-side work in the Analytics world. You send batch files of events (CSV, one event per row) rather than one call at a time, which is what you want for volume and for loading offline or historical data. One caution: bulk-inserted data is permanent, so validate a batch before you ingest it, because there is no clean undo.
• Edge Network Server API: the modern path that belongs to the Web SDK and Experience Platform world. Your server sends to the same Edge Network that alloy.js feeds, and the datastream fans it out from there.

You do not need the payload details to make the decision. Which one you reach for follows directly from which world you are already living in: classic Analytics, or the Edge.

The real problem: who does this hit belong to?

This is the heart of server-side collection, and it is worth slowing down for. A browser hit gets its identity for free. The cookie is right there, so Adobe knows this hit belongs to the same visitor as the last one. A server-side hit has none of that. It arrives with no idea whose action it represents, unless you tell it.

So you have to supply the visitor identity yourself, the ECID (the Marketing Cloud ID) or a custom visitor ID, captured earlier when the person was in a browser and then carried through your systems so it can be attached to the offline event later. Get this right and the refund processed overnight attaches to the very same person who browsed your pricing page last week. The online and offline halves of one human being finally join up.

Get it wrong and the data is quietly useless in one of two ways. Send no usable identity, and every server hit becomes a brand-new stranger, inflating your visitor counts and attaching to no real journey. Reuse a single ID for everyone, and the opposite happens: every visitor collapses into one, and your eVar and event allocation goes haywire. Remember from the AppMeasurement section that Visitors is not a stored number, it is counted from the identity on each hit at report time. Server-side is where that truth gets sharp, because here the identity is entirely in your hands.

The timestamp trap

The second gotcha comes from timing. Offline events are usually late, the hit reaches Adobe minutes, hours, or days after the thing actually happened. So you attach a timestamp telling Adobe when it really occurred, not when it arrived. Simple enough, except that report suites are particular about timestamps, and getting this wrong silently drops your data.

Every report suite carries one of three timestamp settings:

The trap hidden in that table is the one people hit hardest: a report suite collecting timestamped data cannot also collect ordinary JavaScript beacons, because those arrive without timestamps. Required and not-allowed are two separate worlds, and you cannot casually mix them in one suite. "Optional" exists for hybrids but comes with its own awkward rules and is easy to get subtly wrong. There is also an ordering requirement for batch and historical loads: a given visitor's events must be sent in chronological order, or attribution falls apart. The practical upshot is simple: server-side data usually wants its own timestamp-enabled report suite, and that is a decision to make up front, not after the data starts flowing.

When to reach for it

Server-side is not a replacement for client-side collection, it is the complement that catches what the browser cannot see: offline and back-office transactions, events from devices that have no browser at all (kiosks, set-top boxes, connected hardware), and bulk loads of historical data. It is also how you genuinely unite a customer's online and offline behavior into one view, provided you have solved identity.

So the two questions to settle before anything else are the two this section has been about: how the visitor is identified across the browser-to-backend gap, and how timestamps and report suites are arranged. Solve those two, and the rest is just plumbing.

Identity and timestamps have been framed here as server-side problems, the price of leaving the browser behind. There is one more collection method where they are not edge cases at all but the ordinary daily condition, because the device drops off the network constantly and the hit routinely arrives long after the action. Mobile SDK is where collection leaves the web entirely.