I would like to ask if its possible to create and preserve a dataset preserving the accidental experiment that happened around the deployment of the carousel, and around the deployment of lazy loading in August.

I would be happy to execute these queries myself, given the necessary access. However, I am very well aware that within a few days some of the data will likely start to expire.

Windows

• 2026-06-10 -- 2026-07-05 : the mobile image carousel, plus a clean baseline either side
• 2026-08-01 - 2026-08-31 : the desktop native lazy-loading rollout (staggered across wikis)

What

Ideally I would first like to ask to create an extracted table with just counts. I can do the aggregation myself then. This would allow for some misunderstanding of the data format on my side. After that I would like to verify some format issues before aggregating it further.

• requests: hour x project x file x access_method x agent_type x referer_class x country x page
• pageviews: hour x project x access_method x agent_type x country x page

Scope: all wikipedias. Can if needed be limited to articles meeting the criteria of carousel (3 or more images, main namespace) . Country would be great, but I will only use the bigger countries for my study (can provide a list).

Page x Image: From what I understand these combinations of page and image can only be created by first defining sessions. According to that definition, I would like to group the requests with their relevant pageview from the same session.

Too granular? If this is considered too granular, I am happy to discuss how we can make it less granular while still being equally useful. For example, I could imagine aggregating one table at a daily level and one table at an hourly level. If necessary, I'm also happy to work with research to find an appropriate aggregation level for publication and that preserves privacy.

Why?

Mobile users have already experienced lazy loading since 2016. They also receive their articles nowadays with the sections folded up The consequence of that is that The their images do not load until they actually open up a section with the exception of the introduction section (section 0).

This briefly changed during the deployment of the carousel in June between 24 June 07:01 and 25 June 21:15 UTC ( gerrit 1305329 / 1305741 ). At that point for a set of articles, images were being displayed ahead of all the text. The carousel was using the same image without double loading and relied on the browser native lazy loading ( T430897 ). This changed which images were being loaded for which users. After all, the images being loaded at the top were deterministic and included sometimes images that were in a section that normally would not load until you would open that section. As a proof of concept, I'm uploading a graph with 93 pairs of images that only were included on a single English Wikipedia article, With one of the images in the top section, and one of the images subsequently in one of the next sections. As you can see, the file request ratio between those images dramatically changes during the carousel deployment.

If we take the difference between the situation before the carousel and during the carousel, we can estimate for each article how many people are viewing each section with an image in it. Unfortunately with public data, I am very limited in how I can do this analysis because the image requests are not available in de-aggregated form per article. For a research project that I'm performing in a private capacity, trying to understand which readers are still left, once we have lost a lot of our readership, this would be very valuable. I would like to do the same thing around the rollout of lazy loading for desktop in August.