Home AppMeasurement Web SDK · Migration Guide Created by Amit G Dusane

MigrationKnowledge Base › The datastream

Decisions

The datastream

The datastream is a switchboard. The browser places a call; the datastream decides which lines it connects to, Analytics, Target, the Platform, and which report suite it rings.

It's a server-side configuration that tells the Edge what to do with arriving payloads. No datastream, and the Edge has nowhere to send your data; it's discarded. Add the Adobe Analytics service and a report suite ID, and every payload is forwarded there.

The datastream ID (formerly the edgeConfigId)[21] is bound to each Tags environment. You create three, Dev, Staging, Production, so each environment routes independently, and you can apply report-suite overrides for multi-suite setups.

For your migration: the report suite a datastream points at is its most consequential setting. Through the whole build, Dev and Staging point at a validation suite; only Production points at the live RSID, and only at cutover.

⚑ Architect's Decision

Three datastreams, always. Dev and Staging point at a validation RSID; Production gets the live RSID only at cutover.

Full detail, the complete reference

One config, three copies

A datastream is the server-side instruction set the Edge consults for every payload: which services to forward to, and with what settings. You build three, Dev, Staging, Production, and bind each to the matching Tags environment, so test traffic and live traffic route independently. This separation is the backbone of safe validation.

The Analytics service

Adding the Adobe Analytics service to a datastream and entering a report suite ID is what makes your data reach Analytics[21]. The report suite ID is the most consequential setting in the whole datastream: Dev and Staging point at a validation suite throughout the build; only Production points at the live RSID, and only at cutover. For multi-suite or multi-brand setups, report-suite overrides let a single sendEvent route dynamically.

Geolocation and the ID

Enable Geolocation and network lookup so the Edge fills placeContext.geo.* server-side, work that used to need client-side plugins. Each datastream has an ID (the artifact formerly called the edgeConfigId) that you copy into the Web SDK extension per environment.

⚠ The classic error

Pointing Dev or Staging at the production RSID "just to confirm it works." Every test hit is then real, live data; you inflate the numbers the business watches, for weeks, and you cannot un-collect it. The tell: live metrics rise when only QA is active.