Data and privacy
Imports
Bring your history with you. Past events land in the event stream with their real timestamps, so a funnel over last year is a funnel over last year.
How it lands
This area has no published API yet.
Segments, analytics, experiments, messages, imports and retention are reached through the console's own API, which exists to serve one first-party client and changes whenever that client does. Rather than print a shape we would have to break, this page describes what is structurally true. The public reference lands when the interface is stable enough to promise.
Each historical row becomes an event carrying its own past timestamp, with received_at set to now and its source marked as an import. Data → Events shows it as backfilled rather than live, because a row that arrived today did not happen today and the stream must not pretend otherwise.
Imports do not deduplicate
Running the same batch twice imports it twice.
Live ingest is idempotent: event_id is the key, and the same id sent twice is stored once. An import mints a fresh id for every row, so re-running one doubles it. Treat an import as a one-shot operation, and if it fails partway, work out what landed before you retry.
Landing is not reconciling
An import that lands is not an import that reconciles.
Loop will tell you how many rows it accepted. It will not tell you whether those rows are the same population your old tool counted. Different definitions of an event, a different identity model, and a different notion of a session all survive the move. Expect the numbers to disagree, and check a known week before you trust a year.
Identity travels with it
Imported events carry their distinct id, so they attach to the same person your live events do, provided the id is the same one. If your old tool used a different identifier, map it before importing rather than after.