Data Strategy
There are two categories of data that we think about when building games. Telemetry is data about how the user experiences the game. This may include timing information, content exposures, correct/vs incorrect responses, and other key interactions that allow stakeholders to make inferences about the user’s skill mastery and app usability. Telemetry is sent out by the game but not read back. Filament typically works closely with clients to determine the appropriate telemetry storage mechanism, protocol, and schema. We have experience with a wide variety of custom, commercial, and open-standards based systems such as Canvas, Google Analytics, xAPI, and SCORM.
The second category of data is state. State represents the user’s progress through the game and needs to be persisted so that the user can engage meaningfully across multiple sessions. The simplest approach is to persist the state locally on the user’s device. This is sufficient for certain casual or at-home usage scenarios. However, based on the RFP, we will most likely want to remotely persist the state. As with telemetry, there are many options for custom or commercial off-the-shelf state persistence and synchronization systems. For example Google Firebase Cloud Firestore and Amazon AWS AppSync both support robust offline/online models. However, there are ongoing hosting fees for using those services. If it’s determined that the custom route is better, we will work with Marsico’s web developer to define the API for storing and retrieving state and tying it with the user’s identity in a privacy compliant fashion. In this case Marisco would be responsible for building the API itself and maintaining any servers as required.
Confidentiality
There are several strategies that we use when designing the information architecture for our games that embed state-of-the-art privacy practices in a way that doesn’t rely on the developers or QA to enforce. In the case of our industry, the types of data that we want to protect typically fall under the category of Personally Identifying Information (PII). This includes names, emails, phone numbers, addresses, and ID numbers, as well as other domain-specific information.
Data Classification. In the classifications phase, we analyze the proposed design and classify information to be collected. Unless a piece of data can be proven to be non-identifying it is assumed to be identifying, since multiple non-identifying data points about one user can still lead to identification through various modern statistical techniques. This informs our approach for the next step.
PII Reduction. In the reduction phase, we assign a business value to the PII elements. If it doesn’t have mission critical business value, that element is eliminated from the design or restricted to a less identifying form. For example, most teachers can identify their students via first name and last initial. So there is no reason to collect a student’s full first and last name. If we must store location information, it may be acceptable for business to use city, state, or zip code, instead of exact coordinates.
PII Segmentation. The last step is to design the architecture to store PII in a completely separate database from all other data. This makes it easier to secure and audit access to PII. When possible, we prefer to use a known public and trusted identity provider such as Google, Microsoft Azure Active Directory, Okta, AWS Cognito, or other similar service. They specialize in safeguarding user account data so that we can more feasibly manage the security risk on modest project budgets. If a custom solution is required, we typically recommend using OAuth 2-based schemes, JWT tokens, and relying on verified widely-used implementations of those. Of course encryption in transit and at rest is a must, which is another reason to use an established identity provider that already enforces encryption.
More educational game development insights: