This RFC replaces RFC 0019 with a more cohesive policy for how to deal with analytics as the current approach needs some fine tuning and transparency.

Goal

The goal is to better understand what is going on in Pi without compromising on privacy. Today we have an assumption of the size of the user base and install base mostly as a byproduct of people visiting pi.dev and the update check and this information is good enough in many ways to have a basic overview. When pi checks for updates, we get a ping that only tells us which version of Pi is checking for data and nothing else.

We do however want to go beyond this for users who are opting in to help us answer some important questions. To give you an idea, there are various different experiments that can help us better understand how we are doing:

• Edit tool successes and failures by model
• Network errors and issues by model and provider
• Websocket connections downgraded to SSE
• SSE stream failures
• Context lengths by model
• …

Tracking this data cleanly requires a tracking ID and the consent of users. So in this RFC we want to share how we intend on doing this.

Opt-in Analytics

We want to encourage users to opt into analytics reporting in which case the following happens:

• A unique tracking identifier is stored in settings.json
• The update check sends the tracking identifier along
• We report basic analytics for experiments we care about to us for people who are opted in. These experiments are subject to change and are always shown in a new /privacy command.
• Analytics data is sent up in a small HTTP request to pi.dev as it happens.

What experiments emit analytics events will always be transparent and can be seen by users from a single file in source control with all the payloads around it.

Changing One’s Mind

Analytics shows up as a setting in /settings and can be flipped at any time.

Anonymous Request Tracking

We track information on pi.dev from regular HTTP requests. Pi currently does one request which is the update check and we use this check to get a basic view of aggregate activity. These are completely anonymous and just piggy back on top of the update check that pi runs. The only data transmitted is the user agent of the Pi agent which contains the following information:

• Current version of pi
• Current CPU architecture (x86_64 etc.)
• Current platform (macOS, Windows etc.)

We do not attach personal identifying information to such requests unless the user opts into the opt-in analytics. We are intending on applying the same basic request based analytics to model database updates in the future. For this see RFC 0039.