--- title: "Time Anchors" slug: "time-anchors" description: "Time Anchor (also known as \"fact date\") is the timestamp used to determine when the value of a particular metric aggregates." updated: 2025-02-06T17:09:26Z published: 2025-02-06T17:09:26Z canonical: "help.gladly.com/time-anchors" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.gladly.com/llms.txt > Use this file to discover all available pages before exploring further. # Time Anchors Time Anchor (also known as "fact date") is the timestamp used to determine when the value of a particular metric aggregates. Each [out-of-the-box (OOTB)](https://help.gladly.com/docs/what-are-ootb-reports) report in Gladly is attached to a specific Time Anchor, which guides each report's data output, whereas [Insight Builder](/docs/what-is-insight-builder) allows you to use different Time Anchors. When you begin to analyze various reports, it's essential to know which Time Anchor a report uses, as each report's output will differ. ## How Time Anchor works Let's say you run a report that queries data between 1 PM and 2 PM. ![A timeline showing the duration from 1 PM to 2 PM clearly marked.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/Data1-2.png) For things like individual events that only happen at one point in time, finding the right set of data is pretty straightforward—did the event happen in that period of time? ![Graph showing data points between 1pm and 2pm with highlighted elements.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/events.png)Green icons represent events. For things like Contacts and Conversations, which have a “state” (e.g., **Queued**, **Fulfilled**, and **End** state), it’s imperative to know which event/time it’s anchored to. This determines the set of data you’re considering for analysis. ![Timeline showing events Q, F, and E between 1pm and 2pm.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/events-1-2.png) Let's use the Inbound Contacts report, which uses Queued as the Time Anchor. The report would then consider these Contacts: ![A timeline showing events labeled Q, F, and E at different times.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/Queued.png) The Abandoned Contacts report uses Ended as the Time Anchor. The report would consider these Contacts: ![Timeline showing events labeled Q, F, and E between 1pm and 2pm.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/Ended.png) You can see how it wouldn’t make sense to conclude by comparing (i.e., creating an average) information from the two reports that use two different Time Anchors because you would be analyzing different data sets. On the other hand, if both reports were anchored to the same event, you could make comparisons and draw conclusions from the same data set. ### A simplified example Here’s a simplified example. Let’s assume we compare the 2 reports mentioned above, **Inbound Contacts** and **Abandoned Contacts**. - Inbound Contacts report is anchored to Contact **Queued.** - Abandoned Contacts report is anchored to Contact **End**. ![Graph showing inbound and abandoned contacts over time with highlighted abandoned contacts.](https://cdn.us.document360.io/7047b671-c4f2-4df0-bb0a-b9b511fd2452/Images/Documentation/Comparison.png) If you tried to make a comparison between these two reports, you might reason that there are: - 2 Inbound Contacts (Queued) - 3 Abandoned Contacts (Ended) 3 Abandons / 2 Inbound = 150% of Contacts between 1-2 pm are abandoned! The insights are mixed up. If you’re comparing apples to apples, you’d either say: - 100% of Contacts ended between 1-2 PM are abandoned - 0% of Contacts started between 1-2 PM are abandoned So you can see why Time Anchor is important. ## Time Anchor definitions To truly understand how Time Anchors are used in reports, you should know how each Time Anchor is defined. ## Conversations ### Conversation last closed at A Conversation that was *closed-reopened-closed-reopened-closed* would be anchored to the very last close event. In this example, it's considered a single close event. ### Conversation Closed at A Conversation that was *closed-reopened-closed-reopened* would be anchored to every close event. In this example, there are two close events. ### Conversation reassigned at When a Conversation was last reassigned. ## **Contacts** ### Contact queued at Time a Contact was queued. ### Contact fulfilled at Time a Contact was fulfilled. ### Contact initiated at Time a Contact was initiated. ### Contact transferred at Time a Contact was transferred. ### Contact ended at Time a Contact ended. ### Contact ended date (UI), Contact ended at (API) Specific to the Work Session report. - UI - Contact ended date is the date a Contact is ended. - API - Contact ended at is the date a Contact ended. ## **Durations** ### Duration Started Time an Agent started a given duration of being 'Active' or 'Away’ [status](https://help.gladly.com/docs/glossary-and-key-concepts#tasks). ## **Events** ### Event occurred at Time when the relevant event occurred. ### Time of event - when Answer was used Time an Answer was last used. ### Time of event - Conversation reopened The time a Conversations is *closed-reopened-closed-reopened* would be anchored to every close event. In this example, there are two reopen events. ### Time of event - Conversation created at or closed Time a Conversation was either created or closed. - **Created –** When a Conversation was created during a specific time frame. - **Closed –** Any time when a Conversation was closed during a specific time frame. This can happen multiple times for one Conversation. ### Time of event - Task created or closed Time a Task was either created or closed. - Created - When a Task was created during a specific time frame. - Closed - Any time when a Task was closed during a specific time frame. This can happen multiple times for one Task. ### Time of event - Declined or Missed Contact Time a Contact was either declined or missed. - Declined - Any time when a Contact was declined during a specific time frame. - Missed - Any time when a Contact was missed during a specific time frame. ### Time of event - when Topics were updated on a Conversation Time a Topic or set of Topics was added to a Conversation. ### Time of event - when Throttle % is changed Time throttle % was changed as a reaction to incoming chat volume. ### Time of event - when a link is clicked Time when a link is clicked ### Time of event - when a search happens Time a search was started/initiated. ### Time of event Time an event occurred. ## **Tasks** ### Task closed at Time a Task was closed. ### Task created at Time a Task was created ## **IVR** ### IVR started at Time when a call entered the IVR. ## **Payments** ### Date Payment Request Date when the card payment request was requested. ## **Time Buckets** ### Bucketed Segments of time across different "buckets" or time granularities specified using the report's rollup filter. For example, an Agent going "available" at 9:01 and then "Away" at 12:15 has a reportable segment of over 3 hours. If the rollup is set to "half-hourly", one might approach the scenario one of the following ways: - Anchor to the start of the timespan. So, the 9-9:30 granularity would say 3h 14m. - Anchor to the end of the timespan, so the 3h 14m would be in the 12-12:30 rollup. - Distribute the timespan to each of the "bucket" of time. This is how reports using "bucketed" as time anchors work: - 9-9:30 - 29m - 9:30-10 - 30m - 10-10:30 - 30m - 10:30-11 - 30m - 11-11:30 - 30m - 11:30-12 - 30m - 12-12:30 - 15m ## **Voice** ### Voice Outreach Time Time when a Proactive Voice recipient was updated to a complete status.