Report time processing
Report time processing is a virtual report suite setting that allows data to be processed in a non-destructive, retroactive fashion.
Report Time Processing is available only for Analysis Workspace.
Report Time Processing only affects the data in the virtual report suite and does not impact any data or data collection in the base report suite. The difference between Report Time Processing and traditional Analytics processing is best understood using the following diagram:
During Analytics data processing, data flows through the data collection pipeline and into a preprocessing step, which prepares data for reporting. This preprocessing step applies visit expiration logic and eVar persistence logic (among other things) to the data as it is collected. The primary disadvantage of this preprocessing model is that it requires any configuration be done in advance before data is collected. This means that any changes to preprocessing settings apply only to new data from that time forward. This is problematic if data arrives out of order or if settings were misconfigured.
Report Time Processing is a fundamentally different way of processing Analytics data for reporting. Instead of predetermining processing logic before data is collected, Analytics ignores the data set during the preprocessing step and applies this logic each time a report is run:
This processing architecture allows for far more flexible reporting options. For example, you can change the visit timeout period to any length of time you want in a non-destructive way and those changes are reflected in your eVar persistence and segment containers retroactively as if you had applied those settings before the data was collected. Additionally, you can create any number of virtual report suites, each with different Report Time Processing options based on the same base report suite, without altering any of the data in the base report suite.
Report Time Processing also allows Analytics to prevent background hits from starting new visits and allows the mobile SDK to tell reporting to start a new visit whenever an App Launch event is triggered.
The following configuration options are currently available to virtual report suites with Report Time Processing enabled:
- Visit Timeout: The visit timeout setting defines the amount of inactivity a unique visitor must have before a new visit is automatically started. It defaults to 30 minutes. For example, if you set the visit timeout to 15 minutes, a new visit grouping is created for each sequence of hits collected, separated by 15 minutes of inactivity. This setting impacts not only your visit counts, but also how visit segment containers are evaluated, and the visit expiration logic for any eVars expiring on visit. Decreasing the visit timeout will likely increase the total number of visits in your reporting, while increasing the visit timeout will likely decrease the total number of visits in your reporting.
- Mobile App Visit Settings: For report suites containing data generated by mobile apps through the Adobe Mobile SDKs, additional visit settings are available. These settings are non-destructive and only affect hits that have been collected via the Mobile SDKs. These settings have no impact to data collected outside of the Mobile SDK.
- Prevent Background Hits from starting a new Visit: Background hits are collected by the Mobile SDKs when the app is in a background state.
- Start a New Visit upon each App Launch: In addition to the visit timeout, you can force a visit to begin whenever an App Launch event has been recorded from the Mobile SDKs regardless of the inactivity window. This setting affects the visit metric and the visit segment container, as well as visit expiration logic on eVars.
- Start New Visit with Event: A new session starts when an event is fired, regardless of whether a session has timed out. The newly created session includes the event that started it. Additionally, you can use multiple events to start a session and a new session fires if any of those events are observed in the data. This setting will impact your visit count, the visit segmentation container, and the visit expiration logic on eVars.
Report Time Processing does not support all metrics and dimensions available in traditional Analytics reporting. Virtual report suites utilizing Report Time Processing are only accessible in Analysis Workspace and will not be accessible in Reports & Analytics, Data Warehouse, Report Builder, Data Feeds, or the reporting API.
In addition, Report Time Processing only processes data that comes from within the reporting date range (referred to as “date windowing” below). This means that eVar values set to “never expire” for a visitor prior to the reporting date range do not persist into the reporting windows and do not appear in reports. This also means that customer loyalty measurements are based exclusively on the data present in the reporting date range and not on the entire history prior to the reporting date range.
Below is a list of metrics and dimensions that are not currently supported when using Report Time Processing :
- Analytics for Target: Currently unsupported. Future support is planned.
- Analytics for Advertising Cloud reserved metrics/dimensions: Currently unsupported. Future support is planned.
- Single Access Metric: Permanently unsupported.
- List Vars: Currently unsupported. Future support is planned.
- Counter eVars: Permanently unsupported.
- Marketing Channels Variables: Currently unsupported. Future support is planned.
- Days Since Last Purchase Dimension: Due to the nature of Report Time Processing date windowing, this dimension is not supported.
- Days Before First Purchase Dimension: Due to the nature of Report Time Processing date windowing, this dimension is not supported.
- Return Frequency Dimension: Due to the nature of Report Time Processing date windowing, this dimension is not supported. An alternative approach using a visit count metric in a segment is possible, or using the visit metric in a histogram report.
- Days Since Last Visit Dimension: Due to the nature of Report Time Processing date windowing, this dimension is not supported.
- Entry Page Original Dimension: Due to the nature of Report Time Processing date windowing, this dimension is not supported.
- Linear Allocation eVars: Currently unsupported. Future support is planned.
- Original Referring Domain Dimension: Currently unsupported. Future support is planned.
- Visit Number: Due to the nature of Report Time Processing date windowing, this metric is not supported. As an alternative in mobile apps, you can use a calculated metric including visitors/visits with the App Install metric to identify new visitors or visits.
- Transaction ID Data Sources: Currently unsupported. Future support is planned.
Below is a list of dimensions and metrics that are impacted depending on the Report Time Processing settings selected:
- If “Prevent Background Hits from starting a New Visit” is enabled, the following changes occur. See Context-aware sessionization for more information.
- Bounces/Bounce Rate: Background hits that are not followed by a foreground hit are not considered a bounce and do not contribute to the bounce rate.
- Time Spent Seconds Per Visit: Only visits that include foreground hits contribute to this metric.
- Time Spent Per Visit: Only visits that include foreground hits contribute to this metric.
- Entry/Exit Dimensions and Metrics: Only entries and exits from visits with foreground hits appear in this dimension.
- Unique Visitors Metric: Unique Visitors does not include visitors who had only background hits in the reporting date range.
- Visits: Visits reflects whatever settings the virtual report suite has configured, which can be different from the base report suite.
- Serialized Events with Event IDs: Events that use Event Serialization with an event ID are only deduplicated for events that occur within the reporting date range for a visitor. These events are not deduplicated across all dates or visitors globally due to Report Time Processing date windowing.
- Purchases/Revenue/Orders/Units: When the purchase ID is used, these metrics are only deduplicated for duplicate purchase IDs that occur within the reporting date range for a visitor rather than across all date or visitors globally due to Report Time Processing date windowing.
- Non-merchandising eVars/reserved eVars: Values set in an eVar persist only if the value was set within the reporting date range due to Report Time Processing date windowing. In addition, time-based expirations can expire an hour early or an hour late if the persistence spans a daylight savings time change.
- Merchandising eVars/reserved eVars: See above. In addition, for conversion syntax, where the binding is set to “any event,” “any hit” is used instead.
- Hit Type: This dimension specifies whether a hit is foreground or background.