Data sources and collection — where the data comes from and how you get it (so your models don't starve)

"Garbage in, gospel out." — the dramatic prophecy every model learns at orientation.

You're coming in hot from data types and modalities and the classic structured vs unstructured showdown. You remember: modalities tell us what kind of signal we're dealing with (text, image, audio, tabular), and structure tells us how tidy it is. Now we take the next step: where that stuff actually comes from and how to collect it responsibly, so your ML experiments stand a chance in the real world.

Why sources and collection matter (aka the backstage of ML)

If machine learning is the glam band on stage, data collection is the road crew that puts the amps together. Poor sourcing or sloppy collection ruins the concert — noisy labels, missing populations, illegal scraping, or invisible bias will all sabotage performance. Knowing sources and collection methods helps you:

• Maximize relevance and coverage of your dataset
• Anticipate and mitigate bias and legal risks
• Design pipelines that are repeatable, auditable, and improvable

Think back to the Machine Learning Essentials: models generalize from patterns in data. If your data is weird, your model will be weird in equally creative ways.

Main categories of data sources

1) By origin

• Internal: company logs, CRM records, transaction databases, sensor feeds owned by you
• External: public datasets, APIs, partner data, purchased third-party data

2) By collection purpose

• Primary: you collected it directly for your project (surveys, experiments, sensors) — highest control
• Secondary: reusing data someone else collected (open datasets, scraped data, archives) — less control

Quick comparison table

Concrete examples (so it stops being abstract)

• E-commerce recommender: internal transaction logs + clickstream + product catalog (structured) + user reviews (unstructured)
• Autonomous vehicle ML: LiDAR and camera sensors (primary, streaming) + road map data from partners
• Sentiment analysis model: scraped social posts (external, unstructured) + human-labeled subset (primary)

Ask yourself: what modality do you need (text, image, tabular)? Which of the sources above would naturally emit that modality?

How data gets collected (methods and mechanics)

1. Instrumentation & logging
   • Route: automatic, event-driven collection from apps and devices
   • Use when: you need continuous telemetry (e.g., user behavior, IoT sensors)
2. APIs and connectors
   • Route: pull from external services with rate limits and auth
   • Use when: integrating third-party data (weather, maps)
3. Web scraping
   • Route: HTML parsing, crawling
   • Use when: data is public but no API exists — proceed with legal caution
4. Surveys and experiments
   • Route: designed collections targeting a population
   • Use when: you need labeled outcomes or behavior under controlled conditions
5. Manual curation and annotation
   • Route: human labelers, crowdsourcing platforms
   • Use when: ground truth labeling is necessary
6. Purchasing or licensing
   • Route: buy datasets from providers with terms
   • Use when: scale or niche data required quickly

Quick pipeline pseudocode

# simplified collection pipeline
ingest(source):
  raw = fetch(source)
  validate(raw)
  enrich_with_metadata(raw)
  store(raw)
  trigger(quality_checks)

Example API pull (curl):

curl -H 'Authorization: Bearer TOKEN' 'https://api.example.com/v1/items?page=1'

Quality, bias, and representativeness — the sneaky problems

Collecting isn't neutral. Think about:

• Coverage bias: who isn't in your dataset? (e.g., smartphone-only sampling misses offline populations)
• Measurement bias: is your sensor skewed? (e.g., camera trained in daylight performs poorly at night)
• Sampling bias: did you sample conveniently instead of representatively?
• Labeling bias: are annotators consistent or culturally biased?

Ask: whose data is missing, and how would that affect downstream decisions? That question is more important than any accuracy metric.

Ethics, privacy, and legalities (yes, someone will sue you)

• Consent: users should know what you collect and why
• Minimization: collect only what's necessary
• Anonymization and de-identification: reduce re-identification risk, but know it's hard
• Regulation: GDPR, CCPA, HIPAA — know the rules for your domain and location
• Licensing: check dataset licenses; 'public' does not always mean 'free for commercial use'

Pro tip: keep a data inventory and a simple data-processing agreement template. Future you (and your compliance officer) will thank you.

Metadata and provenance — the breakfast of reproducibility

Document: source, collection date, collection method, sampling method, preprocessing steps, schema versions, known issues. Without this, reproducing results is an archaeological dig.

Practical checklist before you collect

1. Define the target population and modality
2. Select sources and justify them (coverage & bias assessment)
3. Design collection method (streaming vs batch, API vs manual)
4. Plan storage, access controls, and retention
5. Define labeling and quality checks
6. Audit for legal and ethical compliance
7. Record metadata and provenance

Closing — TL;DR (but with feeling)

• Data sources are the origin story of every model. Choose them badly and the plot crumbles.
• Collection is both technical and ethical: instrumentation, APIs, surveys, scraping, and purchases all have tradeoffs.
• Always document provenance, watch for bias, and obey privacy rules.

If you remember one thing: pay as much attention to where data came from and how it was collected as you do to the model architecture. The model is the celebrity; the data is the biography.

Key takeaways:

• Start with what you're trying to predict and work backwards to the sources that capture that signal
• Prioritize transparency: metadata and provenance beat guesswork
• Build repeatable, monitored pipelines to keep your dataset healthy over time

Ready for the next move? We'll use these ideas to shape training datasets, label strategy, and evaluation protocols — that's where we turn collected chaos into model-ready rhythm.