[0001] Computing systems, devices, and electronic components may run or execute applications stored on the systems, devices, or components as machine readable instructions. The applications may be released by software developers in a series of versions, with newer versions of an application introducing new features or functions, and/or including patches to resolve existing errors in the application code. New versions of an application may also introduce unexpected errors upon distribution to users. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG.1 is a block diagram of a system to segment users for a staged application rollout, according to an example;

[0004] FIG. 2 is a flowchart of segmenting users for a staged application rollout, according to an example;

[0005] FIG.3 is a flowchart of determining an early adopter probability, according to an example; and

[0006] FIG.4 is a block diagram of a system to segment users for a staged application rollout, according to an example. DETAILED DESCRIPTION

[0007] Various examples described below provide for a user segmentation system for staged application rollout. In an example, an application usage engine receives data for users including a number of screens used in an application version and a number of user actions used in the application version. A staged rollout engine determines, for each user, an early adopter probability based on the number of screens used in the application version and the number of user actions used in the application version, and in some examples a preconfigured factor or weighting. For a new, updated, or subsequent application version, staged rollout groupings are determined. Users are assigned to staged rollout groupings based on the early adopter probabilities.

[0008] Software development and distribution may be based on a model where incremental versions of a software application may be released to a user, with each new version introducing new features or functions, and/or including patches to resolve existing errors or“bugs” in the application code. With the adoption of downloadable software in particular, users have become accustomed to frequent software updates or upgrades, either in the form of minor updates, e.g., from version 1.0 to 1.1, or in the form of major updates, e.g., from version 1.0 to 2.0.

[0009] Although the distribution or“rollout” of a new version may introduce new features or resolve old bugs, a new version may itself introduce new bugs, compatibility issues, or configuration issues. In some cases, a new feature or bug in a new version may affect the overall stability of the entire application. Similarly, new features introduced in a new version may not function as intended, may be difficult to use, or otherwise may not achieve user adoption.

[0010] Staged rollouts may be used to roll out a new version of an application to, for example, a small number of users as a test prior to releasing the version to all users. In some examples, staged rollouts may include two, three, or an even greater number of groupings, successively releasing a new version of an application to a greater number of users as confidence in the new version grows.

[0011] However, releasing a new version to, for example, a random group of users or a group based on demographic attributes may not result in a test group that is likely to test new features, thereby exposing a potentially flawed new version to a group of users that are not the optimal users to test the new version. An approach that increases the probability that a user in a test segment is a user that will use new features in a new version is desirable. Such users may be referred to as, for example, early adopters. Such an approach may, for example, minimize the exposure of a new version to a smaller number users that will provide more significant feedback and validation than a larger number of random users, thereby reducing the potential impact of a flaw in the new version and improving validation and feedback to developers.

[0012] In an example, collection of user statistics and data relating to, for example, usage and event data for a particular application by a particular user may be used to calculate an early adopter probability for each user. Users may then be assigned to staged rollout groupings in the most effective manner.

[0013] Referring now to the drawings, FIG. 1 is a block diagram of a system to segment users for a staged application rollout, according to an example.

[0014] In the example of FIG.1, user devices such as laptop 102, tablet 104, and/or smartphone 106 (hereinafter“computing devices” or“user devices”) may run or execute applications, which may comprise machine-readable instructions that run or execute on the devices. For example, the applications running on laptop 102, tablet 104, and/or smartphone 106 may be word processing tools, spreadsheet tools, presentation tools, programming tools, communications tools, utilities, games, or other applications.

[0015] In the example of FIG. 1, devices such as servers 108 and 112 (hereinafter “computing devices” or“servers”) may also run or execute applications, including machine-readable instructions. For example, the applications running on servers 108 and 112 may be applications, engines, controllers, circuitry, or modules to monitor or analyze usage of applications running on other devices, or to perform a distribution or“rollout” of software, such as rolling out updated software versions to a plurality of user groups or user segments, e.g., groups of devices such as laptop 102, and/or tablet 104 and smartphone 106, as determined by the applications running on servers 108 and 112. In some examples, servers 108 and/or 112 may run the applications on a software as a service (“SaaS”) framework, or a big data framework.

