Skip to content

Tin Can Reference Schema

Do Not Use

  • Any table in the RAW_DB.REFERENCE schema should not be used directly for any reporting purposes. Do not ever use them directly as a data source.

Dropped, not deprecated

RAW_DB.TINCAN.LEGACY_CUSTOMERS, RAW_DB.TINCAN.LEGACY_CONTACTS, and ANALYTICS_DB.ANALYTICS.DEVICES_JOINED_FULL_HISTORY were dropped in the 2026-08-06 V1 retirement. Any query naming one fails to compile — do not try them to verify a number or to fill a gap. RAW_DB.TINCAN.LEGACY_DEVICES and RAW_DB.TINCAN.LEGACY_CDR were retained and are still queryable.

Use Instead

  • The ANALYTICS_DB.ANALYTICS.PARTICIPANT_DAILY_SUMMARY table should be used instead for call log data.
  • The RAW_DB.TINCAN.CONTACT table (joined to RAW_DB.TINCAN.CONTACT_NUMBER for approval status via request_status) should be used for contact data.
  • The ANALYTICS_DB.ANALYTICS.DIM_DEVICE model is the preferred entry point for device data: one row per ROUTING_ID, spanning both the current and legacy device systems, with the activation-date and identity handling described below already applied. It exposes three id columns — ROUTING_ID, DEVICE_ID, LEGACY_DEVICE_ID — and joins from activity tables must be keyed by era, because the DEVICE_ID and LEGACY_DEVICE_ID ranges overlap (see customer_identity.md).
  • Going to the raw tables directly: the RAW_DB.TINCAN.DEVICE table (joined to SUBSCRIPTION / ACCOUNT for subscription and customer linkage) should be used for current device data. RAW_DB.TINCAN.LEGACY_DEVICES was frozen on 2026-08-06 and is retained only for pre-cutover history. Note: device.created_at is a migration timestamp (bulk-loaded ~May 2026), so for true historical device activation dates use legacy_devices.created_at, bridged via device.routing_id = legacy_devices.device_id. This applies to device.created_at only — do not generalize it to other RAW_DB.TINCAN tables. In particular account.created_at is a genuine customer signup timestamp and needs no correction (see customer_identity.md).