> For the complete documentation index, see [llms.txt](https://docs.coresignal.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coresignal.com/guides/choosing-the-right-timestamp-field.md). # Choosing the Right Timestamp Field Choose the correct timestamp field when filtering Company, Employee, and Jobs records. 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](/company-data/multi-source-company-data.md), [Employee](/employee-data/multi-source-employee-data.md), and [Jobs](/jobs-data/multi-source-jobs-data.md) datasets. {% hint style="info" %} `created_at` and `updated_at` are the only universal timestamp fields across Company, Employee, and Jobs datasets. {% endhint %} **Company dataset** Multi-source Company dataset includes two timestamp fields: * `created_at` * `last_updated_at` {% hint style="info" %} In the Company dataset, `last_updated_at` corresponds to the timestamp field `updated_at`, identifying the date when it was last updated. {% endhint %} **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` {% hint style="success" %} 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. {% endhint %} ### 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](/data-introduction/data-overview.md) | Explore all datasets and their types | | [Search Filters](/api-introduction/requests/search-filters.md) | Identify matching IDs using simple filters | | [Elasticsearch DSL](/api-introduction/requests/elasticsearch-dsl.md) | Identify matching IDs using advanced queries | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.coresignal.com/guides/choosing-the-right-timestamp-field.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.