[0016] Computing devices 102-106 and servers 108 and 112 may include a processing resource and a machine-readable storage medium comprising or encoded with instructions executable by the processing resource, as discussed below in more detail with respect to FIGS. 2-4. In some examples, the instructions may be implemented as engines comprising any combination of hardware and programming to implement the functionalities of the engines or controllers, as described below.

[0017] In examples described herein, such combinations of hardware and programming may be implemented in a number of different ways. For example, the programming for the controllers or engines may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engines may include a processing resource and/or circuitry to execute those instructions. In such examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the engines of systems 108 and 112. In some examples, a plurality of machine-readable storage media and/or processing resources may be used.

[0018] As used herein, a computing device may be a server, blade enclosure, desktop computer, laptop (or notebook) computer, workstation, tablet computer, mobile phone, smart device, or any other processing device or equipment including a processing resource. In examples described herein, a processing resource may include, for example, one processor or multiple processors included in a single computing device or distributed across multiple computing devices.

[0019] In some examples, the applications running on user devices 102, 104, and 106 may include or communicate with a software development kit (“SDK”) or application programming interface (“API”) or other tool for purposes of monitoring usage of applications on those devices. In other examples, the applications running on devices 102, 104, and 106 may be monitored by another device, server, or process, such as an external monitoring tool. In such examples, the external monitoring tool may query the devices directly, such as through a“pull” configuration, or may monitor data exported or transmitted from the devices, such as in a“push” configuration.

[0020] Data monitored on user devices 102, 104, and 106 from applications running on the devices may include data related to screens or actions in the application. As discussed below in more detail, data related to screens or actions may include, for example, a number or percentage of old or new screens used in an application version, and/or a number or percentage of new or old user actions used in the application version. In some examples, historical data from old versions may be archived, fetched, or otherwise accessed or stored such as in a database.

[0021] For example, the data may indicate that a user had used or accessed 4 existing or old screens in version 1.0 of an application, and used or performed 10 old or existing actions or functions in version 1.0, while the same user had used or accessed 2 new screens added in version 2.0 and used or performed 3 new actions added in version 2.0. Such data may also be expressed in percentages, such as that the user had used 50% of old or existing screens in a previous version, or 20% of new screens added in an updated version.

[0022] Screens may be labeled or identified by a unique identifier, such as a serial number, or by a name, such as Home, Login, Settings, or User Management, as examples. Similarly, actions may be labeled or identified by a unique identifier, such as a serial number, or by a name, such as“Tapped on Delete Button” or“Tapped on Save Button” as examples. [0023] Data monitored on user devices 102, 104, and 106 from applications running on the devices may also include data related to the user or the application, such as a user ID, an application ID, an application version, or other data or metadata useful in determining an early adopter probability or a staged rollout assignment for a user. The monitored data may also include event data, such as user interface responsiveness data, network error data, and/or application crash data.

[0024] Data monitored on user devices 102, 104, and 106 may be received, processed, or analyzed on, for example, application usage server 108 and/or in application usage engine 110.

[0025] Data received, processed, or analyzed on, for example, application usage server 108 may be used on the server, or on staged rollout server 112 or staged rollout engine 114 to determine an early adopter probability for a user. As discussed below in more detail, the early adopter probability may be based on, e.g., the number of screens used in an application version or versions and the number of user actions used in an application version or versions, and/or a preconfigured factor.

[0026] For a version of an application, such as a new or updated application to be released, e.g., to user devices 102-106, staged rollout groupings may be determined, e.g. on server 112. For example, a determination may be made that a new application version be rolled out in two segments. In some examples, a developer may desire that a first segment comprise small group of users, such as users that are known to use new screens or actions in an application and can provide a useful test base, while a second segment may comprise a larger group of users who are less likely to use new screens or actions in the updated application.

[0027] Users, such as those associated with user devices 102-106, may be assigned to a staged rollout grouping based on the early adopter probability. For example, if the user associated with laptop 102 is known to have a high likelihood of being an early adopter, user 102 may be assigned to first segment 124. If users associated with tablet 104 and smartphone 106 are determined to be less of an early adopter type than user 102, users 104 and 106 may be assigned to a second segment 126. Segment 126 may receive a new version of an application after segment 124, and in some cases, only after the users of segment 124 have validated or fully tested the new version.

