Data privacy considerations
Answer the most commonly asked questions about data privacy on PuzzleMe
Introduction
The Amuse Labs PuzzleMe™ platform is embedded in websites using an iframe model. This document explains the privacy considerations of using PuzzleMe on a Partner’s website. An Amuse Labs Partner refers to the owner of the website embedding the smart games hosted by PuzzleMe. A user refers to an end user/ player who plays the games hosted by the Partner.
Collection
How does PuzzleMe identify users?
PuzzleMe identifies a user via one of two methods:
(a) By a uid parameter passed to the PuzzleMe iframe by the container page. We recommend the Partner to set this to an irreversible function of the string which is normally used to identify their users, such as a CRM ID, login id or first-party cookie. The Partner should ensure this uid is opaque, i.e., the uid is not linkable by Amuse Labs to the user’s original identifier. Once assigned to a user, the uid should not change. If it does change, users will lose their play state, because the uid is the only way for PuzzleMe to identify them.
If a hash function is being used to generate this uid, two further considerations are to use a strong, one-way hash function, and to ensure that the same function is used on different platforms (web, mobile, etc.) so a user has the same uid across platforms.
(b) if a uid is not passed to the iframe, then PuzzleMe uses a randomly generated uid which is stored in the browser as a cookie for the domain cdnx.amuselabs.com. The only way to re-identify such a user is if they revisit the site from the same browser and the browser still has the cookie available.
We recommend the first method (a) because it avoids any problems with browsers restricting third party cookies (which has become increasingly common), and it allows users to carry their identity between browsers or devices. The rest of this document refers to the uid generated by either of these two methods.
What information does PuzzleMe collect?
The PuzzleMe server database collects information on complete and incomplete plays by each user who visits a picker and/or a puzzle. The primary user tables in this database are: (a) A picker-loads table containing information on each load of a picker, including the uid of the user who visited the page, the user’s browser, the time of load, the state in the picker load cycle that they reached (such as whether an ad was shown and for how long), etc. (b) A plays table containing information on each puzzle play. A puzzle play is identified by a unique combination of a puzzle and a uid. For each puzzle play, this table stores information on the uid, the puzzle played, how many times the user has loaded this specific puzzle, the time of last update, the user’s browser, the number of times the puzzle was printed, and the state of the puzzle, such as the state of the user’s grid, the user’s timer value, and other metrics of user interaction. (c) A user preferences table that stores sticky user play preferences (set in the settings dialog), e.g., whether to skip to the next word when the user finishes typing in a word. Rows in this table are identified by the uid.
What logs are collected and why?
In addition to the database, the PuzzleMe server logs incoming requests (along with the client IP address). These logs are collected for two purposes: tracking any malicious attacks on the servers or to debug problems at a low level.
Purpose
Why is this data needed?
The data under points (a), (b) and (c) above are used for the following reasons: (a) is used to record the load by a user to the picker page and for billing purposes. (b) is used to save the state of a play so that if the same uid (user) returns to a puzzle, they can see the state of the puzzle as they last left it. We consider this feature essential because a common reason for support calls is a user losing the state of a puzzle. This occurs if a user cannot be identified for some reason. (c) is used to save user preferences so that the user settings can be restored if a user with the same uid revisits the page. We consider this important, but less essential than (b).
(a) and (b) are also used to generate analytics reports for the Partner.
Who owns the data?
The Partner owns the data. In GDPR terms, Amuse Labs is a data processor, handling data on the Partner’s behalf.
Does Amuse Labs anticipate using the data for any of its own purposes?
We don't use the information other than for tracking the app usage metrics for Partners, and generating analytics reports for them.
Processing
Can any of this data collection be turned off?
Currently, it is not possible to turn off logging. All data items listed in (a), (b) and (c) described above are stored in the PuzzleMe database, and not storing them isn’t possible.
How long is user data retained in the PuzzleMe backend?
The database is expected to keep the plays for three months since the last time the user visited the puzzle, allowing users to retrieve puzzles played in this time window. Older plays are not guaranteed to be kept, but may occasionally be kept longer than this time based on a database purge cycle. Typically, data is not retained for more than 6 months.
The logs are removed from PuzzleMe servers from one month of creation.
Is any data stored in the user’s browser?
A cached subset of the game play state is also saved as an item in the local storage of the user’s browser.
Do you use any third party processors, and do you share any data with them?
We currently use Linode (owned by Akamai) and Google Cloud Platform for cloud hosting services and Google Analytics (GA) for general analytics.
The puzzle player sends a record of user interaction with on-screen elements to GA. Any UX exceptions are also recorded in GA. We use GA to understand general analytics, including how many users are live on the site, trends over time, usage of UX elements, etc.
If needed, GA can be disabled entirely for all the users of a Partner with a setting in the PuzzleMe backend. This can also be done on a per-series basis. Currently, a per-user GA opt-in/opt-out is not possible. A user’s request to opt-out of GA will have to be supported explicitly by the Partner by providing us an additional, unique URL parameter for that user on every iframe load.
What data quality standards does Amuse Labs implement?
(a) We have verified every data element being collected has relevance to a specific purpose. (b) We may limit the collection of a specific data element if absolutely necessary.
What data accuracy standards does Amuse Labs implement?
We analyze monthly analytics reports for any evidence of inconsistent, incomplete and inaccurate data. We also have assertion/invariant checks in our codebase that will flag any unusual or anomalous situations. We regularly monitor these warnings to ensure we know about any unusual events.
What steps has Amuse Labs taken to ensure that data are kept in a form that allows identification of individuals for no longer than is necessary for the purposes for which the data are processed?
We have taken strong measures to not keep identifiable data on our servers at all. An opaque identifier is used for all user communication with the server.
Can Amuse Labs facilitate the exercise of data subject rights?
We can delete data for any uid that is provided to us by a Partner. If there are multiple uids associated with a user, we will depend on the Partner to ensure that all those uids are provided to us. Given a uid, we can also provide available data for that uid in a CSV form upon request. Our Data Privacy Officer can be contacted at dpo@amuselabs.com.