Contents

The webrequest datasets contain logs of all the hits to the WMF's servers (specifically, the Varnish servers). This includes requests for page HTML, images, CSS, and Javascript, as well as requests to the API. For privacy reasons, this data is purged after 90 days. We use the webrequest table and its aggregated tables for app analysis. Specifically:

mobile apps uniques: Count how many different Android and iOS Wikipedia mobile apps installs accessed Wikimedia sites during the given day or month, determined as the number of app uuids appearing in the webrequest table (via the X-Analytics header or formerly the query part of the URL).

mobile apps session metrics: Contain aggregate stats about pageview sessions on the Android and iOS Wikipedia mobile apps, updated weekly. Please note the caveats of this dataset as the metrics may not be what you expected.

Please note that starting from v5.0, webrequest data doesn't contain users' appInstallID if they choose not to send usage reports to the Wikipedia iOS app[1], regardless of whether they agree to send analytics data to Apple at the system level or not.[2] This also means that metrics based on this data may be biased towards app version older than 5.0. Please use filter accordingly.

Since the iOS app uses API for most transactions, it also makes sense to use the ApiAction data, which is logged directly from MediaWiki when it responds to API requests. The benefits of that data include:[3]

Includes internal API requests not routed through the Varnish servers

Data on API requests is not mixed in with data on regular web requests.

Contains detailed data on the content of POST API requests (they are logged in webrequests, but without the request bodies).

We use EventLogging to collect metrics about how users interact with the app. For privacy reasons, event logging data is purged after 90 days unless they are white-listed.[4] We only collect data from users who agree to share their usage report with Wikipedia app from v5.0. This means that metrics based on event logging data may be biased towards app version older than 5.0. Please use filter accordingly.

iTunes Connect provides various metrics to measure the app's performance in App Store such as impression, product page views and app units. It also provides some usage metric from users who agree to share their diagnostics and usage information with Apple, such as sessions, active devices and retention. Within iTunes Connect, App Analytics displays data from devices running iOS 8 or tvOS 9, or later, and that data is displayed only when a certain number of data points are available; Sales and Trends is recorded when a customer initiates a transaction on the App Store. There are some differences in the units reporting between App Analytics and Sales and Trends for the following reasons[5]:

App Analytics data is based on Coordinated Universal Time (UTC). By default, Sales and Trends data is shown in Coordinated Universal Time (UTC), but users can change the time zone to Pacific Standard Time (PST).

App Annie is a third party app market data provider. It is integrated with iTunes Connect and basically provides the same metrics as iTunes Connect and App Store, but with some estimation and better visualization. We've seen some discrepancies between the numbers provided by iTunes Connect and App Annie. Some can be explained by that App Annie's data is based on Pacific Time[6].

Matomo, formerly Piwik, is a free and open source web analytics application that runs on a PHP/MySQL webserver. The Wikipedia iOS app started to use Piwik to collect user interaction events since 2015. However, our Piwik server cannot handle the amount of traffic from iOS Wikipedia app and has failed several times[7]. We are planing to stop using Piwik in the future.

Among all the metrics listed below, the followings are the core metrics for the iOS Wikipedia app that WMF has been tracking on a regular basis since around 2015, reported in the Readers team's quarterly metrics meetings and (partially) in the Audiences department's monthly readers metrics update: daily pageviews, daily installs (aka. app units), 7-day retention, ratings, pageviews per session, session length and sessions per user.

The number of times (or the number of unique devices) the app was viewed in the Featured, Categories, Top Charts, and Search sections of the App Store. Includes Product Page Views. Based on devices running iOS 8 or tvOS 9, or later.

The number of times (or the number of unique devices) the app’s product page has been viewed on a device using iOS 8 or tvOS 9, or later. Includes views on the App Store and within apps that use the StoreKit API to load our app's product page.