[0028] In the example of FIG.1, user devices 102, 104, and 106, and servers 108 and 112 may communicate over network 116 via, e.g., a network interface device. Network 116 may be a local network, private network, public network, or other wired or wireless communications network accessible by a user or users. As used herein, a network or computer network may include, for example, a local area network (LAN), a wireless local area network (WLAN), a virtual private network (VPN), the Internet, or the like, or a combination thereof. In some examples, a computer network may include a telephone network (e.g., a cellular telephone network). In examples described herein, devices that communicate on network 116 may include a network interface device that may be a hardware device to communicate over at least one computer network. In some examples, a network interface may be a network interface card (NIC) or the like installed on or coupled to, for example, user devices 102, 104, and 106, and servers 108 and 112.

[0029] FIG. 2 is a flowchart of segmenting users for a staged application rollout, according to an example.

[0030] In block 202, monitored user data is fetched. The data may be, as discussed above, data related to screens or actions and may include, for example, a number or percentage of old or new screens used in an application version, and/or a number or percentage of new or old user actions used in the application version. As mentioned above, historical data may also be fetched.

[0031] In block 204, a number of screens used by the user and/or a number of actions used by the user may be analyzed, totaled, summed, or calculated, as examples. In some examples, other data may be fetched or calculated to provide insight as to usage by a particular user or groups of users. For example, a number of screens and/or number of actions may be fetched for other users in the same application, or in similar or different applications, across a single version or multiple versions.

[0032] In block 206, an early adopter probability may be determined for each user. The early adopter probability may be based on the number of screens used by the user and/or a number of actions used by the user, alone or in combination with a preconfigured factor or weighting, as discussed below in more detail with respect to FIG.3.

[0033] In block 208, staged rollout groupings for the application are determined. As discussed above, in an example, a determination may be made that a new application version should be rolled out in 2 segments, while in another example, 10 segments may be used. Such a determination may be fetched from or stored in a preconfigured user segmentation setting.

[0034] In block 210, a user is assigned to a staged rollout group based on the early adopter probability. For example, a user with a high early adopter probability may be assigned to a first grouping that is to receive a new version of an application prior to users with lower early adopter probabilities. Users with lower early adopter probabilities may be assigned to groupings that are to receive the new application version later in time.

[0035] FIG.3 is a flowchart of determining an early adopter probability, according to an example.

[0036] In block 302, an application version is fetched. The version or version number may be used to identify which version data is being collected for analysis. [0037] In block 304, a percentage of screens used in the application version is fetched, and in block 306, a percentage of actions used in the application version is fetched.

[0038] In block 308, a preconfigured factor for usage of screens is fetched, and in block 310, a preconfigured factor for usage of actions is fetched. For example, a preconfigured factor for usage of screens may be 0.6, while a preconfigured factor for usage of actions may be 0.4, each of which may be an input into the calculation of block 312 to weight the value of each.

[0039] In block 312, in an example, an early adopter probability is determined for each user of each version of an application. The early adopter probability may be, in an example, calculated with the percentage of screens used in an application version multiplied by a preconfigured factor for usage of screens plus the percentage of actions used in the application version multiplied by a preconfigured factor for usage of actions. Other parameters, such as a total amount of usage of an application, either per user or across a pool of users, may be an input into the calculation of block 312.

[0040] In an example where there are multiple versions of an application, the early adopter probability for each may be calculated in block 312 and then averaged to provide a single early adopter probability for a user. In some examples, data or early adopter probabilities from different applications for a single user may also be averaged.

[0041] In one example, a preconfigured factor for usage of new screens may be set to 0.6, and a preconfigured factor for usage of new actions may be set to 0.4. In this example, a user may have used 3 out of 4 screens in version 1.0 of an application, and 14 out of 20 actions in version 1.0. The user may have then used 1 out of 1 new screens in version 2.0 of the application, and 3 out of 4 new actions in version 2.0. An early adopter probability for version 1.0 may be calculated, in such an example, as 3/4 * 0.6 + 14/20 * 0.4, or 0.73. An early adopter probability for version 2.0 may be calculated as 1/1 * 0.6 + 3/4 * 0.4, or 0.9. [0042] In such an example, the two early adopter probabilities may then be averaged to arrive at an overall early adopter probability of 0.815 (or 81.5%) that the user will be an early adopter of a new version of the application or another application, or new features or functions in a new version. As discussed herein, the early adopter probability of 81.5% may be higher than other early adopter probabilities for other users, meaning the user with the early adopter probability of 81.5% should be in an earlier staged rollout grouping than a user or users with a lower early adopter probability.

