Account Structure

Definitions

Apps and Projects

• In Taplytics, we consider unique workspaces to be Projects
• We envision projects to be a one-to-one relationship to distinct apps

Per Project Permissions

• Each app/project can have its own unique permission settings and roles
• Different teams and individuals can be given access to and denied access or permissions to specific apps/projects

Three Key Roles

1. Project Owner
2. Project Manager
3. Collaborator

Permission Levels and Capabilities

Project Owner:

• Defines roles and permissions for the project
• Has the ability to provision accounts for other users
• Can create, edit, and publish their own A/B tests as well as tests created by others
• Can create and publish push notification campaigns

Project Manager:

• Can create, edit, and publish their own A/B tests as well as tests created by others
• Can create and publish push notification campaigns
• Can provision accounts for other users
• Cannot define or adjust roles or permissions for the project

Collaborator:

• Can create and edit their own A/B tests, but not publish them.
• Can create and edit their own push notification campaigns
• Cannot publish A/B tests or push notification campaigns
• Cannot edit a live A/B test
• Cannot edit A/B tests created by other users
• Cannot adjust roles or permissions or provision accounts

Account Structure

Project Setup

Projects in Taplytics should be set up around individual apps. Each version of the same app (iOS, Android, Mobile Web, Smartphone and Tablet) should be connected to the same project. Taplytics is designed with staging, development and production differentiation built-in, so we suggest using the same project for all environments.

As a specific example, if an organization has three apps, each with iOS and Android versions, there should be three projects set up in Taplytics.

 

Roles and Permissions

For small teams, we suggest keeping permissions turned off. This will ensure a maximum amount of flexibility and low procedural overhead. Permissions limit what certain users can do, and on small teams, proper training on all aspects of the platform is relatively easy.

For larger teams that require more structure it is suggested that permissions be leveraged, as well as the tiered role system. Taplytics’ roles map to these general organizational roles:

 

Taplytics Role	Organizational Role
Project Owner	Directors, Product Managers, and Product Owners
Project Manager	Engineering, Data, Design and QA Leads
Collaborator	Analysts, Developers, Designers, and Marketers

 

Project Owner

The Project Owner should typically be the person who will be the main point of contact with Taplytics. Generally, this will be the Product Manager, Product Owner, Director of Growth, Director of Analytics, etc. While the Project Owner can be unique for each project, Taplytics does suggest that, for teams with multiple apps, a single user be designated as the Project Owner across all projects. This is suggested because it enables a single view of the entire setup and ensures that process can be applied and enforced consistently across the organization.

 

Project Manager

The Project Manager has all of the capabilities of the Project Owner except for being able to define roles and permissions. Because of this, it is suggested that the Project Manager role is reserved for those in team management positions.

Typically, it is seen that the best fit for Project Managers is Lead Engineers, Lead Analysts, Head of Mobile Design, etc. These people are best suited to the Project Manager role because they are typically entrusted with reviewing experiment and push campaign setup, execution, and having the organizational knowledge to be able to set campaigns live.

 

Collaborator

Collaborators are considered the builders within Taplytics. They will typically be the users that create the experiments and push campaigns, usually, these will be developers, analysts, growth marketers, etc. These users will understand the task at hand for the specific campaign but will need another user to verify an experiment or campaign’s setup before it goes live.