Migration › Knowledge Base › The Edge Network
The Edge Network
Picture the old setup as a chef cooking in every customer's kitchen. The new setup hires a waiter: the browser takes one order and carries it to a single professional kitchen, the Edge Network, that cooks for everyone.
The Edge is Adobe's globally distributed server layer. It receives the Web SDK's payload, validates it against your schema, enriches it (geo lookup, identity resolution), and fans it out to whichever Adobe services your datastream names, Analytics today, Target and AEP when you're ready. The work that used to happen in the browser now happens here.
Requests reach the Edge at your first-party edge domain on /ee/ endpoints, an interact call when a response is needed (page views, personalization) and a fire-and-forget collect call[5] for things like link clicks. The datastream is what tells the Edge which kitchens to cook for.
For your migration: because assembly and routing live server-side, your client shrinks and stays stable. Adding a new destination later becomes a datastream config change, not another tag on the page.
Add new destinations by editing the datastream, never by bolting another tag onto the page. Keep collection client-light and routing server-side.
What the Edge actually does
When the Web SDK sends an event, the payload lands on the nearest node of Adobe's globally distributed Edge Network and passes through a fixed sequence: it is validated against your XDM schema, enriched (IP-based geo lookup fills placeContext.geo.*; the user-agent fills browser and OS details), identified (the ECID is read or minted, consent is checked), and finally fanned out to every service your datastream names, Adobe Analytics today, Target and the Platform when you light them up. The crucial mental shift: all of this used to happen in the browser, and now happens on Adobe's servers.
Two kinds of request
The Web SDK talks to your edge domain on /ee/ endpoints, in two flavours[5][6]. An interact call expects a response and is used when the page needs something back, page views that may carry personalization, or any renderDecisions request. A collect call is fire-and-forget, sent with navigator.sendBeacon for things like link clicks where no response is needed[23][24]. Your old reflex of watching the network tab for b/ss/ calls finds nothing now; these /ee/ requests are what you inspect instead.
The datastream is the routing table
The Edge doesn't guess where to send your data, the datastream tells it. That's why the datastream is a server-side config rather than something in your tag: adding a destination later (say, Event Forwarding to GA4) is a change to the datastream, not a change to your site. The same single payload can feed many services because the routing lives here, not in the browser.
The exact endpoint path and version (/ee/v1 vs /ee/v2, interact vs collect) can shift; confirm against the live Debugger rather than assuming. What's stable is the shape: a JSON payload to your first-party edge domain, not a pixel to the legacy collection servers.