[0043] In block 314, the early adopter probability may be output, such as to a staged rollout engine 114, and as described in block 206 of FIG.2. In some examples, the early adopter probability or staged rollout groupings may be sent to an application or“app” store responsible for distributing applications or version updates to users.

[0044] FIG.4 is a block diagram of a system to segment users for a staged application rollout, according to an example

[0045] The computing system 400 of FIG.4 may comprise a processing resource or processor 402. As used herein, a processing resource may be at least one of a central processing unit (CPU), a semiconductor-based microprocessor, a graphics processing unit (GPU), a field-programmable gate array (FPGA) configured to retrieve and execute instructions, other electronic circuitry suitable for the retrieval and execution of instructions stored on a machine-readable storage medium, or a combination thereof. Processing resource 402 may fetch, decode, and execute instructions, e.g., instructions 410, stored on memory or storage medium 404 to perform the functionalities described herein. In other examples, the functionalities of any of the instructions of storage medium 404 may be implemented in the form of electronic circuitry, in the form of executable instructions encoded on a machine-readable storage medium, or a combination thereof.

[0046] As used herein, a“machine-readable storage medium” may be any electronic, magnetic, optical, or other physical storage apparatus to contain or store information such as executable instructions, data, and the like. For example, any machine-readable storage medium described herein may be any of Random Access Memory (RAM), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disc (e.g., a compact disc, a DVD, etc.), and the like, or a combination thereof. Further, any machine-readable storage medium described herein may be non-transitory. In examples described herein, a machine-readable storage medium or media is part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The storage medium may be located either in the computing device executing the machine-readable instructions, or remote from but accessible to the computing device (e.g., via a computer network) for execution.

[0047] In some examples, instructions 410 may be part of an installation package that, when installed, may be executed by processing resource 402 to implement the functionalities described herein in relation to instructions 410. In such examples, storage medium 404 may be a portable medium, such as a CD, DVD, or flash drive, or a memory maintained by a server from which the installation package can be downloaded and installed. In other examples, instructions 410 may be part of an application, applications, or component(s) already installed on a computing device 102-106 or 108 or 112 including a processing resource. In such examples, a storage medium may include memory such as a hard drive, solid state drive, or the like.

[0048] System 400 may also include a network interface device 408, as described above, which may receive data such as data 412 - 420, e.g., via a network. System 400 may also include persistent storage and/or memory. In some examples, persistent storage may be implemented by at least one non-volatile machine-readable storage medium, as described herein, and may be memory utilized by system 400 for monitoring data, determining an early adopter probability, and/or segmenting users for staged application rollout. Memory may be implemented by at least one machine-readable storage medium, as described herein, and may be volatile storage utilized by system 400 for performing the processes as described herein, for example. Storage 404 may be separate from a memory. In some examples, a memory may temporarily store data portions while performing processing operations on them, such as calculating an early adopter probability.

[0049] The instructions in or on the memory or machine-readable storage of system 400 may comprise an application usage engine 110 and a staged rollout engine 114. In block 410, the instructions may fetch event data and usage data from a user and calculate an early adopter probability based on the event data and usage data. Event data 420 may include data such as user interface responsiveness data, network error data, and application crash data. Usage data may include data such as a number or percentage of screens used in an application version 412, a number or percentage of new actions used in an application version 414, an application version number 416, and a user ID 418.

[0050] A staged rollout grouping may be determined, and the user may be assigned to a staged rollout group based on the early adopter probability. In the example of FIG.4, the event data such as user interface responsiveness data, network error data, and application crash data may be used to augment the calculation of the early adopter probability. For example, an application associated with a user with crash data that is above an accepted average may be used to artificially weight that user lower on the early adopter probability scale.

[0051] Although the instructions of FIGS.2-4 show a specific order of performance of certain functionalities, the instructions of FIG. 4 are not limited to that order. For example, the functionalities shown in succession may be performed in a different order, may be executed concurrently or with partial concurrence, or a combination thereof. [0052] All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the elements of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or elements are mutually exclusive.