Projects are the main way Countly keeps data apart. Each project collects its own data, and you analyze it separately from every other project. If you have products with different user bases, such as two different mobile games, create a project for each game and send each game's data to its own project.
Not every situation is this clear cut. What if two of your products share the same user base? What if you have mobile and web versions of the same product? Or what if you want to split the data of a single product?
Take an example where you have one web application, one iOS application, and one Android application. To decide how to structure them in Countly, ask these questions:
-
Are the applications logically similar? Do they give access to similar services (such as web banking and mobile banking), or belong to the same product?
- If the answer is yes, continue with questions 2 and 3.
- If the answer is no, we recommend separate projects for logically different applications.
-
Do the three applications share a single user identifier, such as an email address or an account number?
- If the answer is yes, use a single project.
- If the answer is no, keep the three applications in separate projects, since they do not share a common user identifier.
-
Do different teams need access to these applications?
- If the answer is yes, use three separate projects whatever your answer to question 2, because Countly grants access per project.
Apart from these questions, we recommend giving the testing, QA, and production versions of your applications separate projects, so that test data does not clutter your production projects.
To learn how to create and manage projects, see: