Choosing the Right Timestamp Field

You may come across several timestamp fields across the Company, Employee, and Jobs datasets that look similar. However, each captures a distinct stage in the data life cycle, from creation to pipeline delivery, so it is important to know when to use which field. On this page, you will learn the difference among created_at, updated_at, checked_at, changed_at, and processed_at timestamp fields and their use cases.

Overview

To help you avoid filtering on the wrong timestamp, below you can find data field descriptions and a table summarizing the main differences across the five timestamp fields.

• created_at – shows when the record was created

• changed_at – shows when the record was last changed

• checked_at – shows when the record was last reviewed for changes

• updated_at – shows the date and time when the record was fully updated

• processed_at – shows when the record was processed on our side

User's question	Filter by	Why not the other fields
What’s new in my dataset since YYYY-MM-DD?	created_at	updated_at/checked_at also return old records that were only reverified, filtering by these fields you will miss the date when the record was first created
Did anything in this record change?	changed_at	checked_at returns records without recent changes; updated_at reflects a full refresh cycle rather than a real change; to confirm the real record changes, filter by changed_at
What records were reverified or rechecked recently, regardless of outcome?	checked_at	changed_at excludes checks that found no difference; to find information about records that were recently passed through change-detection process, including the ones that had no changes, filter by checked_at
When was the record last updated?	updated_at	By choosing any other field to filter by, you will miss information about when a specific record was last fully updated
When did Coresignal’s pipeline last process this record for delivery?	processed_at	created_at/updated_at/checked_at/changed_at all reflect changes on the source-data side, not delivery activity; use processed_at to confirm when the pipeline last processed the record for delivery

Timestamp fields in Company, Employee, and Jobs datasets

Some timestamp fields discussed in this guide are dataset-specific, while others are universal across datasets. Below are the exact timestamp fields available in the Company, Employee, and Jobs datasets.

created_at and updated_at are the only universal timestamp fields across Company, Employee, and Jobs datasets.

Company dataset

Multi-source Company dataset includes two timestamp fields:

• created_at

• last_updated_at

In the Company dataset, last_updated_at corresponds to the timestamp field updated_at, identifying the date when it was last updated.

Employee dataset

Multi-source Employee dataset includes the most timestamp fields:

• created_at

• updated_at

• checked_at

• changed_at

• processed_at

Jobs dataset

Multi-source Jobs dataset includes two timestamp fields:

• created_at

• updated_at

Each dataset also has unique timestamp fields that let you track more specific changes. For example, Multi-source Company data includes the salary_updated_at field for more specific filtering.

Common pitfalls

Choosing the wrong timestamp field for filtering can return data that does not match your search intent. Below are the most common mistakes when choosing the right timestamp field.

Filtering on checked_at expecting only changed records

A common mistake is filtering on checked_at and expecting only changed-record information. Filtering on checked_at returns records that were recently reviewed, including ones where no change was found.

Correct usage

Use checked_at to see when the record was last reviewed for changes.

Assuming updated_at and changed_at are always in sync

The updated_at and changed_at fields are not mutually exclusive. updated_at shows when the record was fully updated, but the date can change even if the profile data did not. changed_at, by contrast, always indicates a real data change.

Correct usage

Use updated_at to see the last full record update. Filter by changed_at to find records that had changes in key fields.

Using processed_at as a freshness signal for source-data changes

The processed_at field should not be treated as a freshness signal for source-data changes, as it does not indicate that data fields changed. Instead, it shows when we processed the record.

As a freshness signal use changed_at (direct signal of record change) and updated_at (shows when record was last fully updated).

Correct usage

Use processed_at to identify records of a specific delivery date or to trace record-level platform processing.

Using changed_at alone when the use case needs to identify exact fields changed

The timestamp field changed_at shows when something changed in the record, but it does not show the exact change. To find out which fields changed, use field-change summaries instead:

• profile_root_field_changes_summary – includes field_name, change_type (added, updated, removed), and last_changed_at; allows tracking changes in root fields such as headline, summary, or followers_count

• profile_collection_field_changes_summary – shows collection-level changes, such as experience, education, or activity; includes field_name and its last_changed_at

Correct usage

Use the changed_at timestamp field for change alerts or to exclude records rechecked without any actual profile changes.

Related reading

Resource	Text Description
Data overview	Explore all datasets and their types
Search Filters	Identify matching IDs using simple filters
Elasticsearch DSL	Identify matching IDs using advanced queries