Introduction
This document describes how to use legacy Session Source Data (SSD) reports with Ads metrics. Session Source Data (SSD) is a daily offline historical log (view SSD sample) that provides session-level information for every ad play or attempted ad play in a given day.
For the latest session summary data feeds from Conviva, see Conviva Connect.
Audience
SSD is beneficial to many critical business departments, but it's mainly used by:
Business analysts
Operations teams
Research teams
Get Started with SSD Reports
Define Conviva Session
Each row in the Ad SSD file describes an ad session. Conviva defines an ad session as an instance of an attempt to play an ad; the attempt can be an explicit viewer action or an implicit automatic player action. Prior to the release of the new Conviva Timelines Backend (TLB), each session in SSD (line in the log file) had a unique session ID, which could be used as the primary key. After the release of TLB, a session that is suspended and resumed will appear in different lines in the SSD log file with the same session ID. Each session line has a respective start time, with the first portion of the session showing the session start time and the second portion of the session showing the session resume time. In this case, the primary key to process the sessions is Session ID + Session Start Time.
How to use SSD Fields
We have summarised all the fields in a table, please review the SSD field definitions at the end of this document. You can use the SSD field data to:
filter against a particular metadata field in the SSD file, to identify issues or patterns in a set of ad sessions.
filter against a particular ad SSD metric across one or many days.
calculate key experience and engagement metrics (see Calculate Metrics).
define and shape business KPIs (see Define KPIs).
analyze viewer usage / consumption patterns: by tracking how users are engaging with ads, you can research trends and patterns within viewing habits. This information can be used in ad licensing or production decisions.
You can also define custom metadata to focus your queries on your specific business needs. This processed information is intended for analysis using a third-party tool.
Get the SSD Reports
The most common method of delivery is via FTP, SFTP protocol or our customer's S3 bucket. With FTP/SFTP/S3, storage and retention is controlled by your specific policy. We deliver the file daily within 24-48 hours of the end of the day, based on the time-zone specified in your Experience account.
The SSD file format is CSV (comma-separated values). We use the standard described in RFC 4180.
The SSD file name is in the format: AdSessionLog .csv
Each SSD file is paired with a manifest file, with the same name, but with a .manifest extension. The manifest file (view manifest sample with any text editor) provides all the metadata relating to the specific SSD report.
Tools to Use
Typically users load SSD into a database such as MySQL or into analytics tools such as Tableau or Micro Strategy, to analyze the data and correlate with other data sets. Please see examples at the sample SQL queries provided for some of the metrics.
def decode_pct_encoding(s):
import urllib.parse
if s is None:
return "Unknown"
else:
return urllib.parse.unquote_plus(s)
spark.udf.register("decode_pct_encoding", decode_pct_encoding)
Conviva Metrics and KPIs
Metrics Guidelines
SSD reports are used to calculate Conviva metrics based on historical session data. Please note some important guidelines to assist you with your calculations.
Lifetime and Interval Metrics
In this document we focus on metrics shown in Ads. Each SSD file provides lifetime metrics, which is a snapshot of the entire duration of the session up to that point. If a session spans days (crosses the midnight boundary in the account’s timezone), that session will appear in many SSD log entries: the first SSD log will be the session metrics for the first day (until midnight); the following day’s SSD log will include the complete session up to that point (from when it started the previous day); the third days' logs will include the data for three days. This is by design.
With SSD data, frequently you want to aggregate data based on a set of sessions, for a particular time period (that is, all ad playing time across all sessions for a specific date). To achieve that, we use interval metric calculations and we provide some examples how to calculate those from the SSD lifetime metrics.
SSD and SQL fields
In addition the default fields in SSD, we created three additional fields for the SQL calculations in the How to Calculate Metrics (with SQL examples) section:
client ID: from the Conviva Ad Session ID, we isolate the client ID by using the first four segments. For example, the Client ID is highlighted in blue:**8025681:1708681910:125006299:1630859473:4109428019. In the SSD reports, this is available under the 'device_id (Conviva_device_id)' column.
session ID: from the Conviva Ad Session ID, the session ID is the 5th segment, highlighted in red: 8025681:1708681910:125006299:1630859473:4109428019.
ssd_date: when you load multiple SSD logs at a time, this field helps isolate a specific date as it is the date on which the SSD was generated. The SSD file name is in the format: DailySessionLog_
_ .csv, so the format for ssd_date is YYYY-MM-DD. Use ssd_date in your SQL queries to translate it into a column in your database to identify which session reported on what date.
Please note that for the SQL calculations, we defined an alias for every SSD field. That is shown in the third column in the SSD field table.
- Metrics
Ad Delivery Metrics:
Ads Metrics:
Ad Completion Metrics:
- KPIs
Startup
Startuptime >= 0 AND playing time = (number) AND no error code, corresponds to a successful play.
Startuptime = -1 AND playing time = 0 AND an error code, corresponds to a ASF.
Startuptime = -1 AND playing time = 0 AND no error code, corresponds to an EBAS.
Quality KPI: Successfully started sessions
StartupError = 0 and bufferingtime > 0 => Pass
StartupError 0 or playing time Fail
Quality KPI: Sessions with Startup Time below acceptable threshold
StartupTime Pass
StartupTime > Threshold => Fail
Quality KPI: Sessions Played with an acceptable bitrate
AvgBR >= Threshold => Pass
AvgBR => Fail
Quality KPI: Sessions Played with acceptable buffering ratio
(bufferingtime / bufferingtime + playingtime) * 100 => Pass
(bufferingtime / bufferingtime + playingtime) * 100 > Threshold => Fail
How to Calculate Metrics (with SQL examples)
Ad Attempts
Definition: All attempts made to play ads.
Attempts = Count (Unique (convivaadsessionid))
Calculating interval based metric: no additional steps are needed to calculate interval based metrics for a given day.
SELECT count(*) AS attempts,
FROM CompanyX WHERE ssd_date = 2018-02-20
Definition: The sum or a percentage of the cumulative ended ad creatives that terminated with a playback failure error in the selected time period.
Sessions with Playback Error = 1 represent Ad Playback Failures (APF). The SSD field error list, lists all the error messages received from the client, for ad sessions that ended due to a APF.
Ad Playback Failure = True if (playback_error = 1)
Average Ad Playback Failures (APF) % can be aggregated using the calculation below:
Average APF % = ∑ Count ( APF ) / ∑ Count (EndedPlays)
Calculating interval based metric: when calculating interval based metrics (for the day) APF needs to be adjusted by removing any start failures associated with ads that started on the previous day:
SELECT Interval_attempts AS attempts,
(ASF/Interval_attempts)*100 as ASF_pct,
FROM (
SELECT
count(*) AS Interval_attempts,
SUM ( case WHEN (startup_error>0 and playingtime=0) then 1 else 0 end) as ASF,
FROM CompanyX WHERE ssd_date = 2018-02-20 )a
Ad Startup Time
Definition: Ad Startup Time is the number of seconds between the start of the Conviva monitoring starts and the first played ad frame. We exclude any time trying to play an ad or playing non ad related content.
Average Ad Startup Time (AST) can be aggregated using the Plays metric, as follows:
Average AST = ∑(startuptimems) / ∑(Count (plays)
Calculating interval based metric: to calculate Ad Start Time for a specific day, remove any start times associated with sessions that started on the previous day. Please see SQL below for details:
SELECT
ROUND(SUM(a.jointime -NVL(b.p_jointime,0) )/ count(1)
) AS VST_ms
FROM (
SELECT playingtime,
bufferingtime,
convivaadsessionid,
startuptime as jointime,
starttime,
ssd_date
FROM CompanyX WHERE ssd_date = 2018-02-20 AND startuptime !=-1) a
LEFT outer JOIN (
SELECT r. convivaadsessionid AS prior_session_id,
r.bufferingtime AS prior_buffering_time_ms,
r.playingtime AS prior_playing_time_ms,
r.startuptime as p_jointime,
r.starttime as p_starttime
FROM CompanyX r
WHERE r.ssd_date = 2018-02-19 ) b
ON (a.convivaadsessionid = b.prior_session_id and a.starttime = b.p_starttime)
where a.playingtime >0 and a.jointime >0
Ad Startup Failures (ASF)
Definition: Ad Startup Failures occur when an ad fails to play and generates an error code. The error codes indicate the nature of the failure.
Sessions with Startup Error = 1 represent Ad Startup Failures (ASF). The SSD field error list, lists all the error messages received from the client, for ad sessions that ended due to a ASF.
Ad Start Failure = True if (startup_error = 1)
Average Ad Start Failures (ASF) % can be aggregated using the calculation below:
Average ASF % = ∑ Count ( ASF ) / ∑ Count (Attempts)
Calculating interval based metric: when calculating interval based metrics (for the day) ASF needs to be adjusted by removing any start failures associated with ads that started on the previous day:
SELECT Interval_attempts AS attempts,
(ASF/Interval_attempts)*100 as ASF_pct,
FROM (
SELECT
count(*) AS Interval_attempts,
SUM ( case WHEN (startup_error>0 and playingtime=0) then 1 else 0 end) as ASF,
FROM CompanyX WHERE ssd_date = 2018-02-20 )a
Ads Metrics
Ad Impressions
Definition: Ad impression shows the number of ad sessions where at least one ad frame was displayed.
Impressions are calculated as all attempted sessions that didn’t have a failure like ASF or EBAS ie., impressions = attempts - sessions with ASF - sessions with EBAS. Based on your preference, you can use two methods to get Plays:
- Strictly include sessions where at least one ad frame was played: Impressions = ∑ count if (playingtime >= 0 )
select count(*) as impression from CompanyX where playingtime > 0
- In some cases, the player may report joined state, but the user might have exited before the first ad frame was played. Joined time is indicated by Ad Startup Time > 0. If the session joined but we don’t have the actual join time, we display -3 for Ad Startup Time (instead of null). Therefore, for Ad Impressions calculations, you can include sessions where Ad Startup Time is –3 and Playing Time is > 0. See also FAQ. Impressions = ∑ Count if ( startuptime >= 0 | ( startuptime == -3 & playingtime >= 0 ))
SELECT count(*) as impression
FROM CompanyX
WHERE startup_time >0 or (startup_time = -3 and playingtime > = 0) and ssd_date = 2018-02-2;
Calculating interval based metric: Ad Impressions requires no adjustments.
Ad Rebuffering Ratio
Definition: Ad Rebuffering Ratio shows the percentage of buffering during viewing time. From this metric, we exclude the initial player startup buffering time (before the first ad frame).
Calculating interval based metric: to calculate the Ad Rebuffering Ratio for a day, adjust the Rebuffering Time and Playing Time by subtracting any Rebuffering Time or Playing Time accumulated in the previous day.
SELECT Interval_buffering_time*100/(Interval_buffering_time + Interval_playing_time) as buffering_ratio
FROM (
SELECT
ROUND(SUM(case when a.bufferingtime >30*60*1000 then 30*60*1000 else a.bufferingtime -NVL(b.prior_buffering_time_ms,0) end )/60000) AS Interval_buffering_time,
ROUND(SUM(a.bufferingtime)/60000) AS life_buff_time ,
ROUND(SUM(a.playingtime -NVL(b.prior_playing_time_ms,0) )/60000) AS Interval_playing_time
FROM (
SELECT playingtime,
bufferingtime,
convivaadsessionid,
startuptime,
starttime,
ssd_date
FROM CompanyX WHERE ssd_date = 2018-02-20 AND startuptime!=-1) a
LEFT outer JOIN (
SELECT r.convivaadsessionid AS prior_session_id,
r.bufferingtime AS prior_buffering_time_ms,
r.playingtime AS prior_playing_time_ms,
r.startuptime as p_startuptime,
r.starttime as p_starttime
FROM CompanyX r
WHERE r.ssd_date = 2018-02-19 ) b
ON (a. convivaadsessionid = b.prior_session_id and a.starttime =b.p_starttime)
where a.playingtime>0
) Tmp
Ad Average Bitrate
Definition: This metric shows the average bitrate of a delivered ad, across the entire audience, in a given time frame.
The calculation below shows the aggregate for the Average Bitrate for a set of sessions:
Calculating interval based metric: to calculate the Average Bitrate for a day interval, adjust the Playing Time by subtracting any Playing Time accumulated in the previous day.
SELECT Interval_bytesloaded/(Interval_playing_time) AS bitrate,
life_bytesloaded/life_playing_time as lifebitrate
FROM
(
SELECT
ROUND(SUM(a.bytesloaded -NVL(b.prior_bytesloaded,0) )) AS Interval_bytesloaded,
ROUND(SUM(a.bytesloaded )) AS life_bytesloaded,
ROUND(SUM(a.playingtime )) AS life_playing_time,
ROUND(SUM(a.playingtime -NVL(b.prior_playing_time_ms,0) )) AS Interval_playing_time
FROM (
SELECT playingtime,
averagebitrate*playingtime as bytesloaded,
convivaadsessionid,
startuptime,
starttime,
ssd_date
FROM CompanyX WHERE ssd_date = 2018-02-20 AND startuptime!=-1 and playingtime>0 and averagebitrate>0) a
LEFT outer JOIN (
SELECT r. convivaadsessionid AS prior_session_id,
r.playingtime*r.averagebitrate AS prior_bytesloaded,
r.playingtime AS prior_playing_time_ms,
r.startuptime as p_startuptime,
r.starttime as p_starttime
FROM CompanyX r
WHERE r.ssd_date = 2018-02-19 and r.playingtime >0 and r.averagebitrate>0) b
ON (a. convivaadsessionid = b.prior_session_id and a.starttime =b.p_starttime)
) Tmp
Exits Before Ad Start (EBAS)
Definition: Exits Before Ad Start measures the number of viewing attempts that were terminated, typically by the viewer, before the ad started. If an error is not generated, we count the failed attempt as an EBAS.
Sessions with Startup Time = -1, and Startup Error = 0 represent Exits Before Ad Start (EBAS). An EBAS is similar to a ASF (it is a failure to play an ad), but an EBAS does not include a descriptive error message.
Exit Before Ad Start (EBAS) can be aggregated to any grouping by using the number of attempts as the weighting factor.
EBAS = True if (( startuptime == -1 ) && (startuperror == 0) && (playingtime == 0))*
Calculating interval based metric: The SQL shows the EBAS adjustement for interval calculations, by removing any start associated with sessions that started the previous day:
SELECT Interval_attempts AS attempts,
(EBAS/Interval_attempts)*100 as EBAS_pct
FROM (
SELECT count(*) AS Interval_attempts,
SUM( case when (startup_error = 0 and playingtime = 0 and startuptime = -1)
then 1 else 0 end) as ebas
FROM CompanyX WHERE ssd_date = 2018-02-20 )a
Ad Frequency/Unique Devices
Definition: The Ad Frequency/Unique metric is calculated by dividing the total number of Ad Ended Plays by the number of Unique Devices that played at least one ad. An increasing or higher number indicates that viewers watched more ads. Playing too many ads may impact viewer engagement.
SELECT (T1.Count / T2.Unique) as adFreqUnique
FROM (SELECT COUNT(*) As Count
FROM CompanyX WHERE startuptime != -1 and ended_status > 0 T1,
SELECT COUNT(DISTINCT convivacontentsessionid ) As Unique FROM CompanyX WHERE startuptime != -1 T2)
Session Duration
Definition: Session duration is total time we have been monitoring the session.
The total duration of the session and can be approximated as:
Bandwidth
Definition: To calculate the session's total MB played, you can use the below calculation:
Ad Completion Metrics
Ad Ended Plays
Definition: The Ad Ended Plays metric counts the viewing sessions that ended during the selected interval. The session must have at least one viewed ad frame to count toward the Ad Ended Plays metric. This metric counts only viewing sessions that played and ended.
adEndedPlays = ∑ count if (( playingtime >= 0 ) && (ended_status < 0))*
SELECT count(*)
from CompanyX a
WHERE a.ended_status > 0 and a.playingtime > 0
Completed Ad Creative Plays
Definition: The sum of ad creatives that successfully played at least 90% of the ad content.
SELECT (t1. completedPlays / t2. impression ) AS compAdPlays
FROM (
SELECT count(*) AS completedPlays
FROM (
SELECT (playingtime / contentlength) AS compAdCreative
FROM CompanyX WHERE compAdCreative > 0.90 )) T1 ,
(
SELECT count(*) as impression
FROM CompanyX where playingtime > 0) T2
Ad % Complete
Definition: We calculate Ad % Complete by dividing the total playing time for all sessions by the total content length. We don’t count the playing time for sessions where the content length isn’t available.
To calculate an interval based metric:
SELECT PlayingTime/ContentLength
AS percentage_complete FROM
(SELECT SUM('playingtime') as PlayingTime, SUM('contentlength') as ContentLength
FROM compnayX_2018_02_20 WHERE 'contentlength' > 0)
To calculate lifetime based metric:
ELECT PlayingTime/ContentLength AS percentage_complete
FROM (SELECT SUM('playingtime') as PlayingTime, SUM('contentlength') as ContentLength
FROM compnayX_2018_02_20 WHERE 'contentlength' < 0)
Ad Actual Duration
Definition: The total ad creative playing time in seconds divided by the number of ad creatives that played.
SELECT PlayingTime/ContentLength AS percentage_complete
FROM (SELECT SUM('playingtime') as PlayingTime, SUM('contentlength') as ContentLength
FROM compnayX_2018_02_20 WHERE 'contentlength' < 0)
Frequently Asked Questions
- Difference between Ads Dashboard and SSD
There are differences between the data that you see within Ads and what you see in the SSD logs. This is by design, and there are a couple of reasons why SSD and Ads have differences:
- Ads uses real-time, 1-minute or 5-minute interval metrics whereas SSD provides lifetime metrics and can provide a historical 1-day interval. The average between the two gets closer the longer the time window. That is, a 24-hour average results in a better match than a 1-hour average.
- Although Ads and SSD share the same session level sanitization rules, Ads adds additional aggregation logic based on metric calculations. The idea here is for the consumer of Session Source Data to apply aggregation logic based on the desired use case.
Pursuing an exact match between Ads and offline SSD calculations is difficult and often inadvisable, but following the rules below will help make the calculations much closer.
Exclude the following SSD sessions from your calculations for playback metrics (buffering/bit-rate):
- When calculating playtime metrics only use sessions that joined, sessions that didn’t have ASF or EBAS.
- Playing time = 0 and Buffering time is NOT 0.
- You can also specify that any bit-rates over 10 Mbps be ignored ( rare but one of Conviva VSI's current sanitization mechanisms).
Include the following sessions:
Extremely long Buffering Time (but cap this value at 30 minutes).
Calculate overall Buffering Ratio as:**
A Note on Heartbeats:Conviva uses Heartbeats to monitor the ad sessions. Heartbeats continue to be sent while the ad is buffering, unless the internet connection itself has been interrupted and the Conviva library and backend cannot communicate. In this case, the library will continue monitoring and will send a "catch-up" heartbeat when the connection is re-established.
If the ad is paused or the connection is lost for more than 2 minutes, then no heartbeats will be sent and the Conviva back-end will automatically clean-up the session. We do not count paused time, so if the viewer was paused for more than 2 minutes then the session will time out. We still collect heartbeats during rebuffering, so this will not cause an ad session to timeout. However, if the player ends up in what we call a 'zombie state' (incessant/perpetual buffering) then that contributes to Ads and SSD metrics. The only difference is that Ads metrics cap buffering at 30 minutes, whereas SSD has no such cap. Logic in an SSD-analysis tool to account for this difference is necessary to unify Ads and SSD calculations.
- What does AST = -3 stand for?
- it is a resumed session, where there is no start up time; for example, when a user closes the laptop during playback, and resumes later.
- we have flags that indicate the startup time is not reliable.
- Why do I see unexpected ASCII characters in certain fields?
- How do I stitch SSD across multiple days?
- What is the difference between -1 and 0 in Ad Percent Complete?
AST=-3 means we don't have a specific Ad Startup Time. Possible reasons include:
SSD reports are delivered as CSV files. The Session Tags column in SSD is customer defined and can contain arbitrary strings with special characters which could prevent parsing of CSV; therefore we use URI encoding to remove any offending characters. We recommend that you run URI decoding on the "Session Tags" field, by using various libraries that provide this decode functionality (available in all mainstream languages).
The data in SSD is already "stitched" for sessions that span across multiple days. SSD provides lifetime metrics, which means that when a session data spans across many days, the last session record contains the complete details of the metrics for that session. This is a quick mechanism to view SSD session data across multiple sets. Therefore, when combining SSD sessions, overriding earlier sessions with the most recent session provides the most accurate and quick mechanism to stitch session logs.
The value in Percentage Complete is rounded to the nearest integer value. A value of 0 is a rounded value when percentage complete is less than 1%. This covers the occasions when the startup time>0 but the ad only played for a very small period of time. A value of -1 (usually for live content) indicates that we do not receive ad content length.
SSD Field Definitions
This guide provides a comprehensive list of all available SSD columns. You can customize your SSD reports to include only the columns you need for your metrics. Please contact Conviva Customer Support to add or remove columns from your reports.
| Field Name | Name in SSD File | Alias (for query examples) | Data Type | Description |
|---|---|---|---|---|
| ViewerId | viewerId | viewerId | String | Unique identifier of the viewer (sometimes called subscriber) watching content in that session. This is typically a number, or a hashed/masked identifier without any personally identifiable information. The same ViewerId can have multiple sessions. If no viewer id is available (from Conviva SDK integration), we use the device public IP address (except in EU, due to privacy laws). |
| Conviva Session ID | Conviva_content_session_id | convivasessionid | String | Unique Conviva session identifier in this format: five integer numbers separated by a colon (:). Client ID is part of the Conviva session id - the first 4 blocks of the numbers separated by : represents client id. For example: Conviva session id value = "20048757:2397552430:4151350518:1876058113:4487054" then client id = 20048757:2397552430:4151350518:1876058113 & session id = 4487054 |
| Device/OS | device/os | deviceos | String | Device Operating System |
| Device Id | device_id(Conviva_device_id) | deviceID | String | Conviva unique device (app) identifier - 4 integers separated by colons (:) |
| Browser | browser | browser | String | Name of the browser used by the viewer's device. If no browser is involved in the streaming, such as with a mobile app or connected TV, the value will be "Non-Browser Apps." |
| Country | country | country | String | Country Name |
| State | state | state | String | State Name (geography, like California) |
| City | city | city | String | City Name (geography, like San Francisco) |
| Start Time | start_time | starttime | Integer (unix time) | The time when Conviva received the first heartbeat for the ad session. The format is Unix epoch time in seconds. |
| Startup Time | startup_time(ms) | startuptime | Integer | Time in milliseconds between the start of the Conviva monitoring and the first played ad frame. Note: For Server Side Inserted ads, the startup time may be very small. |
| Content Length | planned_duration(ms) | contentlength | Integer | The planned duration of the ad in milliseconds (ms). If not available, then set to -1 |
| Playing Time | actual_duration(ms) | playingtime | Integer | The actual play duration of the ad in milliseconds (ms). The duration excludes any buffering time. If not available, set to -1 |
| Buffering Time | buffering_time(ms) | bufferingtime | Integer | This is the duration of rebuffering time during the ad session. It does not include the initial buffering at startup. In ConvivaVSI, we display rebuffering as a percentage of the total viewing experience. |
| Average Bitrate | average_bitrate(kbps) | averagebitrate | Integer | Average bitrate at which content was delivered during the session. The ability to determine bitrate depends on the player integration. Not all players are capable of delivering bitrate information. |
| Startup Error | startup_error | startup_error | Integer | If value = 0 then ad played and there was no startup error. If value = 1 then ad failed to play and there was a startup error (see Error list). |
| Error list | ad_error_list | errorlist | String | A list of fatal errors that occurred during this ad session, separated by "&". A session with Startup Time = -1 and Playing Time = 0 and no error list, corresponds to an Exits Before Video Start (EBAS). |
| Session Tags | ad_session_custom_tags | sessiontags | String | Session tags are player metadata that are defined when you integrate your player with Conviva. Each tag describes a piece of information that your player sends to Conviva. You can choose which of the available tags you want to include in SSD and the Ads Viewer Module. You can have a unique set of tags based on your players and business needs and your Conviva Solutions Consultant can assist further with your list. While the player can send many tags, your account can have up to 10 active tags for use with SSD. Tags are key-value pairs in this format: key1=value1&key2=value2 Example: cluster.name=production&protocol.type=cws |
| Conviva Ad Session ID | Conviva_ad_session_id | convivaadsessionid | String | Unique Conviva session identifier for the ad session that is attempting to play. The format is five integer numbers separated by colons (:). Client ID is part of the Conviva session id - the first 4 blocks of the numbers separated by : represents client id. For example: Conviva session id value = "20048757:2397552430:4151350518:1876058113:4487054" then client id = 20048757:2397552430:4151350518:1876058113 & session id = 4487054. The Client ID (4 integers) is shared between Video sessions and ad sessions (for ads that play in the video session). |
| Session End Time | end_time(unix_time) | endtime | Integer (unix time) | The time we received the last hearbeat update from this session. |
| Session Ended Status | ended_status | endedstatus | Integer | An integer showing the status of the session for that SSD: 0 = Not Ended; at the SSD issue time, the session is still active. 1 = Gracefully Ended; the session ended with a session ended event. 2 = Expired due to lack of heartbeat update; we received no heartbeat update for 2 minutes. |
| Ad Technology | Ad_Technology(c3_ad_technology) | adtechnology | String | Used to identify whether the ad is client side or server side stitched |
| Ad Title | Ad_Title(assetName) | adtitle | String | Name of the ad |
| VAST Ad System | Ad_System(c3_ad_system) | adsystem | String | The name of the ad server, such as DFP or Google Ad Manager |
| VAST Ad ID | Ad_Id(c3_ad_id) | adid | String | The Ad Id or Line Item against which the ad impression is counted |
| VAST Creatives Creative ID or UniversalAdId | Ad_Creative_Id(c3_ad_creativeId) | adcreativeid | String | The Id of the Ad Creative |
| Ad Position | Ad_Position(c3_ad_position) | adposition | String | The position in which the ad plays, for example, Pre-roll or Mid-roll. |
| Ad Type | Ad_Slate(c3_ad_isSlate) | adslate | String | Set to 1 if a default media file rather than an ad plays. Primarily used for Server Side Stictched ads on Live streams |
| VAST mediaFileApiFramework | VPAID(c3_ad_mediaFileApiFramework) | admediaapiframework | String | Set to "VPAID" if a VPAID ad creative plays (generally client side ad) |
| VAST Ad Sequence | Ad_Sequence(c3_ad_sequence) | adsequence | String | The number of an ad within an ad break. The first ad in an ad break/ad pod will be 1, the next 2 etc. Only available if the application integration passes in this data |
| First Ad System for Wrapper | First_Ad_System(c3_ad_firstAdSystem) | firstadsystem | String | Relevant for wrapper (3rd party redirect) ads. capture the "first" Ad System in the wrapper chain |
| First Ad Id | First_Ad_Id(c3_ad_firstAdId) | firstadid | String | Relevant for wrapper (3rd party redirect) ads. capture the "first" Ad ID in the wrapper chain |
| First Ad Creative Id | First_Ad_Creative_Id(c3_ad_firstCreativeId) | firstadcreativeid | String | Relevant for wrapper (3rd party redirect) ads. capture the "first" Ad Creative ID in the wrapper chain |
| Ad break Id | Ad_Break_ID(c3_ad_breakId) | adbreakid | String | The ID of the ad break in which the ad played |