Data Handling Details

The Marketing Analytics product is made with data protection by design as a guiding principle throughout the product. We strive to always collect the minimum information necessary for us to deliver you the insights you need. With that in mind, this document's goals is to outline the various data protection policies we have in place and controls that you have to manager how we process data.

System Overview

Below you can see an architectural overview of the Marketing Analytics system. It contains multiple sections including both our platform and visualization of how it interacts with some of your existing infrastructure like your Business Intelligence pipelines.

986

Marketing Analytics Architecture Overview

The architecture is split into two major components:

  1. The Control Plane which handles management tasks such as tracker configuration, access control, and goal management.

  2. The Data Plane which handles event ingestion, touchpoint tracking, attribution process, and more.

This separation allows us to implement additional access controls around the potentially sensitive data in the data plane and keeps data from sprawling out into multiple systems.

The second important note is that all fingerprinting data that traverses or is stored in the data plane is hashed on the ingestion server before being transmitted or persisted. This means that at none of the fingerprint data being processed or stored can be converted back into its original form. You can read more about our data hashing practices in the next section.

Data Hashing

The Marketing Analytics system implements a comprehensive approach to hashing device identifiers to protect any potentially sensitive data being passed to the platform.

In both the touchpoint tracking and event measurement data flows, the edge nodes accept the request then:

  1. We run a Geo-location lookup on the IP address associated with the request. This allows us to generate reports based on the countries that your traffic is coming from. Additionally we check the IP against our bot filters so that we can remove automated traffic from reporting.
  2. We optionally truncate the IP address in certain regions (Germany or EU for example) based on your game's security settings, You can read more about these options in the Data & Security settings guide.
  3. Finally, we replace the IP and device identifiers with specially designed hashed fingerprint values before sending the event to be attributed. The fingerprint values are generated by first normalizing the identifiers (IP address, OS, resolution, language, installed browsers, etc) into standardized formats. These identifiers are then SHA-256 hashed in specific combination along with a title-specific 270+ bit pepper value. The hashes vary in specificity from core identifiers all the way up to a full hash of all provided values. These hashes together are described as the fingerprint.

Supported Fingerprint Values

The potential values currently supported in a device fingerprint are as follows:

  • Operating System
  • Screen Resolution
  • IP Address
  • Timezone
  • System Language
  • Useragent

Example Fingerprint

The following is an example of a simple fingerprint containing 2 distinct hashes:

(
  'efd2398f989316fdc56815148acd35c8829c19d2777287d3e8b7404b168568f7',
  '2e5edd4f8dd082232eba884b703035b5c2417a1d4f3ccba329df3s0190ac62a3645b6285981b7ec2991ced3e2b44b8b12deb350a3eacf3f0f7bd242a83718b55'
)

Other Fields

User ID

One potentially sensitive field is the User ID associated with an event. The User ID value is up to your implementation and we do not perform any hashing or anonymization process on it. The requirements for the User ID are listed in the Measurement API Quick Start. In short, we are looking for a unique value that is useful to your team internally when we report back to you using it. So an internal ID, stored UUID, or hashed value are all reasonable options here.

External IDs

For some use cases, console or cross device attribution in particular, we allow external network IDs to be associated with a device. This populates a device graph for your game, so attribution can be performed across device seamlessly. When providing these fields in the Event Measurement API you are allowed to provide the values either raw or pre-hashed.

If the raw value is provided it will be hashed upon ingestion in a similar fashion to what is described above in the Data Hashing section. If you choose to hash the External ID before sending it you it will need to be a SHA-256 hashed normalized value (lowercase, white-space trimmed).


For more information, or help integrating Gamesight, contact us through live chat or email us at [email protected]