Last modified November 5, 2024 by Shelly Wolfe

Raw event data schema

Swrve logs the raw data for your apps to either Amazon S3 or Google Cloud Storage. This article covers the data schema for those raw events. For more information on setting up raw data export to an Amazon S3 or Google Cloud Storage bucket, see our setup guide.

Data schema

The schema the raw event export files follow is:

  • gzip compressed
  • one line of JSON encoded code (each line represents a single event)
  • each line is a JSON dictionary with the following keys: user, time, client_time, type, app_version, payload, parameters, seqnum, version, device_id

Type

type represents the event type sent to the Swrve API. It may be one of:

  • event
  • user
  • purchase
  • currency_given
  • iap
  • session_start
  • session_end

User

user represents the user identifier sent to the Swrve API with the event (or batch of events).

Time

time represents the time recorded on the Swrve server when the event was received. This is an integer that represents the number of milliseconds since the epoch.

Client time

client_time represents the client time sent to Swrve with event. This is an integer that represents the number of milliseconds since the epoch.

App version

app_version represents the app_version identifier sent to the Swrve API with the event (or batch of events).

Payload

payload represents the optional payload information added to the event. payload is a dictionary of string / integer / boolean values.

Parameters

parameters contains a dictionary of data sent to the Swrve API with the event. The dictionary fields depend on event_type. These parameters match the REST API.

Parameter Fields
event name, user_initiated
user attributes, user_initiated
purchase item, currency, cost, quantity
currency_given given_currency, given_amount
iap Platform dependant
session_start None
session_end None

Seqnum, version, device ID

  • seqnumversion, and device_id are internal and are used for debugging.

Campaign events

Swrve campaign events are logged in two formats, generic or custom, depending on the channel and action type in question. Generic campaign events use a common event name, with differentiators for channel, action and campaign ID stored within the event payloads. In contrast, custom campaign events encode the channel, action, and campaign ID within the event name itself. For examples, see Custom campaign event format below. The following table provides a breakdown of channels and actions by format:

Channel Actions in generic format Actions in custom format
Push sent
delivered
influenced
button_click
rejected
engaged
In-app messages page_view
dismiss
navigation
Impression
Click
Embedded campaigns Impression
Click
Geo notifications impression
engaged
button_click

Generic campaign event format

Campaign touchpoints that are tracked as generic Swrve campaign events will have an event name of Swrve.generic_campaign_event and the following JSON format in the S3 raw logs:

{
    "id": "...",
    "campaignType": "...",
    "actionType": "...",
    "contextId":"...",
    "payload": {
        "key1": "...",
        "...": "..."
    }
}

where:

Property Description
id This is the tracking ID of the campaign event.

Use this ID to map the raw data to campaign metadata such as name, dashboard URL and so forth via the Campaign Meta Data API.

campaignType This indicates what channel the campaign has been run on:

  • push
  • iam
  • geo
actionType This indicates the action of the touchpoint being tracked.

See table above for values per channel.

payload
displayed
This indicates if the notification was displayed (true or false).
reason
This provides a reason if the notification is not displayed (false). The possible values include:

  • permission_denied  – the user has disabled notifications for the app.
  • stopped – the SDK stopped tracking user activity (that is, no user was logged in) and the notification was set to only display for identified users.
  • different_user  – the notification was set to display only if the current user ID is the same as the user who was last logged into the app. For more information on authenticated push, see Tracking your users with Swrve User Identity.
silent
This indicates whether the event is associated with a background app update (true) or push notification (false).
delta
The time in minutes between when the device receives the notification and when the user subsequently opens the app.
buttonId
The ID of the button used to dismiss the campaign or navigate between pages in a multi-page campaign.
buttonName
The name of the button used to dismiss the campaign in a multi-page campaign.
pageName
The name of the page the action occurred on.
to
The ID of the page the user navigated to from the current page.

Example event

{
"type": "generic_campaign_event",
"time": 123,
"seqnum": 1,
"actionType": "delivered",
"campaignType": "push",
"id": "1",
"payload": {
"displayed": "false",
"reason": "permission_denied",
"silent": "false"
}
}

Custom campaign event format

Campaign touchpoints that are tracked as custom Swrve campaign events will encode tracking ID, campaign type, and action type in the event name, rather than the payload:

Channel Actions Event name schema
Push Engaged Swrve.Messages.Push-<ID>.engaged
In-app messages Impression
Click
Swrve.Messages.Message-<ID>.impression
Swrve.Messages.Message-<ID>.click
Embedded campaigns Impression
Click
Swrve.Messages.Message-<ID>.impression
Swrve.Messages.Message-<ID>.click

Where <ID> is the tracking ID. Use the raw event name to map from the log entry to relevant campaign metadata such as name, dashboard URL ,and so forth via the Campaign Meta Data API.

Push sent and delivered events

The raw S3 logs also include Push Sent and Delivered events, both in generic campaign event format.

Push Sent events are logged server-side, so are independent of all SDK flavors and require no SDK update. The deciding factor for Push Sent is what type of push.

Push Type Push Sent events logged
Standard Yes
Via API Yes
Quick Yes
Geo-triggered No – impression event logged from SDK

Push Delivered events are logged client-side, so require an SDK update. They are also not supported by all of our SDKs yet.

SDK platform Push Delivered events logged
iOS Yes
Android Yes
Amazon Yes
Unity Yes
Cordova No
Web No

Need help with Queries?
MessageGears support can help you with parsing and ETL of the data schema described above. If you need help with your queries, contact our Data Services team at support@messagegears.com. They will help you get the most out of your data with dedicated support, pre-built and custom reports, and dedicated data science hours.