The schema for this data will be named ios_article_link_interaction - see initial ios_article_link_interaction Data Instrumentation T374036 doc. Schema structure will essentially match android_article_link_preview_interaction.

We will use integer values for column source and match values where possible to the Android source integer-value definitions
(description: Source screen from which the user triggered the link click and subsequent pageview e.g. "search", "feed")

See iOS Internal Link Tracking Planning Measurement Plan doc for background, requirements and more details.

@Dbrant Hi,

I wonder if I could get more detail on items 1-9 in this spreadsheet. We plan on tracking them in our next release. Are these assumptions correct?

SEARCH
Viewing an article from the Search tab results

Does this include coming from any other search bars in the app (like an Explore feed search bar?).

INTERNAL_LINK
Tapping a link from an article, to another article

EXTERNAL_LINK
Deep linking from outside the app to a particular article

HISTORY
Going to article from History tab

LANGUAGE_LINK
Going to article from Languages button on Article (i.e. choosing a different language).

RANDOM
Going to an article from the Next Random Article button on Random article.

MAIN_PAGE
We don't display a main page on iOS. A user would have to search for it (which shows it in an in-app web view), then tap an article link from the in-app web view.

NEARBY PLACES
Going to an article from the Places tab.

In T374036#10464357, @Tsevener wrote:

I wonder if I could get more detail on items 1-9 in this spreadsheet. We plan on tracking them in our next release. Are these assumptions correct?

Yes! The assumptions are correct, and here are just a few additional notes:

SEARCH
Does this include coming from any other search bars in the app (like an Explore feed search bar?).

Yes, all of the places where the user can "search" take them to the same Search interface. And any result coming from that interface results in a SEARCH source.

MAIN_PAGE
We don't display a main page on iOS. A user would have to search for it (which shows it in an in-app web view), then tap an article link from the in-app web view.

This is admittedly poorly named: This is basically when the user creates a new empty tab. The default page for a new tab is the Main Page, so this is really like a "null" source -- for lack of having any page to load, we load the Main Page.

Removing estimate since it serves as more of an epic.

Hi @Tsevener thinking about the next Navigation Refresh where we will be implementing new Search access points https://phabricator.wikimedia.org/T383827 and testing user behavior using a control group and a variant group that will have access to the new more prominent Search Bar. Clarifying how we will split data since it's relevant for article view data needed for our test.

The Search engagement events (and test group designation) will be tracked in schema ios_search - we may need to update this instrumentation after re-design, search event starts are measured by source values:

• top_of_feed
• search_tab
• article
• unknown
• places

We will use the article views by test group users using data from ios_article_link_interaction.

@SNowick_WMF ok, so maybe when we pick up T382032 we'll need distinct sources for the explore search bar, search tab search bar, article search bar (AB Test Variant), and article search button (AB Test Control)?

Hi @Tsevener I updated my comments above - we will not need to have the source values implemented in ios_article_link_interaction since that's not in scope yet, as long as we can track impression events by user we are good for the data we need. Thanks!

The associated project tag Wikipedia-iOS-App (Wikipedia iOS Release FY2025-26) got archived; please add an active project tag to this open task so it can be found on workboards, and/or update the task status. Thank you!