The number of first-time purchases of the app made on the App Store on devices running iOS 8 or tvOS 9, or later. The number is based on Apple ID. For number of units including earlier platform versions and desktop, check iTunes Connect "Sales and Trends".

As mentioned before, the units reported by iTunes Connect "Sales and Trends" is different from "App Analytics" because of platform and time zone.[5] When reporting the downloads number, we should treat the downloads from desktop carefully, since they are most likely to be the result of Volume Purchase Program or other unusual behaviors[9], and does not reveal the "real" number of downloads.

About App Annie's data:

- The units reported by iTunes Connect "Sales and Trends" (when the time zone is set to PST) is equal to the sum of App Annie's downloads and promotions under the "Downloads" tab.

- The downloads reported by App Annie under the "Store Views" tab is equal to the units reported by iTunes Connect "Sales and Trends" (when the time zone is set to PST) excluding desktop units.

The total number of times the app has been installed on devices with iOS 8 or tvOS 9, or later. Re-downloads on the same device, downloads to multiple devices sharing the same Apple ID, and Family Sharing installations are included.

iTunes: The number of times the app has been used for at least two seconds on devices with iOS 8 or tvOS 9, or later. If the app is in the background and is later used again, that counts as another session.

Based on users who agree to share their diagnostics and usage information with Apple. App Annie extrapolates this metric with opt-in rate.

Mobile apps session metricsalso counts the number of sessions per user. However, this count is based on pageview timestamp and doesn't take other actions on the app into account. See the code for how it is calculated.

iTunes: The number of devices with at least one session during the day. Based on devices running iOS 8 or tvOS 9, or later. Based on users who agree to share their diagnostics and usage information with Apple. App Annie extrapolates this metric with opt-in rate.

iTunes: The number of active devices with at least one session during the previous 30 days. Based on devices running iOS 8 or tvOS 9, or later. Based on users who agree to share their diagnostics and usage information with Apple. App Annie extrapolates this metric with opt-in rate.

The total number of crashes on devices running iOS 8 or tvOS 9, or later. Get detailed crash logs and crash reports in Xcode, such as unique totals for each type of crash and how many users experienced it.

iTunes Connect

app version, device, platform version

Based on users who agree to share their diagnostics and usage information with Apple.

The percentage of users that first installed the app on a given day 0 and used it again on day 0+X. For example, if our app was first downloaded by customers on 100 devices on May 1st, and seven days later (on May 8th) 20 devices are still active with at least one session, then retention on May 8th is 20% (or 20 active devices out of 100).

Retention rate on iTunes Connect is based on users who agree to share their diagnostics and usage information with Apple; retention rate computed with MobileWikiAppDailyStats (schema implementation: T126693) is based on users who agree to share their usage data with Wikipedia app. We are investigating some related bugs (T189356, T189359) thus the retention rate computed with MobileWikiAppDailyStats should be treated carefully.

Currently, session length is calculated as the difference between the first and last pageview timestamp in a session.

mobile apps session metrics

Based on users who agree to share their usage data with Wikipedia app and with at least two pageviews. This session length should be less than or equal to the actual session length on the client side.

Useful ratio:

Daily Active Devices / 30 Day Active Devices: The ratio of Daily Active Devices to 30 Day (roughly monthly) Active Devices displays an engagement level of the active user base . This ratio reveals how much of our monthly active user base checks in on a daily basis.

Sessions per Active Device: The ratio of Daily Sessions to Daily Active Devices is used to understand the number of sessions an average active device launches each day. We also reported sessions per user in mobile apps session metrics. However, it is based on users who have at least one pageviews (thus the count -- the number of users -- is less than the number reported by mobile_apps_uniques), and a session is defined as a sequence of pageviews from the same app ID that does not exceed 30 minutes of inactivity.

Pageviews per session: Reported in mobile apps session metrics. This is based on users who have at least one pageviews and a session is defined as a sequence of pageviews from the same app ID that does not exceed 30 minutes of inactivity.