Before you set up data destinations to load user-level data into your database or platform, learn about the different data schemas Singular offers.
For general info about Singular data destinations, how they work, and the different types of data that can be exported, see Singular Data Destinations (ETL) FAQ.
When you use Singular data destinations, Singular standardizes data from different sources into the same data schema so you can easily query on it in your database.
Singular offers different data schemas you can choose from. Each schema defines a different set of fields that the Singular data destination will load into your database.
Conversions and Events are available to all Data Destinations customers, while other schemas are premium features. Use the table below to help you choose the data schema that best fits your needs.
Available User-Level Data Schemas
For more information about each field, see Export Logs: Supported Fields. To learn about the different timestamp fields, see Timestamp Meanings and Formats below.
Note: User-Level Impressions are available as a custom schema to S3. For more information, reach out to your Customer Success Manager.
Includes all clicks that were examined to determine the attribution of an install or re-engagement.
etl_record_processing_hour_utc
adjusted_timestamp
adjusted_timestamp_unix_utc
affiliate_id
affiliate_name
app_longname
app_version
arguments
attribution_event_timestamp
attribution_event_timestamp_unix_utc
bid_type
campaign_id
campaign_name
city
click_id
converted_currency
converted_revenue
country
creative_id
creative_name
currency
custom_user_id
device_id
device_id_type
install_source
ip
is_fingerprinted
is_reengagement
is_revenue_receipt_included
is_revenue_valid
is_view_through
name
os_version
partner
passthrough
platform
product_category
product_name
product_price
product_quantity
product_sku
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
received_revenue
received_revenue_event
revenue
server_timestamp
server_timestamp_unix_utc
session_id
singular_campaign_name
state
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
tag_id
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_nameIncludes information about installs and re-engagement events, who they were attributed to, and other details about the attribution (e.g., was it identifier-based or probabilistic).
Note: The location provided for the conversion event is based on the IP from where it was triggered - not on any location detected internally in your app or any user-provided information. If you have another source of location data for the event, you can check it by reading the passthrough parameter sent by your app to Singular.
etl_record_processing_hour_utc
affiliate_id
affiliate_name
android_id
android_id_md5
android_sha1
app_longname
app_version
bid_type
campaign_id
campaign_name
city
click_id
country
creative_id
creative_name
custom_user_ids
device_id
device_id_type
device_make
device_model
event_timestamp
event_timestamp_unix_utc
fraud_reason
fraud_status
gaid
gaid_md5
gaid_sha_1
google_click_id
idfa
idfa_md5
idfa_sha_1
idfv
is_fingerprinted
is_reengagement
is_view_through
method
os_version
partner
passthrough
platform
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
singular_campaign_name
singular_partner_name
state
store
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
touchpoint_ip
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_name
waidIncludes data about in-app events, including sessions, registrations, purchases, and any other events that have been defined in the app when integrating the Singular SDK/S2S.
etl_record_processing_hour_utc
adjusted_timestamp
adjusted_timestamp_unix_utc
affiliate_id
affiliate_name
app_longname
app_version
arguments
attribution_event_timestamp
attribution_event_timestamp_unix_utc
bid_type
campaign_id
campaign_name
city
click_id
converted_currency
converted_revenue
country
creative_id
creative_name
currency
custom_user_id
device_id
device_id_type
install_source
ip
is_fingerprinted
is_reengagement
is_revenue_receipt_included
is_revenue_valid
is_view_through
name
os_version
partner
passthrough
platform
product_category
product_name
product_price
product_quantity
product_sku
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
received_revenue
received_revenue_event
revenue
server_timestamp
server_timestamp_unix_utc
session_id
singular_campaign_name
state
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
tag_id
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_nameIncludes data about any postbacks sent by Singular (not just postbacks about attribution decisions). The log includes postbacks to your internal BI (if you've configured them) and to third-party analytics tools.
Tip: When using this schema for troubleshooting, the Response HTTP Code field tells you if the postback was delivered successfully. A 200 code means success; other values mean there was an error. When there's an error in sending, Singular retries the postback 5 more times, in intervals of 1, 5, 15, 30, and 60 minutes. The Response HTTP Body may include additional details about the error.
etl_record_processing_hour_utc
affiliate_id
affiliate_name
app_longname
attribution_country
attribution_event_timestamp
attribution_event_timestamp_unix_utc
campaign_id
campaign_name
click_id
creative
creative_id
creative_name
device_id
device_id_type
event_name
event_timestamp
event_timestamp_unix_utc
http_retries_count
is_attributed_only
is_do_not_track
is_revenue_receipt_included
is_revenue_valid
partner
passthrough
platform
postback_http_body
postback_recipient
postback_sent_timestamp
postback_sent_timestamp_unix_utc
postback_timestamp
postback_timestamp_unix_utc
postback_type
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
received_revenue
received_revenue_event
response_http_body
response_http_code
response_time
singular_campaign_name
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
target_url
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_nameIncludes all the SKAdNetwork postbacks that Singular received from your ad network partners. These postbacks are only available for iOS apps that use SKAdNetwork tracking and for partners who have a SKAdNetwork integration with Singular that involves forwarding postbacks.
Singular also offers aggregated SKAdNetwork data: see SKAdNetwork Raw Data Schemas and SKAdNetwork Data Schemas.
etl_record_processing_hour_utc
app_longname
city
conversion_model_measurement_period
conversion_model_name
conversion_model_types
conversion_model_version
conversion_value
country
decoded_conversion_value
estimated_cohort_period
estimated_conversion_date
estimated_install_date
fraud_reason
fraud_status
ip
is_view_through
max_install_date
min_install_date
partner
partner_campaign_id
partner_campaign_name
partner_creative_id
partner_creative_name
partner_sub_campaign_id
partner_sub_campaign_name
partner_sub_publisher_name
referrer
region
signature
singular_partner_name
skadnetwork_app_id
skadnetwork_campaign_id
skadnetwork_network_id
skadnetwork_publisher_app_id
skadnetwork_redownload
skadnetwork_version
timestamp
timestamp_unix_utc
transaction_id
user_agentThe raw output of the Singular Fraud Prevention System (to learn more, see Understanding Singular Fraud Prevention and the Fraud Reporting and Fraud Logs FAQ).
This data includes a row for every click and impression associated with an install event - including a row for the "organic install" option, which is also examined as an attribution option for every install. Therefore, you may see multiple touchpoints rejected for fraud for one single install. To sort or group together all the clicks and impressions belonging to the same install, use the unique_install_identifier field.
etl_record_processing_hour_utc
app_longname
app_version
creative
device_id
device_make
device_model
fraud_external_reason
fraud_reason
fraud_status
idfv
install_city
install_country
install_ip
install_timestamp
install_timestamp_unix_utc
is_fingerprinted
is_view_through
os_version
partner
platform
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
time_to_install
touchpoint_campaign
touchpoint_city
touchpoint_country
touchpoint_ip
touchpoint_timestamp
touchpoint_timestamp_unix_utc
unique_install_identifieretl_record_processing_hour_utc
affiliate_id
affiliate_name
android_id
android_id_md5
android_sha1
app_longname
app_version
bid_type
campaign_id
campaign_name
click_id
country
creative_id
creative_name
custom_user_ids
device_id
device_id_type
event_timestamp
event_timestamp_unix_utc
gaid
gaid_md5
gaid_sha_1
google_click_id
idfa
idfa_md5
idfa_sha_1
idfv
is_fingerprinted
is_view_through
os_version
partner
passthrough
platform
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
singular_campaign_name
singular_partner_name
state
store
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
touchpoint_ip
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_name
waidetl_record_processing_hour_utc
adjusted_timestamp
adjusted_timestamp_unix_utc
affiliate_id
affiliate_name
app_longname
app_version
arguments
attribution_event_timestamp
attribution_event_timestamp_unix_utc
bid_type
campaign_id
campaign_name
city
click_id
converted_currency
converted_revenue
country
creative_id
creative_name
currency
custom_user_id
device_id
device_id_type
install_source
ip
is_fingerprinted
is_reengagement
is_revenue_receipt_included
is_revenue_valid
is_view_through
name
os_version
partner
passthrough
platform
product_category
product_name
product_price
product_quantity
product_sku
publisher_concatenated
publisher_hashed_id
publisher_id
publisher_name
received_revenue
received_revenue_event
revenue
server_timestamp
server_timestamp_unix_utc
session_id
singular_campaign_name
state
sub_campaign_id
sub_campaign_name
sub_publisher_id
sub_publisher_name
tag_id
touchpoint_timestamp
touchpoint_timestamp_unix_utc
tracker_nameAppendix: Timestamp Meanings and Formats
Tip: Singular provides several timestamp fields for each row of data. Most timestamp fields have two versions, e.g., "event_timestamp" and "event_timestamp_unix_utc".
- Fields ending in _timestamp are formatted as a timezone-aware timestamp column in database destinations, and as a timestamp with timezone information for file-based destinations (S3/SFTP/GCS).
- Fields ending in _timestamp_unix_utc contain the time in UNIX timestamp format (integer) in UTC.
| Timestamp Field | Description |
| etl_record_processing_hour_utc | The time in which the data was fully processed by Singular. This may be later than the time of the event or the server timestamp. Every hour, Singular updates this value for data that was fully processed during the previous hour. |
| Attributions | |
| event_timestamp event_timestamp_unix_utc |
The time in which the attribution event (e.g., the install) happened on the device. |
| touchpoint_timestamp touchpoint_timestamp_unix_utc |
The time of the touchpoint (ad click or ad impression) that led to the attribution event. |
| Events | |
| adjusted_timestamp adjusted_timestamp_unix_utc |
The time in which the event actually happened on the device. |
| server_timestamp server_timestamp_unix_utc |
The time in which the event was received by Singular servers. Note: this may be significantly different from the adjusted_timestamp if there was a technical delay in sending the event data. |
| attribution_event_timestamp attribution_event_timestamp_unix_utc |
The time in which the attribution event (e.g., the app install) happened on the device. |
| touchpoint_timestamp touchpoint_timestamp_unix_utc |
The time of the touchpoint (ad click or ad impression) that led to the attribution event. |
Changing the Data Schema
Once you create and save the data destination, you cannot switch to another data schema. This is because changing the table structure in a live database with existing data comes with a number of dangers and complications.
If you need a data schema change, simply create a new destination. You can either delete the old table before creating the new destination or configure the new destination to load data to a new table with a different name. This process will ensure that your data stays safe and existing queries and work-loads continue working.
