Agree on the handoff first
A collection can run successfully and still produce a file the next team cannot use. The delimiter may be unexpected, the product key may change between runs, or a date may lack its timezone. A short delivery specification helps surface these details before they become rework.
Start with a small example file and the purpose of the dataset. Ask the receiver to import it using their normal process. A real import often reveals assumptions that a field list alone does not show.
Document the output shape
List the output format, text encoding, field names and field types. For CSV, agree on the delimiter and quoting behavior. For JSON, agree on whether the delivery is a single array, a record per line or another explicitly documented structure.
- Identity: define the stable record key and, where relevant, the variant or location key.
- Observation: specify how the collection time is represented and which timezone it uses.
- Values: document currency, measurement units, nulls and optional fields.
- Provenance: retain a source URL or source identifier that helps a reviewer trace a record.
Distinguish a snapshot from a change feed
A snapshot describes the records present at a particular collection time. A change feed describes additions, updates or removals. Those formats require different handling. A missing product in a snapshot might be a genuine removal, a temporary collection failure or a source page that moved.
Decide how those cases will be represented. Avoid treating an incomplete run as a complete replacement without a check. If a delivery contains only changed records, make sure the receiver knows how to apply a deletion and how to identify the previous version.
Define acceptance with observable checks
Use checks the pilot can actually demonstrate: required fields populated, a stable identifier present, no unexplained duplicate keys and a sample of records matching their source pages. Add any region or language requirement that materially affects the data.
Do not rely on an HTTP success code as the only collection check. Confirm that the expected content is present. Record collection failures separately from missing source values so that the receiver can distinguish a source condition from an incomplete run.
Plan for changes and reruns
Source layouts and business requirements can change. Include a schema version with the delivery notes and describe which changes would require a new version. Adding an optional field differs from changing the meaning or type of a field that a downstream process already uses.
Agree on the handling of repeated deliveries. If the same batch is sent twice, the receiver should have a way to recognize it. If a batch is corrected, identify what it replaces. A batch identifier, observation window and a short delivery note can make that process easier to follow.
Pilot handoff checklist: accepted sample file, field dictionary, identity rule, observation time, refresh expectation, failure handling and a named contact for questions.
Inspect the downloadable examples and use the project inquiry form to describe the output your workflow needs.