# Privacy Triage: iOS Day-7 Subscription Promo Pixels

Status: **DRAFT** — to be reviewed and submitted before ship review
Asana project task: https://app.asana.com/1/137249556945/project/1202406491309510/task/1214798984829406

---

## What pixels are being added?

Three new pixels for the day-7 existing-user promo half-sheet:

| Pixel name | When fired |
|---|---|
| `m_privacy-pro_existing_user_promotion_impression` | The day-7 promo half-sheet is displayed |
| `m_privacy-pro_existing_user_promotion_tap` | User taps the CTA ("Try It Free" / "Learn More") |
| `m_privacy-pro_existing_user_promotion_dismiss` | User dismisses the promo modal |

---

## Parameters sent with each pixel

| Parameter key | Type | Value | Description |
|---|---|---|---|
| `appVersion` | string | e.g. `7.215.0` | App version, added automatically |
| `ru` | boolean | `true` / `false` | Whether the user is a returning user (reinstall detected via variant `"ru"`) |
| `free_trial` | boolean | `true` / `false` | Whether the user is eligible for a free trial at time of display |

No user identifiers, no browsing data, no PII.

---

## Privacy Assessment

### Is any new data collected about the user?

No new data is collected from the user. The parameters (`ru`, `free_trial`) are:
- `ru` — derived from the install variant flag already stored locally; same parameter used by `m_privacy-pro_onboarding_promotion_impression` and `m_privacy-pro_skipped_onboarding_promotion_impression`
- `free_trial` — derived from App Store product availability, already evaluated at the time of display; same parameter used by the existing promo pixels above

### Does this introduce any new data collection mechanism?

No. These pixels follow the identical pattern of the pre-existing `m_privacy-pro_skipped_onboarding_promotion_*` pixels, which have already passed privacy triage.

### Is the data linked to a user or device?

No. Pixels are sent anonymously via the standard pixel infrastructure. No user ID, device ID, or ATB is included.

### What is the purpose of the data?

Measure the effectiveness of the day-7 promo half-sheet:
- **Impression** — how many eligible users see the promo
- **Tap** — conversion rate from impression to CTA click
- **Dismiss** — dismissal rate

This data will be used to evaluate whether the feature achieves the goal of 10 trial starts/day and to decide whether to keep the feature on.

### How long is the data retained?

Standard pixel retention policy applies. Pixels are not stored on device after firing.

### Are there any additional risks?

The `ru` parameter could theoretically indicate a user is a reinstaller, but:
- This information is already sent in the existing promo pixels
- It is aggregated data with no user-level linkage
- It is used only to segment promo performance by user cohort

---

## Comparison to existing approved pixels

These pixels are structurally identical to `m_privacy-pro_skipped_onboarding_promotion_*`, which were already approved. The only differences are:
1. Different pixel name (different audience segment)
2. Different origin value (`funnel_modal_ios__subscriptionnudge` vs `funnel_modal_ios__skippedonboardingupsell`)

---

## Open questions for privacy reviewer

- [ ] Is the `ru` (returning user) parameter still acceptable given no new data is collected?
- [ ] Is there any concern with the `free_trial` parameter being sent on dismiss (user never tapped CTA)?
- [ ] Are there any additional parameters the privacy team would like to see for monitoring purposes?